Tag Archives: active directory

Configure PDC Emulator NTP Settings Using GPO

Active Directory,

Active Directory was something I used to spend quite a lot of time working with, but not quite as much these days.  However, this is a trick not many people are aware of.  If you’re familiar with Active Directory, you know that the PDC Emulator FSMO Role Holder in the root domain of the forest needs to be configured to use an external time source.  All other domain controllers should not.  It’s easy enough to do; however, anytime this FSMO role needs to be moved, especially unplanned but even when planned, configuring the new domain controller is often overlooked, as is the old FSMO role holder being reset back if it is to continue running.

However, it’s actually pretty easy to just configure a GPO to target only the PDC Emulator in the root domain to configure NTP settings.  This automates the configuration.  You can simply leave all your domain controllers to default NTP settings, and let this do the work for you.  It’s self-tuning and corrective.  I don’t know about you, but I like stuff that does work for me.

First, create a WMI Filter called “PDC Emulator” that targets the PDC Emulator in the root domain of the forest.  The filter should be:

Select * from Win32_ComputerSystem where DomainRole = 5

Next, create a GPO to accomplish this task, apply the WMI filter above to it, diable the User Configuration portion of the GPO to help reduce login times, and link it to the Domain Controllers container.

Set the following options as follows:

Administrative Templates/System/Windows Time Service/Time Providers

Configure Windows NTP Client – Enabled with the following options:

NTP Server: tock.usno.navy.mil,0x1 ntp-s1.cise.ufl.edu,0x1 ntp.colby.edu,0x1 (Use whatever servers you want, but it’s recommended to use an odd number greater than 1 that are geographically dispersed, but are managed by the same entity.  All three of the above are run by the US Naval Observatory across the east coast.)

Type: NTP

CrossSiteSyncFlags: 2

ResolvePeerBackoffMinutes: 15

ResolvePeerBackoffMaxTimes: 7

SpecialPollInterval: 900 (Default is 3600, but if your PDC Emulator is ever running on a virtual machine, VMware recommends this be set to 900 due to higher clock drifts within VMs.  This simply causes the machine to sync time more often with the NTP server, so it shouldn’t harm physical machines honestly, either.)

EventLogFlags: 0

Enable WIndows NTP Server – Enabled

Allow Active Directory replication to occur or force replication if you like, and refresh the PDC Emulator’s GPOs.

Hope this helps!

Most important Active Directory attribute of all!

Humor,

As I’m writing this, I’m prepping to leave for a much needed vacation, followed by VMworld 2015.  Of course, these have been queued up for release to maintain a three per week schedule, so I’ve been blogging my normal amount plus queuing a bunch for my vacation. So I’m going to indulge on a fun, pointless blog post for once.

I stumbled upon this, and thought it was pretty funny.

Behold, the most important Active Directory attribute of all!  🙂

Expect lots of VMworld goodness starting Monday!

Why don’t people use stub zones?

DNS,

This is one of the more odd things I’ve noticed as a trend in DNS configurations – clear examples of where stub zones should be used, yet I rarely ever see stub zones in environments except for the ones I set them up for.  I suspect it may be because there’s so much widespread misunderstanding of what they are, so people don’t use them, even when they should.  Hopefully, this post might clear up what stub zones are, how they work, and when to use (and not) use them.

What are stub zones?

Stub zones are DNS zones that contain only the SOA, NS, and A glue records for a domain.   Otherwise, they don’t store any other records, such as other A records, PTR records, MX, SRV, TXT, etc.  They’re used to help facilitate name resolution for other domains your DNS servers must resolve that your DNS servers don’t host. Once a stub zone is created on a DNS server, the DNS server connects to the identified DNS server it was told to get the NS, SOA, and A glue records from, and copies down all those records only.  Now, the DNS server knows where to get the name servers responsible for resolving forward lookups for the external domain, so they go there automatically to resolve all records within that domain’s forward lookup zone.  They were added as a feature to Windows 2003 DNS servers to facilitate cross domain DNS name resolution.  You can read Microsoft’s official answer here.

Are stub zones just DNS conditional forwarders/forwarding?

