Once you’ve bought into the Cloud and O365 as the future for your business, the next steps are to determine how you want to manage yet another IT app. In a previous blog post I discussed Identity Management in a SaaS Based World, where I laid out an organization’s options for getting their existing users into the cloud. The next stage is to understand what options are available for managing your O365 tenant in a way that minimizes its impact on your users and IT staff.

Let me just say, PowerShell automation is your friend. Just about everything you can do (and many things you cannot do) in the O365 Management Console can be accessed and automated using the PowerShell module for O365. The first thing you will need in order to get started is the Microsoft Online Services Sign-In Assistant, which provides remote command line sign-in options for O365. Second, you will need the Windows Azure Active Directory Module for PowerShell. You can get these at the following links:

Microsoft Online Services Sign-in Assistant

Azure AD Module for PowerShell

Once these are installed, you can get started by opening a PowerShell console, or the ISE if you are writing part of a larger script, and execute the following CMDLets:

Import-Module MSOnline

Connect-MsolService

Import-Module MSOnline imports the module that provides all of the O365 CMDLet functionality for your local machine. Connect-MsolService initiates the first connection to O365 and will present you with a standard windows credentials dialog.

Now that you are connected to O365 there is a whole world to explore. Maybe you need to create a list of users, groups or contacts for Exchange. What about enabling licensing for all of those users? How about clearing left-over, deleted, test users from the Recycle Bin? If you are synchronizing your local Active Directory users to Azure AD, it can get pretty complicated. The best place to start is to generate a list of O365 CMDLets to get an idea of what types of objects are available to work with.

Get-Command | Where {$_.Name –like “*MSOL*”}

This CMDLet will generate a list of around 167 CMDLets used for interacting with O365 objects. To get started let’s run the following CMDLet to create our first user from PowerShell:

New-MsolUser -UserPrincipalName username@domain.com -DisplayName “UserName” -FirstName “User” -LastName “Name”

Now that we have one or more users in our O365 tenant, getting an object, say $users = Get-MSOLUser, is where the really interesting bits become available. By piping the new object toGet-Memberwe can get a list of all of the Members and Properties for the object as seen in the screenshot below:

$users = Get-MSOLUser

$users | Get-Member

As you can see from the list of properties above, we can now query and update a number of properties for the object such as First Name, Last Name, Last PasswordChangeTimeStamp, IsLicensed, etc. Some of these properties won’t be updateable if you are synchronizing your user from your local Active Directory, but you will still be able to query the property to ensure that it has been synchronized properly.

$user = Get-MsolUser –UserPrincipalName username@domain.com

$user.DisplayName

$user.IsLicensed

$user.PasswordChangeTimeStamp

Now, if you are new to O365, you may be in the process of evaluating a migration from another hosted or on-premises environment over to O365, which might include an import of users, or synchronization from an on-premises AD. If so, you will probably be playing around with the code above to create and delete test users, or maybe syncing and desyncing from AD as you test. There’s a fair chance you will run into a situation where a user you previously deleted or de-synced will throw an error if you try to create/sync another user with the same display name.

The conundrum you might run into is that when a user is deleted or desynced, it is moved to the recycle bin on O365. If you delete the user from your local AD, recreate it, and then try to sync the user up to O365 again, it will fail because the user still exists in O365 even if it isn’t visible. The reason for this is because the unique identifier in the local AD has changed with the creation of the new user, but the display name, if configured exactly the same as the previously deleted user, will still match the user in the O365 recycle bin. It is also worth considering that deleted users still consume licenses if the license wasn’t first removed from the user prior to deletion.

You can check to see if the user exists in O365 or in the recycle bin using the following commands:

Get-MSOLUser -UserPrincipalName “UserPrincipalName”

Get-MSOLUser -UserPrincipalName “UserPrincipalName” -ReturnDeletedUsers

If the user exists in O365 at all, one of these commands should surface it. At this point you have a couple of options. You can undelete the original user in the local AD. This would allow you to resync the user with the correct unique identifier back up to O365, which would in turn take the O365 user out of the recycle bin and reconnect it to the synced local user. That would be too easy though J.

Instead we are going to assume you need to sync up the new user from AD to O365. That means we need to clean up the desynced user from O365 recycle bin. The following command does just that, but first make sure you absolutely do not need any OneDrive or other linked data from this account before deleting it permanently from the recycle bin, because it won’t be coming back after that:

Get-MSOLUser -UserPrincipalName “UserPrincipalName” | Remove-MSOLUser –RemoveFromRecycleBin

Next re-run the command to make sure the user is no longer in the recycle bin:

Get-MSOLUser -UserPrincipalName “UserPrincipalName” -ReturnDeletedUsers

Now it should be safe to re-create or re-sync your user back into O365. There are similar CMDLets for working with Contacts and Distribution Lists in O365 such as:

Get-MSOLContact

Remove-MSOLContact

However, you should be aware that deleted contacts and DLs do not go to the recycle bin. They get deleted straight away, so make sure you really want them gone before deleting them at all.

There is so much you can do in O365 via PowerShell that would be incredibly difficult and time consuming, if possible at all through the GUI. Hopefully this article has given you a head start on working with O365 and PowerShell.

About the Author: