Thursday, 13 October 2016

AD Connect syncing msExchangeMailboxGuid object causes "This user's on-premises mailbox hasn't been migrated to Exchange Online. The Exchange Online mailbox will be available after migration is completed." for new Office 365 mailboxes

When you try to open a new mailbox for an Office 365 users you get the following error;
"This user's on-premises mailbox hasn't been migrated to Exchange Online. The Exchange Online mailbox will be available after migration is completed."
AD Connect is configured to sync users, groups and passwords from the existing Active Directory (SBS 2011), however the option for “Exchange Hybrid Deployment” was not selected on purpose. This is because in this particular case the migration was for 6 users, therefore a PST export/import was done to migrate the e-mails, contacts and calendars.
The root of the problem is because the Active Directory attribute msExchangeMailboxGuid is being synced to Azure AD in Office 365, when it’s not required. 

You have to edit a configuration inside AD Connect (it’s actually FIM 2010 R2 under the covers). To open the configuration panel for FIM, browse to C:\Program Files\Microsoft Azure AD Sync\UIShell and launch miisclient.exe.
Click Connectors and select the connector for your local Active Directory and choose Properties.

Click Select Attributes and scroll until you find msExchangeMailboxGuid, if you have the same problem as me this will be selected. Simply disable this attribute.

You then have to delete the old reference to the msExchangeMailboxGuid from the FIM Connector Space. To do this select the Active Directory management agent (also known as a “connector”), and choose Delete. Read the next part properly.
Ensure that Delete Connection Space Only is selected and click OK.

It will ask you to confirm you want to delete data from the connection space, click Yes. If you did delete the entire connector, you could provision again by running the AD Connector wizard. This is fine if you have not made any major modifications to your AD Connect configuration. 

Use the following PowerShell command to force an entire sync across AD Connect;
Start-ADSyncSyncCycle -PolicyType Initial
You should notice updates when the Operations complete.

Now if you return to Office 365, you should see the following.

Export Exchange mailboxes to PST from the server side

I was recently doing a small Exchange migration using the PST export/import method. Using client side Outlook to do the exporting sometimes works and sometimes it has issues exporting everything. 

In Outlook 2013 if you are doing an export ensure you have configured the profile to cache all the mailbox data and not just the last 12 months, which is the default;

However its easier to do an export from the server side using Powershell;

Create a new share with the following permissions;

  • Share permissions - Everyone F/C
  • NTFS permissions - Everyone F/C + Exchange Trusted Subsystem F/C
Open the Exchange Shell as an Administrator and type;

New-MailboxExportRequest -Mailbox "user" -FilePath "\\uncpath.pst"

To check progress;


Post Exchange migration Outlook won't load with "Cannot start microsoft outlook. cannot open the outlook window. the set of folders cannot be opened. you must connect to microsoft exchange with the current profile before you can synchronize with your outlook data file (.ost)"

"Cannot start microsoft outlook. cannot open the outlook window. the set of folders cannot be opened. you must connect to microsoft exchange with the current profile before you can synchronize  with your outlook data file (.ost)"

Clear the Outlook profile folder on C:\Users\Profile\AppData\Local\Microsoft\Outlook

CTRL + R and enter "Outlook /resetnavpane"

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