I’ve been testing Disaster Recovery scenario restoring Active Directory. One of the servers was restored, and it worked for a moment after restore. If you can regain your Primary DC, it’s best to do so. If you can’t, a standard thing to do during DR is to move all FSMO roles to the restored server so that it can become a master server. You can find out your FSMO holders by using those commands below:
active directory
Working as a freelancer is a great thing if you can handle it. Each day, each week something new happens and a new problem shows up on my doorstep. It also means it’s almost never boring at your job and you get to play with new stuff. But there’s one drawback to this. You’re often thrown at the problem, told to fix it but often that’s about as much information as you get. It wasn’t very different today. I was told to switch Office 365 from ADFS to Password Synchronization. While reasons for this are not really important, the important question here is what is the name of AD Connect server that’s responsible for this configuration?
I’ve been working with Windows Events for a while now. One of the things I did to help me diagnose problems and reporting on Windows Events was to write PSEventViewer to help to parse the logs and write PSWinReporting to help monitor (with use of PSEventViewer) Domain Controllers for events that happen across the domain. It’s handy and I, get those excellent daily reports of what happened while I was gone.
When working with Active Directory one of the common tasks is to move FSMO roles between servers. Well, maybe not that common but it happens from time to time where you have to move all or just some of the FSMO roles. For that purposes, there is single PowerShell command Move-ADDirectoryServerOperationalMasterRole. Sure you can do this via GUI but if there’s one command available to fix it all why bother? To make the move one has to be a Domain Admin, Enterprise Admin and Schema Admin. Everything was going smoothly for some roles but wasn’t working for others.
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.
If you’re paying attention to what’s happening around the world now you probably know Have I Been Pwned service by now. You probably know that it has huge lists of hashes of passwords that leaked out over the years from different services (LinkedIn, Adobe, and so on). This means those passwords are now in possession of good guys, but also bad guys. With Active Directory being often a central place to store your password that allows you to access your Office 365 account, ADFS, Microsoft Exchange it’s important that your AD passwords is both secure and safe. Bad guys may want to try and access your email accounts or other data that’s available online. And having a list of passwords you or other people may have used before doesn’t help you in protecting your own data.
A few weeks ago I’ve released my first version of PSWinDocumentation. It was simple, one command module where you start it and get some basic AD stuff into Microsoft Word document. Today… I’m releasing a new version that has a bit bigger feature set. Are you ready for it? Let’s go!
