Logging onto Windows XP SP2 fails with corrupt profile error message.

Brett,
This previous E-E thread may be of help >

"windows cannot find the local profile and is logging you on with a temporary profile":
https://www.experts-exchange.com/questions/21728169/windows-cannot-find-the-local-profile-and-is-logging-you-on-with-a-temporary-profile.html

Took another look at your problem and found two further references to this 'error'  >
"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":
http://forums.pcworld.co.nz/archive/index.php/t-60936.html

 .. and this one which stated that it was due to a failing hard disk drive:
http://bbugs.axpr.net/bug.php?op=show&bugid=163

However on second thoughts, it can hardly be due to a HDD when you have several computers involved.  Will investigate further.

Thanks for your suggestions so far Jonvee. I've seen several posts like your last two that describe profile corruption and or a failing hard drive. As mentioned, I'm discounting the hardware failure option and I'm inclined to discount the profile corruption as well given that it's consistent across multiple machine, each with multiple profiles and all of which work fine after a reboot. As the only similar factor in each case is the server and the domain it controls, I'm expecting that to be the cause. In regard to the first post, I've just rebooted the server and will see how logins go tomorrow morning.

As some extra information that may help yourself or any other experts, one possible cause that comes to mind is the initial setup of the domain. I had a trial version of Windows 2003 Enterprise running initially to see if a server was useful for the business. When it came time to purchase a server license, I'd discovered the Small Business Server and purchased that instead. Unfortunately, this involved the complete rebuilding of the domain including user and computer profiles. The new domain was created with the same name as the old, as were the new user accounts. I changed the permissions on the accounts on the computers to work with the new domains GUIDs. Although the problem started happening after this event, I still don't believe it is specifically to do with the migration of user profiles from one domain to the other. My reason for this belief is that my account also plays up and I'm pretty sure I didn't bother to migrate my account on this computer as there was nothing worth saving.

I've also decided that this is probably more difficult than the 250 points I initially allocated (quite a bit of googling failed to find an answer), so I'm uping the points to the full 500.

I look forward to any more suggestions.

Brett,
Ok, thanks for the information.  Having just about run out of ideas on this one i suggest that should you not get any further useful comments, post a pointer question (worth 20 points) in the Networking topic area, with a link to this thread number WinXP/Q_21833014.     This will give you input from experts active in that other area.  You should get a quicker response and if successful, have your 20 points returned to you later.  Good luck.

I really don't have an answer for you at the moment, but are you currently using Roaming Profiles for your users?  This just sounds like some type of Roaming Profile issue.

Just offhand, you could also look at some of the Security Settings on the domain and clients - like "Local Policies - Microsoft network server: Amount of idle time required before suspending session", or such.

Just guessing right now - maybe this will jog a thought for someone else.

This looks like a permission issue on both local and server folders where user's profiles are stored.
When
"The new domain was created with the same name as the old, as were the new user accounts. I changed the permissions on the accounts on the computers to work with the new domains GUIDs."
did you also change permissions on the folders or did you create them form scratch.
I would definitely try to create test user and see how this account would behave.

Let us not how you're getting on.
Kris

Thanks for the suggestion Jonvee. I think this probably should have been posted to the Windows 2003 server forum now I think about it, so I will try putting a link in there first.

e_sandrs, I'm currently using standard non-roaming profiles and I don't believe I've changed any GP settings from the standard other than password complexity. That said, I'll have a look and let you know.

Well, you must be using roaming profiles otherwise second error message would not be poping up.
Check that on Profile tab of specific users the profile path field is empty.
Then rename local profile, log the user, this should recreate profile, and then copy his/her settings.

When you did the complete reinstall you changed what is known as the Security ID (SID) of the server and the corresponding SIDs for the different accounts. So you likely do not have the correct User accounts assigned to the User path

What I mean is, if the permissions on the profile directories are still the ones applied by the SBS Install, the New Enterprise Install can not determine who has rights to access the profile folders.

To check if this is the problem you could remove all users from the security tab and add the user account that is suppose to be able to access it back in with full rights.
If this works then you know the problem is a rights issue.

Hope this helps,

David

OK, thanks for comments all.

Sorry, krzywis, I'm not using roaming profiles. I've just confirmed that the Profile path field is blank.

Regarding the profile 'migration'. What I did was create the new users on the SBS server with the same name. I then logged into the required computer with the new account, creating a new profile username.000. I gave the new account full access to the old profile files and the registry hive. Finally, in regedit, I found where the new account was pointing to the new profile and changed it to point to the old profile (username instead of username.000). I work for a big government agency which recently merged into a new domain and we had to use this process on some accounts that failed to change automatically, so I know this process does work and I don't believe that we've had any of these problems at my gov. work.

