Office 365 is a huge beast. It has so many services that it’s hard to track all of them. It’s even harder if you want to manage Office 365 using PowerShell. Microsoft makes many different PowerShell modules available for you, such as AzureAD, AzureADPreview, ExchangeOnline, MicrosoftTeams, and recently, Microsoft.Graph. But even with so many different modules, there are still tasks that Microsoft won’t let you do from PowerShell. But it doesn’t mean that it’s not possible to do it. I’ve spent some time tracking how Microsoft does things while you click thru the interface and created an O365Essentials PowerShell module that can do it in an automated way.
Some time ago I’ve wrote PowerShell way to get all information about Office 365 Service Health, and if you were thinking that I would try the same concept for Azure Services you were right. However, I failed. This is because Office 365 Health can be gathered using Microsoft Graph API, and Azure Health information, as far as I know, is not available in the form I wanted it. Azure Status is available as part of Azure Status website. Contrary to Office 365 health you don’t have to login to your Office 365 tenant to read it.
As you may have seen in my other post, there’s a simple, PowerShell way to get Office 365 Health Service data for you to use any way you like it. But before you can use that, you need to register granular permissions on your Office 365 tenant so that that data is provided to you. Here’s a step by step way to do it.
Office 365 is an excellent cloud service. But like any service, there’s some infrastructure behind it that has to be cared for. Since this is Cloud, Microsoft does this for you. But any problems Microsoft has to have some impact on your end users. And you may want to have that visibility for your users. Microsoft provides this to Admins when they login to the portal, but while useful you may want to use that data in other ways than those planned by Microsoft.
Hosting your VM’s in Azure Cloud is excellent. You have all those features, professionally managed and virtually limitless. I don’t want to take your time to sell you Azure Services but to share a solution to one of the things I had to solve in Azure and sooner or later you may end up with on. During the test restore for Active Directory and multiple other machines which were much older (or newer) then Active Directory Domain Controller that was restored it turned out one can’t log in to most of the devices. First of all your domain password is already changed, but that can quickly be addressed. Your second and more significant problem is Network Level Authentication (NLA), and your 3rd problem is broken trust relationship.
During synchronization of Active Directory with Office 365 via Azure AD Connect I was greeted with a list of accounts that have permission-issue. Error message by itself gives you a slight hint, but it doesn’t tell you exactly where to look.
Recently I had a weird case where one of our Azure servers was starting losing space pretty quickly making Pulseway go nuts. As you can assume from the title of this post the cause for this is Azure Agent itself. But before I actually knew that I had to do some digging as it’s not that obvious because Windows Explorer isn’t showing anything worth checking.