|
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.
|