DNS Zone Types Explained, and their Significance in Active Directory

==================================================================
==================================================================
Ace Fekay, MCT, MVP, MCSE 2012/Cloud, MCITP EA, MCTS Windows 2008/R2, Exchange 2007 & 2010, Exchange 2010 Enterprise Administrator, MCSE 2003/2000, MCSA Messaging 2003
   Microsoft Certified Trainer
   Microsoft MVP: Directory Services
   Active Directory, Exchange and Windows Infrastructure Engineer and Janitor

Revisions

Original publication 4/30/2013

Prelude

Ace here again. I thought to touch base on DNS zones, and more so, focus on what AD integrated zones are and how they work. This blog almost mimics my class lecture on this topic. Check back for updates periodically, which I will notate with a timestamp above with whatever I’ve added or modified.

This topic was also briefly discussed in the following Microsoft Technet forum thread:
Technet thread: “Secondary Zones?”
http://social.technet.microsoft.com/Forums/en-US/winserverNIS/thread/c1b0f3ac-c8af-4f4e-a5bc-23d034c85400

 

AD Integrated Zones AD Database Storage Locations

First up is a background on the various parts of the Active Directory database and what gets stored in them. This will help understand where DNS data is stored as I discuss it later in this blog.

The Active Directory Data Store (the AD database):

There are three possible storage locations for DNS zone storage in the Active Directory database:

  • DomainNC – This was the only available location with Windows 2000. This replicates to all DCs only in a specific domain.
  • DomainDnsZones partition – Introduced in Windows 2003 and used in all newer operating systems. This replicates to all DCs only in a specific domain in the forest.
  • ForestDnsZones partition. This replicates to all DCs in the forest.

You can see how not all partitions are replicated forest wide. It depends on the partition:

 

Ok, Now the DNS Basics:

  • A Secondary is a read-only copy
  • A Secondary zone stores it’s data in a text file (by default in the system32\dns folder)
  • A Secondary gets a copy of the zone data from the Primary
  • A Primary is the writeable copy
  • A Primary stores it’s zone data in a text file (by default in the system32\dns folder)
  • There can only be one Primary, but as many Secondary zones as you want.
  • You must allow zone transfer capabilities from the Primary zone if you want to create a Secondary.
  • AD integrated zones do NOT need zone transfers to be allowed (see below for specifics)

Active directory Integrated Zones changes this a bit:

AD Integrated zones are similar to Primary zones, however their data is stored as binary data in the actual AD database and not as a text file. The specific place in the AD database depends on the DC’s operating system version and replication scope, which means what “logical” part of the physical AD database it’s stored in, which will affect which DCs in the forest it will replicate to.

  • The “only one Primary Zone” rule is changed by introducing the Multi-Master Primary feature. This is because the data is not stored as a text file, rather it is stored in the actual, physical AD database (in one of 3 difference logical locations or what we call the Replication Scope), and any DC that has DNS installed (based on the replication scope) will be a writeable copy.
  • The zone data is replicated to other DCs in the replication scope where the data is stored (based on one of the 3 logical locations)
  • Each DC in the replication scope that has DNS installed, will automatically make available the zone data in DNS
  • Each DC that hosts the zone can “write” to the zone, and the changes get replicated to other DCs in the replication scope of the zone/
  • The DC that makes a change becomes the SOA at that point in time, until another DC makes a change to the zone, then it becomes the SOA
  • An AD Integrated zone can be configured to allow zone transfers to a Secondary, but the Secondary CANNOT be a DC in the same replication scope as the zone you are trying to create as a Secondary, otherwise the DC you are attempting to create the Secondary on will automatically change it to AD integrated, since it “sees” it in the AD database. In some cases, if this is forced or done incorrectly, it can lead to duplicate or conflicting zones in the AD database, which is problematic until fixed.

And if you install DNS on another DC, the zone data will *automatically* appear because DNS will recognize the data in the AD database. AD integrated zones can also act as a Primary zone for secondary zones, whether they are on Windows machines, BIND (on Unix) or any other name brand.

Remember, AD integrated zones still follow the RFCs, but have more features.

 

Duplicate or Conflicting zones?

