DHCP option 002 for Lync phones

Maybe I have been living under a rock… but I have been doing this manually… finally found a nifty chart so I can stick it in OneNote instead of having to figure it out each time – complete with instructions on how to calculate manually.  I take no credit, this is blatantly cut from a Cisco website source.

Standard Pacific time is GMT -8. This is a simpler way to calculate GMT with negative values:

1. The number of seconds equivalent to - 8 hours = - 8 hours * (3600 seconds / hr) = - 28800 seconds.

2. With a scientific calculator, enter the number -28800 in the calculator with decimal values. The (-) sign is very important. In order to get the negative sign in front, press the +/- key.

3. Choose Hex. This gives you FFFFFFFFFFFF8F80. This is because, by default, the calculator has Qword enabled.

4. In order to get rid of the extra Fs, choose Dword. This produces the value FFFF8F80. If you do not have this option in your calculator, use only the first eight digits from right to left.

5. The value placed in the DHCP pool configuration now becomes option 2 hex FFFF.8F80.

 

Table of Conversion of Different Offset Times into Hexadecimal

This table gives the conversion of the different time zones around the world. The hexadecimal values are set to have a fixed length of 32 bits as specified in Option 2 of the DHCP RFC 2132. For a world timezone map, refer to World Time Zone Map.

GMT offset (in hr)	GMT offset in seconds	GMT offset in Hexadecimal
0	0	0000.0000
+1	3600	0000.0E10
+2	7200	0000.1C20
+3	10800	0000.2A30
+4	14400	0000.3840
+5	18000	0000.4650
+6	21600	0000.5460
+7	25200	0000.6270
+8	28800	0000.7080
+9	32400	0000.7E90
+10	36000	0000.8CA0
+11	39600	0000.9AB0
+12	43200	0000.A8CD
-1	-3600	FFFF.F1F0
-2	-7200	FFFF.E3E0
-3	-10800	FFFF.D5D0
-4	-14400	FFFF.C7CD
-5	-18000	FFFF.B9B0
-6	-21600	FFFF.ABA0
-7	-25200	FFFF.9D90
-8	-28800	FFFF.8F80
-9	-32400	FFFF.8170
-10	-36000	FFFF.7360
-11	-39600	FFFF.6550

Example

Pacific Time Zone = GMT –8

60*60*8 = 28800.  Change sign. Now we have –28800.

Click the Hex button.  Now we have

Click the DWord button.  Now we have

Here is the value in the DHCP Server Options. Note that we take the DWord value and append “0x” to it.

YMMV

AudioCodes 420HD Lync Phone Device Review

 

Initial Impressions

Great packaging; Clever base construction – not rickety, solid connection to base with a good angle sitting on the desk; Construction seems to be top notch – typical AudioCodes quality.  Cabling connection locations don’t get in each other’s way.  Switch ports for workstation/laptop pass-through well marked; the setup documentation (420HD IP Phone Quick Guide - included in the box) matches the actual contents of the box – something that seems to be lost on other vendors.

The phone needs to have power before the built-in switch works. Plugging the 420HD into my network between my switch and my laptop, but with no power, resulted in my laptop coming up on the local WAP (as it should).  Maybe I am making too much of this. If you have PoE, this is probably a moot issue.  But for those of us without the fancy-schmancy switches in the network and are using the power adapter, this may be a environment item to consider.  For what it is worth, this phone is firmware version 2.0.1.44.21.

Built in support for Lync

Take a gander at the deployment guide…pages 9-11 outline what is needed on the Lync side.  Trusting that my corporate peers had configured things correctly, I chose the “Sign in” option, and the phone simply queried me for login name, network user name, password, and in I went.  Very nice.  Assuming that the Lync environment is setup properly, this phone will just work.  Noted also is that I am in Portland, Oregon, and the server I connect to is in Chicago, Illinois.  This means that I am a completely remote user, and I unboxed this unit, did the setup and connected with no need for corporate IT to be involved.  SWEET!    I was up and using the phone with great results with Lync in a very short time frame.

Volume control and volume itself was very good.  Great audio quality. Clear, with good voice tone. The phone does not sound tinny or cheap at all.  It sounds very robust. Single button for voice mail.  Nice. As noted below, if the power fails and the phone drops off line, when the power comes back you auto-sign-in.  If you sign out, then you must enter domain credentials.  So, I see this as a positive – but an item for user training if you want to avoid help desk calls.

You can use this phone to sign in with a UPN and password, or you can use an extension number and PIN.  Again, see the referenced pages of the deployment guide. 

Usability

