If you do directory sync from Active Directory (AD) to Office 365, users will not be able to change their passwords on the Office 365 portal. Since the AD sync is a one-way process, the password changes do not come back into AD locally. Thus, by default, the Office 365 Portal will not allow users to change their passwords as they will just be overwritten by the local AD.
The problem this creates is sometimes you have a mix of users: some local and some that may not have local domain access to change their passwords. Here is a workaround using the OU exclusion in DirSync. I would recommend you use a test account or two to make sure you have the process down before doing any mass moves.
First, put the users in a separate OU such as “Webmail” and exclude that OU from DirSync. This allows the users to change from “Directory Synced” to “Cloud”, which you can confirm in the Office 365 Admin Console. Here are the steps:
Caution: Don’t try this at home, ladies and gents, unless you are seasoned domain admins — email flow will be impacted for users as they are changed.
Copy the shortcut to your desktop:
C:\Program Files\Windows Azure Active Directory Sync\SYNCBUS\Synchronization Service\UIShell\miisclient.exe
Open and select Management Agents and Active Directory Connection:
Right click and choose properties:
Select Configure Directory Partitions and then Containers:
The system will prompt you for your credentials. Enter in your LOCAL ADSync username and password.
Browse and exclude the OU:
After you select OK a couple of times, you will be able to force the DirSync process.
Open up PowerShell as Administrator and run the following command to initiate a sync:
Import-Module DirSync
Start-OnlineCoexistenceSync -fullsync
Select the Operations tab to view the status:
Note deletions in the bottom right:
Note: force the DirSync process two to three times to make sure all settings synchronize.
Log onto Office365 portal> Deleted Users> Select Users> Restore Users:
The users should now be able to change their passwords from the webmail interface. If not, use the admin console to force a password reset per user to purge out any AD password settings.
In my testing — since I performed this process after hours and quickly restored the accounts — little to no email was kicked back as “recipient does not exist.” Additionally, the end users did not notice any impact to their email as it was in a limbo state, not yet truly “deleted.”