Userenv error EventID: 1000

[Mike Morgan]

I have a new server that I want to use to deploy Exchange. I've put it in
the DMZ of our firewall. Everything seems to work fine on it (including the
networking from DMZ to LAN). However, the application log is getting the
following error event at regular intervals:

Event Type: Error
Event Source: Userenv
Event Category: None
Event ID: 1000
Date: 9/29/2004
Time: 1:24:10 PM
User: NT AUTHORITY\SYSTEM
Computer: PUBLIC

Description:
Windows cannot obtain the domain controller name for your computer network.
Return value (59).

I've checked userenv.log and it is full of entries like the following:
USERENV(808.8bc) 13:24:10:109 ProcessGPOs: DSGetDCName failed with 59.

I've checked DNS backward and forward and run Netdiag. The server passes
every test. I'm baffled. Does anyone know what causes this event to be
logged? I really don't want to proceed with our Exchange rollout until the
event viewer is completely error-free. Any help would be greatly
appreciated. Thanks.

 

[Ken B]

Are you sure you have to put the Exchange server in the dmz? Wouldn't it be
'safer' to just forward the ports it requires?

I would try taking the server out of the 'public eye' of the internet, and
see if your event logs quiet down. If they do, then you can draw the
conclusion that your server is the subject of an attempted attack, no?

KenB

 

[Mike Morgan]

Yeah, its got to go in the DMZ. It's going to have some other 'public'
functions. At the moment the DMZ is not open inbound from the Internet at
all. Eventually, it will be on two or three ports only. But, not right now.
I don't know if this error is actually a problem. It appears to have
something to do with group policy, but I can't find where anything has
actually gone wrong with group policy. I'm trying to find out what actually
causes this error to be logged in the application log in the first place. I
can't seem to locate any information on it. Would you happen to know
anything about it?

 

[Kevin D. Goodknecht Sr. [MVP]]

In

I have a new server that I want to use to deploy
Exchange. I've put it in the DMZ of our firewall.
Everything seems to work fine on it (including the
networking from DMZ to LAN). However, the application log
is getting the following error event at regular
intervals:

Event Type: Error
Event Source: Userenv
Event Category: None
Event ID: 1000
Date: 9/29/2004
Time: 1:24:10 PM
User: NT AUTHORITY\SYSTEM
Computer: PUBLIC

Description:
Windows cannot obtain the domain controller name for your
computer network. Return value (59).

I've checked userenv.log and it is full of entries like
the following: USERENV(808.8bc) 13:24:10:109 ProcessGPOs:
DSGetDCName failed with 59.

I've checked DNS backward and forward and run Netdiag.
The server passes every test. I'm baffled. Does anyone
know what causes this event to be logged? I really don't
want to proceed with our Exchange rollout until the event
viewer is completely error-free. Any help would be
greatly appreciated. Thanks.

Is the Exchange server using the internal DNS only for DNS?
Do not use an external or ISP's DNS in TCP/IP properties, make sure all
ports are open between Exchange and the DC.

 

[Mike Morgan]

The DNS setting on the soon to be Exchange server are both internal. I've
opened the ports between the DMZ and the LAN according to Microsoft Knowlege
Base Article 832017. I can nslookup all domain controllers from the DMZ
machine. Nslookup replies with all domain controllers ip's when used with
the domain name or the domain name alias. Everything appears to work. I
can't see where this error is actually causing any problems. It certainly
doesn't appear to be DNS related. But, I don't feel comfortable proceeding
until I know why the error is appearing in the event viewer.

 

[Kevin D. Goodknecht Sr. [MVP]]

In

The DNS setting on the soon to be Exchange server are
both internal. I've opened the ports between the DMZ and
the LAN according to Microsoft Knowlege Base Article
832017. I can nslookup all domain controllers from the
DMZ machine. Nslookup replies with all domain controllers
ip's when used with the domain name or the domain name
alias. Everything appears to work. I can't see where this
error is actually causing any problems. It certainly
doesn't appear to be DNS related. But, I don't feel
comfortable proceeding until I know why the error is
appearing in the event viewer.