While stub zones and DNS forwarders share the same purpose, they’re not quite the same thing.  DNS forwarding is a simple rule on a DNS server that states “connect to these DNS servers to resolve IP addresses for domain whatever.com”.  They’re static rules that don’t automatically update.  Until Windows Server 2008 and higher, you couldn’t automatically configure all your DNS servers in your domain to use the same forwarding rule, but 2008 did add this ability.  Another important distinction is that forwarding does NOT store DNS zone records, while stub zones do, but don’t let that confuse you from the fact stub zones and forwarding accomplish the same goal, just differently.

Stub zones can also propagate settings effectively like DNS forwarding does with Windows 2008 depending upon how you set the zone up to be stored.  If you use to make the stub zone Active Directory integrated, the zone is stored in AD, and is replicated to at least all the domain controllers in the domain where you created the stub zone, and potentially through the forest.  The key difference between the two in the end as far as functionality is concerned is that stub zones have the distinct advantage of automatically updating what the DNS servers are for the other domain, so long as the administrators of the other domain keep the NS, SOA, and glue A records updated properly.  With forwarding rules, whenever a DNS server for the external domain is added or removed, you must update your forwarding rule, but that’s not the case with stub zones.

When should I use stub zones, and when should I use forwarding?

First off, stub zones are not useful for resolving broadly all internet DNS names.  You use a catch all forwarding rule typically for this, or root hints.  Stub zones (and conditional forwarding for that matter) typically are for situations where you want to resolve DNS names that aren’t on the internet.

With that said, between the two, stub zones are the better choice, provided your DNS environment meets the following:

  • All your DNS servers can connect to all the external DNS servers for that other domain.
  • There’s no significant advantage to have some of your DNS servers consistently connect to varying DNS servers for the other domain.  For example, if you had let’s say two DNS domains internally for domain1.local and domain2.local, and you had two physical sites, with DNS servers for both domains in both sites, if there’s a compelling reason that DNS servers in site 1 always connect to the DNS servers for the other domain also in site 1, stub zones are not the best solution, because you can’t within a stub zone use such rules to dictate which DNS servers identified stored in the stub zone to use.  Your DNS servers will use any DNS server for the other domain.  In this day and age, DNS traffic isn’t exactly eating up bandwidth, and remember that DNS records are cached anyway, so unless you have a bunch of records with low TTL, this generally doesn’t matter.

Why aren’t stub zones used more then?

I think honestly people just know conditional forwarding works, they understand how it works, so they use it instead, even when stub zones would be the clearly better choice.  I only point out that if name servers may change either by adding or removing them from the external domain, you have to keep on top of that, whereas stub zones would automatically update in those events.  The advantage of stub zones increases the more external domains your DNS servers must resolve other than through internet DNS servers, the more the external domain’s DNS servers change, and the more segregated the management of the DNS servers between the domains are.  For example, if domain1.local’s DNS zones are managed by a different team than domain2.local’s DNS servers, either domain’s admins might not remember to tell the admins of the other domains that DNS servers have changed.  Stub zones would have automatically done that.

Yet, stub zones are consistently the redheaded stepchild in DNS design.  But don’t forget about them.  They’re extremely useful, and we should look to use technologies that can help automate our environments.

What about you?  Do you use stub zones?  Why or why not?

Fix AD Lingering Objects with PowerShell

howto, ,

I briefly ran a blog before on wordpress.com, and most of the information there is outdated, or probably not relevant today, but there are a few posts that I’ve found little else on the internet to address.  These typically harken back to my AD/Exchange heavy days, but they’re still relevant today.  One of those posts is how to fix Active Directory lingering objects using PowerShell.

I ran into a problem in a large forest with multiple child domains and lots of domain controllers – 10 domains and 275 domain controllers!

To protect identities, let’s assume a forest consisted of domain.com, with two child domains – child1.domain.com and child2.domain.com.  Each domain has 2 global catalog servers (gc1, gc2), and one domain controller that is not a global catalog (dc1).

What are lingering objects anyway?

Remember that at least one domain controller in each domain must be a global catalog server.  GC’s have a copy of all objects in the forest, but only a subset of each object’s properties is found in AD.  For all objects in a GC that are not in that domain controller’s domain, the GC has a read-only copy.  You cannot manually go in and alter, create, or delete objects directly in the Global Catalog for objects that reside in another domain.

