Auto Answer on Polycom VVX phones

•2015/02/20 • Leave a Comment

An admin at one of the sites I help support asked me the other day if there is a way to have a Polycom handset automatically answer a call. I was initially confused as to what he meant. I thought maybe he meant forwarding the call to an AutoAttendant or another extension. (There is a language barrier here too so something may have gotten lost in translation.)

Because seriously: What is the point to have a handset auto answer a call? The person calling the phone will just talk to no one?

Well that is exactly the point. Essentially, this is a “budget” paging function which is what the admin at the remote site wanted to know.

I did some digging and the Polycom VVX phones support this feature natively. I won’t go into the details on how to set this up as you can read this document for the full details. (Skip to page 21)

I have successfully tested this on the VVX 310 and the VVX 500. You call the number assigned to the handset, the phone answers, and any rubbish you say comes out of the speaker on the phone.

If you are interested in a proper paging solution with groups and fancy features using the VVX phones, then check out this article on Anthony Caragol’s Lync/Skype Blog

Deep Dive into the Set-CsPinSendCAWelcomeMail Cmdlet

•2015/02/18 • 3 Comments

mr-mrs-atm-pinWe are rolling out a big dial-in conferencing project. As a good percentage of our users are not yet enabled for Enterprise Voice we are doing a lot of discussing and testing about how to get those users their PIN numbers.

Without a LineURI defined, setting a PIN can be a challenge. Check these articles for more detail: LyncBuilder or ExpertsExchange We have 2 options that we can think of:

1.) We could rip their defined phone number out of AD and assign that as their LineURI. Then they can go to the dialin page and set their own PIN. The problem here is that there is no guarantee that the number in AD is accurate, valid, and/or properly formatted. Even with EV disabled on an account, as soon as you set LineURI you can right click on a non-EV user and a pop out becomes available to call their work number. This should work fine but again, who knows if AD is accurate, has a valid number defined, and has that number in e.164 format.  Plus this could add some confusion when we do get around to EV enabling the user. Since they already have a lineURI, do we overwrite it? Probably, but….confusion.

2. Assign a random PIN to those users and e-mail it to them. Fortunately, there is a poorly documented Lync PowerShell command that actually does this: Set-CsPinSendCAWelcomeMail. This cmdlet is so neglected it doesn’t even get a proper Technet page like every other cmdlet does. Fortunately, it’s a fairly self explanatory cmdlet. In it’s shortest form, you can generate a random PIN for a user and then send them an e-mail with that PIN using the following syntax:

Set-CsPinSendCAWelcomeMail -UserURI -from -smtpserver

