Office 365 using DirSync users cannot change passwords in Office 365

If you do directory sync from 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. The following is a work around using OU exclusion from DirSync.

First we need to put the users in a separate OU such as “Webmail” then we will exclude that OU from DirSync. That will allow them to change from “Directory Synced” to “Cloud”. Which you can confirm in the Office 365 Admin Console. Here are the steps:

Caution: Seasoned Domain Admins Only this is Active Directory and email flow will be impacted for users as they are changed

“you break it you bought it…”

Copy Shortcut to desktop

C:\Program Files\Windows Azure Active Directory Sync\SYNCBUS\Synchronization Service\UIShell\miisclient.exe

Open and select Management Agents and The Active Directory Connection:

Right Click and Select Properties:

Select Configure Directory Partitions and Containers:

You will be prompted for credentials enter in your LOCAL ADSync Username and Password

Browse and Exclude the OU:

Select “OK” “OK”

You can now 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 status:

Note Deletions in the bottom right:

Note: force the DirSync process 2 to 3 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 is in a limbo state not yet truly “deleted”

I would recommend you use a test account or 2 to make sure you have the process down before doing any mass moves.