I decided to give it a little try to see more and it works like a champ. Very cool to see this capability coming to light as it’s been something that I know I’ve been looking for some time to have available when a VM wasn’t coming back up slower than I would have assumed it would. Well done folks!

If you happen to log into your Office 365 Admin Portal on a regular basis good on you – though perhaps you can get most of your alerts through the Office 365 Admin app on your phone. If you do happen to log in though and you’re using Directory Synchronization by way of either Azure AD Connect or Microsoft Identity Manager, you hopefully don’t stumble upon a message like this on the Home page.

If you do though, don’t worry, it’s not just a red highlighted bit of text, but it’s a link to your Directory Synchronization status (not DirSync is no longer around… AAD Connect is the way to go these days). What does it mean to your end users if Directory Synchronization is failing? Well, any change that they happen to make to their profile within your on-premises Active Directory won’t be synchronized with Azure Active Directory until the issue is resolved. Not a big deal – right? Well, just think if you changed your password on-premises, you’ll still be using your old password through Office 365.

If you happen to click the error message though you’ll come to a page with this displayed, you’ll note that you see something like this:

If you’re not familiar with the above, it’s the Sync Status Health page. Typically if things are working good then you’ll see the last time that you sync’d successfully in addition to other pertinent information about your Office 365 tenant’s synchronization status as well as a less stormy picture of the cloud. 🙂

In this case, it just happens to be that I turned off the server that the Azure AD Connect tool was running on. Turning the server back and on and the error messages go away and identity changes begin to synchronize once more – life is good.

So you have a proof of concept Office 365 instance and you realize that you want to take things to Production, but you also realize that you want to keep your POC tenant up and oeprational. Caveat, you went through and applied your Domain Name to your tenant thorugh another registrar. How do you get your domain back?

The gist of the script was running get-msoluser and feeding that to an array. From there looping through and modifying the UserPrincipalName’s domain name. Required a little more work than expected but in the end, worked quite nicely.

If you’ve only got a few users, probably easy enough to make this change through the Office 365 Admin UI. If you’ve got more than a few, PowerShell is your friend – working with arrays and foreach clauses to filter out the users you need to update to the “onmicrosoft.com” domain or another domain you’ve established and working.

After you get below a certain number of users (unknown what that is) with the non-offending domain remaining in the UPN, you can delete the domain from the tenant.

From there you can change your DNS settings back within your DNS registrar to continue making use of the domain or setting it up on your new Office 365 tenant that you’re actually switching over to use for production.

Nevertheless, be sure to try this all out in a test tenant and be mindful that if you’ve got a provider hosted app that’s looking for a specific domain name associated with a user and it’s changed, the user’s access may also have been changed with it. This is similar to if you have an on-premises application and you modify the user’s User Principal Name on-premises – applications that used to rely on that begin to break.

Bottom line – TEST! TEST! TEST!

After you’ve worked out the kinks, you should be good to go! Best of luck!

One of the funnier things that I run into every so often is when someone’s Office 365 implementation isn’t working because their firewall administrator is following the age-old practice of least permission. Definitely, a good way to keep your environment secure, and I wouldn’t tell you not to go down this path… but you probably want to tell your firewall admin to open up the IPs and URLs that are needed for your end users to make use of Office 365 appropriately.