Can you access the SYSVOL share at \\domainname\SYSVOL from the Exchange
server?

 

[Mike Morgan]

You know, I had had a small problem with that last week between the two
domain controllers. There was a small rights problem on the SYSVOL share. I
fixed it straight away when it happend. I just accessed \\domainname\SYSVOL
from the Exchange machine and browsed it without any problem. Again, I'm not
even sure that this error really means anything. I just want to know why its
being logged. It just happened again a few minutes ago. In fact, it happened
last night at 1:03am, 2:16am, 2:48am and this morning at 9:26am. Looking
back farther in logs has suggested that the event that is causing the error
to be logged is completely random. There doesn't appear to be any set time
interval between errors. And, it happens whether anyone is here working on
the server or not. I'm stumped.

 

[Kevin D. Goodknecht Sr. [MVP]]

In

You know, I had had a small problem with that last week
between the two domain controllers. There was a small
rights problem on the SYSVOL share. I fixed it straight
away when it happend. I just accessed \\domainname\SYSVOL
from the Exchange machine and browsed it without any
problem. Again, I'm not even sure that this error really
means anything. I just want to know why its being logged.
It just happened again a few minutes ago. In fact, it
happened last night at 1:03am, 2:16am, 2:48am and this
morning at 9:26am. Looking back farther in logs has
suggested that the event that is causing the error to be
logged is completely random. There doesn't appear to be
any set time interval between errors. And, it happens
whether anyone is here working on the server or not. I'm
stumped.

Hopefully you'll find something here that will help you with the error 59, I
think it has a lot to do with having the Box in your DMZ.
http://www.eventid.net/display.asp?eventid=1000&eventno=1441&source=Userenv&phase=1

 

[Mike Morgan]

You may be right. I've run all of the suggested netdiag and dcdiag tests on
all of the involved machines. Everything passes with flying colors. I've
checked all of the ports from DMZ to LAN and they are correct. The only
group policy change that should have affected this server applied just fine.
It works. I'm beginning to think that this error is insignificant. I just
wish I could find out why its happening. Thank you for your help.

 

[Ace Fekay [MVP]]

In

You know, I had had a small problem with that last week between the
two domain controllers. There was a small rights problem on the
SYSVOL share. I fixed it straight away when it happend. I just
accessed \\domainname\SYSVOL from the Exchange machine and browsed it

<snip>

Is your domain name a single label name as depicted in your post above or is
it of the proper format? Such as:
\\domainname.com\sysvol\etc... ?

If it is a single label name, that can be the cause of the whole problem.

--
Regards,
Ace

Please direct all replies ONLY to the Microsoft public newsgroups
so all can benefit.

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

Ace Fekay, MCSE 2003 & 2000, MCSA 2003 & 2000, MCSE+I, MCT, MVP
Microsoft Windows MVP - Windows Server - Directory Services

Security Is Like An Onion, It Has Layers
HAM AND EGGS: A day's work for a chicken;
A lifetime commitment for a pig.

 

[Ken B]

You should be able to use the FQDN or the Netbios name, no? I just tried it
out with my \\domain\sysvol and also with \\domain.local\sysvol and both
worked?

KB


"Ace Fekay [MVP]"

 

[Mike Morgan]

Yeah, I just did it both ways, too. Either way (\\netbiosname\sysvol or
\\fqdn\sysvol) works fine. On the upside, the error only occured once last
night and I can't find a single problem with either the domain or the
server. It passes every test so far. I guess I'm going to proceed until I
run into a problem.

You should be able to use the FQDN or the Netbios name, no? I just tried it
out with my \\domain\sysvol and also with \\domain.local\sysvol and both
worked?

KB


"Ace Fekay [MVP]"