Since I touched based on duplicate and conflicting zones, you may want to check if they exist in your AD database. You have to check each partition, and if you have more than one domain, you have to check the DomainDnsZones and DomainNC of each domain. You may even have to check it on multiple DCs in various AD Sites to see if they all “see” the same copy or different copies. You would be surprised what I’ve seen with AD replication problems and seeing different DCs “seeing” something different in its own database. This issue also manifests as a symptom in more than just a DNS problem, where you create a user on one DC and it never replicates to another DC.

Using ADSI Edit to Resolve Conflicting or Duplicate AD Integrated DNS zones
http://msmvps.com/blogs/acefekay/archive/2009/09/02/using-adsi-edit-to-resolve-conflicting-or-duplicate-ad-integrated-dns-zones.aspx

 

Primary Standard Zone, Secondary Standard Zones & Zone Transfers

Zone transfers allow you to create a read only copy (a Secondary zone) on another DNS server, that will pull a copy (transfers) from the read/writable zone (the Primary zone).

Primary and Secondary zones store their data as text files.

On a Windows machine, the zone files can be found in the \system32\dns folder with a file name such as “domain.com.dns”. You can have numerous read only copies, but there can only be one read/write of that zone.

Please keep in mind, the authoritative DNS server listed in the registrar for a public domain name (zone) does not have to be a Primary, it’s just the host nameserver listed as authoritative. It can get it’s data from a Primary that is not listed, hence the writable copy is actually hidden and protected from public access.

Do I need Zone transfers Allowed for AD Integrated Zones if I do not have Secondaries Zones?

The short answer: NOPE.

The reason is that the term “AD Integrated” means the zone is stored in the AD database, and the zone will replicate to other domain controllers within the same replication scope (domain-wide or forest-wide) automatically as part of the AD replication process.

By default, AD integrated zones are configured to not allow zone transfers.

Allowing zone transfers is an option provided to support non-DC DNS servers, BIND or any other name brand DNS server that you want to allow zone transfers to a secondary on those servers.

Rotating SOA

Additional security options of AD integrated zones, is one of the feature of AD integrated zones, as well as the fact that there can be more than one Primary zone copy of it. This is because all DNS servers that host the zone in a domain or forest has the ability to be a writable copies and becomes the actual “start of authority” (SOA) of that zone when a specific DC/DNS accepts a write operation, such as a client machine registering, or the DC itself updating its SRV records.

For example, if a DC updates it’s SRV and other records at the default 60 minute interval (all other machines register every 24 hours), it will update its data into the DNS server listed as the first DNS address in the network card. This server now writes it into DNS and NOW becomes the SOA of the zone. That data is replicated to other DC/DNS servers with default AD replication. Now all other DC/DNS servers will see the change.

To further explain, since the zone is AD integrated, each and every DC in the replication scope of the zone, can accept changes, due to an AD integrated zone’s Multi-Master Primary Zone features. Based on the definition of what an SOA is, that is being the DNS server that’s authoritative to accept writes, therefore, whichever DC/DNS accepted a change to the zone, that specific DC/DNS will become the SOA for that moment in time. Then when the next DC/DNS that accepts a change, it will now become the new SOA. The SOA constantly changing in an AD environment is accepted, and default behavior.

That is why you can watch the SOA name on AD integrated zones change. The data is replicated automatically as part of the AD replication process because it is stored in the AD database.

Active Directory-integrated DNS zone serial number behavior (SOA default behavior) 
http://support.microsoft.com/kb/282826 

 

References

Configure AD Integrated Zones
(When converting to AD integrated zones)
Quoted: “Only primary zones can be stored in the directory. If a zone is configured on other domain controllers as a secondary zone, these zones will be converted to primary zones when you convert the zone to AD integrated. This is because the multimaster replication model of Active Directory removes the need for secondary zones when a zone is stored in Active Directory. Conversion of the zone from secondary to primary will occur when AD DS is restarted.”
 http://technet.microsoft.com/en-us/library/ee649181(v=ws.10)

Understanding DNS Zones
http://www.tech-faq.com/understanding-dns-zones.html

Understanding stub zones: Domain Name System(DNS)
Jan 21, 2005 – The master servers for a stub zone are one or more DNS servers authoritative for the child zone, usually the DNS server hosting the primary …
http://technet.microsoft.com/en-us/library/cc779197(v=ws.10).aspx

AD Site Design and Auto Site Link Bridging, or Bridge All Site Links (BASL)

