After Hours



AD clients NTuser.dat locked on login

By ·
Tags: Off Topic

We're having problems with some of the users on our AD domain. They get userenv 1508 errors (among others) when they try to log in the first time in the morning.

Some background:
Our original domain is an nt domain. All users on the AD domain (except 1 or 2) were migrated from the NT domain to the AD domain using microsoft's ad migration tool.

The AD domain is win2k3 r2 (upgraded to r2), the clients are xp.

We were migrating users from the NT domain in a staged fashion and some had been working fine for a couple of months.

One Friday night I made some GPO changes to try to correct some time sync problems, and get the PDCE to sync with an external source.

The following Monday morning there were a rash of issues with people getting warnings that their profiles couldnt be loaded and temp profiles were being created.

It would be an unbelievable coincidence if the two events were not related (I dont believe it).

Most were able to reboot and get loaded correctly but several profile rebuilds were required.

I backed out the changes I had made previously but the problems persisted in the following days. The user could log in and out all day long with no problem, but overnight the issue was created.

At suggestions from another site, I tried GPOfix to return the group policy back to default (which was fine because previously the default group policy had been modified and this gave us the chance to default it and, instead create our own adjunct policies). However the problem persists.

About 150 of somewhat over 300 users have been migrated. Of the 150, I'd estimate about 50 of those have experienced the problem. Maybe 6 or 8 experience the problem very consistantly. Others come and go. Some seldom have the problem, many have not yet experienced it. We had 11 users reboot yesterday, 16 the day before. The 1 or 2 that were built on the AD domain have not yet had a problem.

Using Sysinternals procmon and process explorer we have determined the cause of the problem (at least in the case of our test subject) is that system (PID 4) is locking the profile's NTuser.dat.

The problem is profile specific as we had our test user attempt to log in and when it failed, log off and attempt to log in under a different account. The attempt was successful.

For those who have daily problems, rebuilding their profiles usually give good results, but not always permanent.

We have tried installing user profile hive cleaner. Again this had some but not universal success. (and I consider it a band-aid). It worked fine for some of our sample group, but the main test user had little or no improvement.

By logging in under another account, and manually loading the users profile we have been able to determine that, in the case of the test user, the event causing the issue occurs betwen 20:00 and 20:45. The user logs out about 15:30 each day but I don't think the event is related to the logout time (I could be wrong).

I think those are the main facts (there are certainly a hundred others).

Does anyone have any idea how we might approach finding a solution to these problems?

Thanks for your help.

This conversation is currently closed to new comments.

Thread display: Collapse - | Expand +

All Answers

Collapse -


by In reply to so what method did you us ...

The one suggested by alashhar - deleting all of the profile entries in the registry - and then creating a new profile. We'll have to see if it holds....

Collapse -

Better solution

by In reply to Alashhars

For anyone battling this type of problem, I have found a somewhat better solution than Alashars on another forum. In Alashar's solution, you - of course - wind up blowing the profile away and it requires you to rebuild the users profile - copy all their old stuff over, etc.

The following procedure avoids that and seems to fix the problem, and can be executed remotely with a little effort, without bothering the user:

1 Get the SID of logged in user that has experienced the problem - I do this by remotely executing whoami.exe using OWexec.exe (a tool similar to psexec but runs under logged in users credentials)

2 remotely connect to the user's registry and go to HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\<SID from above>.

3) Note the value for ProfileImagePath

4) Check the value of ProfileImagePath for each of the other SIDs in CurrentVersion\ProfileList to see if they are the same value as noted in step 3.

a) NOTE: %systemDrive%\documents and settings\(profile) is the same path as C:\documents and settings\(profile)
b) If a duplicate value exists:
i) export the registry key and save it to c drive of that machine just in case.
ii) Then Delete the key containing the duplicate path and disconnect from the remote registry.

So far this has worked for the machines I've implemented it on (over 30). But I would LOVE to have an explanation of what is going on here.

Remember that these are :
1) clients migrated from an NT4 domain to an AD domain
2) running xp and win2k
3) not running terminal services
4) a 2-way trust exists between NT and AD domains
5) Does not occur to every PC every day ? only about half of the migrated PCs have exhibited the problem. Some of those occaisionally ? some regularly.

