Windows cannot obtain the domain controller name for your computer network return value(59)

Can someone please help!!! I have been fighting this issue for awhile now.

I have 4 different offices. 1 main office (where all my servers are) and the other 3 just have user computers. We are all connected VPN via checkpoint firewalls.

I am trying to apply group policies to my users but whenever they try to logon they are getting Windows cannot obtain the domain controller name for your computer network return value(59) in the event viewer, and no GP's are being applied. However they are able to logon to the domain and browse to the sysvol at my main office with the dns name without any problems!

Here is something that puts a twist into things, at one of my sites i setup a DC and after that the GP's were being applied with no prob, however once I took it offline they once again were getting the above message and no GP's.

I checked MS site and cannot find anything helpful, all I can find is reference to DNS errors, but my users are all using the correct DNS servers.

I have checked my firewall logs and Im not seeing anything dropped, I have even added a route to my servers for my remote offices.

Please someone help, I am about at the end of my rope!
LVL 6
ITHelper80Asked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

detox1978Commented:
I had a similar issue, i rejoined the domain which sorted it.  Not sure if that will help you tho.

here is the TechNet article on it;
http://support.microsoft.com/default.aspx?scid=kb;en-us;834859
ITHelper80Author Commented:
I have already done that , and no luck :( oh by the way all my server are win2k
detox1978Commented:
have you tried it via the NetBios domain Name and the FQDN?
Big Business Goals? Which KPIs Will Help You

The most successful MSPs rely on metrics – known as key performance indicators (KPIs) – for making informed decisions that help their businesses thrive, rather than just survive. This eBook provides an overview of the most important KPIs used by top MSPs.

David WilhoitSenior Consultant, ExchangeCommented:
detox1978Commented:
Also on your Domain Controller check your server settings by typing;

netdiag

Might show up somethnig.
David WilhoitSenior Consultant, ExchangeCommented:
ITHelper80Author Commented:
Yes I saw the gigabit issue but the users at my lmain office arent having any problems so I assumed that wouldnt be the issue.
ITHelper80Author Commented:
The error message I posted was from a Win2k Pro machine, however my Xp machines are having the same problems
David WilhoitSenior Consultant, ExchangeCommented:
but at the remote sites, they're on VPN, the GB is much quicker than  the VPN, right? Could be the issue...especially if you already put a DC at the remote sites as a test, and it worked fine....

D
detox1978Commented:
have you tried "netdiag" from the Domain Controller....?
ITHelper80Author Commented:
Just ran the netdiag and everything passed :(
ITHelper80Author Commented:
Question about the network adapter, should i do that on my DC's or my users PC?
David WilhoitSenior Consultant, ExchangeCommented:
Well, it leaves it open for both server and client, but I'd try the client level first, since the local users don't have the issue. Try it on one or 2 of the clients remotely.

D
ITHelper80Author Commented:
Rejoined the domain as  D1978 said and still same issues.
ITHelper80Author Commented:
Tried the regedit and no luck still.

FYI here is what my XP machines are giving me.

" Windows cannot obtain the domain controller name for your computer network. (An unexpected network error occurred). Group Policy processing aborted."

Hope that info helps you all help me!!

David WilhoitSenior Consultant, ExchangeCommented:
How high did you go with the setting? If 60 didn't work, what else did you try?

D
RDAdamsCommented:
Have you tried putting the IP address in instead of the DC name?
RDAdamsCommented:
You may be forced to put a DC at each remote office.
RDAdamsCommented:
On the computers do you log into the VPN first or after logging into the desktop?  Try setting up the system so you need to log into VPN first.
ITHelper80Author Commented:
The VPN is always connected, I have a NG-1 box and the rest are VPN edge boxes
ITHelper80Author Commented:
Surely I wouldnt have to put a DC at each local, we are all on T1's and there arent that many users at each office, one only has 3 ppl!!
David WilhoitSenior Consultant, ExchangeCommented:
No, that's overkill. Has it ever worked? Could the VPN be blocking something vital? Is it possible to force the policy AFTER the logon, or does that fail too?

D
ITHelper80Author Commented:
I do a gpupdate on the machines(xp ones) once they are logon to the domain and nothing  happens, I am at a loss at this point, I dont know what it could be blocking......Has anyone ever heard of a firewall blocking LDAP?
David WilhoitSenior Consultant, ExchangeCommented:
review the event logs, I just have to believe there's something in there we're missing. The clients only have one internal DNS server, right? Not an external too?
ITHelper80Author Commented:
We have two internal DNS servers both at the main office, then of course the forward any unknow packets to the internet. All users are using the internal DNS server, they are setup statically. Ill look over the logs again and post if I find something
ITHelper80Author Commented:
My event log just has the same error over and over, Ive even checked to DC's logs but they do not have any errors.
JohnGerhardtCommented:
I have seen problems with GPO's being applied over slower links - there are some settings that you can change within the GPO editor to help with this...
Try User Configuration => Administrative Templates => System => Group Policy....
Under there look for "GPO slow link detection" and GPO domain controller selection"
"GPO slow link detection" also appears in Computer Confguration as well....
See if these setting help...
J
RDAdamsCommented:
>I'm having problems pushing our group policy to remote users. I have organizational units setup with policies on each. Some of our >remote users are in these OU's, and I want them to be on the same level as the home office. I have VPN setup to where it comes >up prior to the Windows login screen (for them). Once connected to VPN, they log into Windows. This should technically log them >into the domain, but it doesn't appear the policies are pushed properly. I've already tried the /refreshpolicy from the cmd-line. >Ideas?  

Similar problem, this was suggested by   Jeremy Moskowitz  The first thing to check is to see if they are really logged on to the domain. My tool of choice for this task is KERBTRAY, found in the resource kit. KERBTRAY can let you know if user is, in fact, logged in to the domain. If the user IS logged in to the domain, the other thing I would check next is the connection speed. The policy setting named "Group Policy Slow Link Detection" can help you manage at what speed GPOs will be processed.
RDAdamsCommented:
This may also help.

>In response to Nachi, we blocked ICMP Pings to & from our VPN.
However,
>it appears that this also has disabled group policy updates for remote
>VPN users. We ran network traces and saw the ICMP packets, I think
>they're part of the negotiation phase where the server tries to
>determine if the client is on a slow link.


This may be too late but I encountered and solved the large ping problem
a few months ago. Here is the document I wrote detailing the fix.
-----------------


When running a M$ based network with a central location and numerous
satellite locations, you may encounter a rather nasty problem. Windows
2000's method for locating a domain controller is not exactly flawless.
When a workstation checks connectivity with the DC it first uses a
normal icmp ping. If the normal ping succeeds it then tests the
connection speed with an oversized ping. Specifically the size is
2048k* which puts the total packet size over 2k due to headers. This
isn't a problem when you are on a local network with nothing between you
and the DC but a switch. However, if you are at a satellite location
and you must traverse a VPN to speak to the DC there may be trouble.
Our VPN is operated by Cisco Pix series firewalls. The Pix denies
oversized icmp traffic by default. This functionality is designed to
prevent ye-old ping flood among other things. Because of this behavior
workstations at satellite sites succeed with the first normal ping but
fail on the oversized one. That causes the following error to show up
in the workstation's event log.


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


The userenv.log, which can be found in /winnt/debug/usermode/, will show
you more useful information if you have environment debugging turned on.
To do this add the following key to the workstation's registry.
Key: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows
NT\CurrentVersion\Winlogon
Value: UserEnvDebugLevel
Value Type: REG_DWORD
Value Data: 10002 (Hex)
The information provided in the userenv.log will show you that the DC is
found and "lost" as described above.


USERENV(b8.27c) 11:51:30:760 ProcessGPOs: Starting computer Group
Policy processing...
USERENV(b8.27c) 11:51:30:760 ProcessGPOs:
USERENV(b8.27c) 11:51:30:760 ProcessGPOs:
USERENV(b8.27c) 11:51:30:760 EnterCriticalPolicySection: Machine
critical
section has been claimed. Handle = 0x288
USERENV(b8.27c) 11:51:30:760 ProcessGPOs: Machine role is 2.
USERENV(b8.27c) 11:51:30:800 PingComputer: First time: 30
USERENV(298.294) 11:51:31:211 LibMain: Process Name:
C:\WINNT\system32\MSTask.exe
USERENV(1f4.2a0) 11:51:31:982 LibMain: Process Name:
C:\WINNT\System32\svchost.exe
USERENV(b8.27c) 11:51:33:629 PingComputer: Second send failed with
11010
USERENV(b8.27c) 11:51:33:652 PingComputer: First time: 60


As you can see, the "second send failed," but the first succeeded.
I discovered two solutions to this problem. The most obvious and best
for my particular situation was to increase the ping size limitation to
3k on the PIX firewalls. A more secure but harder to implement solution
is to add the following two keys to every computer affected by this
problem:


Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\System]
"GroupPolicyMinTransferRate"=dword:00000000


Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\System]
"GroupPolicyMinTransferRate"=dword:00000000