Lingering objects occur when through a variety of ways, a global catalog in one domain ends up with objects that no longer exist in another domain.  For example, let’s say a user exists in child2.domain.com and is deleted.  If somehow this doesn’t replicate to a GC in child1.domain.com or domain.com, the global catalogs in domain.com and child1.domain.com now have that user as a lingering object.  This can occur through a variety of ways, such as replication failures, or a global catalog server was disconnected for a long period of time.

Further info can be found here.

To find if you have lingering objects on a domain controller, you must run the following command:

repadmin /removelingeringobjects ServerName ServerGUID DirectoryPartition /advisory_mode

Simply remove the /advisory_mode switch to remove lingering objects.

ServerName is the fully qualified domain name of a global catalog that has lingering objects.  ServerGUID is a domain controller’s GUID from the domain that the lingering object is from, and you’d like to use it as a reference.  DirectoryPartition is the distinguished name of the GC partition with the lingering object.  Usually, lingering objects are computer or user account objects, so this would look like dc=domain,dc=com.
Finding the DC’s GUID can be done by looking in the forward lookup zone _msdcs.domain.com.

Lingering objects can cause problems with outdated or invalid group membership, problems with address book generation with Exchange, or basically problems with anything that depends upon valid info within the global catalog.  It can even cause replication failures depending upon your global catalog replication topology, and if you have strict replication enabled.

Scenario
Let’s say you suspect gc1.child1.domain.com has lingering objects from child2.domain.com.  You would first need a GUID of a DC in child2.domain.com that you believe has accurate domain information.  Let’s say you believe that dc is GC2.child2.domain.com.  Use the DNS MMC, connect to a DNS server hosting domain.com, look in the _msdcs.domain.com zone, and you will see all domain controllers in your forest.  Copy the GUID to your clipboard.  Let’s say GC2.child2.domain.com’s GUID is:

85d158d2-a006-4fff-b1e5-f9b6eaabab2b

You would then run:
repadmin /removelingeringobjects gc1.child1.domain.com 85d158d2-a006-4fff-b1e5-f9b6eaabab2b dc=child2,dc=domain,dc=com /advisory_mode

Note you need the Windows Support Tools installed.

This isn’t so tough.

However, if you suspected all your global catalogs had lingering objects for this domain, you’d need to run this command for each GC not in child2.domain.com.  Not terrible for this small of an environment.  To fix them, just chop off the advisory mode switch, and you’re done.

Think Big!

What if your environment was a 10 domain forest with over 100 domain controllers, and no predictable pattern of which domain controllers were global catalogs and which weren’t?!  Even if you knew which were global catalogs, who wants to issue that many commands?!

Wouldn’t it be nice is if we could issue this command to every global catalog not in child2.domain.com (since their GC’s have writable copies of the partition, theirs would be correct and would fix lingering objects on their own)?

That is what I faced.  I found replication wasn’t occuring for a domain partition in the global catalog because strict replication was enabled, and all global catalogs outside of a particular domain had lingering objects.  Talk about a pain in the butt!  Unless of course…
PowerShell to the rescue!

We can easily get all the global catalogs in the forest:
$forest = [system.directoryservices.activedirectory.Forest]::GetCurrentForest()
$forest.globalcatalogs | select-object name

You would receive output of the fully qualified domain names of all global catalogs.
But wait.  We only want GC’s that are NOT in child2.domain.com.  Simple enough with a where-object filter.

$forest.globalcatalogs | where-object {$_.name -notlike “*.child2.domain.com”} | select-object name

Now we just need to set this to a variable, so we add “$gcs = “ to the beginning of the second line.  This will allow us to have an array we can then perform an action or command on.  The last part is a bit tricky because we’re intermixing PowerShell with a standard command line.  Usually, you need to use the ‘ character around phrases.  Also, in this case, we’ve actually grabbed objects within the $gcs variable, so we want to make sure we’re not passing any other properties or code associated to objects.  We literally just want the name of each to be passed.  Remember, $_ means every object in the pipeline.  By adding .name, we’re saying don’t pass any other output related to each object in the array other than it’s name.  Without it, you get errors because PowerShell is putting extra characters in for each Global Catalog.

Final commands:

$forest = [system.directoryservices.activedirectory.Forest]::GetCurrentForest()
$gcs = $forest.globalcatalogs | where-object {$_.name -notlike "*.child2.domain.com"} | select-object name
$gcs | foreach-object {repadmin /removelingeringobjects $_.name 85d158d2-a006-4fff-b1e5-f