In Mike Morgan <[email protected]> made a post then I commented below
<snip>

Is your domain name a single label name as depicted in your post above

or

 

[Kevin D. Goodknecht Sr. [MVP]]

In

Yeah, I just did it both ways, too. Either way
(\\netbiosname\sysvol or \\fqdn\sysvol) works fine. On
the upside, the error only occured once last night and I
can't find a single problem with either the domain or the
server. It passes every test so far. I guess I'm going to
proceed until I run into a problem.

Just to verify, these are the names of the domain and not the machine's
name.

I have also seen this error if the DC is multihomed and the NIC with file
sharing is not the default connection. (Top of the binding order)
TO check the binding order, right click on Network Places and choose
properties from the pop up menu. Then in the Network properties window
select the Advanced menu, then Advanced settings. In the connections pane
(top) the internal NIC should be at the top of the list and File sharing and
client for MS Networks selected in the Bindings pane.

 

[Lanwench [MVP - Exchange]]

Yeah, its got to go in the DMZ. It's going to have some other 'public'
functions.

This is unwise. You will have to open up so many ports between DMZ and LAN
that you'll effectively not have a DMZ anymore. What are the 'public'
functions you speak of? Perhaps there's a better way.... your Exchange
servers, and DCs, really belong on your LAN, and should be protected.

At the moment the DMZ is not open inbound from the

Internet at all. Eventually, it will be on two or three ports only.

Which ones?

But, not right now. I don't know if this error is actually a problem.
It appears to have something to do with group policy, but I can't
find where anything has actually gone wrong with group policy. I'm
trying to find out what actually causes this error to be logged in
the application log in the first place. I can't seem to locate any
information on it. Would you happen to know anything about it?

What's open between DMZ and LAN now?
Have you looked for clues at eventid.net? See
http://www.eventid.net/display.asp?eventid=1000&source=userenv

 

[Ace Fekay [MVP]]

In

Yeah, I just did it both ways, too. Either way (\\netbiosname\sysvol
or \\fqdn\sysvol) works fine. On the upside, the error only occured
once last night and I can't find a single problem with either the
domain or the server. It passes every test so far. I guess I'm going
to proceed until I run into a problem.

Ok, never having tried it with the NetBIOS name, I tested it, and it does
connect.

Back to the Event ID 1000, I am still curious whether the domain name is a
single label name as a previous post indicated.


Ace

 

[Roland Hall]

: In : Mike Morgan <[email protected]> commented
: Then Kevin replied below:
: > Yeah, I just did it both ways, too. Either way
: > (\\netbiosname\sysvol or \\fqdn\sysvol) works fine. On
: > the upside, the error only occured once last night and I
: > can't find a single problem with either the domain or the
: > server. It passes every test so far. I guess I'm going to
: > proceed until I run into a problem.
:
: Just to verify, these are the names of the domain and not the machine's
: name.
:
: I have also seen this error if the DC is multihomed and the NIC with file
: sharing is not the default connection. (Top of the binding order)
: TO check the binding order, right click on Network Places and choose
: properties from the pop up menu. Then in the Network properties window
: select the Advanced menu, then Advanced settings. In the connections pane
: (top) the internal NIC should be at the top of the list and File sharing
and
: client for MS Networks selected in the Bindings pane.

I helped someone setup an FTP server yesterday who was having issues with
Event ID: 1000 Source: Userenv
The FTP server was a DNS server with 2 NICs. Public address on one NIC,
private IP on the other.

The resolution had four parts:

1. User was a domain user and needed to be added to group policy for local
logon.
2. Primary DNS on public NIC needed to point to itself (public address -
also running DNS). Primary DNS on private NIC needed to point to DC DNS.
3. Primary DNS on DC needed to point to itself. (Primary was public address
of other server and secondary it pointed to itself)
4. The private NIC needed to be first in the binding order and file and
printer sharing needed to be removed from the public NIC.

