Recently I was testing renaming the NETBIOS name of an Active Directory domain. While this process is fairly easy, there are a few gotcha’s, and before one would like to rename their domain or NETBIOS name, serious testing is required to be sure everything works after rename. In the end, if something goes wrong, the rollback will not be a walk in a park. It will hurt, and it will eat your time. So there was I going thru the usual steps.
Active Directory
In March 2020, Microsoft will release its monthly updates. With those updates, Microsoft will disable insecure LDAP Bindings, which is going to break a lot of your systems (hopefully not). But this was already communicated, and you know all about it, right? If not, you should read those two articles that can help you with understanding what is happening and when.
Setting up a new Active Directory is an easy task. You download and install Windows Server, install required roles and in 4 hours or less have a basic Active Directory setup. In an ideal world that would be all and your only task would be to manage users, computers, and groups occasionally creating some Group Policies. Unfortunately, things with Active Directory aren’t as easy as I’ve pictured it. Active Directory is a whole ecosystem and works well ranging from small companies with ten users to 500k users or more (haven’t seen one myself – but so they say!). When you scale Active Directory adding more servers, more domains things tend to get complicated, and while things on top may look like they work correctly, in practice, they may not. That’s why, as an Administrator, you need to manage Active Directory in terms of its Health and Security. Seems easy right? Not quite. While you may think you have done everything, checked everything, there’s always something missing. Unless you have instructions for everything and can guarantee that things stay the same way as you left them forever, it’s a bit more complicated. That’s why Microsoft delivers you tools to the troubleshoot your Active Directory, such as dcdiag, repadmin and some others. They also sell monitoring solutions such as Microsoft SCOM which can help and detect when some things happen in your AD while you were gone. Surely there are some 3rd party companies give you some tools that can help with a lot of that as well. Finally, there is lo of folks within the community creating PowerShell scripts or functions that help with some Health Checks of your Active Directory.
I shouldn’t be telling you that, but Active Directory Backup is an essential part of your Active Directory setup. When a backup of Active Directory happens, AD is aware of it. Following PowerShell solution allows you to get Active Directory Last Backup Time for the whole forest or by domain.
One of the common ways to connect to Active Directory is thru LDAP protocol. There are a lot of applications that talk to AD via LDAP. By default Active Directory has LDAP enabled but that’s a bit insecure in today’s world. That’s where LDAPS comes in. It’s not easy to set up, but when you get it done, it works. The problem I had recently is that while setting up LDAPS on DC’s I only did this on some of the DC’s, and not all of them as I should.
In Active Directory when you change something, it’s replicated to other Domain Controllers regularly. It’s a standard procedure that happens automatically in the background for you. It’s a handy feature because you can have multiple DC’s all over the world and have your users data in sync. You can change almost anything on DC nearest to you and be sure it will be the same value all over the place. But is it always the same? Well, it should be unless it isn’t. Today I was given a new migration from Exchange to Office 365. I started with ADConnect installation and wanted to make sure that UserPrincipalNames have all UPNSuffixes in place.
Having Bitlocker and LAPS in modern Active Directory is a must. But just because you enable GPO and have a process that should say Bitlocker and LAPS are enabled doesn’t mean much. Now and then you should verify things yourself. One of the Facebook users on PowerShell group just had this idea of exporting Bitlocker keys and then giving that list to his colleagues for manual verification. He wanted to do it half PowerShell and half manually. While the idea was great, why not take full advantage of PowerShell and have a helpful report with all the necessary information?
There was I, deploying PSPasswordExpiryNotifications for one of my Clients when I started getting complaints that some users are not getting their Password Expiry Notifications. Well, that’s a new one. I’ve tested this script multiple times, and it worked just fine. So I dive into the details of my script to see what I did in there (I don’t even remember anymore – it just works) to find out this little line:
I’ve been working today trying to deliver to one of my Clients Active Directory documentation. To my surprise, something that worked fine for a very long time has started to provide weird results. So, after spending about 8 hours taking apart a few of my PowerShell modules trying to find out what is wrong finally, I’ve found it: Export-CliXML / Import-CliXML. Those two commands are great. I’ve used them multiple times with great success (or so I thought).
Today I saw an article on how to get Windows Version Report from Active Directory and thought that this is a cool idea. Something handy for migration scenarios or information on how up to date is your infrastructure. Since there are many ways to do the same thing I decided to tackle this myself and further include it into PSWinDocumentation.AD project. By default Active Directory stores Operating System and Operating System Version but it doesn’t really show versions one may expect.