For year’s I’ve struggled with odd behavior on Windows 10 machines and interestingly this all started with the introduction for Microsoft Account sign-in.

When using an online account, MS automatically “build” a username from your first and last name. Sadly in my case my name has a unicode character in it.

Some software packages fail to install because the user path cannot be found, mostly because they don’t support unicode characters in paths. Others create the “missing” directory with interesting interpretations of the original character, see the screenshot above.

Others still will install successfully but then fail to work, the installer supported the character set but the software itself doesn’t.

The latest annoyance, gRPC using Visual Studio.

Generating classes from the .proto file fails because the utility is in a path containing a unicode character. This isn’t plainly obvious from the error messages and without some investigation, it’s easy to assume you are missing a piece of software or that the NuGet install of dependencies has failed to complete successfully or didn’t occur at all.

The usual solution to software that won’t install successfully is to create a secondary administrative account on the system, one that does not contain any special characters and then use that account to install the software. This can sometimes be achieved by using RunAs from the current user account and other times it requires logging into the secondary account. This is not a great process when installing an Outlook extension for instance, where you’d need to link the new account to your email profile for some extensions to install successfully. TaskLine appears to have worked around this issue by moving from a user profile based installation to a program files install. I’m thankful for this, even though I no longer use their software on a regular basis, installing it proved to be challenging for years.

One way to work around this is to only use local accounts, but that’s not always practical. If you’re using domain accounts that happen to be hosted by Office365 and you’d like remote management of systems should a remote wipe become necessary, you’re really going to need online accounts. There’s also the activation of Windows with licenses linked to online accounts, though I’m sure this can be done by adding the account without having it be the sign-in account.

You can change your first name and last name on your Microsoft account, but that could have further reaching consequences that aren’t immediately obvious. It could change the name that is displayed in global address lists, on email headers etc. This may or may not be a problem for your organization.

Finally, you can use a secondary admin account to rename the user folder and change the ImagePath in the registry. This is the option I prefer, but it is best done when a machine is commissioned, so it needs to go onto a build checklist so that it can be done for anyone with unicode characters in their name.

Why at commissioning?

I recently changed a user folder on one of my development machines and the change was far reaching. For one many applications that modify environmental variables and specifically the path variable do not use the %USERPROFILE% place holder, instead adding the full path. These will need to be updated manually (or through a script) to replace the now incorrect portion of the path. It’s wise to use the placeholder if at all possible when making this change.

A bigger headache is all the software that uses a registry keys to point to various assets and libraries that also do not use the appropriate placeholder. To clarify, if they did use the placeholder, a folder rename and update of the imagepath key would be sufficient to finalize a user folder rename. Everything else would automatically resolve the new path.

And finally there are application specific configurations files and possible databases that also point to fixed paths. These can be difficult to track down as they aren’t centrally stored and could be in a format that isn’t plain text searchable.

You’ll know that you’ve missed something when a piece of software stops working following the change, not an ideal way to find this out.

Making the profile change directly after Windows is installed means that all additional software should have the correct path at install time with no need to hunt down missed changes because the folder name can now be left as is for the lifetime of the Windows install.