Today, I encountered the following on a newly imaged workstation: “The user Profile Service service failed the logon. User profile cannot be loaded.”

Often times when I encounter this it’s a simple matter of hacking the registry to fix it. This is covered in detail in this Microsoft KB You receive a "The User Profile Service failed the logon” error message. It also covered in one of my older (pre-MS KB) blogs.

The article, however, doesn’t cover the other scenario. Local admin and domain techs accounts could logon but not standard users accounts. This is often due to file permissions. For whatever reason, a system-admin protected file was created deep into the profile of the Default user account. This is where all new profiles are created from, and Everyone\Users must have at least read permissions for a new profile to be successfully spawned from the Default. The details are alluded to in the Windows Application event logs, event ID 1509:

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.

DETAIL – Access is denied.

Looking at the problem file, we can see that the file has no permissions for Everyone\Users:

The solution is to delete the file (if non-essential) or add the correct user(s) and permissions. And depending on the location, you may need to uncheck Hide protected operation system files in Windows Explorer.

I have run into this a few times. I suspect the issue was being caused by the method in which the original installation of the JRE client was being uninstalled. In our environment, we control the installation of removal of most software via a 3rd party utility. This means that in some cases our techs (or sometimes the user) will try to remove a product via Programs and Features but will not have complete permissions to undertake the process, which may end up only partially uninstalling the product, leaving fragments of it in the file system.

The problem often starts with the following warning": "Java Setup. This software has already been installed on your computer. Would you like to reinstall it?”

Selecting Yes results in the following error: “Error 1723. There is a problem with this Windows Installer package. A DLL required for this install to complete could not be run…”

Sometimes this may be proceeded or followed by a Windows installer error: “This action is only valid for products that are currently installed.”

Looking at the details of the error in the Windows Application Event logs offers some details:

I can only assume regutils.dll is the module necessary for registering and unregistering the JRE client properly. Looking at that path, I can see that the Java programs folder is gone or the sub-folder for regutils.dll is empty. I am guessing that sometimes a technician comes along and decides to just delete the Java programs folder in desperation while trying to recover from a botched uninstall.

One way to work around this is to simply take this dll from a another workstation and copy it to or create the folder path in the error. For standalone computers, though, this may not be an option. I decided to take a quick look in the registry to see is I could identify the key that was still in place and preventing the complete removal or upgrade of the existing JRE using Process Monitor. I filtered the trace for the Java install-uninstall msiexec, registry only. After the trace was collected, I filtered further to include only “installer” in the path. After a few tries, I came to the culprit:

After deleting HKCR\Installer\Products\4EA42A62D9304AC4784BF238120602FF The Java JRE install proceeded normally.

I should mention that Microsoft offers another way to handle stubborn uninstalls: http://support.microsoft.com/mats/program_install_and_uninstall/, and upon reproducing the issue I can confirm it also works in properly cleaning up the residual registry key(s).