XP Local User Profiles in a domain environment

[godfather]

Hi All,

This is a pain in my Bu** as I am having problem with a user account. The user account has administrator level role on the local machine and also the account has already been added in admin group on local machine. Howerver, user is getting the domain profile on the local machine when the user login on XP client . It means that the user has no ability to access the local resources i.e. control panel, admin tool. I have followed all the steps which are mentioned on this threat but no luck. Can anyone help me please as it is really annoying to me. At the moment, I have put the user ID in the Admin folder which is not the best practice for myself as a Sys Admin. I am looking forward to hearing from anyone who can help me out. Thanks in advance.

Cheers,
GF

[nfpiddo]

Originally Posted by Ozzyo99

Right this has been the proverbial plague for our business, it doesn't happen frequently but when it does it's a pain in the backside, especially when factoring in additional non-standard build software, and requesting licence keys for activations etc.

Glad i bumped into this thread because the answer to the problem is:

1. Log onto system (preferably as admin).

2. Goto start/run/regedt32

3. Locate key - HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList

4. This will show all readable profiles on the machine, it may but probably will not show information leading to the users original profile.

5. Navigate to C:\Documents and Settings\UsersName and note the profile name of the original profile, usually the same minus the domain information. Make a note of it.

6. Now go back to regedt and manually edit the duplicate profile location in the ProfileImagePath key to that of the original e.g:

Original - %SystemDrive%\Documents and Settings\jsmith
Duplicate - %SystemDrive%\Documents and Settings\jsmith.domain



Change the duplicate to point to the original profile, save the change.

7. Now have the user log back in, and they should now again be operating on their original profile - bring on huge relief!

Ozzyo99, thanks for posting this solution!
It worked 100% for me and saved me a lot of time, great!!!

[seacliff]

Originally Posted by Ozzyo99

Right this has been the proverbial plague for our business, it doesn't happen frequently but when it does it's a pain in the backside, especially when factoring in additional non-standard build software, and requesting licence keys for activations etc.

Glad i bumped into this thread because the answer to the problem is:

1. Log onto system (preferably as admin).

2. Goto start/run/regedt32

3. Locate key - HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList

4. This will show all readable profiles on the machine, it may but probably will not show information leading to the users original profile.

5. Navigate to C:\Documents and Settings\UsersName and note the profile name of the original profile, usually the same minus the domain information. Make a note of it.

6. Now go back to regedt and manually edit the duplicate profile location in the ProfileImagePath key to that of the original e.g:

Original - %SystemDrive%\Documents and Settings\jsmith
Duplicate - %SystemDrive%\Documents and Settings\jsmith.domain



Change the duplicate to point to the original profile, save the change.

7. Now have the user log back in, and they should now again be operating on their original profile - bring on huge relief!

As I can understand, Windows create a new folder if the user doesn't have a folder with the same "login name" or if that profile has corrupted files (NTuser.xxx).

I have tried your Reg Tweak, and it works like a charm and makes things a lot easier. But what happens if the original profiles is corrupted? Won't the duplicate one becomes corrupted?

[ka.rot]

I know that some people dislike old cases being continued. But I also had above problems of multiplication of user profiles. And though I found above information very professional and profound it did not really help to solve my problem.

So I did some additional investigation and found out both, why the problem occurred on my installation and how I could solve it. And after all I also detected some of above points contradicting to my experience. I thought my findings may be helpful to some others suffering from this kind of problems.

First experience that has been helpful to me:
network logon for a specific user with Domain control and server stored profile was
successful on a desktop.
not successful and leading to profile replication on a laptop

Conclusion
The reason for profile replication must result from something in the client and cannot, at least not in my case, be caused by the server.

Difference of settings in Desktop and Laptop
In the laptop I used a registry setting that caused profile unloading at user logoff (Security reasons)
In the desktop I maintained the profile at user logoff (speed reasons)

