While implementing Lync Online at a customer a while ago, I ran in to a small, but for the end-users, quite annoying issue. The sign-in address was not automatically populated in the Lync Client at first sign on, which means they had to put in their email address/sip address at first logon. Since both Dirsync and ADFS was in place, auto-populated username would mean SSO for the users, which of course is something you always want.
SOLUTION(s)
After doing some research, it turned out that the Lync/SfB Client is getting the sign-in address from the proxyAddresses or msRTCSIP-PrimaryUserAddress (requires Lync/SfB ad schema extensions) attributes.
In order to solve the issue, you need to follow one of the approaches below. The first one is the recommended one since it doesn’t require you to extend your AD schema, but the second one might be good to have as a reference.
APPROACH #1 – Populate the proxyAddresses attribute
With this approach, we simply populate the proxyAddresses attribute with the corresponding sip/email address with a SIP: prefix. In my example below, I am assuming that your email/sip address is the same as the UPN on your users.
#Import Active Directory Module
Import-Module -Name ActiveDirectory
#Loop through all users with 365lab.net as UPN domain
Get-ADUser -Filter {userprincipalname -like "*365lab.net"} | ForEach-Object -Process {
#Construct SIP address based on UPN
$SIPAddress = "SIP:{0}" -f $_.UserPrincipalName
#Populate the msRTCSIP-PrimaruUserAddress attribute with the constructed SIP Address
Set-ADUser -Identity $_.SamAccountName `
-Add @{"proxyAddresses"=$SIPAddress}
}
Verify that your users have got the proper address with the attribute editor, as below:
APPROACH #2 – Extend the AD schema and populate the msRTCSIP-PrimaryUserAddress attribute
Please note that this requires you to extend your Active Directory schema with extensions from the Lync Server installation. If you’re not familiar with schema extensions, please consult someone with that experience!
1. Download the .ldf schema extension files from my OneDrive here (at your own risk), or download a Lync Server 2013 installation media for example from here. You will find the required .ldf-files in the \Support\Schema folder on the .iso file as below.
2. Import the schema files using ldifde.exe from your schema master domain controller (as per instructions on http://technet.microsoft.com/en-us/library/gg398607.aspx) in the following sequence (Important!). The changes must of course be performed by a Schema Admin, in an elevated command prompt.
- ExternalSchema.ldf
ldifde -i -v -k -s DC1 -f ExternalSchema.ldf -c DC=X "DC=contoso,DC=com" -j C:\LogFileFolder
- ServerSchema.ldf
ldifde -i -v -k -s DC1 -f ServerSchema.ldf -c DC=X "DC=contoso,DC=com" -j C:\LogFileFolder
- BackCompatSchema.ldf
ldifde -i -v -k -s DC1 -f BackCompatSchema.ldf -c DC=X "DC=contoso,DC=com" -j C:\LogFileFolder
- VersionSchema.ldf
ldifde -i -v -k -s DC1 -f VersionSchema.ldf -c DC=X "DC=contoso,DC=com" -j C:\LogFileFolder
In my example below, the domain name is lucernepublishing.local/LUCERNE and the schema master DC is LUC-DC1.
After a successful schema update, you should be able to see the required attribute on a user as below:
3. Populate the msRTCSIP-PrimaryUserAddress attribute for all Lync enabled users. The attribute shall be populated just as it would be in a regular Lync environment, (example: sip:aaron.beverly@365lab.net). In order to automate this you could use my powershell script below. In the script I am assuming that your UserPrincipalName matches your SIP address (which is usually the case, at least when using Office 365).
#Import Active Directory Module
Import-Module -Name ActiveDirectory
#Loop through all users with 365lab.net as UPN domain
Get-ADUser -Filter {userprincipalname -like "*365lab.net"} | ForEach-Object -Process {
#Construct SIP address based on UPN
$SIPAddress = "SIP:{0}" -f $_.UserPrincipalName
#Populate the msRTCSIP-PrimaruUserAddress attribute with the constructed SIP Address
Set-ADUser -Identity $_.SamAccountName `
-Replace @{"msRTCSIP-PrimaryUserAddress"=$SIPAddress}
}
After running the script, all users in scope will have their msRTCSIP-PrimaryUserAddress populated.
RESULTS
The result we get after updating the attribute(s), is that we now have a properly populated username when starting our Lync client the first time.
If you have questions or suggestions regarding the post, let me know!
/Johan
Tailspintoys - 365lab.net 
Hi,
When I run the script I get this message:-
At D:\MT_Update_SIP_Address.ps1:4 char:94
+ … bject -Process {
+ ~
Missing closing ‘}’ in statement block.
+ CategoryInfo : ParserError: (:) [], ParseException
+ FullyQualifiedErrorId : MissingEndCurlyBrace
Hi,
THanks for reading. It sounds like you have missed to copy row 10.
/Johan
Hello Johan,
Please note that there is no need for the Lync schema extention.
You could have simply added the SIP address to the proxyaddresses attribute.
This would achive the same result without extending the schema.
Too bad our documentation is not clear enough
Regards,
Eric S.
Hi Eric,
Thanks for the information – really good to know!
/Johan
Thank jimminies for you guys… might be worth mentioning the proxyaddresses at the top though! Almost went extending schema when there was no need:)
Hi Simon,
Thanks for reading, I will make sure to add this in the very top. 🙂
/Johan
I have now updated the post accordingly. Thanks again for reading.
Thanks this worked great! I had already extended the schema anyway, but your PowerShell script was invaluable!
Hi to All,
The following PowerShell script worked extremely well for me. After running the script, all users in the Searchbase will have the AD Attribute msRTCSIP-PrimaryUserAddress populated. Example = sip:first.last@mydomain.com
This allowed for seamless login to O365.
~#~#~
#Import Active Directory Module
Import-Module -Name ActiveDirectory
#Loop through all users with mydomain.com as UPN domain
Get-ADUser -Filter {userprincipalname -like “*mydomain.com”} -SearchBase ‘OU=Root,DC=Name,DC=MyName,DC=com’ | ForEach-Object -Process {
#Construct SIP address based on UPN
$SIPAddress = “sip:{0}” -f $_.UserPrincipalName
#Populate the msRTCSIP-PrimaryUserAddress attribute with the constructed SIP Address
Set-ADUser -Identity $_.SamAccountName `
-Replace @{“msRTCSIP-PrimaryUserAddress”=$SIPAddress}
}
~#~#~
In the above script. replace these two items with your own:
1. *mydomain.com
2. ‘OU=Root,DC=Name,DC=MyName,DC=com’ (Test the script on a test OU first, not the root of your OU or domain.)
Note: “sip” needs to be in lower case.
PoSH on!
Hi Chaps
why do you set the msRTCSIP attribute? I have not needed it for users to login when using Skype Online. Is it just when you have a local Lync server?
Anyway to add the SIP address in the proxy Att. I just used ADmodify.net selected the users and then customised the attributes with these settings.
attribute Name – proxyAddresses
attribute Value – SIP:%’givenName’%.%’sn’%@cnlsoftware.com
Tick multivalue append
Nice easy GUI to use if you not an AD PS prof like me.
Do you know if this will work even if SSO is not implemented?
We do use DirSync (Azure AD Connect), but what would be the added benefit of ADFS/SSO in this case for logging into Lync/Skype, if the username is already populated as the user’s e-mail/UPN?
Hi,
Thanks for reading!
In case you are not using ADFS for SSO purposes, this would benefit the end user so that they don’t have to enter ther user name at least 🙂
/Johan
Hi John
The benefit of ADFS/SSO is that users don’t need to type in their password to any of the Office 365 Apps. This streamlines SharePoint, One Drive, Outlook and so on. Once implemented its a feature that users appreciate and this can be used to service many other products for SSO. ADFS is not a small setup as it has to be setup with HA. If the ADFS box fails users will not be able to login to anything until you have resolved the issue. You should have 2 ADFS servers sitting behind a load balancer internally. For external users you need 2 internet facing WAP servers sitting behind a load balancer too. So 6 servers, 1 SAN from a CA and a public IP.
Its a juicy project to get your hands dirty with, just make sure its working flawlessly before you federate it with O365. This can be built in Azure too.
Oh wow ok, so I’m curious in how that works. Are they already authenticated to SSO before their Skype client is launched, hence the pass through login?
Or the Lync client has to be configured to point to a specific server for SSO?
Sounds a bit complicated in terms of setting up the on-premises servers. At least I’m more apprehensive about that. Is the Azure alternative with ADFS any easier?
My colleague wants to implement Shibboleth, but I’m not sure that would be best for a MS roduct.
Pingback: Skype for Business Meeting Delegation not Working « Sunu Gohil
2018 and still valid;-) Great job! Thanks