DNS Service doesn't start on bootup

Sponsored Links

Fresh install of 2008 R2, DNS and AD DS roles installed. On reboot, DNS
doesn't start automatically, but I can log on and start DNS manually. In
system events, I see ID 7036 "The DNS Server service entered the stopped
state," followed by ID 7023, "The DNS Server service terminated with the
following error: The network is not present or not started." Suggestions on
where to start?

There's one in the message itself. Is your network present and
started?

As Jonathan indicated, it appears that the message you are getting, "...The
network is not present or not started," may indicate that the NIC or network
services are not starting first, which is required for DNS and other network
based services. The 7036 and 7023 eventID#s are generic to any services.
We'll need something a little more specific. Do you see any other error
messages in any other event logs?

I see some warnings from the network adapter as the link goes down and back
up on each port before initializing. This happens prior to other services
starting. It's an Intel PRO/1000 PT dual port server adapter configured for
teaming. I tried disabling teaming, but DNS still failed to auto-start.

How do you know this?

Have you checked and tried to eliminate the simple things, such as a bad
wire, connection loose, bad switch port, etc?

Startup messages from other services appear in the event logs after the
successful NIC initialization message.

I've tried different cables and different switch ports. I changed some NIC
parameters (specified link speed instead of autonegotiate for the individual
NICs and disabled 'probes' for the team) and this eliminated all of the NIC
error events, but DNS still doesn't auto start.

How about drivers? Have you considered disabling the team and see if that is
causing it.

Apparently something is holding it up. It's difficult to ascertain.

Disabling teaming didn't help. However, I just disabled the Intel NIC and
installed an old Broadcom NIC and DNS started on reboot, just like it's
supposed to. It appears there's something wonky with my Intel NIC or its
drivers. Armed with that information, I think I'll continue troubleshooting
tomorrow, on company time.

That's good to hear you narrowed it down. Let us know how you make out.

Dumb question. What kind of switch do you have? Maybe it's not recognizing
the team properly if both interfaces are plugged into the same port?

Does that include a service start event for the DNS server service?
It may *stop* after the NIC has been initialized, but have you made
sure that it doesn't actually *start* until the NIC has been
initialized? Check its dependency graph.

And read MSKB Q954423, too.

This morning I uninstalled the Intel drivers and started over. With the
Microsoft driver, each NIC in the PRO/1000 PT Dual adapter works fine as a
standalone NIC. I can load the Intel drivers and I'm still good in
standalone, but if I team the NICs, DNS fails to start. Then if I remove the
team and try to return to standalone, DNS fails on a standalone NIC. The
only way I've been able to get it back to working is to uninstall the Intel
drivers and start over again. I've repeated this cycle a couple of times.
Intel support hasn't been any help so far.

Dell 5324. I have an identical NIC in an Exchange server on the same switch
with no problems. No DNS role on that one, though.

I can, but I don't know what I should be looking for there. (Right now I'm
trying to get Intel to fix a broken download link so I can try a driver
update.)

Maybe there's a delay on the switch side that is causing DNS to hang? Can
you check the port settings?

Sorry, I can't remember the setting. It's regards tuning the teaming config.
Here's Cisco's take on it for their Catalyst series.

http://www.cisco.com/en/US/products/...ml#nic_teaming

JB> (Right now I'm trying to get Intel to fix a broken download link
JB> so I can try a driver update.)

You're going off at tangents somewhat. The basic etiology of this
problem is *described in the MSKB article that I pointed you to*. And
the answers to the questions that I asked, which you haven't yet
provided, are some pretty basic things that you should be looking for,
that have nothing to do with driver versions or device
configurations. Indeed, you *know* that you can successfully bring up
the DNS service with the *current* driver, and with your original
device configuration. You said so, after all, in the very first
message in this thread. Read the MSKB article, and look for the
answers to those questions.

The MSKB you posted, http://support.microsoft.com/kb/954423, indicates the
following:

- The server does not have network connectivity.
- The network device to which the server is connected takes a longer time to
start than the server.

Therefore, that was why I was pointing to switch configuration. Cisco claims
there is an issue with their Catalyst where the spanning tree algorithm
hangs and may intermittently drop connection while it recycles the port. I
don't know about the Intel switch Joe has, but it alerts me that the issue
*may* reside with the switch.

Indeed. But basics first. This could be as simple as a non-existent
service dependency, meaning that the two services are starting in
parallel. See the second bulleted point that you quoted. A simple,
ordinary, race condition, entirely independent of driver versions,
device configurations, or switch capabilities, explains the observed
behaviour. Hence my "How do you know this?" question asked almost a
week ago, and my ensuing questions that remain still unanswered. M.
Blizzard is off on extensive tangents, without first properly checking
for something basic, straightforward, fairly probable, and fixable
with a simple registry tweak.

Regarind a registry tweak, are you saying to make DNS dependent on the
network services to start first?

AF> Regarind a registry tweak, are you saying to make
AF> DNS dependent on the network services to start first?

Actually, I'm not even saying that, yet. We haven't even progressed
that far. I'm saying to check that this is or isn't the problem.
(But that is the fix, if it is.) Here are the unanswered questions
still outstanding from 2009-12-22:

JdeBP> Does that include a service start event for the DNS
JdeBP> server service? It may *stop* after the NIC has been
JdeBP> initialized, but have you made sure that it doesn't
JdeBP> actually *start* until the NIC has been initialized?
JdeBP> Check its dependency graph.

If the DNS server service is happening to start wholly after the NIC
is fully initialized, then this isn't the cause of the problem of
course. But if it is starting in parallel before the NIC is fully
initialized, which is quite likely (especially given that NIC
initialization is non-trivial in this case), then this is, per
Q954423, what is going on. As I said, it's a straightforward,
probable, and basic thing, with an easy fix, that needs to be checked,
and still hasn't been. The questions are still unanswered.

Then let's see how Joe responds to your questions before moving forward on
any other assumptions.