Now I found out, that the reason for profile replication on the laptop was always, that in conflict with registry setting the profile could not be unloaded at user logoff. I have take three measures against this:
1. Use user profile hive cleanup uphc (this helped to get rid of some *.dat files at logoff)
2. Set Windows Indexing Service to manual start (this helped to avoid production of some *.URL files that could not be unloaded. They mainly occurred in the favourites directory and in the startupmenu)
3. Remove automatic start of Active Sync (this helped to avoid creation of a file $_hpcst$.hpc, that could not be unloaded inspite of uphc.

Once these measures have been implemented all reasons for reproduction of the problem have been removed in my case.

But repair of the profile is still necessary. This comprises:
1. Removal of all locally stored profiles for the given user
2. Introduction of a profile username and give it one dummy file ‘(should look as being used and unavailable for futher usage)

This all being done. I could login on the laptop, found myself always as user.domain, and this has remained since then for many logins without and with intermediate processor boot.

That being said
Local Registry corruption can be excluded as the problem reason an my laptop, where user profile is unloaded at logoff.

One could now raise the question, whether registry corruption could become a problem for the desktop, where user profile is not unloaded. I doubt!! Based on my experience with my Desktop profile downloading to the desktop is very fast. As both my laptop and my desktop are connected with my network over LAN I conclude from this difference in speed of profile downloading that profile downloading to the desktop is only done for the files that have changed. So if registry had not changed there is no download. If registry has changed the new registry will be downloaded from the server. I cannot see any way how a corrupted registry on the client can inhibit downloading of a good registry into the existing profile and hence cause creation of a new profile. Therefore deletion of the registry in the profile existing on the client cannot be a permanent solution to the problem of profile replication.

Last not least I want to address the issue of a registry corruption on the server. In my opinion that could cause stability issues on the client after completion of download. It could however not cause replication of profiles.

All measures described above have been necessary and sufficient to solve my problem as far as repair and prevention is concerned.

I know, that for reasons of space and time I had do leave out quite some details. But if there is a need I am ready to fill existing gaps.

[ka.rot]

I know that some people dislike old cases being continued. But I also had above problems of multiplication of user profiles. And though I found above information very professional and profound it did not really help to solve my problem.

So I did some additional investigation and found out both, why the problem occurred in my installation and how I could solve it. And after all I also detected some points contradicting to my experience. I thought my findings may be helpful to some others suffering from this kind of problems.

First experience that has been helpful to me:
network logon with Domain control and server stored profile was
successful on a desktop.
not successful and leading to profile replication on a laptop

Conclusion
The reason for profile replication must result from something in the client and cannot at least not in my case be caused by the server.

Difference of settings in Desktop and Laptop
In the laptop I used a registry setting that caused profile unloading at user logoff (Security reasons)
In the desktop I maintained the profile at user logoff (speed reasons)

Now I found out, that the reason for profile replication on the laptop was always, that in conflict with registry setting the profile could not be unloaded at user logoff. I have take three measures against this:
1. Use user profile hive cleanup uphc (this helped to get rid of some *.dat files at logoff)
2. Set Windows Indexing Service to manual start (this helped to avoid production of some *.URL files that could not be unloaded. They mainly occurred in the favourites directory and in the startupmenu)
3. Remove automatic start of Active Sync (this helped to avoid creation of a file $_hpcst$.hpc, that could not be unloaded inspite of uphc.

Once these measures have been implemented all reasons for reproduction of the problem have been removed in my case.

But repair of the profile is still necessary. This comprises:
1. Removal of all locally stored profiles for the given user
2. Introduction of a profile username and give it one dummy file ‘(should look as being used and unavailable for futher usage)

This all being done. I could login on the laptop, found myself always as user.domain, and this has remained since then for many logins without and with intermediate processor boot.

That being said
Registry corruption can be excluded as the problem reason an my laptop, where user profile is unloaded at logoff.

I could now raise the question, whether registry corruption could become a problem for the desktop, where user profile is not unloaded. I doubt!! Based on my experience with my Desktop profile downloading to the desktop is very fast. As both my laptop and my desktop are connected with my network over LAN I conclude from this difference in speed of profile downloading that profile downloading to the desktop is only done for the files that have changed. So if registry had not changed there is no download. If registry has changed the new registry will be downloaded from the server. I cannot see any way how a corrupted registry on the client can inhibit downloading of a good registry into the existing profile and hence cause creation of a new profile. Therefore deletion of the registry in the profile existing on the client cannot be a permanent solution to the problem of profile replication.

Last not least I want to address the issue of a registry corruption on the server. In my opinion that could cause stability issues on the client after completion of download. It could however not cause replication of profiles.

All measures described above have been necessary and sufficient to solve my problem as far as repair and prevention is concerned.

I know, that for reasons of space and time I had do leave out quite some details. But if there is a need I am ready to fill existing gaps.