Collapse -

NT domains and Active Directory domains don't intergrate

by CG IT In reply to AD clients NTuser.dat loc ...

this one, because of the way you migrated from NT to Active Directory using ADMT, I think is a security permissions problem.

0226 userenv 1054
0628 userenv 1508
Windows was unable to load the registry. This is often caused by insufficient memory or insufficient security rights.

This one probably is probably the same as the one above. A security permissions issue. BUT it might be profile related. again because of how you migrated them from NT to Active Directory

2 sec later userenv 1502
Windows cannot load the locally stored profile. Possible causes of this error include insufficient security rights or a corrupt local profile. If this problem persists, contact your network administrator.

This one, seems as though it's looking for the Active Directory profile and can't find it. There is an account in Active Directory but no associated profile for it.

<1sec later userenv 1511

Windows cannot find the local profile and is logging you on with a temporary profile. Changes you make to this profile will be lost when you log off

This one I think is more of a problem. Not quite sure what you did here. Did you move the NT DNS to the Active Directory DNS and create a new zone for! it in Active Directory? if so, that's a problem. NT is not compatible with Active Directory. Your DNS server can act as a DNS for the NT domain, but you can't intergrate the NT domain with an Active Directory domain. They still have to remain seperate domains, thus seperate zones in DNS and not intergrated into the Active Directory DNS zones for the Active Directory domain.

Later on, we created a new DNS server on the AD domain on a DC - decommissioned the DNS server on the NT domain, and moved the IP address - x.x.x.30 - of the old NT dns server, to the DC. We bound it's DNS to x.x.x.30, and disabled it's old nic so x.x.x.30 became it's only address.

and this one is related to the one above:

0033 userenv 1054
Windows cannot obtain the domain controller name for your computer network. (A socket operation was attempted to an unreachable host. ). Group Policy processing aborted.

note: NT domain users must use the NT domain PDC or BDC to authenticate to the NT domain. They can not use the Active Directory domain to authenticate with. NT Domain users can not log on to the Active Directory domain using their NT domain profiles ..and.. their workstations have to be members of the NT domain. If their workstations are joined to the Active Directory domain, they have to use the Active Directory domain user profiles. If you want to keep NT domain user profiles in the Active Directory domain, the ADMT might not work as planned, and you'll have to use the fix corrupt profile method of creating a clean profile, then moving over the old profile settings into the new clean profile and leaving out the these 3 files from the old profile.


Collapse -

DNS problem resolved

by In reply to NT domains and Active Dir ...

"This one I think is more of a problem. Not quite sure what you did here. Did you move the NT DNS to the Active Directory DNS and create a new zone for! it in Active Directory? if so, that's a problem. NT is not compatible with Active Directory. Your DNS server can act as a DNS for the NT domain, but you can't intergrate the NT domain with an Active Directory domain. They still have to remain seperate domains, thus seperate zones in DNS and not intergrated into the Active Directory DNS zones for the Active Directory domain.

No what we actually did was just create an AD DNS server and move the IP address only, of the old DNS server that was serving the NT domain, over to the new DNS server on the AD domain. In this way, all of those static clients pointing to x.x.x.30 for DNS would still find a DNS server there - only now it is a different server running on an AD domain. So it's just like you said, an AD server serving up DNS to an NT domain.

"note: NT domain users must use the NT domain PDC or BDC to authenticate to the NT domain. They can not use the Active Directory domain to authenticate with. "

Right, and that is exactly how it is. The NT users authenticate to NT4 PDC and BDC. The AD users authenticate to an AD PDCE and DC.