Other than the login failure that occurs if you leave the login too long, the domain has been working fine for about a year and these migrated accounts have had no problems ... which is why the problem is so difficult to track down unfortunately.

Brett,

Unfortunately that process may work on a large enterprise environment, but not with SBS because the nature of a small business network is to have much more controlled and centralized management most of which is pre-configured.  The process you used would have worked if you completed a few more steps, specifically, granting full permissions to the registry key for the new user.

There is an outline of this in this article:  http://www.certmag.com/articles/templates/cmag_howto.asp?articleid=819&zoneid=91

What you may not be aware of is SBS has a unique way to migrate the current local profile to a domain profile.  This is done when you add the workstation to the SBS network with the http://<servername>/connectcomputer wizard.  I'm assuming that you did not use this method when you joined the workstation to the domain.

There is a good article which describes how to add users and computers to SBS networks here:  http://sbsurl.com/add

If you did not join the computers using this method, you will ultimately have many other SBS features that don't work.  
To see all that connectcomputer does, please see http://sbsurl.com/connectcomputer

To correct this, you will need to unjoin the computers from the domain, rename then and rejoin by following these steps:

The following needs to be done with the client machine:
1.  Log in with THAT machine's LOCAL administrator account.
2.  Unjoin the domain into a WORKGROUP
3.  Change the name of the computer
4.  Delete or rename the following directory C:\Program Files\Microsoft Windows Small Business Server\Clients
5.  Ensure that DHCP is enabled and there are  no manually configured network settings
6.  Reboot

Then on the server, from the Server Management Console:
1.  Remove the client computers if it still shows in the Client Computer screen on the Server Management Console
2.  Add the client with it's NEW name using the Add Computer wizard

Then, go back to the client machine and join the domain by opening Internet Explorer and navigating to http://servername/connectcomputer

Before doing that, though, you may want to folllow Harry's recommended procedure to get the profile moved over as outlined in the CertMag article linked above.

Jeff
TechSoEasy

Bugger then! You would indeed be correct that I didn't create the computer account the 'SBS' way. As mentioned, I work in a large organisation that uses the manual pre-stage in AD then add computer to domain from My Computer properties .. and that's how I did it. Oh well, live and learn.

So, I guess I need to follow your steps to join them properly .. but first some more questions.

1. Do I have to change the name of the computer, or is just moving to work group, removing from AD and then joining correctly enough?

2. On the third link you gave above, one of the posts at the bottom mentions that users then have admin rights to these PCs. Is this correct? If so, can that be avoided?

I'll try to do the rejoin in a day or so when I have an evening free and I'll post my results.

Thanks
Brett

Forgot to mention. Method 2 from the first link from TechSoEasy basically describes exactly the method I used to migrate the user profiles, so I'm presuming I'm fine to keep using them. Please let me know if you think I need to do anything else though.

Hey Jeff,

I was actually refering to http://sbsurl.com/connectcomputer as the link, but If you say admin rights aren't a problem if you use software policy restrictions, then i'll look into that as well. Guess it's not a major problem to remove them from the admin group later anyway .. unless that breaks something else :/ .

Method 2 talks about changing the registry permissions by loading the users hive and changing permissions to full access for the new account. Is this what you ment by 'revise the registry key permissions'? If so, then yep, I did that .. I'm pretty sure it wouldn't be working at all if I hadn't.

As for doing things the enterprise way, I'm more than happy to do things the SBS easy way, but when you've learnt to do them one way, you don't necessarily think to go looking for a different away. Thanks for the itpro doc .. I suspect it would have been good to read before starting but hopefully I haven't messed too much up.

Brett

Brett...

Yeah, unfortunately there is a fair amount of software that still requires that a user have local admin rights... not the lease of which is Windows Update.  Although if you use WSUS, you can get around that.  Susan Bradley, who's blog that connectcomputer link points to, also has another site which hilights these software companies:  www.threatcode.com

Yes, that's what I was referring to regarding changing registry permissions.

And I totally agree with you about folks with a lot of experience not going looking for a different way to do things... I've said many times that it's really too bad that Microsoft didn't do a better job in educating the huge MCSE base about SBS.  It's really been an ongoing battle between the MCSE's and the SBSers... and perhaps thats how Microsoft wants it.  But if you haven't seen this yet, I think you'll enjoy it now that "you know":  http://sbslinks.com/Us_v_them.htm

Jeff
TechSoEasy