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 1 or 2 that were built on the AD domain have not yet had a problem. We had 11 users reboot yesterday, 16 the day before. Some seldom have the problem, many have not yet experienced it. Maybe 6 or 8 experience the problem very consistantly. Of the 150, I'd estimate about 50 of those have experienced the problem. However the problem persists.Ībout 150 of somewhat over 300 users have been migrated. The user could log in and out all day long with no problem, but overnight the issue was created.Īt 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). I backed out the changes I had made previously but the problems persisted in the following days. Most were able to reboot and get loaded correctly but several profile rebuilds were required. It would be an unbelievable coincidence if the two events were not related (I dont believe it). 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. 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. We were migrating users from the NT domain in a staged fashion and some had been working fine for a couple of months. The AD domain is win2k3 r2 (upgraded to r2), the clients are xp. 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. They get userenv 1508 errors (among others) when they try to log in the first time in the morning. We're having problems with some of the users on our AD domain.

Ntuser dat windows 7