So in the midst of a beautiful Sunday night deployment of Internet Explorer 10, I came across a workstation that failed during deployment. So in order to take a closer look at why it wasn’t installing on a particular Windows 7 desktop, I decided to remote desktop to that workstation. Upon remote-desktoping (I am making that a new word right now) into the workstation, I came across the interesting error of ‘User profile service’ service failed the logon. User profile cannot be loaded
My first thought was that it must be my workstation administrator account already has a profile loaded on the workstation that is corrupted or something of that nature. So I performed the normal troubleshooting steps to remove any preexisting profiles that were on the workstation using basic remote management:
When the machine came back online, tried again. Same error. So I poked around a bit more, took a look at the ‘user profile service’ service saw that it was running as normal. Getting a little frustrated, it was time to exercise some google-fu. Just about every result in google search results yielded the same feedback, a copy and paste from Microsoft going through the troubleshooting steps I just mentioned regarding fixing a corrupted profile (Microsoft Article Here).
After giving up hope on finding some helpful information from google, I decided to poke around a bit more. In poking around, I launched up Event Viewer and found a couple more clues. The main clue being the following error message:
Windows cannot copy file \\?\C:\Users\Default\AppData\Local\Microsoft\Windows\Temporary Internet Files\SQM\iesqmdata_setup0.sqm to location \\?\C:\Users\TEMP\AppData\Local\Microsoft\Windows\Temporary Internet Files\SQM\iesqmdata_setup0.sqm. This error may be caused by network problems or insufficient security rights.
Based on the understanding that new user profiles are essentially cloned off of the ‘Default’ profile, I decided to take a peak at the \\%HOSTNAME%\c$\Users\Default\AppData directory and refresh/reapply the permissions to all the child objects in that folder. To reapply the permissions, you would follow these steps:
(First make sure show hidden files is enabled, and protect operating system files is turned off in your explorer folder view properties)
Sure enough, I attempted the login again, and voila! I don’t think I’ve ever been happier to see the ‘Preparing your desktop..’ message. As for the root cause of this error message, I’m not particularly sure. It’s the first time I’ve seen something like that in our environment. I’m not sure how the permissions would get messed up on the default users folder, but if it happens again, I’ll be sure to take a deeper look.
It was a nice little Sunday night victory for me. Starting the week off on a positive note is always a good thing.
Happy Monday everyone!
EDIT: Of course after I struggle with the issue for a little while, I find a post here in the google results that could have helped about an hour ago. The solution suggested by this particular blog suggests to copy the entire .Default folder from a known working machine. I’m sure that would accomplish the same as the method we used above.