These keys tell the workstation to not test the speed of the connection
with the DC. This setting is also available in group-policy; however,
the computers must first have the setting to download the group-policy.
That is commonly known as the chicken and the egg problem. The
complicated part of this problem is that every user on every workstation
must have the user key added. Adding the key to the default user
registry space was not effective. I never put much work into a fully
automated method of distributing these keys. There is a shareware
program called "Multi Remote Registry Change"
(http://www.eytcheson.com/mrrc.htm) that was useful on the short term.
         


-Alex N. Speaks

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
ITHelper80Author Commented:
Thanks Alex the regedits really did the trick
David WilhoitSenior Consultant, ExchangeCommented:
sweet....
MightySWCommented:
I appreciate this Alex.  You really got me out of a bind with your ICMP find.

If you want to resolve this without the registry then you can configure your firewall to not inspect for ICMP fragments because that is what they show up as to the firewall.

Thanks again.
jbishop2446bCommented:
Hi Alex, I have windows 2003 (not a domain controller) where about would I insert this registry fix for a 2003 server?
stuartsolutionsCommented:
I had/have this issue, too.  I, too, use Checkpoint firewall's as VPN endpoints.  I think it is something with checkpoint filtering.  I've never had this problem before with any other devices.  In fact, one client of ours was working fine with a single DC, many satelite office setup, until they were put behind checkpoint firewalls.  We had to put this in place on every new machine that goes out.  When I called checkpoint, they acted like no one had ever called in with this problem.  Quite shocking if you ask me.  I am even having a similar problem with servers on different VLAN's all behind the same Checkpoint at our datacenter.
jmsjmsCommented:
I also had to disable "block ping of death" checks on Draytek VPN routers.
dodyryda1Commented:
thanks alex your solution worked a treat been trying to work thsi out for friggin ages ... absolute beit with regard jmsjms comment. I run draytek routers here and with dos defense disable i still couldn't get the group policy to update.. as soon as i run an update with alex's registry keys worked 1st time...
so don't think the ping of death is the causing this issue
TroiMklureCommented:
I had this issue on a Check Point device as well. Going into SmartDefense and setting the 'Max Ping Size' to 2048 resolved the issue.
VFRRiderCommented:
Alex,
Good research and a great article, we had been working on this for 2 days before I stumbled on this artlcle and it was an instant success....

Thank You!
sspeierCommented:
Optional automation to help push out to large number of remote site/clients:

1) Download PsExec.exe from http://technet.microsoft.com/en-us/sysinternals/bb897553.aspx, place/extract to \\domain_name\netlogon folder