And, I found the issue with the strange DNS Suffix! Taking a very close look at the packet captures from pinging NTPDC.NTDOM.COM vs just pinging NTPDC, I finally noticed that there was a semicolon at the end of the created fqdn in the latter case ( I checked the search suffix on the client and even replaced that entry, though it looked fine. Still had the issue. I took a close look at the DHCP server. That's when I found the blurb about microsoft not supporting DNS suffix order - Is that true? But in any case, I noticed that the suffix search order in DHCP option 119 was separated with semicolons. That made me suspicious (not sure if semicolons are allowed there or if it has to be commas)

but then I remembered that somebody long ago(not that long ago) had specified a suffix search order in group policy. So I took a look at that and it was separated by semicolons as well, and on that one, the descrpition specifically says to separate with commas.

So I changed that, forced a gpupdate on a few clients, did an IPconfig /flushdns, repeated my pings, and this time it correctly resolved with

One little mystery solved but I don't think it will help us with the profile issue.

btw. I have been assuming all along, that running an RSOP would show any failed permission issues for group policy. Is this true or am I swimming under a false assumption?

Thanks for all your help

Collapse -

the result of all policies applied.

by CG IT In reply to DNS problem resolved

you want logging mode to see how the GPOs are applied to users/computers/groups of em. eg if you've got 5 GPOs applying to an OU or a combination of nested OUs you can see the result.

Planning mode allows you to see a result without applying the GPO. Great for what ifs.

RSPO doesn't really tell you conflicts per se eg this policy conflicts with this policy, because conflicts are handled by order of precedence eg local, site, domain and OU in that order so a conflict at the OU level with local machine level, OU applies with the exceptions of block and no override.

If you have 3 GPOs at the OU level and they apply in order 1,2,3 RSPO will show you the results of those GPOs being applied in that order.

And back to NT domains. Much of what admins could do in NT domains, they couldn't do in Active Directory domains. Some of the older NT guys really disliked Active Directory domains because many of the scripts, configurations, tweeks, and waaahaaas to keep NT working right no longer work. Just like the open source debate with programmers hating standardized applications. They can't do their magic or tweeks, or little code changes they like to do.

so while NT scripts are ok for NT machines, they may not be ok for AD domains. same with importing group policies from NT to AD. Especially going from NT to W2003.

and I would still try that corrupt profile method for moving NT profiles to AD profiles if desktop setting for the user environment is a necessity.

Collapse -

added thoughts....

by CG IT In reply to AD clients NTuser.dat loc ...

typically, microsoft's best practice of moving from an NT domain to an Active Directory domain is to upgrade the NT domain to Active Directory. The upgrade process juggles all the seperate security domains in the NT domain, into, basically, one big security domain. While the upgrade process tries to incorporate some of the security domains into child domains, sometimes that doesn't work well. So those security domains end up like these seperate domains in a different forest. Weird but it happens, especially if there are a bunch of security domains with different names [non contigious names]. The upgrade process also changes the schema which is really at the core of the differences in NT and Active Directory. The way Active Directory names objects is different and the way those objects are cataloged is different than NT.

Collapse -

No Control over the guilty apps

by CG IT In reply to AD clients NTuser.dat loc ...

No Control over the guilty apps
They reside in someone else's ballpark and they won't modify them.

And there is still the issue of the 2 domains. does \\myNTserver\thisshare refer to \\\thisshare or \\\thisshare.

So I am not sure we can get away from this scenario in the short term. But if it is more reliable to handle it on the host, than it is via DHCP or group policy, or more reliable to handle it some other way, we want to do that.


it shouldn't matter provided that your using W2K and above. you can actually turn off NetBIOS over TCP/IP and run a pure TCP/IP network with DNS......and you might want to consider WINS for pre W2K stuff and go with a simple computer name to ip address resolution rather than some Group Policy stuff that may or may not work reliably.

but if your mixing and matching domains in a non contigious namespace using trusts, and the domains are NT and W2003/2008 Active Directory, I wouldn't mix and match users unless it's done simply to access shared resources where share and NTFS permissions apply.

and after I thought about it, I wouldn't mix and match users in the domains. Either 1 or the other and they access stuff through the trust or remote access, but not access by span domains and with mapped drives, I'd screw the names and stick strictly with ip address. \\ip address\share name.. least with that, you either get a credential box popup or the trust allows access.

if it's remote, you know, least painful way, use Remote Access to control it. and that's until someone comes up with a plan to move all data and all users/compters from the NT domain to the Active Directory domain.

The 2 domains are just making a big headache and costing money.

Related Discussions

Related Forums