I believe the Primary DNS pointing to the public address of the multihomed
FTP server was the main issue.

The FTP/WWW configuration also had to be modified to allow for a single IP
address hosting multiple FTP sites but it's not relevant here.

The original problem was the FTP user could not authenticate but web and
FPSE authticated fine. Hopefully this info can be of some benefit to the
discussion.

--
Roland Hall
/* This information is distributed in the hope that it will be useful, but
without any warranty; without even the implied warranty of merchantability
or fitness for a particular purpose. */
Online Support for IT Professionals -
http://support.microsoft.com/servicedesks/technet/default.asp?fr=0&sd=tech
How-to: Windows 2000 DNS:
http://support.microsoft.com/default.aspx?scid=kb;EN-US;308201
FAQ W2K/2K3 DNS:
http://support.microsoft.com/default.aspx?scid=kb;EN-US;291382

 

[Ace Fekay [MVP]]

In

I helped someone setup an FTP server yesterday who was having issues
with Event ID: 1000 Source: Userenv
The FTP server was a DNS server with 2 NICs. Public address on one
NIC, private IP on the other.

The resolution had four parts:

1. User was a domain user and needed to be added to group policy for
local logon.
2. Primary DNS on public NIC needed to point to itself (public
address - also running DNS). Primary DNS on private NIC needed to
point to DC DNS.
3. Primary DNS on DC needed to point to itself. (Primary was public
address of other server and secondary it pointed to itself)
4. The private NIC needed to be first in the binding order and file
and printer sharing needed to be removed from the public NIC.

I believe the Primary DNS pointing to the public address of the
multihomed FTP server was the main issue.

The FTP/WWW configuration also had to be modified to allow for a
single IP address hosting multiple FTP sites but it's not relevant
here.

The original problem was the FTP user could not authenticate but web
and FPSE authticated fine. Hopefully this info can be of some
benefit to the discussion.

Thanks for adding that. Yes, hopefully its beneficial. The only issue I'm
concerned with its a DC. DCs with multi NICs will register both addresses
for its one hostname and also register both addresses wtih the
LdapIpAddress. The LdapIpAddress is used for GPO, DFS and other
functionality. Also if its a GC, that will cause issues as well with the two
IPs. If its a NAT, the outer IP won;t be accessible by internal clients if
DNS gives that answer to the clients for a query. We'll need to alter the
reg to alter that registration behavior. Maybe unchecking Round Robin and
making sure Netmask Ordering is enabled may help.

But for the most part, the best bet is to keep DNS or a DC on a single NIC
machine to avoid all these pitfalls and the additional administrative
overhead with altering behavior to get something like this working.

Ace

 

[Mike Morgan]

None of the machines are multi-holmed. The DC's have multiple NIC's, but
they are bound with a teaming driver into a single IP. The future exchange
server has a single NIC.

"Ace Fekay [MVP]"

 

[Ace Fekay [MVP]]

In

None of the machines are multi-holmed. The DC's have multiple NIC's,
but they are bound with a teaming driver into a single IP. The future
exchange server has a single NIC.

I apolgize if I didn't see that in this thread.

As for the intermittent errors, is there anything sepecific running at that
point in time?

That article you mentioned just gives you a generalization of all possible
ports, but really doesn't specifically say which ports are required or not
required for domain communication traffic. I believe it may have something
to do with this, since DNS seems to be setup correctly. See if these help
and are more specific for your needs.

Active Directory Replication over Firewalls - Microsoft Service Providers:
http://www.microsoft.com/serviceproviders/columns/config_ipsec_P63623.asp

Download details Active Directory in Networks Segmented by Firewalls:
http://www.microsoft.com/downloads/...amilyid=c2ef3846-43f0-4caf-9767-a9166368434e3

179442 - How to Configure a Firewall for Domains and Trusts:
http://support.microsoft.com/?id=179442

Hope that helps.

Ace