Tuesday, 13 September 2016

Skype for Business Online Users not Appearing after AD Connect sync

I was recently having a problem provisioning Active Directory users with Skype for Business Online access, basically after a DirSync job had completed none of the user accounts were appearing under the SFB Admin Centre. The AD that was being used previously had Lync Server 2013/SFB 2015 deployed, therefore I thought it might be some kind of Active Directory attribute causing the problem. The first stage was to compare a new user account (which had never accessed Lync on premise) and an existing user account, to see if there were any differences in the msRTCSIP- attributes.

The only one I noticed consistently was the msRTCSIP-DeploymentLocator. This attribute was populated on user account NOT being enabled for SFB Online. The new user account, with full access to SFB Online did not have this attribute set.


For a test I removed the msRTCSIP-DeploymentLocator attribute, then forced and AD replication cycle. 


The next step was to run a full sync from the DirSync (or AD Connect) server, to update the Office 365 Azure AD instance with the changes. The following command can be used to force a sync for DirSync;

Start-ADSyncSyncService -PolicyType 


You can view the progress of the DirSync jobs from the FIM 2010 R2 console, this can be launched using the miisclient.exe from inside the installation folder. 


If your problem has been the same as mine, you should see an update under the Active Directory import management agent under FIM. This is basically telling FIM to sync updates from the AD to its own metaverse, before pushing the changes out to Azure AD.


The msRTCSIP-DeploymentLocator attribute is no longer being synced. 


This this change, the users from AD were now listed as SFB Online users. This meant they could login to SFB without problem. I tested audio/video calls and everything was fine, I had initially worried about other stale attributes for things like SIP causing problems.

Friday, 19 August 2016

SCVMM 2012 R2 - Joining Hyper-V 2012 R2 Host to Host Group fails with "error 415 agent installation failed copying"

Trying to join a Hyper-V host to a VMM 2012 R2 Host Group fails with;

"Agent installation failed copying C:\Program Files\Microsoft System Center 2012\Virtual Machine Manager\agents\Amd64\3.1.6011.0\vmmAgent.msi to \\HyperVHost\ADMIN$\vmmAgent.msi.
The network path was not found."


This was because I forgot to add the VMM Run As account to the Local Administrators group on the target Hyper-V server.


Sunday, 14 August 2016

Office 365 & Exchange Migration Split Brain AutoDiscover Workaround

I’ve just migrated an Exchange 2010 installation to Office 365 using the “cut over” migration method. As it was a small deployment I did not go through the exact process documented by Microsoft, instead I did a PST export/import migration. For this, it created an interesting problem in regards to name resolution for clients in the domain. Clients would successfully do an Autodiscover, but the internal DNS would continue to point users to the old Autodiscover service on the Exchange Server.

The following changes were made to prevent Active Directory resolving the old Autodiscover service;

·      Edited the “HomeMDB” attribute from ADSI Edit (Configuration)
·      Disabled (deleted) the Mailbox from Exchange
·      Recreate the Outlook profiles for each user

Remove the HomeMDB Attribute using ADSI Edit

Connect to ADSI Edit, and connect to the Configuration container and find the Microsoft System Attendant at the following path.

N=Configuration,CN=Services,CN=Microsoft Exchange, CN= "OU", CN=Administrative Groups,CN= Exchange Administrative Group, CN=Servers, CN=EXCH", CN=Microsoft System Attendant

Simply clear out the value in this attribute until it looks like this.


Disable the Exchange Mailbox (Delete the mailbox without deleting the user)

From the Exchange Management Console, browse to Recipient Configuration/Users, select the User and then choose the Disable option.


If you select the Disable option, the Active Directory user object will remain. The Exchange Mailbox is not actually deleted from the Mailbox Database until the next purge is carried out, which is determined by your Retention Policy.


Although this work around works fine in a small environment, it may not be so straight forward in a more complex deployment. It is possible to configure Autodiscover redirection if required.

Comments system

Disqus Shortname