Published: July 7, 2014.
Updated: September 8, 2014
I’ve been looking for this functionality for quite some time, and with great help from Guy Bachar, we created the following script to help assign Lync policies to Active Directory Security Groups.
This version of the script allows assigning user-scope policies to any all Lync enabled users in a certain Active Directory Group.
The process is easy:
Run the script from a computer or a sever that has both the Lync Management Shell the Active Directory PowerShell Module installed. If they’re not there – The script will let you know.
As you run the script, it will automatically check if you have local admin privileges on this machine and will prompt you to elevate your PS session if you didn’t choose “Run As…”. Many thanks to Ben Armstrong for creating the self-elevating script. We changed it to match our needs here.
If all is ok, the script will next ask you to choose your desired AD group: Enter the group’s display name, and in return the script will show you its CN, just to make sure it’s what you’re looking for:
The script will immediately ask you to choose which type of policy or dial plan you would like to assign from the following 14 options:
One of my recent posts was about Configuring Lync 2013 On-premises and Exchange Online to work together. After dealing with some feedback from customers and readers, I thought it might be worth to spend some time clarifying things: Edge Server You Edge Server must be configured as described in the post and enabled for federation. Confirm you have all the firewall rules in place between your Front-End and your Edge server, and your Edge server and the internet. Alternatively, you might want to restart your edge server or services just to be sure it’s all running… It’s all about the sequence There’s some logic in the order you’re committing the changes, especially if you’re migrating mailboxes from Exchange on-premises to Exchange Online. The steps are:
Before you do anything, make sure the user is already in Office 365, synced using DirSync. If you’re migrating from Exchange On-Premises to Exchange Online, you’ll have to disable the existing UM option for these users. Don’t worry, all the data will still be there when you re-enable UM later.
Run the Lync 2013 UM commands first. If the user is already synced or migration was completed, that’s the time to run the following: Grant-cshostedvoicemailpolicy –identity LocalDomain\<user> –policyname <PolicyName> and Set-csuser –identity LocalDomain\<user> –hostedvoicemail $true
Let it sync. Although it should usually work immediately, go get a cup of coffee. Or something.
Enable the user for UM in Exchange Online.
Just follow the steps… If you try to grant the on-prem policy to a user and you’re getting an error saying that the command cannot be found – it means you probably missed or skipped one of the steps. The workaround is simple: Disable UM for that user in Office 365 and wait a while for the attributes to reset. then, run the Grant-cshostedvoicemailpolicy command and voilà- it’ll work.
It’s been out quite a while and it works just fine. Here’s how to enable users to communicate with Lync server from their mobile devices…
Prerequisites, clarifications and supported platforms:
You must install Lync Server CU4 (KB2493736) for this to work. I usually download the LyncServerUpdateInstaller.exe file and let it automatically install all the needed updates. (If you have a more recent update – It’s already on there).
You must download the “Microsoft Lync Server 2010 Mobility Service and Microsoft Lync Server 2010 Autodiscover Service” McxStandalone.msi. Don’t tempt to just run it now, we have a few things to do before that.
Your Edge server is used only for push notifications, via Lync Online. You can run the CU4 installation tool there to update your server, but you must not install the mobility update on your Edge Srver.
Your reverse proxy (ISA\TMG\UAG) or any other device you’re using for that matter is what we’ll use to publish this service. Infact, we use the meet.yourdomain.com publishing rule.
If you feel like being useful, pre-publish a new external DNS A record called LyncDiscover.yourdomain.com and point it to the IP adsress of your ‘meet’ rule.
I recommend using a trusted, valid, 3rd. party certificate on your reverse proxy server – it saves you loads of trouble.
There are currently Lync mobile apps for WP7, Android, iPhones and iPads. I know not about any Symbian apps soon.
There is something Blackberry-ish, Never saw it working.
So, Let’s get started.
Install the updates needed by launchig the Lync Server update installer from where you saved the file:
Once finished, the installer shows you you’re all good. It also saves the installation logs of every update in the folder from which you launced the installer.
After installing the updates, we need to update the system. We will use the following Lync Powershell command to do so. If you’re using a single standard server like me, your command should look like this:
Now we can start configuring the system for the mobility part. This will be done mostly by using the Lync Server Management Shell.
A prerequiste for this service to work is to have IIS Dynamic Compresion enabled. It can be quickly installed using two commands in Poweshell:
Import-Module Serv* (You can type the whole “ServerManager” command, but I always end up typing it twice so I’m getting lazy here…)
To configure the listening ports for the sevice, we will run one command twice, with two variables; the Primary listening port (internal) and the External listening port. These ports are documented in the Microsoft Lync Server 2010 Mobility Guide. To do that we will use the command “Set-CsWebServer” and provide our Front-end server’s FQDN and ports:
Then, we will update the topology using the followong command:
Now, remember I told you not to run the McxStandalone.msi file? here’s why: You should now take this file and paste it to the following location:
"C:\ProgramData\Microsoft\Lync Server\Deployment\cache\4.0.7577.0\setup" and just paste the file there:
After the file is there, you can either launch the Lync Server Deployment Wizard and choose “Setup or remove Lync server components”:
Or just go to the Lync Server deployment folder (“C:\Program Files\Microsoft Lync Server 2010\Deployment”) and run the file “Bootstrapper.exe” This will install the update directly from the folder where we put it.
To view the log browse to your %tmp% folder and look for the latest Bootstrap-CsMachine log. If everything worked right, you will see a similar screen to this:
This tells you you have successfuly installed the service!
But we’re not done yet. If you used the Lync Server Deployment Wizard, don’t close it just yet. If not, this might be a good time to open it. We now need to generate a new certifiacte request and assign a new certifiacte for the Front-end server.
Why you’re asking? well, the answer will be revealed in the certificate wizard: If you look closely, you’ll see that two SANs were added automatically to the request: Lyncdiscover and LyncDiscoverInternal. They are added to every SIP domain configured in your topology:
You can now assign the certifiacte to your server and move on to the nest step:
The service works now, you just need to configure the reverse proxy. But wait – what’s a mobile app without push notifications? Well… Setting that up is rather easy if you have Lync Federation enabled and is done by running four Powershell commands:
If you’ll check your Lync Server Control now, you’ll see you have a new provider:
And a new federation partner:
That’s it, configuration on the fron-end side is done.
Now, for your reverse proxy:
If you’re using TMG like I do, it’s rather easy. All you have to do is add “Lyncdiscover.youdomain.com” to the Public names and make sure you have c ertifiacte that corresponds to that name on your listener:
That’s about it.
Now, let’s test what we just did:
I have a WP7 device and want to connect it to Lync. If everything was configured correctly, we will go through these steps:
I’ll launch the Lync on my phone, it will show me this screen:
I will now insert only my Lync sign-in address and my password – this is all it takes for automatic sign in!
The app thinks for a while them launches the first screen:
It will ask you for your phone number – You can skip this step if you don’t have Enterprise Voice implemented:
Now it will ask you if you wish to enable push notifications:
And That’s it – you’re signed in:
How does push notifications look like?
Look at the top of the screenshot, this is what you see when you get the message:
If you did not respond to the notification, the live tile will remind you you have one unread message in Lync:
You’ve seen it. The contact card in Lync shows you everything you entered in Active Directory, except for phone numbers. even when you know you have them there!
This can be quite frustrating, especially if you’re not yet connected with enterprise voive and clients want to pull all the relevant information from Lync during an IM session, including the other side’s phone numbers.
Here’s what you get:
Instead of seeing the relevant phone numbers from Lync like here (sort of…)
You’re getting a card that has no phone info what so ever:
As you can see, ‘test’ Springsteen here, has no phone info in his contact card.
Let’s take a look at Active Directory, see what’s configured there:
This can’t be right! All the information is there! Home, Mobile, even the Office phone is there.
How can we resolve this issue, even without implenenting Lync Enterprise Voice?
Let’s take a look at the event viewer to get some help.
If you scroll down the Lync server logs in event viewer, you’ll probably see event number 21034 generated by LS Address Book Server. It will tell you something like this:
“One or more phone numbers failed to normalize.
‘X’ total numbers failed to normalize. They are listed in the text file: ‘\\<Lync Server Name>\<Lync Share>\1-WebServices-1\ABFiles0000000-0000-0000-0000-0000000000000000000-0000-0000-0000-000000000000\Invalid_AD_Phone_Numbers.txt’ Cause: One or more phone number attributes in Active Directory contained text that could not be normalized. Normalization rules are contained in the optional Company_Phone_Number_Normalization_Rules.txt file located in the output location or in the generic rules built into Address Book Server. Refer to the documentation for a description of the built-in generic normalization rules. Use the ABServer -dumpRules command to see all the rules that Address Book Server is currently configured with.”
It looks like this:
If you press the path in the event propertis or browse to the file location in your server (always in the same place, in the same name), you will see the following:
What you get here is a list of the users and they’re phone numbers you thought were ok.
Why is this happening?
Well, Lync expects all the phone numbers in your AD to be in the E.164 format, meaning they should be +1-111-11111111 etc. If they’re not like this (as the example above shows us), you will have to normalize them if you want Lync to publish them.
How can I fix this?
Quite easily, to be honest. If you continue reading in event 21034, you’ll see the following:
“Either create a Company_Phone_Number_Normalization_Rules.txt file in the output location and make sure it covers all cases found in your Active Directory deployment or fix the invalid phone number(s) in the Active Directory record(s).”
You get a free advice – you don’t throw it away, do you? What Lync actually tells you, is to create a file called “Company_Phone_Number_Normalization_Rules.txt” in the root of the AB folder of your Lync shared folder (Not in a sub folder, not by a different name, EXACTLY this one) – like it shows you here:
In this file, you must enter normalization rules according to your country code and other variables.
I used to freak out when I heard normalization rules, but fortunately the guys at Lync made it quite simple for us: I use the Lync Server Control Panel to generate and test my normalization rules. It’s really easy and fun to use – Just enter the details and copy the results. In the next example I created a rule to normalize our internal numbers:
I copied the “Pattern to match” and the “Translation Rule” from the wizard and copied them one line below the other (in the order they appear at the wizard) to the txt file I created. Note you can add “##” at the beginning of each line if you want to write comments.
This is how my file looks like at the end:
Now, all I have to do is run the “Update-CsAddressbook” command from Lync Management Shell and that’s it.
If you configured the rules correctly – you will see the results in your clients. It might take a while for the clients to download the updates, but eventually you’ll see it works perfectly:
* This article works for all versions of Skype for Business and Lync clients *
You might want to configure Lync clients manually to connect to Lync Online if you don’t have an SRV record published or unable to reslove for some reason. If the Lync client cannot find the right records in DNS you will not be able to sign in and will get the following error messgae:
It is quite easy to configure a manual connection to Lync Online. To do so, please follow these instructions:
Click the gear on the right top side of Lync client:
In the new “Lync OPtions” window that opens click “Advanced”:
You’ll get the default Automatic configuration window:
Choose “Manual Configuration” and enter the address sipdir.online.lync.com:443 in both the Internal and External server fields, and then press “OK”:
retype your Office 365 username (always in firstname.lastname@example.org format) and sign in:
I’ve been looking for a way to lighten up the end user’s first dip into Lync 2010 client.
I found two things annoying:
Address book takes a while to update.
The first Launch splash screen can make the users brake their screen.
The solution is a very simple registry fix. I edited the following registry jey with two options:
1. The first hive Shortens the address book pulling delay to zero – meaning the client will immediatley download the address book.
2. The second hive tells the computer that the splash screen has already ran, so there is no need to run it again (this registry key is being added during the installation of Lync client, and sets itself to the ‘0’ value after the first run. pre-populating the registry with this key means the first launch tour screen will not run).
You don’t have to use both keys, but I run them together to achieve a smooth, quieter client-side installation: Windows Registry Editor Version 5.00