Today I ran into a problem at a costumer. They are running an Exchange 2013 server in a hybrid configuration with O365. Part of the users are on the local Exchange server, but the main part of the users use O365 for their mailbox needs.
Some new mailboxes were needed, so I created the users in Active Directory and ran the
enable-remotemailbox cmdlet to provision their mailboxes. Next step is to assign a license in O365, so I kicked of DirSync with the
start-onlinecoexistencesync cmdlet and reverted to the O365 portal to license my new users… But they didn’t show up.
I checked the MIIS client to see that the export to Azure AD failed with the
After some research, I found that this can be related to the execution policy in PowerShell. For DirSync to run successfully, it turns out the PoSH execution policy should be set to
unrestricted. Earlier this week, a GPO was activated at this costumer to enable PowerShell remoting, including the option to set the execution policy to
remote signed. After creating a deny for this policy for the server running DirSync and manually setting the execution policy back to
unrestricted', DirSync worked again and my newly created users started showing up in the O365 portal.
Wise lesson: for DirSync to run successfully, the execution policy for PowerShell on the server running DirSync needs to be set to
unrestricted'. Pretty weird, as in IMHO remote signed' is the preferred and most secure setting. It is strange, at least, that Microsoft’s own products don’t work in this scenario. I haven’t tried this with the newer AADSync yet, so maybe this flaw was fixed in the newer releases.
Use of GPO’s
There are a few issues on the O365 support pages regarding this issue, some of which stating that even if the execution policy is set to
unrestricted' via GPO DirSync won’t work; the GPO must set the execution policy to undefined and the execution policy on the server needs to be set manually. However, only some of the people responding could confirm this, so your mileage may vary :)