USERNAME.DOMAIN profiles showing up in Documents and Settings...

[mvbighead]

I have noticed over time that we have some systems in our environment that essentially scrap an old local user profile (IE - C:\Documents and Settings\jdoe ) and create a new one with the following naming convention (IE - C:\Documents and Settings\jdoe.domain or C:\Documents and Settings\jdoe.domain.000 or C:\Documents and Settings\jdoe.domain.001).

I have been all over looking for a reason as to why this occurs, and most admins seem to suggest just handling the new profile (in logon scripts and such) by using the following:

%homedrive%\%homepath%

My problem is knowing full well that the jdoe.domain folder shouldn't really have to be there in the first place, so by doing the above, I am just avoiding finding the reason to why the path is there. Furthermore, I recently was informed about a system that has several of those folders from various users and the system has only been in place for a few weeks. I am not sure if classifying those as corrupt profiles is correct or incorrect, but if anyone has some insight as to why these occur, I would greatly appreciate your input.

All hosts are Windows XP Pro SP3, authenticating through Windows 2003 Server with the latest patches as well.

 

[dphantom]

It's just profile corruption and a new local profile with the domain name appended is created. Could be lots of reasons why a profile becomes corrupt.

 

[Red Squirrel]

This also happens if you take the pc off the domain and put it back, or delete the user and recreate. Actually I may be wrong on removal of domain part, but I know for sure if a user is deleted then recreated, as it tries to create a new profile upon first login, sees one exists but that the permissions are wrong, then it just writes a different one. When a user is deleted and readded what I normally do is rename the profile to .old or something, login with the new user, let it create the profile, reboot, log in as admin, delete the new profile and rename the .old one to the right name then add the permissions. This way you're not stuck recreating the user's profile. (desktop shortcuts, personalized settings etc etc this can take days if the user uses lot of weird crappy apps).

 

[mvbighead]

Originally posted by: RedSquirrel
This also happens if you take the pc off the domain and put it back, or delete the user and recreate. Actually I may be wrong on removal of domain part, but I know for sure if a user is deleted then recreated, as it tries to create a new profile upon first login, sees one exists but that the permissions are wrong, then it just writes a different one. When a user is deleted and readded what I normally do is rename the profile to .old or something, login with the new user, let it create the profile, reboot, log in as admin, delete the new profile and rename the .old one to the right name then add the permissions. This way you're not stuck recreating the user's profile. (desktop shortcuts, personalized settings etc etc this can take days if the user uses lot of weird crappy apps).

Thanks for the replies (you as well dphantom).

