I'm trying to fix things up at a site where the server has been destroyed by viruses and neglect. Whilst some things were working from a user point of view nothing was administerable - eg I can't add/delete users.

We set up another server and gave it the same domain name. We exported/imported the list of groups and users. We copied the files/databases across.

Before we shut down the "old" server we went around to each desktop PC and moved it to a workgroup - ie removed it from the domain. We then removed the old server from the network, plugged in the new server and went around starting to add the PCs back to the domain.

The Win98 machine we tried seemed to join back on ok.

The Win XP Pro machines joined back to the domain without any problems but when you go to log in they sit there saying "applying your personal settings" and nothing ever happens past that point.

Does anyone know why? Or how we can go about fixing it?

Update - after leaving it for a long time (15mins or so) they eventually logged in and worked.

Tomorrow we have a heap more machines to join to the domain so I'll try the logging suggestion below.

  • are you saying that your dc was destroyed by viruses? if so then everything within your facility has probably been rooted at this point. – tony roth Dec 15 '10 at 15:18
  • also is this a single server enviro or something like SBS? – tony roth Dec 15 '10 at 15:22
  • I think the DC has been destroyed by viruses - I can't see why else pretty much all the admin side of things has broken while it still works from the user point of view. Once I get it all working there will be 2 servers, one as a backup. Standard Win Server 2003 running SQL Server Express 2008 R2. – peter_mcc Dec 15 '10 at 16:22

If you want to troubleshoot this kind of issue, you can try to setup the userenv.log file with high details, try to login, wait a bit and then review the userenv.log file.

You should be able to see what is stopping your login.

More information here : http://support.microsoft.com/kb/221833


Most of these sort of issues with long AD logon times are DNS-related, caused by the clients not being able to look up vital SRV records for the domain. It's unintuitive, because even with misconfigured DNS, these clients are able to join the domain by locating it via NetBIOS, and then left in a state where they're unable to actually do anything with it.

In most instances, especially at small sites, these are caused by having a DHCP server (usually a cheap broadband router) other than Active Directory handing out upstream Internet DNS servers rather than passing DNS off to AD. The simplest way to fix this is usually to disable DHCP on the router and ensure that Active Directory is responsible for handling DHCP leases, but if you continue using another DHCP source, at least ensure it's configured with the correct AD DNS servers.

Double-check the DNS configurations when the client systems finally finish logging in, and make sure that all of your important SRV records are resolvable through nslookup.

  • I'm a bit of a novice with this - what SRV records should I have? – peter_mcc Dec 16 '10 at 17:51

Applying personal settings is when machines download any mandatory or roaming profiles from the DC. You should check that they are available on the new server.

  • They only have a logon batch file that has 3 commands related to mapping drives. – peter_mcc Dec 15 '10 at 11:47

If you're joining to the domain then dns seems to be working.

If you did not change the original domain name then it's possible that the old profile is being reused.

  • That's possible - the domain name didn't change. I'll try deleting the old profile on a machine tomorrow and see if that helps. It only seems to be the first time that it is slow. – peter_mcc Dec 16 '10 at 17:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.