Moving from manual to automatic Microsoft Azure AD license assignment

Wouldn’t it be nice if we never have to worry about assigning a license manually to a user, ticking that checkbox for new starters and unticking it for leavers. Or what about having to change a license subscription and having to change over from the old one to the new for all users. Ohhh! what a nightmare!

Good thing is that Azure AD Group-Based License Management is now a thing! And what’s better than that? Rule builder is now available – for the ones that are not too savvy in creating their own dynamic rule syntax.

Here are the steps on how to make this thing work for you and your organisation:

  1. Gather information and prepare requirements.
    • Identify the baseline license that bulk of the users should have.
    • Identify if the accounts are purely AAD or synchronised from AD on premise, this will come in handy when identifying the next bullet below.
    • Identify the attribute and the unique value that the users have in common.
    • Ensure that you have the appropriate number of licenses.
    • Ensure that you have at least Azure AD Premium 1 to be able to create dynamic groups.
    • Ensure that you have at a minimum User and License Administrator privileges in your tenant.
    • Once the above steps are complete, you are ready to start.
  2. Create a new dynamic membership Azure AD security group with an easy to identify name.
    • Example: License Assignment – O365 F1 and EMS E5
    • Set the membership type to Dynamic User.
    • It’s also a good idea to add an owner for future reference.
    • Setup the dynamic query using the rule builder. By default the first entry is already filled in so you may need to update it if needed – just like what I did below.
    • You may add up to 5 expressions as of this writing. The rule builder also automatically creates a rule syntax (highlighted in yellow) which you may also need to update if your query is a bit complex.
      In the above example, I need to update the rule syntax and group the department together hence adding a parenthesis () after the second “and” query as shown below. Note that once the rule syntax has been manually updated the rule builder entries will show as empty.
    • Hit the save button once you are happy with the rule to create the dynamic group.
  3. Review the newly created dynamic membership group.
    • Click the object to see the processing status. Once the processing is done notice that the group now have members. Review the accounts and see if you have captured the correct users. If not, revisit and update your rule syntax until you have the correct users.
    • Once you are completely happy with the dynamic membership group members then you may now proceed in associating the group to the license.
  4. Associate the group to the license.
    • From the group pane, click Licenses then hit Assign.
    • Select the licenses that you want to associate to the group and save the changes.
    • Once the process has been completed, you should be able to see a message whether the licenses were applied. It will also mention if there is an error which you can click on to see more information on how to resolve. An error will also show up here if you do not have enough license.
  5. Review the license assignment. Once the group license assignment has been processed, you will see the assignment paths as having Direct or Inherited. Review the assignment and ensure that all users that have inherited assignment is correct, otherwise, revisit your group filter in step 2.
  6. Perform a cleanup. Remove direct license assignment and ensure that state is Active.

Things to note:

  1. While the user has both direct and inherited license assignment, the user is still using ONE license.
  2. License assignment may take awhile to process so ensure that everything has been processed BEFORE removing direct license.


  1. If there are issues with the state, reprocess license assignment.

There you go! Hope this helps someone, somewhere out there! 🙂

Remove a device from Hybrid Azure AD join – permanently!

A few weeks ago, one of my clients asks me to remove one device from Hybrid Azure AD join. I said, well that’s easy! Open command prompt and type dsregcmd.exe /leave and that should do everything for you. Guess what?? It did not!

So here’s what I did to completely remove a device from Hybrid Azure AD join.

  • On the server, ensure that the machine is not part of the GPO that is setup for automatic registration.
  • On the machine to be removed from Hybrid AAD join, remove the applied GPO locally for automatic registration.
Computer Configuration/Administrative Templates/Windows Components/Device Registration -> Not Configured
  • Delete the registry key for autoWorkplaceJoin.
  • Open powershell and connect to Azure AD, run Get-MSOLDevice and take note of the DeviceID. Install the module if needed.
Install-Module -Name MSOnline -Force
  • In the same powershell command window, run Remove-MsolDevice command and enter the DeviceID taken from previous step of the machine to be removed.
  • To verify the changes made, run Get-MsolDevice again and you should be able to get the “Device not found” error.
  • Open mmc.exe –> certificates and delete the two certificates below.
  • Manually disable the task scheduler on the affected servers. Ensure to disable the Task itself and the trigger. \Microsoft\Windows\Workplace Join
  • Run dsregcmd /status from command prompt and it should show that the machine has been removed from AAD join.
  • To completely verify, refresh policy and run gpupdate /force then run dsregcmd /status once again. It should show the same output as in above step.
  • Logoff from the machine and log back in and run dsregcmd /status once again. It should again show the same output as in above step.

There you go! Hope this helps someone, somewhere out there! 🙂

Password writeback unrecoverable issue with account configuration error

Last week, one of our clients encountered the error below when performing password change.

“We’re sorry, but we cannot change your password at this time. Unfortunately, this is due to unrecoverable issue with your account configuration, so trying again won’t work.

Please contact your admin to change your password for you.”

Figure 1: Error when performing password change

Their accounts are synchronized from on-prem AD to AAD via AD Connect and for the password change to work, password writeback is enabled from AD Connect.

Troubleshooting steps done with no luck:

  1. Ensured AD Connect is in the latest version
  2. Ensured that the sync account (automatically created during install and starts with MSOL_ however you can also define another account for this) has correct permissions to AD, it would need password reset and change
  3. Disabled and enabled password writeback
  4. Disabled and enabled password hash
  5. Disabled and enabled 1 and 2 at the same time
  6. Uninstalled and installed AD Connect
  7. Uninstalled AD Connect, cleanup install location and installed AD Connect

After doing all the steps above, I can’t think of anything else to do. My mind just keeps on going back to the sync account.. it should have permission.. it should have permission.. until I’ve decided to do item 7 again and delete the sync account together with cleaning up the install location. And voila! Issue resolved.

Here’s an outline of the steps done to resolve the issue: This requires deletion of install location and registry so ensure that you have a backup.

  1. Uninstalled Microsoft Azure AD Connect, this includes Sync Service and Databases.
  2. Deleted AADConnect folder in C:\ProgramData.
  3. Deleted the following folders in C:\Program Files. These folders should be automatically deleted once AD Connect has been successfully uninstalled. However there are instances where some folders just don’t do what they’re told.
    • Microsoft Azure Active Directory Connect
    • Microsoft Azure AD Connect Health Sync Agent
    • Microsoft Azure AD Sync
  4. Deleted lingering registry entries.
    • [HKCU]\SOFTWARE\Microsoft\Azure AD Connect
    • [HKLM]\SOFTWARE\Microsoft\Azure AD Connect
  5. Deleted sync account from AD. To find out what the account is, open synchronization service, navigate to connectors and open properties for ADDS. See figure 2.
  6. Restarted server.
  7. Reinstalled AD Connect.
  8. Enabled Password writeback.
Figure 2: Where to find service account used to run the ADDS connector

There you go! Hope this helps someone, somewhere out there!

Oh! And welcome to my first blog post! 🙂