Being a Microsoft MVP has quite a few benefits. You get to be part of unique offers that help you enhance your knowledge even further. Microsoft Learning team decided to provide free training on Microsoft Fundamentals for MVPs and the Microsoft community, so I’m sharing this with you! Starting next week, Microsoft will run each activity from 9 AM to 5 PM Eastern Standard Time (EST) or 15:00 to 23:00 in Europe (CET).
azure
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.
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.
Azure AD Connect is an application responsible for synchronizing Active Directory with Azure AD allowing for a natural population of users, groups, and devices in Office 365. While for most companies standard setup is very easy and most of the time touch-free, there are companies which require greater customization. During installation of AD Connector, you choose what should be used for Azure AD Username from your AD. UserPrincipalName field is an obvious choice for this and also proposed by default for that purpose. This field is utilized further by your users to log in to your Exchange, SharePoint, Teams and so on.