The 10 key + softkey choosing-which-buttons-to-use routine was less than optimal.  However, I read absolutely zero documentation and still had it working in a very short time frame.  Buried on page 13 of the deployment guide (see below) is what you need to know to help out your co-workers.  In my case, the “…and 1 for the special characters @ and .(dot)” – I figured it out, but it would be nice if that was in the USER MANUAL (see below).

Oh wait.  I just found this on page 21 of the User Manual…

I guess I should start reading manuals again, eh wot?  In my defense, I don’t find this to be very clear.  Or maybe this type of stuff should be in the first few pages where a typical user might look.  Yes, I know, I am defending myself to some degree, but still…

Link to user documentation LTRT-11881 420HD IP Phone User's Manual Ver. 2.0.2

Link to Lync 420HD deployment guide LTRT-21920 AudioCodes 420HD Lync-Compatible IP Phone Deployment Guide.pdf

Issues

Searching the corporate directory

Having to type names in with the 10 key+softkey routine (as mentioned above) was a tad tedious.  After consulting with my friendly AudioCodes support engineer, it would seem that there is “something” not quite right, because according to the documentation, I should be able to enter a single letter – J for instance, and have the phone return all matches in the corporate directory that start with “J.” – We are looking into this and I will update as a resolution is found.

Device Passwords

The default admin password ‘1234’ did not work.  It seems that when the phone logs into the Lync environment, the user’s domain account and password take effect.  So, in my case, I had to use “John” and my domain password to get it to work.  Note that I did not include the full UPN, and not the NETBIOS format of domain\user; just username.  Odd.  How does that equate to an administrative login?  I ask this because the phone is logged in with my creds, and at that point a regular admin cannot access the phone’s web interface using the admin user and password.  And while I am noting that, pulling the power off the phone results in a dead phone (duh) but when the phone gets power again, it logged back in as me.  Without asking any questions.  It just logged in.  I can see where that might represent a security issue to some folks.  If anyone in AudioCodes-land reads this and can correct me on that supposition, I will gladly update this article.

D’oh! category

After some poking around, I “discovered” that if you sign out of the phone – THEN the default user name and password works  -  ‘admin’ with “1234’ – if you are signed into the phone, the only login that works is your user name and your domain password – and then all you get is the “user” subset of the web interface – none of the administrator level functions are exposed.  I don’t think I would be telling users that the web interface even exists, let alone telling them how to get into it, but that might be just me.

BTW, the user and admin logins can be changed…...

While I am using the device with Lync, here is the “OOB” support – it would seem that AudioCodes would like to have a larger market than just Lync.

Nit Pick

The web interface was clearly designed by someone using a large display.  It does not resize.  On my laptop with a 1920x1080 resolution, if I did not have the web interface full screen I had to scroll around in it to see important things like the “Submit” button.  Is it too much to expect to have a developer allow for dynamic resize?  This comment is not directed just at AudioCodes, but at others also.  You know who you are.  Not everyone has a 32 inch plasma for their primary display.

Checking out the internal dial plan on the phone

^(\d{11})$=+$1;^(\d{10})$=+1$1;^(1\d{10})$=+$1;^([2-9]\d{9})$=+1$1;^9(1[2-9]\d{9})$=+$1;^9([2-9]\d{9})$=+1$1;REDACTED AT THIS POINT to protect internal data.

That is a serious Regex one-liner!  Before I redacted, the phones’ internal dial plan went a good 15 lines down the page – all one string.  We could all be learning something from this.  I see phone strings in there that would indicate that this regex is being picked up from Lync.  Based on my understanding of how Lync clients work, this is how it should be.  In testing, dialing 5 digits and then waiting for the time out resulted in the phone dialing a correct number.  Nice.  In the stupid tricks bracket, I could call myself.  Entering my extension resulted in my Lync client toasting, my mobile getting the simulring, and when I ended the call, my Outlook getting a missed call notification.

Overall impression

Usability

Total setup time from looking at the box, to setting up the phone on the desk, to login and being connected to the office was less than 30 minutes.  I did nothing to my network, I did nothing to my account (I was already EV enabled).  I am a total remote/external user, so I pretty much expected this phone to work, and it did.  Mission accomplished. 

Quality

Quality is typical AudioCodes.  Solid feel, buttons are clearly marked and press cleanly, ports are labeled, while the audio quality and volume are excellent. I think that this is a clear winner

Lync Functionality

Works out of the box with no fiddling with the phone.  ‘Nuff said there.  I like it.

You can get your very own AudioCodes 420HD right here.

YMMV

Exchange 2007 mailbox users Lync EWS

 

Scenario

