Active Directory tips, tricks, and tweaks

Sometimes it can pay off to dig into that bag of tricks you’ve been accumulating from talking with colleagues in the IT profession. This recently happened to me when I was asked to give some advice concerning an issue an organization was having with replication in their Active Directory environment. In researching their problem, I came across a whole lot of other Active Directory tips and tweaks that I’d come across during my meanderings across the tech landscape, and I thought it might be helpful for readers who work with Active Directory to share some of these with you. As usual, these tweaks are presented “as is” with no guarantee or warranty, so be sure to try them out in your test environment before making use of them in a production environment. And if you have any Active Directory tips, tricks, or tweaks of your own you’d like to pass on to readers, you can send them to me at [email protected] and I’ll either include them in a followup article on this topic or share them with the 400,000 readers of our popular WServerNews weekly newsletter.

Tip: Firewalling countries

One consultant I know was asked to provide some advice to an enterprise that had an Active Directory forest deployed across several countries including one country (Country X) that they didn’t trust so much even though they had a branch office located in that country. The organization wanted to put some firewalls in place between the networks located in each country while still allowing Active Directory to function properly with the idea that if the network in Country X was compromised the damage could be contained, and Active Directory in the remaining countries would remain unaffected. He asked me if I had any suggestions or recommendations on how to implement such a solution, and I said that I vaguely remembered reading something and would get back to him soon.

Anyway, as I searched for any resources that might help him, I came across the following Microsoft Knowledge Base (KB) article: How to configure a firewall for domains and trusts. Although this KB article focuses on Windows NT (yikes!), Windows 2000 Server (golly!) and Windows Server 2003, none of which are supported any longer by Microsoft, a quick look at the article’s footer shows that the article has been revised five times and is guaranteed as accurate up to Windows Server 2012. I would hazard a confident guess that it’s still valid for Windows Server 2016 as well.

But as I read through this interesting article I came across the following statement:

“For more information about Active Directory and firewall configuration, see the Active Directory in Networks Segmented by Firewalls Microsoft white paper.”

And when I read this I thought, “Aha! That’s what I’ve been hunting for” because I recall reading that particular whitepaper way, way back shortly after the turn of the Millennium. So I clicked on the link that was embedded in the above sentence to download the whitepaper and got, “We’re sorry, this download is no longer available” in response.

Fortunately, an IT architect named Angelo Schalley who lives in Belgium archived the updated 2004 version of the original 2002 whitepaper and you can find the PDF version among the downloads for his blog. I say “fortunately,” because I chatted with a premier field engineer (PFE) at Microsoft who works with Active Directory and he said that as far as he was aware, the information presented in this whitepaper was most likely still valid. So I’d advise any of you who administer Active Directory in large enterprise environments to download and save a copy of this paper in case you ever need it in the future because, unfortunately, Microsoft seems to have a policy of trashing old documentation even when it still might have usefulness and validity. The moral of the story? Successful IT pros are packrats.

Anyway, I suggested the KB article and whitepaper to my colleague, and he said it basically answered most of his questions. I did find one other related whitepaper, Active Directory Domain Services in the Perimeter Network, that dates back to the Windows Server 2008 era (which is also now out of support) but I think it’s probably still pretty accurate. Unfortunately, the link to that whitepaper also is no longer available either! What’s with Microsoft these days? Are they running out of disk space in the cloud they use for their Download Center? Do they think no one is using Windows Server 2008 any longer?? Whew, turns out the content of this whitepaper is still available in another form on TechNet. But for how long?

Trick: Listing sites

Here’s something that was passed on to me from a colleague who says he got it from an engineer inside Microsoft. It’s a PowerShell script that uses Lightweight Directory Access Protocol (LDAP) to list all of the sites in an Active Directory forest. What’s cool about this script is that it works without a domain controller:

import-module activedirectory
$ADRootDSE = Get-ADRootDSE -Properties *
$ADconfigurationNamingContext = $ADRootDSE.configurationNamingContext
Get-ADObject -searchbase $ADconfigurationNamingContext -LDAPFilter “(objectclass=site)” | ForEach-Object {
# no NTDS Settings object? Empty site.
if (-not (Get-ADObject -searchbase $_.distinguishedname -LDAPFilter “(objectclass=ntdsdsa)”))
{
$_.name
}
}

Tweak: Separate disks

Those of us who have worked with Active Directory for a long time and have promoted literally hundreds or perhaps even thousands of domain controllers have probably struggled over this one: Should the Active Directory directory database and log files be placed on the same or different disks? And is it OK to store them on your boot volume or should they be located on some other disk or partition?

Guidance for this seems to have varied over the years depending on who you talk to. This article by Sander Berkouwer from way back in 2007 tried to bring a reasoned analysis to the problem, but a lot has changed since that time, especially with regard to system hardware such as CPU speeds and storage capacity. In fact, the whole idea of separating the directory database, log files, and SYSVOL onto separate spindles to minimize disk I/O pretty much doesn’t make any sense today given the speed and capacity of system hardware used for domain controllers, even those deployed in the cloud. Way back in the old days, when the cloud was mostly mist, the decision for separating the directory database and log files onto separate drives was basically driven by load. That’s because way back then, our domain controllers were often I/O bound due to the limited amount of cache memory available for the directory database, which if I recall correctly, was around a gigabyte or so. But now we only use x64 systems where the amount of RAM available for the cache is more than the size of the directory database, which means there’s really no longer any possibility of a domain controller becoming I/O bound.

That doesn’t mean this never happens, however. For example, certain operations involving groups in Active Directory can result in a very high write rate for a short period of time, which can effectively cause your domain controller to become temporarily I/O bound. And when the cache is being warmed up, that can also briefly result in more I/O that Active Directory can gracefully handle. But if you simply back your directory database with a good-quality sever-grade solid state disk, then the chance of I/O becoming a bottleneck is approximately zero.

On the other hand, you might still consider the following tweak when you’re promoting a Windows Server system to the role of domain controller. The tweak is to locate your directory database, log files, and SYSVOL folder on a separate volume than the system volume where the operating system and Active Directory service binaries are located. For a system running Windows Server 2016, we’re talking about the Paths page of the Active Directory Domain Services Configuration Wizard, which you can see in the screenshot for step 17 in this DCPROMO walkthrough on the CANITPRO.NET blog. So instead of simply accepting the defaults of C:\Windows\NTDS for your database and log files folders and C:\Windows\SYSVOL for your SYSVOL folder, you could tweak this a little and use D:\ or some other drive instead for locating these files.

What’s the rationale for doing this tweak? A colleague of mine asked a PFE this question and was informed that it “might reduce the noise affecting the DFSR journal thread,” which in layman’s language I think means that Active Directory replication might perform more smoothly and with fewer interruptions or delays. So with this bit of practical advice I’ve now decided to adopt this small change when promoting a member server to the role of domain controller, but I really don’t know if it’s making any difference in how the Active Directory environment performs. Perfmon, anybody?