Preparing Network Connections

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Rachel L Chipman - 21 Jun 2007 22:07 GMT

When I reboot some of my 2003 DC, they get to "Preparing Network Connections"
and sit for AT LEAST 5 minutes before the CTRL-ALT-DEL screen comes on. Is
this normal for DCs?

I have read some articles saying it is a DNS problem however I have run
DCDIAG and everything looks fine. I don't know what else to do . Any
suggestions would be appreciated.

Reply to this Message

Kevin D. Goodknecht Sr. [MVP] - 21 Jun 2007 22:40 GMT

Read inline please.

In news:9E16A750-6DE0-4337-A766-031984D417D8@microsoft.com,
Rachel L Chipman <RachelLChipman@discussions.microsoft.com> typed:

> When I reboot some of my 2003 DC, they get to "Preparing Network
> Connections" and sit for AT LEAST 5 minutes before the CTRL-ALT-DEL
[quoted text clipped - 3 lines]
> run DCDIAG and everything looks fine. I don't know what else to do .
> Any suggestions would be appreciated.

Make sure each DC has another DC's address (that is already running and has
its zone) for its Preferred DNS, then itself for Alternate. Also, you should
likely make ALL DCs a Global Catalog in AD Sites & Services. When rebooting
DCs, it is recommended to have at least one DC with DNS running at all
times.

Signature

Best regards,
Kevin D. Goodknecht Sr. [MVP]
Hope This Helps

===================================
When responding to posts, please "Reply to Group"
via your newsreader so that others may learn and
benefit from your issue, to respond directly to
me remove the nospam. from my email address.
===================================
http://www.lonestaramerica.com/
http://support.wftx.us/
http://message.wftx.us/
===================================
Use Outlook Express?... Get OE_Quotefix:
It will strip signature out and more
http://home.in.tum.de/~jain/software/oe-quotefix/
===================================
Keep a back up of your OE settings and folders
with OEBackup:
http://www.oehelp.com/OEBackup/Default.aspx
===================================

Reply to this Message

Niatross - 29 Jun 2007 17:50 GMT

Kevin,

Is this because the netlogon service starts before the DNS service?

Is this why you have each DC point to another DC that's already running.

It looks as if the DC (that points to itself, using netlogon to register
it's SRV records - PARTICULARLY IT'S _GC RECORD) finds that the DNS service
has not started. The DC finds that it cannot find itself and will not logon
for 5 minutes, until netlogon tries to register SRV records again once DNS
has started

My question is this:

Why can a single DC (that's point to itself) logon quickly with no problems?
Why is it that when you introduce a second DC (that's pointing to itself)
cannot find itself anymore?

Thanks in advance for your response.

-----------------------------------------------

> Read inline please.
>
[quoted text clipped - 13 lines]
> DCs, it is recommended to have at least one DC with DNS running at all
> times.

Reply to this Message

Kevin D. Goodknecht Sr. [MVP] - 29 Jun 2007 18:57 GMT

Read inline please.

In news:452F602A-6BD3-4702-AF12-B7BC1AA527A5@microsoft.com,
Niatross <niatross@newsgroup.nospam> typed:

> Kevin,
>
[quoted text clipped - 15 lines]
> problems? Why is it that when you introduce a second DC (that's
> pointing to itself) cannot find itself anymore?

Call it a bug, call it by design, or you can call it another one of
Microsoft Windows "Features". Apparently when you have a Second DC, both are
aware that a second DC exists and it expects to find a DNS server and Global
Catalog already running. If it can't find what it knows should be there it
waits until it just gives up. Personally, I think it's because it won't load
the AD database until it can verify that its Update Sequence Number (USN) is
correct.
If the USN doesn't match what it is supposed to be it breaks replication and
will eventually Tombstone the other DC. It won't Tombstone itself, but each
DC will think it has the correct USN and they will stop replication with
each other eventually forever. This usually happens if you do an improper
restoration from backup, like when you try to use a Ghosted drive for a
backup, or if network and DNS problems prevent replication.

On that note- if you use Ghosted drives for backups, you have to disconnect
all DCs from the Network (Stops replication in it tracks) and take your
Ghost of ALL DCs. If you have to use a ghost to restore a DC, you have to
restore all Ghosts at the same time. I happen to know this because I have
one client that does it this way, and three or four years ago, he had tried
to restore one DC from his ghost backups and two months later he called me
because everything started going bad (One had Exchange) when both of his
DCs Tombstoned the other and Exchange crapped out on him.

Signature

Reply to this Message