By Ace Fekay, MCT, MVP, MCSE 2012/Cloud, MCITP EA, MCTS Windows 2008/R2, Exchange 2007, 2010 & 2013, Exchange 2013, Exchange 2010 Enterprise Administrator, MCSE 2003/2000, MCSA Messaging 2003
  Microsoft Certified Trainer
  Microsoft MVP: Directory Services
  Active Directory, Exchange and Windows Infrastructure Engineer

Updated 12/12/2013

Preface

Ace here again with something I really would like to discuss, since this topic comes up from time to time.

To properly designed an AD multi-site infrastructure, there are a few things that need to be taken into account. I won’t bore you with all the background techno babble, rather I’m going to discuss a no-nonsense, get down to business on why you need to either keep Auto Site Link Bridging enabled, or why you need to disable it, both of which depends on your physical routed topology design.

AD Sites

First, a basic understanding of Active Directory Sites is important to understand before I go further.

Some of the biggest questions I hear about AD Sites are:

  • What are AD Sites?
  • What are AD Sites for?
  • Why can’t I create an AD Site without a domain controller in the Site?

These are all valid questions. A little research will usually result in an answer, but you may have to dig through piles of technical details to get to it. Let’s address each one:

What are AD Sites?

An AD Site defines a highly-connected, physical network locations in Active Directory. We define them by IP subnet or subnets. And yes, you can have multiple subnets that are highly-connected by routers within a location. In some cases, for example, if you have a very high-speed backbone, such as an OC-1 (51.84Mbps or higher), between locations, you can put all those subnets in one AD Site. However, in many cases, we probably don’t want to do that. Hang in there, I’ll be getting to that in a few minutes.

What are AD Sites for?

AD sites are basically used for two things:

  1. To facilitate service localization. In simple English, this means to control logon and authentication traffic to DCs in a specific location, or Site. After all, we don’t want a client in NYC to pick a DC in Seattle, Japan, or somewhere else, to send its logon or authentication request (such as when accessing a folder), do we? Nope. The client side DC Locator process will find a DC in its own Site by using the client’s IP address.
  2. To manage DC replication traffic. In simple English, this means to control DC replication traffic across WAN links between the bridgeheads (the DCs in a Site that communicate with DCs in other Sites). By default, replication between Sites are compressed down to 15% of total traffic. And with Sites, we can control frequency of replication, and when we’re allowing it to happen.’

Why can’t I create an AD Site without a DC in the Site?

Good question. If you look at what AD Sites are for, then it should be pretty obvious that you need a DC in it. After all, if there is no DC in it, and a client picks a Site based on its IP subnet, then looks for a DC, it won’t find any, will it? Nope, so it may wind up randomly picking a DC in another location, such as that DC in Seattle or Japan.

DC Locator Process

I don’t want to dwell on this, but I will briefly mention it because this is part of the reason why we want to create AD Sites anyway.

There is a process that a client uses to pick a DC. Here’s a quick view of how a client picks a DC. I should add a #9 to the list in a scenario when no DC exists in the Site, then it uses Automatic Site Coverage, and this ONLY if you created an IP Site link to another Site that you want the DCs to cover that site.

If you didn’t create an IP Site link for a Site that has no DCs, then it will pretty much become a random process, sort of, by using other factors, such as subnet netmask ordering and Round Robin. If you want to read up on this subject, here are two good TechNet Forum discussions on it:

Briefly, here are the DC Locator process steps, and these steps were directly quoted from How Domain Controllers Are Located in Windows XP

  1. Client does a DNS search for DC’s in _LDAP._TCP.dc._msdcs.domainname
  2. DNS server returns list of DC’s.
  3. Client sends an LDAP ping to a DC asking for the site it is in based on the clients IP address (IP address ONLY! The client’s subnet is NOT known to the DC).
  4. DC returns…
    1. The client’s site or the site that’s associated with the subnet that most matches the client’s IP (determined by comparing just the client’s IP to the subnet-to-site table Netlogon builds at startup).
    2. The site that the current domain controller is in.
    3. A flag (DSClosestFlag=0 or 1) that indicates if the current DC is in the site closest to the client.
  5. The client decides whether to use the current DC or to look for a closer option.
    1. Client uses the current DC if it’s in the client’s site or in the site closest to the client as indicated by DSClosestFlag reported by the DC.
    2. If DSClosestFlag indicates the current DC is not the closest, the client does a site specific DNS query to: _LDAP._TCP.sitename._sites.domainname (_LDAP or whatever service you happen to be looking for) and uses a returned domain controller.