2) Create a temporary (Domain User) service account that has local admin permissions on each workstation, i.e. – Gpfix (user account)

3) Open notepad, paste the aforementioned registry entries:

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\System]
"GroupPolicyMinTransferRate"=dword:00000000

Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\System]
"GroupPolicyMinTransferRate"=dword:00000000

4) “Save As” Mintrans.reg in the \\domain_name\netlogon folder

5) Open notepad, paste the following:

@echo off
regedit /s \\domain_name\netlogon\mintrans.reg
gpupdate /force

6) “Save As” gp_fix.bat in the \\domain_name\netlogon folder

7) Open notepad, paste the following:

@echo off
\\domain_name\netlogon\psexec.exe gp_fix.bat -u domain_name\Gpfix -p password

8) “Save As” psexec.bat in the \\domain_name\netlogon folder

9) Add \\domain_name\netlong\psexec.bat to your existing login script

10) Be sure to disable/delete the “Gpfix” user account when done

*note – be sure to replace following entries with your environmental variables:
Domain_name = with your Domain name
Password = Password for your “Gpfix” user account
sspeierCommented:
If using Windows Firewall you will need to add a line to disable the firewall, so step #5 above will look like this:

@echo off
netsh firewall set opmode disable
regedit /s \\domain_name\netlogon\mintrans.reg
gpupdate /force
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Network Analysis

From novice to tech pro — start learning today.