The UserURI is the user’s sip address without the “sip:” part. The Set-CsPinSendCAWelcomeMail does a few lookups to find a Lync user that matches this address. Note that if you just use the SamAccountName (cdiaz) or provide a SIP address ( that the cmdlet will be unable to send the e-mail. (I learned this the hard way!). I haven’t tested to see what happens if the e-mail address does not match the users SIP address but I bet the -UserEmailAddress parameter comes in handy in this case.

The -from field is the usual from field used in e-mail. Set this to an administrative account so when people receive the e-mail it will look “official” instead of coming from some doofus like me. Finally you provide the name of the mail server through which to send the e-mail with the -smtpserver parameter. So far so simple. And I bet you can figure out most of the other parameters pretty easily.

The one that took me some time to figure out is the “-TemplatePath” parameter. What this parameter does is let you pick an alternate e-mail message template than the default one that ships with Lync.

Oh, there is a default one?

This is what the default e-mail looks like. I don’t particularly like the verbiage on the first line because I think it’s wrong. Just because you have a PIN doesn’t mean you can suddenly join conferences. You can join conferences without a PIN.   PIN Default welcome Check out this folder on your Lync server: C:\Program Files\Common Files\Microsoft Lync Server 2013\Modules\Lync

Inside there is a file called “CAWelcomeEmailTemplate.html”. Open it in Notepad or some other text/HTML editor and take a look. It’s all just basic HTML but I do want to point out that there are 2 variables in this file. If you want to create your own custom templates, you might need to use these:

%URL% – This is the URL to your dial in Simple URL

%PIN% – This is the PIN that was set by the cmdlet

If you only want to make a minor change, feel free to back up the original CAWelcomeEmailTemplate and then edit that one directly. Note that this directory has the annoying security set on it so you need to open your editor as Administrator in order to save back your changes. Also keep in mind that if you have multiple front ends, you’ll have to copy this edited default file to each one of your servers. And then don’t forget to do it when bringing up a new Front End in the future.

After editing the file, I ran Set-CsPinSendCAWelcomeMail again and this is the new message: PIN Edited default welcomeNow if you want to have a separate template, or want to leave the default template alone, you need to use the -TemplatePath parameter. You can’t just copy your changed template into the C:\Program Files\Common Files\Microsoft Lync Server 2013\Modules\Lync directory and just provide the name of your new template. That would be easy. No, you have to provide a full path  (or have the file sitting in your local home folder (i.e. %userprofilee% directory)). I suppose there is an advantage to this. Instead of having to copy a file to every front end, you only need to keep it in one location. Anyway, here is the command from above but this tme run with the -TemplatePath parameter:

Set-CsPinSendCAWelcomeMail -UserURI -from -smtpserver "c:\temp\MyWelcomeTemplate.html"

When running it, you get something like the following: PIN Edited default welcome PathI hope you read that whole e-mail. Paritally because any reference to The Hitchhikers Guide to the Galaxy ought to be read, but mostly for the last few words: “Your PIN has not been changed”. If a user already has a PIN, then this command will not change it. How to tell if a user already has a PIN? Run Get-CsClientPinInfo -identity <user>. 

So what can you do if you want to use this command but also want to change the PIN no matter what? You can append the -force switch to the command. So running this bad boy produces the output below:

Set-CsPinSendCAWelcomeMail -UserURI -from -smtpserver &quot;c:\temp\MyWelcomeTemplate.html&quot; -force

PIN Edited default welcome Path force Check out the very bottom and you can see that a random PIN was generated.

If you run this cmdlet, doesn’t it seem more like a script than just a cmdlet? That’s because it is a script. If you look in the C:\Program Files\Common Files\Microsoft Lync Server 2013\Modules\Lync directory, there is a file called SetCsPinSendCAWelcomeMail.ps1. This is the script that actually does all the magic. It’s a really straightforward script. I’m not sure what you might want to edit in it except perhaps defining your own variables like %PIN% and %URL% that you want to add yourself.

There may be one reason that you actually do want to edit this script and that is because the verbose mode is “broken”. Lync MVP Pat Richard even opened an IdeaScale entry for this “feature”. Hacking this file will provide a workaround until Microsoft decides to update this file.

Open the file and remove every occurrence of “-Verbose:$Verbose”.  According to TechNet, -verbose “displays any verbose messages, regardless of the value of the $VerbosePreference variable.” And by default, $VerbosePreference is set to “SilentlyContinue” which means “don’t show verbose messages”.

So Microsoft – I provided the fix. Can you implement it please?

Lync Regions and assigning Dial-In Conference Numbers

•2015/02/12 • 2 Comments

RegionsI consider myself really sharp at Lync. However there are still times when I have “duh” moments that I feel like I should have known for years. Since Lync is a pretty complex and varied system there are just some things I never sat down and properly figured out. Dial-In conferencing Regions is one of them. I’ve probably set up dozens of dial-in conferencing numbers over the past few years but there were still a few things I just missed. This article will do a fairly deep dive into Regions and Dial-in Conferencing numbers.

So first off: What is a Region? A Region is anything you want it to be. It’s just some text. A region is independent of an Active Directory site or a Subnet or anything similar. A Region could be “Earth”. A Region could be “Germany”. A Region could be “My bedroom in the basement of mom’s house”. In practicality, a Region is used to define where a dial-in conferencing phone number resides. So if I have a dial in number in Indianapolis and one in Stockholm, the regions could be”Indianapolis” and “Stockholm” or they could be “United States” and “Sweden” or they could be “North America” and “Europe”. The Regions are just a way to let people know where the dial-in conferencing phone number is located.

None of this should be too mind blowing.

So where do you configure these region names? If you answer: “In the same place where you configured the dial-in conferencing number” then you would be wrong. You actually configure them in Dial Plans. There is a reason for this that I will get to later.

In order to set a region, open any dial plan and in the “Dial-in Conferencing Region” box, type in anything you want. In the example below, I entered United States. Also note that this is being set on the “Global” dial plan.

Global_RegionIf we want to see our existing dial-in conferencing Regions, you can run this PowerShell command:

Get-CsDialPlan | Select-Object DialInConferencingRegion

If I run that command I see the following:


OK this is great. I have a region. Now how do I assign it to a Dial-In Conference number?

Assuming you don’t have one yet, let me show you quickly how to create a dial-in conferencing number. In Lync Control Panel, navigate to the “Conferencing” section and then the “Dial-in Access Number” tab. Click “New”


Look at the above image. The “Display Number” can be anything you want. It can be in any format you want. In this case I formatted it to the standard way phone numbers in the North America Numbering Plan tend to be formatted. The Display Name field is really a comment for you the administrator so you know why this number was added. Line URI must be the exact, normalized phone number that Lync will use to answer the call. This number needs to be exactly right. The SIP URI can be anything you want. I often make it match the Line URI but you can use anything you want. The Pool is used to tell Lync which of your Lync pools will receive the inbound call. Finally you can select a Primary language and up to four secondary languages for this dial-in access number.

And where do we define the Region? All the way down at the bottom. I have to scroll down so you can see it.


After clicking the Add button you are given a list in which to select your region. In this case, we only have one available region.


Once you select that region, you are returned to the main page for adding a Dial-In Access number. Click “Commit” and you now have a Dial-In Access number.

For those excited by PowerShell, you can perform all of the above using the following PowerShell commands:

Set-CsDialPlan -Identity "Global" -DialInConferencingRegion "United States"
New-CsDialInConferencingAccessNumber -PrimaryUri "" -DisplayNumber "(317) 555-1212" -DisplayName "Indianapolis" -LineUri "tel:+13175551212" -Pool -PrimaryLanguage "en-US" -Regions "United States"

So how can we see what this now looks like? Point a web browser to your dial-in simple URL. In my case, that is and I see the following:



If you don’t know your dial-in Simple URL, you can run the following PowerShell command:


Now more has happened here beyond just having created a new dial in number for the United States.

[Here is the part I never really knew until this week…]

What I have also done is assigned a default dial-in number for all of my users. This may seem obvious but it really isn’t (at least to my thick Hoosier skull (or I guess my now Nashvillian skull)). The reason that all of my users now have a default dial in number is because I assigned the Region to the Global dial plan. I currently only have one dial plan so everyone gets this dial plan by default. Since the dial plan controls the region, all of my users are now considered to be in the United States region.

So what happens if I create a new dial plan. Does the global Region still define the Region for users assigned to a user-level (or site-level) dial plan? Let me create a user level dial plan without a region and see what happens.

Testing this gets a little tricky because we can’t just go to the dial-in simple URL because that just shows a list of all the defined numbers, not the default number for a given user. Since I created a user-level dial plan, I had to assign that dial plan to a specific user. In order for them to see what their dial-in Region is, they need to create an Outlook meeting and then use the Lync Meeting calendar add-in (alternately, a “Meet Now” meeting directly from the Lync client).

Doing all of those steps, I see that the Global dial-in Region applies if the user-level dial plan has no Region defined.


So it’s probably a good idea to set a default Region in your Global dial plan. Unless you don’t want everyone to have a default location. Then leave it blank.

Now let’s go to the next step. I want to add a second dial-in number for our office in Nashville. I will call this region “United States – Southeast”. I create a User-Level dial plan and simply type “United States – Southeast” into the “Dial-in conferencing region” field. I then skip over and create a new dial-in access number.

After waiting about 5 minutes I reloaded the page and I see that I now have a new entry in my list.


So that’s pretty cool. But here’s the part that I just figured out this week:

How do we set the default dial-in number for a user when they create a new meeting invite via Lync? It is obvious now but for years I never really knew. I always told people to manually edit the settings in their Outlook Lync Meeting options tool.


Meeting Options 1

Meeting Options 2

Now setting that works fine for individual users. I was asked how this can be changed for an entire office and I…uh…well…uh…stammered an “I don’t know”.

Well now I know. And it’s really obvious to me. Now.

All you have to do is set the users dial plan to one that contains the correct region. Duh! So if I have a user who needs to use the “United States – Southeast” dial-in number as their default I then assign them to the user dial plan I created. If the user needs the generic “United States” as their default dial plan I leave their dial plan setting unassigned (i.e., the Global dial plan).

Here is what a meeting invite looks like after I changed my test user from the Global dial plan to the user-level dial plan:

dic 2

Notice that it now sets the default dial-in number to “United States – Southeast” instead of the Global “United States”.

To expand on this, if you have an office (or, more likely, a region) with 4 dial plans, you have to make sure that the Region on all 4 dial plans says the same thing. It’s a bit redundant to have to manually type in the same region value into each dial plan.

So use PowerShell!

Set-CsDialPlan -Identity "Atlanta" -DialInConferencingRegion "United States - Southeast"
Set-CsDialPlan -Identity "Tampa" -DialInConferencingRegion "United States - Southeast"
Set-CsDialPlan -Identity "Orlando" -DialInConferencingRegion "United States - Southeast"
Set-CsDialPlan -Identity "Raleigh" -DialInConferencingRegion "United States - Southeast"

Here is an advanced scenario you might run into. Let’s say that somehow you get a batch of dial-in conferencing numbers that you need to add to Lync, for example via SIP trunks that bring in a bunch of phone numbers from around the globe to a central location. How do you add those Regions?

The same as you would in any other scenario. You have to create a dial plan and type in the region name. In other words, you create “dummy” dial plans (if necessary), set the region in those dummy dial plans, and then use that region when defining the dial-in access number.

Here is some PowerShell showing how to create 3 “dummy” dial plans and three dial-in access numbers using the regions created in those “dummy” dial plans:

New-CsDialPlan -Identity "DIC-Argentina" -DialInConferencingRegion "Argentina"
New-CsDialInConferencingAccessNumber -PrimaryUri "" -DisplayNumber "+54123456789" -DisplayName "Argentina" -LineUri "tel:+54123456789" -Pool -PrimaryLanguage "es-MX" -SecondaryLanguage "en-US" -Regions "Argentina"

New-CsDialPlan -Identity "DIC-Austria" -DialinConferencingRegion "Austria"
New-CsDialInConferencingAccessNumber -PrimaryUri "" -DisplayNumber "+43123456789" -DisplayName "Austria" -LineUri "tel:+43123456789" -Pool -PrimaryLanguage "de-DE" -SecondaryLanguage "en-GB" -Regions "Austria"

New-CsDialPlan -Identity "DIC_Bahrain" -DialinConferencingRegion "Bahrain"
New-CsDialInConferencingAccessNumber -PrimaryUri "" -DisplayNumber "+973123456789" -DisplayName "Bahrain" -LineUri "tel:+973123456789" -Pool -PrimaryLanguage "en-GB" -Regions "Bahrain"

Note on the New-CsDialPlan I don’t do anything other than provide a name (identity) and set a region. That’s all. There is no need for anything else because this dial plan will never actually be used as a dial plan (i.e. phone number normalization). They are being created solely to define a region.

Now look at the dial in web page:


That looks like a real dial-in page now! Note that my test user, when creating a Lync meeting via Outlook will still use the “United States – Southeast” number as his default number as he is assigned to that dial plan. If I wanted him to use the Bahrain number as his default dial-in number is would have to move him to that dial plan (and probably add some normalizations too).

I think that about wraps it up. This is stuff I feel like I should have known years ago but for some reason it didn’t click until this past week. That’s probably due to me having to add about 25 SIP-delivered dial in numbers to our central pools and me actually having to think it all the way through.  I now feel bad to those people to whom I gave wrong, or at least mediocre, information about setting the default dial-in numbers.

For me, the big take away is that *every* dial plan should have a region set.

For more (and probably better) explanations, check here and here.

HP Stream 8 review (+ Sway!)

•2014/12/30 • Leave a Comment

hp_stream_8_tablet-100462970-origI bought myself an HP Stream 8 a few weeks ago.

A few weeks ago, Microsoft released their new “Sway” product.

So I decided to put these 2 new things together and write a detailed review of the HP Stream 8 using Microsoft Sway. Follow this link to see it:

Validate your Federated Domains

•2014/11/14 • 1 Comment

nslookupWe have hundreds of federated partners defined in our Lync environment. Having this many invariably means that our federation with a partner “breaks” because the partner changes their Access Edge configuration. They could be using closed federation and changed their Access Edge DNS. They could have been configured for Open Federation and switched to closed. They could have historically unreliable Open Federation so we stick in an Access Edge setting that then changes.

It’s also tedious to use NSLookup to manually check the partners SRV settings.

So this script addresses these issues.

By default, it will pull in all of your federated partners via the Get-CsAllowedDomains cmdlet. It then cycles through all of these and checks to see what the actual SRV record for _sipfederationtls._tcp.{domain} is set to. It then compares what you have in Lync with what the DNS lookup returns and spits out a .csv file with all of its results. It’s then up to you to do something with this report such as finding the discrepancies and updating your federation.

This script also supports a one-off check saving you the work of having to do the SRV lookup the manual way. Just run it as Validate-ProxyFQDN -Domain {domain} and it will compare your Lync configuration with what it finds via DNS.

I have done some decent testing of this script but please point out any errors or improvements you’d like to see as this all came together pretty quickly.

Click here to download the script.

Lync SBA’s: The Good The Bad, and The Annoying

•2014/11/04 • 8 Comments

If you’ve deployed Lync Enterprise Voice, you’ve at least had a discussion around Survivable Branch Appliances. You may have even deployed them. After having deployed (or assisted in deploying) and supported over 25 of them I’ve learned quite a few lessons about SBA’s that I thought I would share.

First off: sizing. If you look at the official Microsoft documentation, they say that an SBA can support between 25 and 1,000 users. However the SBA vendors do not offer just one single SBA option. They offer options with 2GB RAM and 4GB RAM. They offer SBA’s with different CPU’s. So is there a disconnect between what Microsoft says on Technet and what the vendors are providing? Can a 2GB SBA really support 500 users?

That really ends up being the wrong question, or at least it’s not the only question. I have some 2GB SBA’s that can not support 25 users . The Front End service keeps crashing every day or so. This behavior is not exhibited on the 4GB models.

It ends up that the supported user count isn’t the only metric you need to review when sizing an SBA. You need to understand how large your entire Lync deployment is (or will be). If you will only have a few thousand users then I think a 2GB SBA would work out fine. But if you have 10s of thousands or hundreds of thousands of users then don’t even consider a low powered SBA. As an example: We have an 8 person office using a 4GB SBA and they experience none of the issues that the larger offices we have experience with a 2GB SBA. All of those user accounts, all 10,000 or 50,000 or 200,000 get at least partially replicated to the SQL store on the SBA’s (at least I think it does – I’ve never looked into the DB to see what all is in there). And those large databases eat RAM. And without RAM….The Lync Front End service crashes.

There are other issues to consider before buying a low-powered SBA. How often will you need to monitor or troubleshoot? If Lync barely runs in 2GB of RAM, how well will your logging tools perform? We have crashed the Lync Front End Services on a 4GB RAM SBA just by trying to open a log file in Snooper that was too large for the SBA to handle. Lesson learned. So now when dealing with large log files we have to copy them off of the SBA to our local PC’s to open them in OCSlogger/Snooper. All of this adds delay while the users in that location can’t make or receive phone calls.

With a low powered SBA, other things will take longer too. Your patching window will need to be longer just because installing a Lync Cumulative Update or Windows patches will take longer. You surely need to run antivirus. You may also run a SCCM/SCOM agent or two. Antimalware? IDS/IPS agent? Any other management stuff running and chewing up CPU and RAM? If you add up the price difference for the extra RAM and/or the faster CPU, will you save that money in less downtime and quicker time resolving issues?

Installing and configuring an SBA is completely different than bringing up any other Lync role. Traditionally, you add a device to Topology and then either run the setup off the Lync CD for a first time install or you run bootstrapper to add the new features. You do this via remote desktop and life is good. If something goes wrong, you can just uninstall Lync and start the install over again. This is pretty much how you install all software you’ve ever installed on a Windows Server.

But with an SBA, things are different before you even turn the thing on. First, you have to add an SBA to your Active Directory first and then manually add an SPN value to that computer object. I’m sure someone who’s good at AD can explain why this is needed on an SBA but not needed for any other Lync role.

Next, after publishing Topology, you do not remote desktop to the machine and install Lync off the CD (or .iso image). Instead, you connect to a vendor-written website on the SBA to configure the server. These web-based installers handle all sorts of things such as renaming the server, adding it to a domain, and changing the password of the Administrator account. Of course it does all of this via HTTP by default so if security is important to you the first thing you do is waste 10 minutes to install a certificate on IIS on the SBA.

All that these web-based installers do is wrap PowerShell into a web GUI and invariably all of them have issues. For example, I have never successfully completed a certificate request through the Web installer. The other fun thing is that these SBA’s don’t have an uninstall option for Lync. So if things go wrong for whatever reason you can’t just uninstall Lync and start the install over again. You have to re-image the entire thing and set the whole thing back to scratch. Fortunately this doesn’t happen often.

But my core issue is figuring out what the point is of this web-based installer? Why not just ship a copy of the .iso with the SBA and install it just like you do every other Lync role?

In my imagination I see a bunch of Microsoft people sitting in a conference room

Forward Thinker:  “Hey, how can a Lync administrator install an SBA when they only have limited connectivity to the device? Like, they only have a dial-up modem connection to the site or a firewall policy limits their access?”

Everyone else in the room: “WEB BASED INSTALL!!!!!”.

And so we get stuck with a web based installer but in reality the web based installer solves no issues. It only creates them. If you only have a 56K connection to a site, you probably shouldn’t be installing Lync in that site in the first place, at least not an SBA. Go with a Standard Edition. What if you only have HTTP(S) access to the site? Well, you can then install Lync but you can’t do any logging or troubleshooting with OCS Logger so you better never have an issue. In other words, this has always seemed to me to be a solution in need of a problem.

This is also one of the reasons why I greatly prefer to deploy an SBS over an SBA: I can install off an iso and I’m not limited to under-powered hardware. However, depending on how your organization is structured, you may want to limit the amount of hardware (and “ownership” of that hardware) at a remote location. So an appliance makes sense which is why we continue to push them out.

When shopping for an SBA, there are some key points to ask the vendors you are comparing:

1. How easy is it to upgrade the SBA? Based on the above diatribe, you can’t just uninstall Lync 2010 and install Lync 2013. You have to *completely* re-install the server with a brand new copy of Windows and run through the whole rotten Web-based installer again. Some of the vendors make the upgrade process generally painless by letting you download an image and then flipping a switch on the server to boot to a new partition. These are easy to upgrade remotely. Others require you to download an image and overwrite the existing installation and this has to be done via a USB key or some other transport. These are harder as you may need to do some of the upgrade steps via a serial/terminal connection. (How exactly do I do this over HTTP? I can’t. Another reason the web installer is pointless.)

2. Can your vendor provide some semblance of local support if you have offices scattered all over the globe? Some vendors are a bit more global than others and this could become an issue regarding sourcing equipment and supporting them. It becomes a bigger issue if a part fails on the gateway and a vendor who claims to be global can’t get you parts because those parts are caught up in customs.

3. How good is their support? I’ve dealt with three different SBA vendors. Two of them are great with support, one of them not so much. And to my surprise, things I heard “on the street” about the support at these vendors did not match my reality when I worked with them. So ask the vendor how easy it is to open tickets, how quickly tickets get a response, how easy or difficult it is to set up a voice call for support, etc. I don’t know if there is an easy way to get real information out of a vendor so talk with peers about their experiences with a vendor. Alternately, if you are working with a Lync support organization, ask them how well they can support the gateway side of the product and their experience with the support organizations of the gateway vendor. Note that I am not calling any one out here so don’t ask me in the comments which one of the three I’ve had the most difficulty with. I won’t say.

One other thing to keep in mind: The vendor is on the hook for supporting both Windows and Lync on the SBA. So if the Front End service crashes, don’t call Microsoft. Call the SBA vendor.

4. Manageability. Your network guys have tools that monitor their routers and switches and firewalls. Can they also monitor this device? Some of the vendors sell their own monitoring software. Check those out and compare them. Can Vendor A’s software also monitor and manage Vendor B’s gateway? Can I write custom scripts to manage or monitor the gateways myself? How easily can I extract reports from your solution and link them with my Lync monitoring reports? Can I push out firmware upgrades? Can I centrally back up my configurations? Do you have a SCOM Management Pack?

5. Completeness of Vision. This isn’t a hard and fast set of questions or requirements of a vendor. But you do want to make sure that the vendor is completely committed to Lync as one of the core facets of their business. You want to make sure that no matter what screwball telecommunications connection you need to use in whatever screwball location that the gateway will be able to handle the connection. As an example, we had to connect to a screwy SIP trunk provider and in order to make the connection work the gateway had to manipulate the HTTP headers being sent to the SIP provider. I was impressed that this feature was available but then this completeness of features is one of the reasons we use this vendor. I have full confidence that anything we ever need to connect to our gateways will be able to be handled by this vendor.

Make sure that your SBA’s can route to your Edge servers. As calls come in to an SBA from the gateway, Lync will go through its whole STUN/TURN/ICE game and that includes seeing if using the Edge is a good option. But if the SBA cannot reach the Edge servers then calls will fail. There are some workarounds to this issue but if you have a properly configured network you won’t need to use them. We have one office that is always messing up their DNS servers. We ended up having to add our Edge servers to the local Hosts file on the SBA so that the SBA could reliably resolve and connect to the Edge servers.

Don’t put in an SBA thinking it will solve all of your congested WAN problems. Sure, if you can keep calls off the WAN that will address a portion of your WAN congestion. But if your WAN fills up the SBA could start dropping calls (inability to reach Edge) and/or putting your SBA-homed users into limited functionality mode (inability to reach parent pool).

And no matter what, make sure you have QoS working across your WAN. Someone could be copying a large file across the WAN link and during that time Lync can’t deliver calls and/or your users go into limited functionality mode. QoS helps avert this.

Since I’m talking about congested WAN’s I may as well bring this up: configure the client policy for all of your remote users to use web based address book lookups in the Lync client instead of downloading the address book. Even if the bandwidth is negligible between the two, consider this problem:

We were migrating remote users from Lync 2010 to Lync 2013. 1 week later we got reports from the network group that Lync was crushing the WAN connections to 1 of our remote offices. After some work we figured out it was that everyone in the office was downloading the Lync address book at about the same time and there wasn’t enough WAN bandwidth to support this. We effectively knocked that office off the WAN due to address book downloads. We changed the client policy to Addess Book Web Query and told everyone in the office to sign out/in on their Lync client. Within an hour or so the traffic calmed down. We changed our global policy to Address Book Web Query only.

Conferencing. Installing an SBA does not change the way Lync dial-in conferencing works. An SBA/SBS cannot be a conferencing server. So if you use publish a dial-in conferencing number that is hosted by the SBA, keep in mind that all traffic on that conference is still going across the WAN to your Front End servers. You may actually be increasing your WAN bandwidth with people now calling the number at the remote office to join meetings. Also, know how many available lines or SIP trunks you have connecting your gateway to the phone system. If you only have 10 SIP channels you can only have 10 callers dialing in to that dial-in conferencing number. The 11th caller gets a busy signal. This could also prevent customers from calling you because all 10 channels are being used for the conference.

Don’t blindly add a dial-in conferencing number to an SBA. Be sure that the local users know how the voice is routed and what the maximum number of invitees should be. Also make sure QoS is enabled on the WAN so people dialing in do not have a bad meeting experience.

We didn’t do this initially but we have gone back and fixed this. When we initially configured our gateways, we only configured a connection from the gateway to our SBA. So what happens if the SBA crashes or is getting upgraded or patched? All calling fails as the gateway can’t reach the Mediation service on the SBA. Instead, set up a Mediation server in your parent pool to be a fall back route (both inbound and outbound) in case the SBA is unavailable. While calls will now be travelling over your WAN during an outage, calls can still be made and received.

And be sure you have QoS configured on your WAN so that these calls don’t sound terrible.

I used to think that SBA’s were neat little devices. Now I kind of hate them. Not because they perform poorly. A properly sized SBA can handle 800 or more users in the largest of environments and once deployed we kind of forget they even exist. But upgrading them, configuring them, troubleshooting them, and dealing with their quirks is just a giant pain. I would love it if Microsoft nuked the entire install process in Lync vNext and just made it the exact same process used to install every other piece of Lync. I’m a big fan of the SBS precisely because every complaint I have about the SBA’s doesn’t exist with an SBS. You install it the same way you install everything else. You aren’t limited by overpriced and under-powered hardware. Microsoft handles the support. If they could take this flexibility and put it into the SBA model then life would be just that little bit better.

Moving Immovable Users

•2014/09/17 • Leave a Comment

immovableThis is probably the first of a few blog posts regarding a problem we are facing with our Lync 2013 environment. In short, we have 2 corrupt routing groups right now. Users assigned to those routing groups are unable to add a contact to their buddy list and they cannot change their status.

This tip isn’t anything too special and a lot of you may already know this but I’m putting it out there in case someone else runs into this situation.

Our initial thought was to move the users to a different pool which will remove them from one of the bad routing groups. However, we cannot move the users to a different pool. When doing so, we get the errors seen below.

PS C:\Users\flinchbot> Move-CsUser "" -Target poo
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help
(default is "Y"):
Move-CsUser : Distributed Component Object Model (DCOM) operation begin move
away failed.
At line:1 char:1
+ Move-CsUser "" -Target
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 + CategoryInfo : InvalidResult: (:) [Move-CsUser], MoveUserExcept
 + FullyQualifiedErrorId : FAILED::MoveRetry,Microsoft.Rtc.Management.AD.Cm
Move-CsUser : Distributed Component Object Model (DCOM) operation
RollbackMoveAway failed "-1007781356".
At line:1 char:1
+ Move-CsUser "" -Target
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 + CategoryInfo : InvalidResult: (:) [Move-CsUser], MoveUserExcept
 + FullyQualifiedErrorId : FAILED::MoveRetry,Microsoft.Rtc.Management.AD.Cm
Move-CsUser : Distributed Component Object Model (DCOM) operation begin move
away failed.
At line:1 char:1
+ Move-CsUser "" -Target
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 + CategoryInfo : InvalidOperation: (CN=Uk\,lre poc\..flinchbot,DC
 =com:OCSADUser) [Move-CsUser], MoveUserException
 + FullyQualifiedErrorId : MoveError,Microsoft.Rtc.Management.AD.Cmdlets.Mo

So that wasn’t going to work. So we decided to try a force-move of the users. In general a force-move is to be avoided as this process will move the user but it will throw away, among other things, any contact list entries.

So we did an Export-CsUserData of the users information first:

PS C:\Users\flinchbot> Export-CsUserData -UserFilter "user@flinchbot.c
om" -Poolfqdn -filename "e:\temp\"

We verified that the data was correct by extracting the .zip file and looking at the .xml file. In there we could see the contact list entries that the user already had.

Next we did the force-move.

PS C:\Users\flinchbot> Move-CsUser "" -Target poo -force
Move-CsUser [Using Force will cause data loss!]
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help
(default is "Y"):

This moved the user. Finally we restored the data using the Update-CsUserData cmdlet:

PS C:\Users\flinchbot> Update-CsUserData -UserFilter "user@flinchbot.c
om" -FileName "e:\temp\" -verbose
VERBOSE: Processing input file e:\temp\
VERBOSE: Opening file
VERBOSE: Opening file e:\temp\
VERBOSE: Processed 1 users so far.
VERBOSE: User specified in User Filter processed.
VERBOSE: Output file C:\Users\flinchbot\AppData\Local\ImportUserDataTemp.Xml
 generated successfully.
VERBOSE: Processing user
VERBOSE: Processed 1 users so far.
Are you sure you want to perform this action?
Performing operation "Update-CsUserData" on Target "".
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help
(default is "Y"):

After signing out of the user account and signing back in we saw the contacts had been restored. We were also now able to add new users to the contact list as well as update the Lync status.

Moving the user back to their original pool gave the same errors as in the first example above. We need to figure that issue out but at least our users can have full Lync client functionality again even if they are now in the wrong pool.

%d bloggers like this: