Office 365 has high SLAs (the latest English version) backed by Microsoft’s excellent Azure Cloud. However, like every other cloud services, there is always the chance for something unexpected to happen. This year April Office 365 had a major hiccup to its service. Its Asia Pacific backend Azure AD authentication went haywire. As a result, users lost access all O365 services. To make it worse, the usual Office 365 monitoring channel: Office 365 dashboard was not accessible due to this fault.

I had a long holiday in China recently. It had been a fun and eyes opening trip. Feels like the whole nation is in the middle of a “technology revolution”. Among all, Internet has become one of the core driving force. But while Wifi beomces a life essential here, the infamous Great Firewall (GFW) is also getting more effective. After tried numbers of paid and free VPN providers, I just could not find a reliable VPN service to simply let me post a picture on Facebook.

In my last article, I discussed the steps to setup AWS SSO through Azure AD. By using Azure AD app roles, we are able to use our Azure AD accounts to access AWS Console. But with this measure, you will find there is no option in AWS IAM to generate Access Key and Secrete for CLI and API access. Fortunately, we are not the only ones out there have this problem.

As organization acquires more AWS accounts, it becomes quite a challenge for IT to manage the access to all those accounts. Instead of dealing with individual IAM accounts across multiple accounts. We need an identity solution to simplify the user access provision and removal process. AWS itself offers a service called AWS SSO, which allows integrate AWS access with on premise AD through SAML. However, the service does incur charges and will require provision of an AD Connect appliance in AWS, if you don’t already have ADFS in place(Yes, it has the same name as Azure AD Connect).

Migrate Azure AD Connect Between AD Forests I was recently involved in an AD forest migration project for one of our customers. As part of the requirements, we need to move the existing AD Connect server to a newly created AD forest. While the process itself is pretty straight forward, I do notice there aren’t many online resource out there detail the whole process. So to make things even easier for the folks out there, I will share the steps I took to complete this AD Connect migration.

Ran into an interesting issue with one of our Exchange Online customer. Thought it probably worth sharing with the solution I found. The customer has an Exchange Hybrid setup. Recently some of Office 365 Exchange Online users complain they cannot email to a particular on premise mailbox: [email protected]. The user bascialy does not show up in Exchange Online GAL. The on premise mailbox is working fine and other on premise staff can send emails to it without issue.

Recently I received some complains from our US users about the timestamp of our SharePoint site hosted in Office 365. The timestamp of the documents and folders on the site are all showing Australia Eastern time for them. It takes me sometime to find out how to allow each individual user to see their local timestamp. This requires some setting changes from the user end. Here is what needs to be done.

It happens to me quite a few times. After synced On-Premise AD user objects into Office365 through DirSync, users' specified UPN will not be synced correctly into Office 365. Tried all the suggested tricks from Office 365 forum. None of them worked. I even tried to re-configure our DirSync settings. But the username in O365 just refuse to change. After banging my head on this issue for a few days. Eventually I figured it out, the solution is simply to revoke any O365 licenses assigned to the user.

Recently I was working on Exchange Hybrid Deployment for one of our customer. The Hybrid Configuration process itself went smoothly. No errors for HCW. The problems came when I tried to move mailbox to Exchange Online. The migration fails with error: Target mailbox doesn’t have an SMTP proxy matching ‘.mail.onmicrosoft.com’" To check that I ran the following command against the On-premise Exchange. Get-Mailbox “O365 Test5” | fl and check the EmailAddress filed