During the transition to Exchange 2013 from Exchange 2007, Exchange Web Services (EWS) integration for Lync will be unavailable for users whose mailboxes remain on Exchange 2007. 

 

The Bad News

Jeremy Silber has an excellent blog article on this issue.  It bears reading if you fit the above scenario.  Jeremy shows in extremely clear detail what is going on, and why. Unfortunately, he also shows that there is no fix.  Here is the article:

http://silbers.net/blog/2013/12/19/lync-ews-broken-during-exchange-20132007-transition/

YMMV

Ex-OCS2007R2 user unable to login to Lync 2013

The Scenario

A recent project was an OCS2007R2 migration to Lync 2013.  The environment had two central sites.  At the main central site, “somebody” had already installed Lync 2010, migrated most of the users, while the other central site was still R2.  Users had moved between pools in both directions.  Edge services were supplied by the Lync 2010 pool.  Users were homed on a variety of OU’s.  The CSAdministrator and RTCUniversalServerAdmins groups were not domain admin enabled.  The Lync 2013 environment was also two central sites.  Users from each site moved to their respective 2013 pool.

Everything went pretty well until we went to move users.  All the users eventually moved, but due to a really hosed up Active Directory, we had “issues.”  After the user move, the R2 components were decommissioned as were the Lync 2010 components.  THEN we discovered that a small subset (about 200 users) of the total user population could not login.  These users were all coming from domain-joined machines.  We tried disabling the users from Lync, waiting for 24 hours, then enabling from scratch. Still had issues.  Move the user to the other pool?  Nope.  Still no good.  Different workstation?  No.  Login from mobile works maybe?  Not a chance.  The various Lync clients simply said the user account information was no good.  Over and over.  Not a certificate issue, it was behaving like the username or password was fat-fingered.  But the user was already had a valid login to the domain. Grrr. Worse yet, Lync 2010 or and R2 client would login. Around in circles we went.

To be very clear, this was NOT an AD issue, this was an issue with SOME users that moved from an OCS 2007 R2 pool or a Lync 2010 pool to a new Lync 2013 pool.

At which point we decided to nuke the users from the database.

The Fix

Before you go much further – this is a one way procedure.  When you get to step 4, there is no getting it back without going all the way through.  So, you might want to consider if you have exhausted all your options before you take this route.  There is also a slight chance of thoroughly borking up the RTC database when you do this.

  Proceed at YOUR OWN RISK 

You may want to verify that your environment is replicating properly before you go much further, because we are going to force the issue down in step 3.  Get a PowerShell window open and run “get-CsManagementStoreReplicationStatus” and be checking for all servers showing TRUE.  If not, then you may want to fix that first.  You do check for this on a semi-regular basis don’t you?

OK. 7 steps to success.  Here we go

Let’s assume this user is totally unable to login to Lync 2013, even though EVERYTHING looks like it should work, and credentials work just fine in the domain for everything else.

Step 1 - Export user data

Execute this either on a remote PowerShell or on a Lync PowerShell on the server itself.  This will save contacts, but not meeting/conference information.

Export-CSUserData –poolfqdn poolfqdn –userfilter “username@domain.com” –filename “whereyouwantthefiletogo”

Like so:

Step 2 - Remove the user from Lync Server

You can do this from the control panel, or get fancy and one-line it from PowerShell.  Here is the Control Panel method:

Step 3 - Invoke replication and wait for replication status to show true. 

Let’s hope your replication process is good, eh? - Invoke-CSManagementStoreReplication, wait a bit, then get-CsManagementStoreReplicationStatus

Step 4 - Clear out the entry of user object from the Front End server local database

We used the SQL Management Studio for this. If all you have is an Standard Edition (SE) or two, then you will have to either be a SQL wizard, or go install the SQL Management Studio somewhere.  I have an Enterprise (EE) pool, so I have a SQL Backend with the Management Studio. If you have an EE pool, then you need to do this on all pool FE servers BEFORE moving to step 5.

Open SQL Management Studio. Once you have that open, connect to each FE server RTCLocal database instance in question.  In this case, we have two EE pool servers, so we connected to both, each to the RTCLocal instance.

 

Now, open up the individual instance, select the ‘rtc’ database…

Now, select “New Query” from the tool bar…

…and you should have something that looks like this – importantly, the database little indicator window thingy should have lit up…notice you have a new tool bar that sprang into being when the mighty admin-mage invoked the Query…

From here, in the SQLQuery pane, we want to enter the following – and this is CASE SENSITIVE…

execute dbo.RtcDeleteResource ‘username@domain.com’

