Applying your personal settings..... - HANG!!

[PJamesD]

Directly after we upgraded out Domain Controllers from W2K to W2K3 (fresh builds, not in place upgrades), we are experiencing problems logging into a small number of member servers. It will sit on the "Applying your personal settings..." for about 10 minutes.

Eventvwr states:
Event ID 1000
Windows cannot determine the user or computer name. Return value (1753)

Any ideas? I can't seem to find much applicable information, i've run netdiag to no avail.

Any help much appreciate, i've wasted so much time trying to resolve this now!

 

[58sniper]

If you migrated DNS to the new servers, along with DHCP, make sure that the DCs are configured to only look at themselves for DNS (configure your ISP's DNS in the Forwarders).

Also make sure that the DNS addresses being given out via DHCP are ONLY those of the Domain Controllers, and not public DNS.

Pat Richard, MCSE MCSA:Messaging CNA
Microsoft Exchange MVP

 

[PJamesD]

Hi - thanks for your help.

We are not using DHCP, all IP addys are statically assigned. It's a secure LAN, no DNS forwarders, or internet access is needed.

As it happens, - the DCs DNS settings were NOT all pointing at themselfs for their prefered DNS server. I have now changed this to point at themselves, I have flushed the DNS cache on the DCs and on one of the member servers which was having a problem, - I then tried to log in again, and unfortunately the same thing has happened, and the same Event Log message has been returned.

Regards
P

 

[Cstorms]

So when you placed these new servers in production you let the old 2k boxes replicate all objects in AD to the new 2k3 box? (same for dns zones and such?) Or is this a whole new build from ground up.

If you have a primary dns server configured to look at itself you should point other dcs to the primary dns server and as a secondary point them to themselves. (this wont resolve the issue but thought I would mention)

Again, emphasis on dns settings on the client machines, you cleared the cache but you have also changed the appropriate NIC tcp/ip settings to point to the new server? You could verify if its actually hitting the dns server by checking if it dynamically registers a host record for itself if you wanted to.

Simple stuff like that usually bites me in the butt

Good luck in any case!


Cory

 

[PJamesD]

Hi - cheers

yes, new servers were built, and AD etc was replicated over. The old DC were demoted (dcpromo). Obviously the FSMO roles were swapped over and back again etc.

There are no primary or secondary DNS servers, as they're all Active Directory Integrated.

"New Servers" - the new servers have the same hostnames and IP addresses as the old servers. As a "swing" method was used to migrate the servers to W2K3, ie, we built a new W2K servers, dcpromo'd it, transfered FSMO roles. Then we upgraded this "migration server" to W2K3. We then demoted all the other domain controllers, deleted them from the domain, rebuilt them with fresh W2K3 builds, and dcpromo'd them. We then transfered back the FSMO roles and demoted the "migration server".

This left us with 'fresh' W2K3 DC with AD replicated accross.

Hope that makes sense.

I am looking at this article, and all ports above 1024 ARE blocked, only RPC 135 is open, as per the article.

However, I have just noticed that all the member servers we are experiencing problems on haven't got 'teamed' network cards. All the servers which are working fine have.

Best regards
P

http://support.microsoft.com/kb/839880

 

[PJamesD]

Logging in locally is fine!

It's only when I log on to the domain on SOME acccounts it hangs on "Loading Personal Settings...". I did think that could be a User Group Policy issue, - but the exact same thing is happening on two seperate domains which we've upgraded in the same way.

It does point also to DNS, although name resolution is working fine.

Strange coincidence in regards to the network cards mentioned above.

Any help very much appreciated, - I'm very frustrated that this is still unresolved!

Regards
P

 

[Cstorms]

Try looking into your Userenv logs to maybe see where its hanging.

http://technet2.microsoft.com/windo...99a5-40fd-b68a-6c1979e565a21033.mspx?mfr=true

Cory

 

[lhuegele]

It sounds like a DNS issue to me also. Do an NSLOOKUP to see that you don't get any errors on your DNS server. We had a similar problem and it turned out that the DNS servers were missing the reverse lookup entries for the domain. We also noticed at the time that none of the DC's were taking on the global catalog role, so we had to fix that too. Once we did that, the slowness you described went away for us.

Good luck.

 

[PJamesD]

Thanks again for everyone who had kindly put forward comments and suggestions.

I'm not sure it's DNS... Certainly DNS is resolving queries as expected, including reverse lookups using ping -a as suggested by lhuegele.

Thanks for that suggestion Cstorms, - it's telling me that GetUserNameEx failed with 1753.

1753 is a return value meaning "There are no more endpoints available from the endpoint mapper".

I have followed & checked everything detailed on this document

http://support.microsoft.com/?kbid=839880

- all seems to be okay apart from when i run the gpotool, - i'm getting
Error: Version mismatch on <servername>, DS13, sysvol=12

It says this for each (four) domain controller.

Kind regards
P

 

[PJamesD]

I reckon the version mismatch stuff is a red herring really, - there is no reports of end point mapping problems which is the main thing

 

[sshowe]

PJamesD,

I am experiencing similar issues. Are you able to ping FQDNs as in Server.domain.com? I am unable to do this. Thanks

 

[PJamesD]

Hi sshowe

yes, i'm able to ping/resolve FQDNs no problem at all. Yours definitely sounds like a DNS issue, - I fear that mine is a little more complicated!

Good luck - keep us informed of progress!

 

[PJamesD]

Okay - the problem was the firewall.

The firewall was configured to let through all the usual AD DNS etc traffice and RPC traffic on 135. This worked perfectly when everything was Windows 2000.

Since we upgraded to Windows 2003, - all the RPC problems described above.

This ^^^ - I do not understand. I wasn't aware that the workings of RPC have changed under Windows 2003 ?????????????????????


Microsoft state the port 135 must be open which is used to listen for RPC traffic, - and then all ports from 1024 - 65535 must also be open as the Endpoitn Mapper then tells teh client which randomly assigned port between these values it will then continue to use.

You can hardcode a smaller range of ports to the client will use in the registry, so as not to completely open up the firewall, - I guess this is what we'll have to do, - and then allow this specific range of ports tcp access through the firewall.

http://support.microsoft.com/kb/839880

If any one has any better ideas, I am all ears!!

Cheers once again for everyone's help.

Best regards
P