Brief overview:

For a full-sized image, click on the images.

Let me point out again, that if there are no DCs in a Site, then Automatic Site Coverage will take over.

To me, it’s a process to “find” a DC that will authenticate a user in a Site without a DC. However, my take on it is I would rather associate the location’s subnet to a current Site so as to not make the client go through this process. Besides, there may be scenarios that not having a DC in a Site can directly affect directory enabled applications and services such as DFS site referrals, SCCM or Exchange with it’s high dependency on GCs and DSAccess.

Here’s the DC Locator process, directly quoted from the Technet article, “How DNS Support for Active Directory Works:”

  1. Build a list of target sites — sites that have no domain controllers for this domain (the domain of the current domain controller).
  2. Build a list of candidate sites — sites that have domain controllers for this domain.
  3. For every target site, follow these steps:
    1. Build a list of candidate sites of which this domain is a member. (If none, do nothing.)
    2. Of these, build a list of sites that have the lowest site link cost to the target site. (If none, do nothing.)
    3. If more than one, break ties (reduce this list to one candidate site) by choosing the site with the largest number of domain controllers.
    4. If more than one, break ties by choosing the site that is first alphabetically.
    5. Register target-site-specific SRV records for the domain controllers for this domain in the selected site.

If there are no DCs in a Site, you can use PowerShell to figure out which DC in which Site will be picked. If you like, you can further read up on the commands used to figure this out in Sean Ivey’s blog:

Sites Sites Everywhere…, By Sean Ivey, Microsoft DS PFE
http://blogs.technet.com/b/askds/archive/2011/04/29/sites-sites-everywhere.aspx

So wouldn’t you want your clients to pick a DC in its own Site?

Moving forward, do we really want a client to pick a DC in some other site or go through the Automatic Site Coverage process? Would you want that? I ‘m sure you already know the answer to that.

Therefore, if you have a location that have no DCs, then simply create an IP subnet object, and associate the subnet object to an existing AD Site that you want those users to use. In this case, you may base your own pick on a site linked by the fastest WAN link, or the only WAN link.

And if there are any subnets that are not associated with an AD site, then any DC is game to authenticate a client, as seen in the process above. To check for clients which subnets are not configured to AD Sites & Services, among other things, enable Netlogon logging, and check the system32\config\netlogon.log file. Here’s more info:

Enabling debug logging for the Net Logon service, Last Review: May 3, 2011 – Revision: 11.0, Applies to: all operating systems.
 http://support.microsoft.com/kb/109626

Auto Site Link Bridging

This now brings us to bridging, what it is, etc.

Within an AD Site, the KCC (Knowledge Consistency Checker) will automatically assume that all DCs can directly reach each other, and create Intrasite replication partnerships between the DCs in the Site. The one point that I want to be clear about that no matter how many DCs are in a Site, and there can be hundreds of DCs in a Site, the KCC will make sure that the  partnerships created are done so that all DCs in a Site will have an updated replication set for any changes by any of the DCs in the site, within 15 minutes. If you add a new DC to the Site, the KCC jumps in and evaluates the new guy and adds it so it gets updated data from other DCs under 15 minutes. How does it do that? It follows a set algorithm, but that is beyond this discussion.

When there are multiple Sites, and more specifically three or more Sites, and keeping in mind that by default AD automatically assumes that all the Sites have direct physically connectivity and communications between each other. This means you can literally ping a DC from in any Site to any other Site.

Here’s where the ISTG (Intersite Topology Generator) kicks in. The ISTG is a component of the KCC. It evaluates the overall topology, and builds connection objects between servers in each of the sites to enable Intersite replication— DC replication between sites.

Here’s a fully routed infrastructure, For the full-sized image, click here.

 

If remote sites cannot directly communicate with each other and only to the hub site

However, if your physical network topology is designed where each site does not have direct communications with each other, and you leave all the default “Auto Site Link Bridge” setting enabled as is, then lots of things will go wrong, such as replication problems, duplicate AD integrated zones, and more … keep reading. But I won’t address duplicate zones. You can click the link in the previous sentence for more on that.