Here is my example.  Note that the user name is SPECIFIC and it has SINGLE quotes and it was the SIP ADDRESS not the SAMAccountName or UPN or NetBios format.  SIP ADDRESS!  Oh, did I mention the stored procedure is CASE SENSITIVE?

 

When you get that EXACTLY right, click on the “Execute” button as indicated.  Should you have done all of this correctly, you will see this:

Now, what does it say on the shampoo bottle?  Lather, rinse, and repeat as necessary.  If you have 10 users that are borked, then do all 10.  And make sure the process is run against all applicable pool servers.  If you have 4 EE servers, then you must do this for each user on each server. 

Step 5 - Enable user

You don’t need me to illustrate this do you? Use either PowerShell or Control Panel and enable the user that you just got done (hopefully) nuking from the system.

Step 6 - Import the user data from the backup file

Import-CsUserData –poolfqdn poolfqdn –UserFilter "username@domain.com” –filename “sourcefile”

Like so:

Step 7 - Restart the FE service

I use a cmd line window.  “net stop rtcsrv && net start rtcsrv” but you can get a services.msc window open and do restart from there…takes about 3 minutes or less to restart – any user on the server when you do this will get dropped with no warning.

On the nice side, when the server comes back, they should sign back in automatically.  If you did the rest of your work correctly (read DNSLB), they might have already signed in to another pool member.  Just to get dropped again when you restart the RtcSrv on the other pool members.  Maybe you should do this after hours.

Summary

We stipulated some users that could not login, even when we KNEW the domain credentials were good.  With all hope for world peace exhausted, we proceeded through a seven-step process that nukes the user from the system, resets the system, and in theory gives you a new user, with their old contacts (but not their conference information).

YMMV

Lync 2013 RGS drop to Exchange AutoAttendant

The Scenario

As part of a greenfield Lync 2013 deployment, the client requested to have a Response Group Service (RGS) workflow answer a phone call, offer various options, one of which was to redirect out to the company directory – in this case, Exchange 2013.  We got the first parts done without issues, but the “redirect out to the company directory” part just killed us.  No matter what we did, we either got nowhere, or the call would just drop.  Not good.

After some searching, I found bits and pieces that enabled a Lync 2013 Response Group (interactive) to have an option to drop to the company directory. In theory, this should have been pretty easy.  Fellow MVP Brian Ricks has a write up that will get us started.  Then take a look at this TechNet forum thread. Parts here, parts there.  Put enough together, and we have a solution.

The Solution

Assuming you already have the Exchange Auto Attendant setup in Lync as a contact object with a valid DID, The overall flow is: you need a user, a group, a queue, and then the workflow with the queue as the selection.  The queue must have a group which must have a member, although the user will never login and the queue will never get to the point of trying to contact the group because we are going to set the queue to go straight to the AA.  The group, the queue, and the workflow all need to be homed on the same application server (pool).  RGS is specific to a pool.

Create a RGS Group with at least one member – I used a dummy account enabled for EV but with no DID.  It won’t matter too much, as you will see in a bit, the group member will never be used.  But, you need to have a group with a member.

Dummy user

RGS group

Now that we have an RGS group and with our dummy user, we need to create an RGS queue that has that group as the target.

Create a Queue.

Now, set the queue as follows:

Note that the queue “enable time out” is unchecked.  We did enable the “queue overflow” with a maximum call count of ZERO.  This results in a queue that immediately takes the call action of “forward to SIP address” which in our case is the Exchange UM AA contact object “ExUMAA” – this is why the dummy user is not used – the queue gets no farther than this action.

Create the workflow – for our purpose, we had an interactive with several choices, one of which was to drop out to the company directory (read Exchange Auto Attendant).

If you have multiple pools, make sure you select the same pool as the group and queue. When the website opens, in the “Create a New Workflow” you can select either – we are using the interactive selection.

Make sure that you know what the SIP address of the group is that will receive the calls.This is important to the functioning of the RGS workflow as a whole, but unimportant to our little slice of functionality.  We will however, be using this SIP address in a bit.  This SIP address will exist as a CsApplicationEndpoint – and will not exist until you create it with the process of creating the workflow.  You will also need a valid DiD (if you want this to be accessible from PSTN) or extension (if this is an internal only thing).  Either way, the TEL is entered as E.164. (+11234567890 format).

Glossing over the configuration of the rest of the RGS workflow, let’s move onto the selection process for the interaction we want.  If you are interested in learning RGS creation, here is the official guidance.

Here is the relevant section of the workflow creation.  We used “Response 3” – but it could be on any of the four available.

Notice that the queue selected is the one we created, with the group and the dummy user that will never get used.

