Error 1054 in the event log - Source: Userenv

I am trying to troubleshoot this error for several weeks now to no avail.

this error is repeating itself every 5 min on my SBS2003 server.  

Here is the scenario:
I have 2 different locations: Seattle and Portland connected by a WAN-VPN link (not very fast)

SBS2003 Server

Windows 2003 secondary domain Server
On the Portland server I am getting errors: 1058 and 1030 which I believe are caused by or a product of (i'm not sure which) the errors on the Seattle server.  (i have attached photos of these errors)

After reading multiple posts and trying several things I attempted a reg edit on the SBS server.  After doing this the error still appears but only every 2 hours or so.

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\System   "GroupPolicyMinTransferRate"=dword:00000000

I found this recommendation here:

I also found some suggestions on the same post to delete any network cards in the registry that did not exist.  I did have some that are in the registry and do not exist and deleted them as techsoeasy instructed, but upon a restart they came right back.

I'm not sure where I should go from here and I really need help.  Thanks in advance!

Who is Participating?
Darius GhassemCommented:
I did some research and found a case close to yours. Their fix was to use this MS article. The try the article below too.

have a look at this article as it describes the event 1058. i had some similar problem and solved it by looking at the permissions on the policy that server tried to access. In your case Portland is trying to reach Seattle, so try and check Seattle permissions.

this article describes event 1054.

hope this helps. i will look around for some more info for you!!
Darius GhassemCommented:

To resolve event id 1030 and 1058 immediately, contact Microsoft to obtain
the hotfix (the hotfix is free - knowledge base 842804).
As workaround open the command prompt type dfsutil /PurgeMupCache, and then
press ENTER.

Free Tool: ZipGrep

ZipGrep is a utility that can list and search zip (.war, .ear, .jar, etc) archives for text patterns, without the need to extract the archive's contents.

One of a set of tools we're offering as a way to say thank you for being a part of the community.

""Distributed File System
The Distributed File System (DFS) service manages logical volumes distributed across a local or wide area network (LAN or WAN) and is required for the Microsoft Active Directory SYSVOL share. DFS is a distributed service that integrates disparate file shares into a single logical namespace.

NetBIOS Datagram Service --UDP 138
 NetBIOS Session Service --TCP 139
 LDAP-- Server TCP 389
 LDAP-- Server UDP 389
 SMB-- TCP 445
 RPC-- TCP 135          
 Randomly allocated high TCP ports-- TCP RANDOM
 NetBIOS Datagram Service--- UDP 138

Netbios is a non routable protocol. Since DFS uses Netbios, and Netbios broadcasts are blocked by when trasiting a VPN connection, you will not be able to DFS share your SYSVOL RECORDS to the Seattle base computer. Another thing you will probably note is that the Seattle computer shouldn't show up in "My Network Places" of the Portland computer.

WINS can be used as a transport between the servers over the VPN connection. It was suppose to be replaced by DNS. However, MANY crucial functions, like the Master Browser Service and DFS use Netbios Datagrams. The problem is, without WINS configured, these netbios broadcasts can not propogate over a firewall, through nat, and through a VPN tunnel.

FIX 1) So, here is what you do. You can configure WINS. Below, is an article on how to configure WINS for the Master browser service. All you want is a transport of the VPN tunnel. 

Alternative fix: Fix 2) An alternative fix is to use DNS as the transport for DFS:
PLEASE NOTE: Please look at the key ports used by Windows 2003 anything using ports 137, for WINS and Netbios datagram ports 138 and 139 are effected if you do not use WINS. If all you are after is DFS, then you could use DNS. So, there are drawbacks to using DNS.

ITPro44Author Commented:

I appreciate the responses.  I had something come up last night and have been kept busy until now and now I must leave to get home after this long day.  I apologize for the late response.  and I will look into them in more detail tomorrow.

ITPro44Author Commented:
Ok, I applogize again for my delayed response.  I'm ready to start tackling this full force now.

adnan007:  Your first article applies to Windows XP, my errors are exactly what they describe but I'm running windows server 2003 - Your thoughts?

Your second article I have tried already, the settings are correct.

dariusg:  My problem does not consist of the server coming out of a standby state like the article addresses.

ChiefIT:  Thanks for your extended research and response.  Before I jump into following what you have recommended I wanted to note that I can browse to the Seattle server within "My Network Places" on the portland server.  Does this change anything?

Thanks for your responses!

Darius GhassemCommented:
If you don't have the support tools installed, install them from your server
install disk.

Run dcdiag, netdiag and repadmin in verbose mode.
-> DCDIAG /V /C /D /E /s:yourdcname > c:\dcdiag.log
-> netdiag.exe /v > c:\netdiag.log (On each dc)
-> repadmin.exe /showrepl dc* /verbose /all /intersite > c:\repl.txt
-> dnslint /ad /s "ip address of your dc"