I believe RedSquirrel is probably spot on with the removal of the PC from the domain and putting it back (I would guess one of our helpdesk folks must've done that). There were several accounts on this specific machine that did that, so I couldn't think of a reason as to why all of a sudden 4-5 profiles would suddenly be unusable and be recreated.

To correct the problem on all workstations, I simply added some code to our startup script (used for some software deployments, shortcuts, etc.) that looks for and moves both the username and username.domain folders to the C:\Documents and Settings\OLD. (Obviously, I am only moving folder pairs that have the .domain extension.) Seems to be working well and the "corrupt" profiles are out of the way, allowing everything else to function correctly.

Thanks again for your input.

 

[GeekDrew]

Perhaps it's just me, but I can't help but wonder *why* you're intentionally working to keep poorly written scripts working right, rather than just refer to the profile using the correct environment variables or system calls? There are very well documented reasons out there (do some googling, or browse the MSKB) why you could never manually construct the path to special folders, such as profiles, documents, etc.

 

[mvbighead]

Originally posted by: GeekDrew
Perhaps it's just me, but I can't help but wonder *why* you're intentionally working to keep poorly written scripts working right, rather than just refer to the profile using the correct environment variables or system calls? There are very well documented reasons out there (do some googling, or browse the MSKB) why you could never manually construct the path to special folders, such as profiles, documents, etc.

I can see the perspective that one would think the scripts are working poorly, however, my intentions were set to make sure that user profiles all show up with the same naming convention. To me, seeing jdoe followed jdoe.domain can be quite cluttered, and it would be quite possible that our helpdesk staff would try to add something directly to a specific user's desktop and it would not show up (because it was put in the corrupt profile) as that user has two separate profiles because one magically became corrupt. Also, the default behavior for a profile path has always been based on the user name, not the username.domain convention, which seems to signify a problem. And it becomes even more cluttered when you start seeing:
jdoe
jdoe.domain
jdoe.domain.000
etc.

I haven't seen a lot of that in our environment (maybe once or twice), but it just makes things look very sketchy IMO.

I'll likely look into using the %homedrive%\%homepath% convention in the future based on your input, but I guess I wanted to solve the problem of a cluttered Documents and Settings path. And since some of our workstations are used by 5-6 reps throughout a week, over time there can be a lot of profiles in that path.

In addition, by doing what I have mentioned, I can later set up some simple code to clean that folder out based on the age to free up drive space. And since most of these workstations have 40GB HDDs, they need any help they can get.

Thanks again for your viewpoint though, as I will likely look to do that with the scripts in the near future.

 

[DrGreen2007]

I have some auto scripts that use delprof.exe to clean out workstations of profiles older than x days.
Here is part of the script, just repeat for more computer names.
(delprof.exe needs to be in the C:\Windows folder of the machine the script is run from)

START c:\Windows\delprof.exe /q /i /D:6 /c:\\ComputerName


the above is in a bat file.

D:6 is the days to keep profiles

 

[thisisfutile]

To expand on RedSquirrel's post...

Those 000 and 001 extensions are also created after a system restore. I once did a system restore about a dozen times on a workstation in an effort to find a registry setting. Afterward, I went into the Documents and Settings and was amazed at all the 000, 001, 002, etc, etc entries that were there.

HTH

Futile

 

[mvbighead]

Thanks all. As an update in my scenario, I have recently adjusted all of my scripts to use environmental variables as opposed to specific file paths. So even if a .DOMAIN profile exists, my scripts will function correctly.

In addition, I have updated some logging mechanisms so I can find these profiles and ensure that they don't exist. Perhaps I am being to picky about how clean that area looks, but it just doesn't set well with me to see 2 or 3 profiles for the same user. To me, it just signifies an under-lying problem.

For instance, one of my agents is what I would consider an above average user. She has her own specific workstation (a laptop actually), and she had gotten a new profile numerous times with her computer. One of our helpdesk folks re-imaged it (quite some time ago), and roughly a month or so later, she had received another one. We hadn't done (to my knowledge) any system restores, detachment from and back to the domain, etc. But it just started to throw more strange profile names into the directory. I realize over-writing them isn't in MS's best interest, but I would figure if the UID behind the username is the same, the profile belongs to them, and any corrupt contents should be renamed to *.BAK (or filename.username.domain.001.bak) so the user can continue to use whatever they have in their current profile.

 

[GeekDrew]

How often are you seeing this happen? I've personally seen this happen quite a few times, but that's over the course of years, many networks, and thousands upon thousands of profiles. I'm also curious as to what you're using to determine that these presumed-corrupt profiles don't exist.

Windows won't create an additional profile for a user unless there *is* a problem while attempting to load the existing profile. These are a few questions that come to mind, that might or might help determine why those profiles are being created:

Are there any programs or services that could be interfering with the logon/logoff process?
Are these roaming profiles, or local profiles?
If roaming, is the connection between the server and the workstation both fast and reliable?
Is folder redirection in use?
What's the size of an example profile?
Is time sync working properly between the workstations and domain controllers in question?
Are there any relevant errors or warnings being shown in the event log? Anything about network connectivity, authentication, or registry hives?

 

[mvbighead]

To be honest, it doesn't happen all that much. With about 700 systems, I've seen it on a few.

As for what I'm using, I have created a relatively simply script that just moves the username & username.domain profiles by using the dir /b "C:\Documents and Settings\*.domain" > "c:\Documents and Settings\file.txt"; which creates a simple list of files that have .domain appended to the name. I then move the original and the .domain profile to C:\Documents and Settings\OLD\ and when the user logs in, they receive a fresh profile without the .domain appended.

As for the problem with the profile, this I understand (to an extent), but if something was corrupt, I would rather it mark the old profile a username.bak, and then create a new profile based on the standard naming convention.

There are no services/programs, to my knowledge, that interfere with the logon/logon process. I do have kix scripts that run for both. (www.kixtart.org)

All of these are local profiles, not roaming.

We are not using folder redirection, the normal documents and settings path is in use.

Sizes of each profile vary anywhere from about 3mb to 300mb or more.

Time sync is working properly.

No specific error/warning messages in the logs, but it has been some time since I have dealt with one of these profiles. Next time I work with one specifically, I'll take a closer look. One thing I have seen on pretty much every machine is that the system will create a .domain profile for the Administrator account because it has already been logged into with the local Administrator account on the system. Not really a big deal to me, but it does show that those .domain profiles aren't always a sign of a corrupt profile, and are using to create folders where the username's folder already exists.

Again, none of this would be a problem to me if every folder was username.domain, but since that's not the default, I know there has been a problem with the profile. I'd prefer to clean that up.