Active Directory Domain Services could not replicate the directory partition – The replication operation encountered a database error

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.

I’ve been in IT for a longer time now. I’ve made my fair share of mistakes and misconfigurations. One of those misconfigurations was removing Authenticated Users from Security filtering in Group Policy Objects. While it worked fine at some point Microsoft rolled out a Hotfix MS16-07 on June 14th 2016.

Active Directory replication is a critical process that ensures the consistent and up-to-date state of directory information across all domain controllers in a domain. Monitoring this process is important as it helps identify any issues that may arise and resolve them quickly. One way to monitor Active Directory replication is by using the Repadmin command-line tool. Repadmin provides a wealth of information about the replication status and health of a domain. However, manually checking the Repadmin output can be time-consuming and tedious, and running it manually every 30 minutes just to check if everything is great doesn’t seem like a great idea. While PowerShell has its own commands around replication I’ve not found something as fast and reliable as repadmin /replsummary.

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.

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:

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.

PasswordSolution uses the DSInternals PowerShell module to gather Active Directory hashes and then combines that data into a prettified report. If you have ever used DSInternals, you know that while very powerful, it comes with raw data that is hard to process and requires some skills to get it into a state that can be shown to management or security.

Duplicate SPNs aren’t very common but can happen in any Active Directory as there’s no built-in way that tracks and prevent duplicate SPN’s. One has to either know all SPN’s in the environment, track them or check each time whether it already exists or not. Things get more complicated with larger Active Directory environments as people change, new apps are added, old apps are forgotten, but SPNs prevail.

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.

Have you ever looked at your Active Directory and wondered, “Why do I still have computers listed that haven’t been turned on since World Cup 2016?” Yeah, we’ve all been there. Keeping AD clean and up-to-date is like trying to organize your garage—it’s easy to put off until it becomes a total mess.

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.

I was scrolling X (aka Twitter) today and saw this blog post, “PowerShell: Report On-Premises Active Directory Accounts that are Synchronized with Azure AD Connect” by Kevin Trent. I like reading blog posts as I tend to learn some new things and see how people tend to solve their problems.