**Note: Using the /E switch in dcdiag will run diagnostics against ALL dc's
in the forest. If you have significant numbers of DC's this test could
generate significant detail and take a long time. You also want to take
into account slow links to dc's will also add to the testing time.

If you download a gui script I wrote it should be simple to set and run
(DCDiag and NetDiag). It also has the option to run individual tests
without having to learn all the switch options. The details will be output
in notepad text files that pop up automagically.

The script is located on my website at

Just select both dcdiag and netdiag make sure verbose is set. (Leave the
default settings for dcdiag as set when selected)

When complete search for fail, error and warning messages.

ITPro44Author Commented:
Hey DariusG  I performed the tests using the utility you provided.

I have uploaded the log results.  I'm not sure how I should interpret everything.  I'm heading to lunch and will be back in an hour.  I'll check back then.

Darius GhassemCommented:
I don't see anything to be concerned about. You do have WINS installed and it is not having any problems that I can see if the report. The one thing I would look at doing since I didn't see one is adding a WINS server to the Also, I would still run the dfsutil /PurgeMupCache.
ITPro44Author Commented:
I ran the dfsutil /PurgeMupCache on both servers and there was no change to the error.

I will add a wins server to Portland and report back in the morning.  I have to head out of the office for today.

Thanks for you help dariusq!
ITPro44Author Commented:
An additional note, I think I added the Wins server to the Seattle SBS2003 server when I was attempting to try and solve this problem.  Not sure if I really need it or not.  I'm not sure how it will affect things.
Wins is a transport. Since you have a VPN connection between the two and netbios can't route over the VPN connection, you must use wins between them. You should not be able to see eachother in My network places. You did have WINS, but only one record between them. That means the transport is one way. Here is a pick of what you want. Netbios over TCP/IP broadcasts between the local clients and server. Then WINS transports the netbios over the VPN connection.

Now this particular one is for the browser service. However, they rely upon the same transport and broadcasts.

I think your issues will be resolved when you have a WINS record for both machines at both sites.
ITPro44Author Commented:
So I went to install WINS on the Portland Server and it asks me for the windows cd.  Is there anyway to get around this.

Also, I looked back to see when these problems originated and the errors on the Portland server 1030 and 1058 have been happening consistently back until March of 2008 where the logs stop.  The error on the Seattle Server just started to occur recently when I migrated the SBS server, on May 25, 2008,  to a virtual machine.  I now believe these issues to be totally separate. Should I open up a separate question for the Seattle Server Error?
ITPro44Author Commented:
Thanks dariusq!!!

I didn't try the microsoft article as it didn't seem to apply because I do not have an AMD processor.  

I did try the suggestion made on the second link:

I used Group Policy Object Editor (Gpedit.msc) to modify "Group Policy slow link detection" on the server at both "Computer Configuration\Administrative Templates\System\Group Policy" and "User Configuration\Administrative Templates\System\Group Policy".  I enabled it and set the value to 0 (zero) which disables link detection.

I have not gotten any errors in the 30 min after I did this, we'll see how it turns out over time.  Can you tell me what this change does and if there is any possible adverse affects it may have.  I'd hate to put a bandage on a severed limb.  
ITPro44Author Commented:
ChiefIT:  Thanks for your description.  I would still like to put a wins server in Portland, but I'm not sure how to install it remotely without the CD's.  Do you know how?
Darius GhassemCommented:
This will give you a little overview of slow link detection. It is based on 2000 but the same technology.
ITPro44Author Commented:
Thanks for the link!  I read what slow link detection does and got to thinking.  Like I mentioned, I did a P2V conversion of this server to Hyper-V on 5-25-08 and this error has been consistent since that point.  I then remembered seeing that when I ping from the SBS Virtual server to a cient machine get crazy response times.  like 11000ms!!!  check out the attached file.  All of these ping results are returned immediately and there is not delay as their should be if the response times were what they say they are.
I can ping from a client machine to the server and get normal results of 1ms.

Additionally the virtual adapter that Hyper-V installs says its a 10GB adapter (photo attached).  I'm not sure if this is a bug within Hyper-V or if this is something within SBS and detecting the adapter speed wrong.

Any ideas as to why this may be happening?
Darius GhassemCommented:
I don't know but it does seem weird.
There's no need for another question:
They are separate issues and you are a wee bit ahead of me. So, let's separate the issues and we will knock them both out>

For instructional purposes let's look at these LANS as two single isolated LANs:
Event ID 1054: And how to correct this issue.
"This error is repeating itself every 5 min on my SBS2003 server"
This is usually caused by a wrong preferred DNS server in one of the NICs. If the NIC resides on a DNS server, that NIC should start with itself as the preferred DNS server and one other internal DNS server as its list of preferred DNS servers. Use the IP address, instead of the 127 loopback address for the prefered DNS server list. Also, if this is a name server, use its IP address first for the preferred DNS server. Here is how to change the prefered DNS server.

These nubers are just an example and shouldn't be used for your application:

IP address is<<<<<<<<<My Name server's IP
Default gateway is
Subnet mask;
DNS servers : <<<<<<<<<My primary prefered DNS server IP.
              <<<<<<<<<Alternate prefered DNS server's IP. If no other DNS servers on that LAN it should be left blank.

Still viewing this as separate LANS:
1030 and 1058 in your case means that you are not sharing your GPOs from One Seattle DC to the Other Seattle DC. Replication of these shares is done by DNS between the servers. When you get the preferred DNS server right, you can force replicate. That information will be provided in the fixes below.
Still looking at these LANS individually:

Using this article as a reference:

This is what netbios does for a single isolated LAN communications. For one isolated LAN, all you have to do is enable Netbios over TCP/IP on all of the NICS on the LAN >>unless it is a multihomed computer<<:

1) DFS (Distributive file shares will share out Group policies)
2) Browser service (The browser service internally uses netbios broadcasts and going to different subnets uses WINS)
3) Fax service
4) license logging service
5) netlogon
6) messanger
7) performance logs and alerts
8) Print spooler
9) RPC locator
10) server service
11) system management server
12) WINS of course

NOW let's join the two LANS:
The two LANS can be in a trust relationship that use DNS for many services. One may be a forest server and the other may be the forest's child domain. Or each can be an individual domain that trust eachothter. In this case, they will share most things between them. However some functions of Netbios will not go from one domain to the other without WINS.

Since netbios is not routeable, you may need to involk WINS for some of these 12 services to work. Example, If you want a full list of computers, from both sites, in 'My Network Places' you need WINS to share the browselist between them. This is illistrated in the free body diagram I provided you. Netbios will populate the browselist in each domain. Then sharing those browselists will need WINS. The key to remember is netbios is not routeable.

Now to your Fixes:
First fix each LAN, individually of the 1054, 1030, and 1038 errros by setting the preferred DNS server settings right. Then, replicate between from that site's PDCe to the other site server.  Here is how to force replicate.
Step 1:
Step 2:

When done, consider communicating between the two LANS by WINS and how important these 12 services are to you.  Wins is on the CD and I don't think is downloadable.

ITPro44Author Commented:
Well, I found this link:

It seems to discuss the same issue I am having.  And oddly enough, your first link that you posted several posts ago:

seems to contain the solution that some seem to be using.

Darius GhassemCommented:
Chief I think we fixed the first problem with the GPO error it seemed to be the slow link detection.
ITPro44Author Commented:
Yup, disabling the slow link detection eliminated the error.  That then shed some light on the problem and I have narrowed it down to being a problem with Hyper-V.  This link explains things:

The crazy ping results only seem to occur when the guest VM has 4 logical processors assigned to it.  So rather then put a band aid on the issue I am going to change the logical processors to only have 2 and then revert the GPO settings that I changed back to default.

I do still want to fix the errors on the Portland server, but if I have to have the cd to install wins then that will make things a bit difficult.
What's your ping latency now? It should be less than 10ms and more like 1ms. To give you an idea, I am in the middle of the pacific. I connect via satellite. My sat connection passes my traffic to another sat and sent back to the east coast out to our headquarters router that is another 1200 miles away. From the HQ router it goes out to the outside world for a ping on google. 700ms for that latency.
ITPro44Author Commented:
I have not made the change yet.  I have to take down the server in order to do so.  I am waiting for the weekend in order to be able to do that.  Also, I will be traveling to Portland for a Wedding this weekend and I'm going to try to swing in the Portland office and install Wins really quick.
ITPro44Author Commented:
Here is another link that describes the ping problems within Hyper-V

While we take a breather:

You know, dariusq, these guys are top knotch. I am pretty impressed with SPD. There's very little heineous crime there. Federal Way PD is cleaning up the red-light district, too.

When I worked for the phone company, SPD had a real nice 911 call center setup that we phone techs worked on periodically. If you go by the 911 call center, (that I think may still be ranked #1 in the country), their IT staff has put some serious thought and time into it.

I guess I can see the importance of what we are working on, here.

ITPro44Author Commented:
OK I added "/usepmtimer" to the boot.ini  as described in this article.

This has solved the problem my 1054 Errors!!  Woot Woot!!  

I also installed the WINS Server in Portland over the weekend.  I am, however, still a little skeptical about this.  as it stands, I can ping the computers in Portland by there FQN and view them in the network neighborhood.

I'm heading to lunch right now and will come back in a bit and review everything again to see if I can better understand things now that I one error out of the way and know that they are not related.
ITPro44Author Commented:
Oh my... I've gotten innondated with other tasks.  The 1054 Error was my main problem and the other ones on the portland server have been happening for over 6 monthes now with no adverse affects.  I plan to put in a new server in Portland anyway within several monthes so I am not going to spend anymore time trouble shooting those errors.  I appreciate both your help and if the time comes again, I will post a question specific to these errors.

Thanks guys!!
ITPro44Author Commented:
Thanks for both your help!
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.