Join or sign in Register for your free TechRepublic membership or if you are already a member, sign in using your preferred method below. Use Your Email Use FacebookUse Linkedin

XP clients take too long to apply user settings from Server 2003 R2

Locked

Hello,
I have been experiencing this issue for a while, and I’m hoping some other users will be able to help me out.

Originally, it was only one workstation, and now it’s most of the LAN that experience this issue. Each user authenticates with username/password, and in the process of arriving at their desktop the system seems to stall at “applying user settings”.

The server is about 4 months old, with the following spec:
HP ProLiant ML310 G4
Dual-core Xeon 3050 @2.13GHz
2GB DDR2 RAM
2x500GB SATA drives, configured RAID-1
Windows 2003 Server R2 Standard Edition.

We have about 13 users accessing the server, and this office seemed to manage okay for a few years on a Windows 2000-based environment with a P4 2.8GHz setup. When the previous server failed, we setup this ProLiant and it seems to be causing us quite a headache.

Thanks in advance for your support.

Topic

Clarifications

In reply to XP clients take too long to apply user settings from Server 2003 R2

Clarifications

what’s on the server?

In reply to XP clients take too long to apply user settings from Server 2003 R2

Is it a domain controller or a file/print server?
Do your users have a roaming profile on this new server?

Is the server in the same office as these 13 users?

we use ProLiant

In reply to what’s on the server?

our servers are all proliant and have no probs…

if its taking ages on apply settings, is there a group policy in place thats updating the systems at each logon?? i would check that….

also where are these machines getting their IP addresses?

IPs are coming from the router

In reply to we use ProLiant

I don’t think there are any group policies on sign-on, although we use a login script to make the network drives.

The IPs are coming from the SonicWall router/gateway device.

As I posted above (in response to the other person), I was suggested that it might be DNS-related, and have to check on the configuration of the DNS server.

Server is a PDC and file/print server

In reply to what’s on the server?

Thanks for the reply. The server is both a primary domain controller and a file/print server.

I don’t believe that we have roaming profiles, and the server is in the same office.

I think the issue is related to DNS, as two people that I spoke to suggested, and will hopefully check on that when I am on-site next time.

definitely dns issue

In reply to Server is a PDC and file/print server

I am 100% sure it is a dns issue. setup xp clients manually to use ip address of ur server 2003 as their dns server and also check srv record of dns server.

DNS is probably wrong

In reply to XP clients take too long to apply user settings from Server 2003 R2

I have experienced this before and it was the DNS setting not pointing to the server doing the authentication.

DNS SRV records

In reply to DNS is probably wrong

Hi,

If the server is new, it could be possible that when DCPROMO was run, and the existing server was removed from the domain, the NS records for the old server haven’t been removed.

Also try checking the Service Location records within the Zone. It may be that there are rogue servers listed in their, this causes problems with trying to find a DC to authenticate with.

Debugging

In reply to XP clients take too long to apply user settings from Server 2003 R2

Turn on user debugging see:
http://support.microsoft.com/kb/221833/en-us
this produces a detail time stamped list of things as they happen during machine startup and user login. In our situation we we able to see where there was a 20 second delay during login and this fixed it:
http://support.microsoft.com/kb/899409

Event viewer logs

In reply to XP clients take too long to apply user settings from Server 2003 R2

I doubt it’s authentication that’s causing the issue. If you get to the “applying user settings”, your clients are already authenticated. This seems like an issue applying GPOs to me. I would check event viewer logs on the DC as well as the clients for any events showing issues with applying GPOs.

I had a like issue

In reply to XP clients take too long to apply user settings from Server 2003 R2

But we Dell eqipment at my office. But the cause was a piece of equipment called a TOE clip. What this looks like is a rj-11 clip. Mine was green in color. I had to shut the machine down and then just removed the clip and started the machine and things were fine after that. What was actually going on was it would take over 1 hour to copy over 258 mb of data and when I removed the clip it only took maybe 3 minutes or less. the same file. I was told by Dell that was designed for larger networks over 30 servers. Might want to look into this if your server has this “wonderful” piece of equipment.

Logon profiles take forever!

In reply to XP clients take too long to apply user settings from Server 2003 R2

We had a similiar experience. We use manditory profiles (for students) and what I found was that during the logon, the policy seems to sit and wait for 3 by 20 sec delays. I was unable to determine what it was really waiting for. Since I originally thought it was because I had include the OFFICE admin policy stuff, I decided to disable the policy and the logon was quick. I then created a new one and proceeded to “screen by screen” reset the polices settings as per the original. Image my surprize when after several intermediate tests, I was able to reset all the same original policy settings and have a quick logon!!

It would appear that the original policy is looking for something that no longer exists (why I dont know but maybe something changed over time to the network). Anyhow the problem has now gone.

If you are using any policies (or the default), try disabling them temporarily to see if this make a difference. If not then its not the problem! 🙂

Thanks for the feedback: Result was DNS Issue

In reply to Logon profiles take forever!

Thank you to all who responded. Someone else was called in (without my knowledge) and explained that it was a DNS issue. I don’t know what went wrong that it was “all of a sudden” and originally on one workstation, and then the problem spread.

[Author]

Replies