If the network topology was a hub and spoke and BASL wasn’t disabled and individual sites links between the hub and each site weren’t created until recently, then there may be replication problems. This is a whole different subject. What I can say, besides checking to see if there are duplicate zones, as I mentioned in the previous paragraph, I would also run the Active Directory Replication Status Tool to check replication status. It will provide a report, and anything amiss will show up in Red. Pretty cool tool. Download it here:

Download The Active Directory Replication Status Tool (ADREPLSTATUS):
   http://www.microsoft.com/en-us/download/details.aspx?id=30005
     Note: This tool requires .Net Framework 4. If it’s not installed, download and install it:
       Microsoft .NET Framework 4 (Web Installer)
       http://www.microsoft.com/en-us/download/details.aspx?id=17851

Remember, by default, the KCC assumes all sites can directly communicate, therefore it will create partnerships between Bridgeheads in all sites. And any DC in a site can automatically become a bridgehead.

So if corporate headquarters is in NYC, and you have three remote locations, Miami, Chicago and Seattle, and direct communications does not exist, meaning that each remote location can only communicate with headquarters, and IP routing has not been configured between the remote locations, and the KCC creates a connection object (partnership) between a DC in Miami and a DC in Seattle, what will happen?

Since they can’t directly communicate, then replication fails. And if the Seattle partnership is the only connection object Miami may have, but Seattle happens to have one to NYC, and keeping in mind, replication is a PULL request, then Seattle will receive replication from NYC, but Miami can’t pull anything from Seattle, because there is no direct or indirect communications. So Miami winds up being in a secluded island.

In Miami’s DC’s view, it thinks no one wants to talk to it, so it will complain (you will see multiple event log errors) that others having replicated with it. And according to the DCs in the other sites, they will all think the same thing about Miami.

So who’s right? Of course, they all are. If the lack of replication goes beyond the AD Tombstone, then Miami would need to be demoted. Then again, you can’t even do that because it doesn’t have direct communications with its partner. Then if it does pick a DC in headquarters to demote, you will see an error stating that the headquarters DC already thinks the DC no longer exists. In the case of trying to demote it, or even forcedemoting it beyond the Tombstone, then your only option is to unplug it, run a metadata cleanup and re-promote it. But wait, then the same thing will occur if you don’t disable BASL.

So is it right that we do the same thing over and over and expect different results? Nope. Let’s configure AD to make sure it will not happen again, by disabling BASL.

Here’s a non-fully routed infrastructure. For the full-sized image, click here.

Disable BASL

Simply put, what we need to do is disable BASL (Bridge All Site Links) in a non-fully routed infrastructure to tell the KCC to only partner DCs across a specific site link.

Yes, that means you also have to create specific IP site links between headquarters in NYC to each site, as the image above shows.

And even if you have 20 sites all fully routed EXCEPT for one of them, then the same thing goes. You must disable it all because of that one site, otherwise the KCC will partner with a DC that it may not have direct communications with.

How to disable BASL. For the full-sized image, click here.

Summary

If you want to make sure your AD infrastructure is properly purring along and doing its job, then by all means let’s design it properly, make the necessary modifications, and other changes, to get it going in the right direction.

Oh, and you can’t forget to bone up on your DNS knowledge and how it supports AD. All Sites get registered in DNS by the netlogon service. Read more:

How DNS Support for Active Directory Works
http://technet.microsoft.com/en-us/library/cc759550(WS.10).aspx

And to understand the DNS SRV records registered by a DC’s Netlogon service, read Sean Dubey’s blog, with DNS SRV records examples, once again, I refer you to Sean Ivey’s blog:

Sites Sites Everywhere…, By Sean Ivey, Microsoft DS PFE
http://blogs.technet.com/b/askds/archive/2011/04/29/sites-sites-everywhere.aspx

References

Designing the Site Topology
http://technet.microsoft.com/en-us/library/cc787284(WS.10).aspx

Detailed branch office deployment guide (downloadable doc)
http://www.microsoft.com/downloads/details.aspx?FamilyId=9353A4F6-A8A8-40BB-9FA7-3A95C9540112&displaylang=en

Best Practice Active Directory Design for Managing Windows Networks
http://technet.microsoft.com/en-us/library/bb727085.aspx