The logic is this:  The caller lands on the RGS, and if they select option 3, the RGS looks into the workflow and redirects the caller to the queue.  But the queue is set to zero calls and redirects to the SIP of the Exchange AA.  Wala!

Assign the workflow SIP to the Dial Plan. 

But, at this point, the entire construction still won’t work.  We need ONE more item – we need the RGS to be able to talk to Exchange.  To accomplish this, we need to assign the CSApplicationEndPoint (from above) to a user voice policy that belongs to the dial plan that is being used with Exchange.  This authorizes the RGS to communicate with Exchange.  To do this, open the Lync Management Shell. Once you get there, this is the command string you are looking for:

Get-CsApplicationEndpoint sip:<RGS_SIP_Address>| Grant-CsVoicePolicy -PolicyName <VOICE_POLICY_NAME>

Happy RGS’ing to you!

Summary

To allow a Lync RGS to redirect to an Exchange Auto Attendant, we created a dummy user, added that user to an RGS group, create a queue with our group as the member; the queue was configured to immediately forward to a SIP address; then we created an interactive RGS workflow with one of options set to redirect to our queue with the group and the dummy user.  Finally, we granted the SIP URI of the RGS workflow a user level voice policy to connect the RGS workflow to the Dial Plan.

YMMV

Logitech Mobile Speaker Phone (device review)

The fine folks at Logitech sent me a new toy!  And it is not even Christmas (yet).  Obviously, I am stoked.  You can check out the Logitech market-speak right here. As an “Optimized for Lync” – AND with a Skype label – I am interested in seeing how well it does.

What comes in the box

The standard stuff comes in the box.  The unit itself, a wall charger, and the one non-standard piece:  the doohickey that shims the mobile device slot for different sizes (Clunky at best).  Perhaps I have fat fingers or something, but I had a somewhat difficult time getting the little thingy installed, and when I went to turn it around (cuz I chose the wrong direction) I had to use a tool (a handy scissors) to pry it back out and then futz with it to get it back in.

The Good

Charging time was pretty good, it did not take too long and I was up and running.  So here is the good part.   Performance on Lync was excellent.  Plug it in to the nearest USB port (my hub in this case) and it was working. Sound quality is really good, volume control seemed to fill the room, and the unit seems very solid.

The not-so-good

My iPhone is not NFC capable (apparently no Apple mobile product will do NFC)(and no, I did not do extensive research).  So that feature is moot to me. And then I could not figure out how to (easily)(interpret this as John does not read the docs, but expects to be able to figure it out with minimal hassle) pair the device with my iPhone 4s.  Again, maybe it is just me, but I found that having the power button, the BT pair button, and the charge indicator around to the side/bottom of the unit to be…inconvenient. 

Why not have those buttons up top where I can see them right off?  And while we are at it, why is the power button a pushy-thing?  Hold it?  For how long?  Gimme a slide button for power on/off.  So I KNOW it is done.  With the P710e, playing with the power button invokes a color show as the indicator lights on the front go blue and red and run in circles.  Pretty, but unless you speak Logitech, fairly confusing.  The exact same LED’s turn green and light up to indicate volume setting while in a call…but are blank until you are actually IN a call. And even then, my experiment only had them flash at me while I adjusted the volume, and then they went dark again.  OTOH, volume for the call was excellent, and audio quality was also excellent.

BUT!  With my iPhone in the slot, you cannot hit the home button.  So, to test Pandora audio quality, I had to pickup the phone, change things, then put it back down.  At which point I stopped using the handy cradle thing. 

But, the audio quality, while not up to Infinity Studio Monitor standards, was beyond pretty good for a speaker phone.  Certainly capable of filling a small room.

While I am complaining, I also found the buttons for controlling the call start, end, volume and mute to be just a bit too touch sensitive.  Just brushing your finger over the button invokes whatever the button does.  Maybe I just need to be more aware of my surroundings or possibly move the unit to a new location?  But wait, from my hub to where I want to put the unit exceeds the length of the USB cable.

Back to the Good

BlueTooth on my laptop seemed perfectly happy pairing with the P710e.  I only had to do the infamous PnP shuffle twice before it worked.  Not too bad.  I then noticed that my laptop seemed to think the the P710e might have a display.  So I disabled that. 

And at that point, I have replaced the oh-so-high-quality Lenovo built-in speakers and microphone with the P710e.  And it sounds very nice.  I like it.

Battery life is ridiculous!  It reminds me of the stupid bunny.

Lync and Skype performance was on-par with anything else I have used.  Simple setup, works well, and ignoring my fat fingers and lack of brain cells, functions as advertised.  Another solid Logitech product.  You can get one right here.

YMMV