You may want to take a look at the design IPD guide (Infrastructure Planning and Design) for AD – Download Details: IPD guide for Active Directory Domain Services – version 1.0
http://www.microsoft.com/en-us/download/details.aspx?id=732

Download the complete Infrastructure Planning and Design (IPD) Guide Series v2.0 including links for AD IPD, SCCM IPD, and more.
http://technet.microsoft.com/en-us/library/cc196387.aspx

Comments & Corrections are welcomed.

Ace Fekay

Event ID 1054

Original publication: 8/12/2010
Edited: 8/30/2014

 

Prologue

Ace here again. This was an older blog that I’ve revamped. I’ve been going through my blogs to clean them up, syntax, accuracy, etc. If anyone sees any discrepancies, please let me know.

There are a number of reasons this event may occur, no matter which Source Name its related to. One of the main reasons this behavior may occur is if the address for the configured preferred DNS server unreachable. One of the first things to do is check www.eventID.net’s link to see if it applies to your scenario:
http://eventid.net/display.asp?eventid=1054

Summary of possibilities:

1. Using a DNS address that doesn’t have the AD zone data. Make sure the only DNS addresses on the NIC are the internal DC/DNS servers. Remove the ISP’s or the router’s as a DNS address. They do not have AD’s zone data that is required for AD to function properly.

Active Directory’s Reliance on DNS, and why you should never use an ISP’s DNS address or your router as a DNS address
Published by acefekay on Aug 17, 2009 at 7:35 PM
http://msmvps.com/blogs/acefekay/archive/2009/08/17/ad-and-its-reliance-on-dns.aspx

2. Multihomed DCs. If the DC is multihomed, numerous issues can result, too long to list. See the following for more info:

Multihomed DCs with DNS, RRAS, and/or PPPoE adapters
Published by acefekay on Aug 17, 2009 at 9:29 PM
http://msmvps.com/blogs/acefekay/archive/2009/08/17/multihomed-dcs-with-dns-rras-and-or-pppoe-adapters.aspx

3. AD DNS Domain Name is a Single Label Name. The name has no TLD, such as “domain” rather than domain.net, domain.local, etc. This can cause numerous problems, too lengthy to list. It also causes Windows XP SP3 and newer operating systems to fail the ability to resolve DNS names properly. See the following link for more information.

Active Directory DNS Domain Name Single Label Names
Published by acefekay on Nov 12, 2009 at 6:25 PM
http://msmvps.com/blogs/acefekay/archive/2009/11/12/active-directory-dns-domain-name-single-label-names.aspx

4. There are unknown LdapIpAddress entries. This is the “same as parent” name under the zone. There should only be one for each DC in the domain. If there are others, it will cause numerous issues with AD, GPOs, DFS, and other AD functions.

5. Multiple A records for the DC. Make sure there is only one IP address for each DC. If not, it falls under the multihomed DC issue in #2.

6. Multiple GcIpAddresses. Check the _gc_msdsc.yourDomain.local record to make sure there is only one entry for each GC. If there are multiples for one GC, that will cause problems, and falls under the multihomed DC issue in #2.

7. Unknown NS names in the zone. Go into each zone properties (yourDomain.local and _msdcs.yourDomain.local), Nameservers tab, and make sure only your DC/DNS servers show up.  If there are others, please remove them. This tab indicates which NS and SOA is for the zones, and if any unkown servers are listed, the client machine may be trying to query for them during resolution and registration, and will cause problems.

8. AMD Opeteron CPUs are known to cause issues. One poster in the Microsoft forums reported EventID 1054 issue on a Dell T105 (circa 2010) with Dual Core Opterons. It was found the AMD Opeteron processor has timing issue. From previous reports, Microsoft supposedly fixed it in Windows 2003 SP2, but something may have changed in recent AMD core releases causing it again. One key test was to ping the server’s own IP. If you receive negative ping times, timing is skewed. A reboot fixes it for a while but then it drifts and EventID 1054 resume.

There are AMD processor patches that you can find at AMD’s website. Another workaround is to add the “/usepmtimer” switch to boot.ini. KB895980 provides more specifics about this issue.

Programs that use the QueryPerformanceCounter function may perform poorly in Windows Server 2000, in Windows Server 2003, and in Windows XP
http://support.microsoft.com/?id=895980

9. Make sure time is configured properly. You never know, this is one that many do not think about that can cause many issues, which may or may not possibly cause EventID 1054 errors, but it would not hurt to make sure the time service is operating properly. See the following link for more information:

Configuring the Windows Time Service for Windows Server
Published by acefekay on Sep 18, 2009 at 8:14 PM
http://msmvps.com/blogs/acefekay/archive/2009/09/18/configuring-the-windows-time-service-for-windows-server.aspx

 

Steps to help narrow down this issue:

Let’s start by using nslookup to see if you get the proper resonse when querying for LDAP SRV records.

1. Type nslookup, and then press ENTER.
2. Type set q=all, and then press ENTER.
3. Type _ldap._tcp.dc._msdcs.domain.com and then press ENTER.

You will be looking for the domain controllers to respond to this query. If they do not, then we need to look at your SRV records as well as whether any of the above summarized causes are contributing to the non-DC responses, such as using an ISP’s DNS, the router, multihomed DCs, single label name, etc.

More possible causes:

In addition, These errors may occur because link status fluctuates as the network adapter (also known as the network interface card, or NIC) driver initializes and as the network adapter hardware negotiates a link with the network infrastructure. The Group Policy application stack executes before the negotiation process is completed and can fail because of the absence of a valid link.

*

Possible Resolutions:

Resolution 1:

To resolve problem related to link status fluctuation use the steps in 239924 –
“How to disable Media Sensing for TCP/IP in Windows” at
http://support.microsoft.com/?id=239924 .

To prevent your network adapter from detecting the link state:

  1. Open Registry Editor (Regedt32.exe).
  2. Go to the following key in the registry:
    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters
  3. Add the following registry value:
    Value Name: DisableDHCPMediaSense
    Data Type: REG_DWORD -Boolean
    Value Data Range: 0, 1 (False, True) Default: 0 (False)

Resolution 2:

Contact the vendor of the network card or visit their web site to obtain updated
drivers for the Gigabit NIC.

Examples of NICs known to exhibit this issue:
– Broadcom Gigabit Adapter
– Intel Gigabit Ethernet PRO Adapter, Intel Pro/1000
– Intel 82544EI-based XT Gigabit Adapter (82540EM chipse)
– Compaq/HP NIC dual interface 10/100/1000 doing teaming (HP NC7170)
– Dell Inspiron laptops using an on-board Broadcom BCM4401 NIC

Resolution 3:

A sever may have a Dual Port NIC or multiple NIC’s with one port or NIC set to
Disabled. The disabled port or NIC should not be at the top of the binding order
in the Network Advance Properties.

  1. Click Start, point to Settings, and then click “Network and Dial-up
    Connection”.
  2. On the Advanced menu, click “Advanced Settings”.
  3. On the “Adapters and Bindings” tab, in the connections list, select the NIC that
    the clients use to connect to the server and move it to the top of the list.

Resolution 4:

Disabling spanning tree on the switches (Cisco Catalyst)

Note: STP=Spanning Tree Protocol. Turning off STP can cause issues in your network
if a loop ever develops. If you are running a Cisco Series switch or any other
switch that runs Spanning Tree, it is best to leave spanning tree turned on, but
enable PORTFAST on all the ports except uplink and fiber trunks. (I.E any ports
that aren’t connected to a workstation directly should not have it enabled, ports
that do go directly to a workstation or computer should have it turned on.)
PORTFAST eliminates the 50 second waiting period that STP has, but allows you to
keep the functionality of STP.
 

*

References:

326152 PRB: Cannot Connect to Domain Controller and Cannot Apply Group Policy
http://support.microsoft.com/kb/326152

298656 Event ID 1054 Is Logged in the Application Event Log
http://support.microsoft.com/kb/324174/en-us

239924 How to Disable Media Sense for TCP/IP in Windows
http://support.microsoft.com/kb/239924

*

Summary

I hope this helps to track down the cause of an Event ID 1054.

Ace Fekay
MVP, MCT, MCSE 2012, MCITP EA & MCTS Windows 2008/R2, Exchange 2013, 2010 EA & 2007, MCSE & MCSA 2003/2000, MCSA Messaging 2003
Microsoft Certified Trainer
Microsoft MVP – Directory Services
Complete List of Technical Blogs: http://www.delawarecountycomputerconsulting.com/technicalblogs.php

This blog is provided AS-IS with no warranties or guarantees and confers no rights.