Category Archives: Windows

A computer by any other name… would be better;how to change the hostname of a Windows 10 computer during setup


Over the years the setup process for the Windows OS has been streamlined and optimized a lot. It used to be that you have to input a lot of information throughout the installation and the actual transferring of the OS files onto the hard drive took a long time. Now, the data copying has become a lot quicker by using things like imaging technology, and the user interaction during setup has been reduced to the bare necessities. So much so in fact, that I personally am now missing a few options that I could previously set. One of those is the computer name or hostname; the name you give your computer. In Windows 10 there is no question during setup what the computer should be called. Instead, Windows Setup automatically generates a name for you that looks something like this: DESKTOP-7KCPLCO. You can of course change this later using e.g. PowerShell’s Rename-Computer cmdlet. The problem is that the original name is often stored in the services you connect to, before you can actually change it. For example, when you join Azure AD during the Windows 10 Out-of-Box-Experience (OOBE), your machine is joined to Azure AD with the name that Windows Setup configured, and even if you change it later, it does not update in Azure AD. This is surely (hopefully) something that Microsoft will fix, so that it works the way it does in local Active Directory, where, if you change the name of a domain joined computer; the name in the directory also changes. But for now, that is not the case, and it can be quite a challenge keeping track of all those DESKTOP-<random number> machines.

The Fix

Luckily there is a workaround available. (In fact, there might be more than one workaround, but one was enough for me.) The one I made work was using the Windows unattended install support to supply a computer name during the specialize phase of Windows Setup. I basically configured an XML file that told Windows Setup which name to give the computer. Since there is no GUI prompt for this it all happens behind the scenes during your install. Using unattended setup of Windows is usually something that is only cost effective if you are going to install a bunch of machine over a long period of time, and it usually requires a lot of configuring a testing and things like driver packages, reference machines, distribution shares and in-depth knowledge of the Windows DISM utility. But in our case we need none of that, the only thing we want is a file with the name of the computer in it. This is how you set that up…


The file that holds all the information to install Windows 10 in a highly customized, hands-off fashion is called an answer file and is called unattend.xml by default. It is usually generated with the System Image Manager tool, which is part of the Windows Assessment and Deployment Toolkit (ADK). Hundreds of settings can be added to unattend.xml, but right now we only need the one for the name of the computer. This particular value is called ComputerName and is configured during the specialize phase of setup. Here is the entire chunk of XML you need to set the name of your computer using unattend.xml:

<?xml version="1.0" encoding="utf-8"?>
<unattend xmlns="urn:schemas-microsoft-com:unattend">
 <settings pass="specialize">
  <component name="Microsoft-Windows-Shell-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="" xmlns:xsi="">
   <ComputerName>ENTER YOUR DESIRED NAME HERE</ComputerName>

You must enter you desired name in the ComputerName element, and also change processorArchitecture from amd64 to x86 if you are using this file to install the 32-bit version of Windows (which you shouldn’t). Remember to adhere to the rules for computer names, which you can find in the information about the ComputerName element provided above.

You need a removable drive

So how do we get Windows Setup to read our unattend.xml file during setup? When we do large deployments of Windows we usually have several XML files for different variations of installs, and they are specified using the deployment tools used. Luckily for us, we need nothing so complex here. Remember, we are talking about the occasional install of a few machines. Windows Setup is configured to implicitly look for an unattend.xml file in several locations when it starts. (It’s called implicit, because you can also explicitly provide an answer file using a command line parameter.) Windows Setup looks in a lot of places for unattend.xml, and also looks for other XML files to use with other phases of setup, but we don’t need to go into detail about that here. Setup will look for unattend.xml in the root of all RW/RO removable drives on the system, and this is by far the easiest method to achieve what we are trying to do here.

After you have configured your desired name in the piece of XML provided about, save it as unattend.xml, in the root of either the USB drive from which you are installing Windows, in the root of another USB drive, of even on a floppy disk (virtual or physical). As long as it is called unattend.xml, is in the root of the drive and the drive is of type removable, it will be picked up by Windows Setup. Start Windows setup as you normally would and wait until OOBE starts, then configure your computer like you want it. The setup process itself will not change and you will have no indication that the machine has been given another name until you can access the desktop and check for yourself. Once that happens you can use e.g. hostname.exe to see if your change was successful.

Note that since setup looks in several places for unattend.xml, it might find more than one. There is a search order and the answer file with the highest precedent is used. Make sure you know which one will be picked in your scenario and that you make your changes in that file.

Good luck!

BTW: I hope someone out there picked up on my attempt at Shakespeare-pun in the title of this post:

“A rose by any other name would smell as sweet”

 -Juliet in Act II, Scene II of Rome and Juliet


Fun with Bash on Ubuntu on Windows

Ever since the Windows Subsystem for Linux/Bash on Ubuntu on Windows feature in Windows 10 I have been playing around with it. Canonical, the makers of the Ubuntu Linux distribution, and Microsoft, made the Windows Subsystem for Linux (WSL) together, and it enables bash, which is the de facto default CLI shell on Linux, to run on Windows as a first class citizen. You no longer need things like Cygwin to run  bash and its command language and tools on your Windows 10 computer.Recently I did a little customizing to get a more genuine Ubuntu feeling on my Windows box. Specifically I wanted to make my Windows-based bash window look as much as the real thing as possible.

Windows has its own fonts for console windows, like Command Prompt (Consolas) and PowerShell (Lucida Console). But Ubuntu uses the Ubuntu Mono font for its console windows. Luckily for us the Ubuntu Font Family, of which Ubuntu Mono is a member, is freely available to anyone, in easy to install TTF format. To use it for your bash windows, download the package from the Ubuntu font site, extract its content and right-click each font file (.ttf) you want to install.

Screenshot (1)

Now, open your bash shell and edit its properties. In the Font list, select the newly installed Ubuntu Mono font:

Screenshot (2)

Granted, it’s not a huge difference between the default font and Ubuntu Mono, but the devil is in the details 🙂

Screenshot (3)

Screenshot (4)


Error 0x80070001 on Windows 10 when trying to install a new app

This is slightly off topic for me, but because I spent quite a bit of time on figuring it out and could not find this documented anywhere else, I thought I would write it up quickly.

At some point I could no longer install any new apps from the Windows Store on my Surface 3 Pro Windows 10 machine. Apps already installed would update fine, but new ones could not be added. The error was:

“Try that again. Something went wrong. The error code is 0x8007001, in case you need it”.

If we translate that number to a human readable form we get:

Incorrect function.

Not much to go on. I initially thought this was something to do with either the modern app framework or Windows installation and tried things like resetting the store with (WSReset.exe) and scanning the system files with SFC.EXE. None of these things helped. In the end it turned out that is was related to my SD card. I had an  SD card installed and had previously moved a few apps to it. Apps that were so large that I didn’t want them eating up my system drive. Moving these apps somehow caused all new apps from then on to try to install on the SD card, or at least rely on it for something during the install. I shut down the computer, removed the card and could then install apps again. At this point I also reinserted the card and could now also install new apps with the card inserted. Some setting somewhere had obviously been changed. I do not know the root cause of this behavior, which is always annoying, but I am prepared to accept that I made it work.

Updating already installed apps worked because they were all on the correct (C:) drive. The default install location for apps was also set to the C: drive, which makes this even stranger…

Hope this helps someone. Happy installing!

Connecting to an Azure AD joined machine with an Azure AD user account over Remote Desktop


Windows 10 introduces the ability to join a computer to the cloud directory service Azure AD. This is very similar to the traditional domain join, where you join a computer to an Active Directory domain, run on-premises by one or more Domain Controllers. Both operations lets the computer operate within a common security context and benefit from Single Sign-On (SSO) to all resources that share the same security context. However, joining Azure AD instead of a traditional domain can break things or make them more difficult. There are many examples of this, but the one I want to discuss here is connecting with Remote Desktop (RDP) to an Azure AD joined computer with a user account from Azure AD. Just to be clear; the connection we want to establish is to an Azure AD joined computer, logging on with an account from Azure AD. This account can either be synced from on-premises or be mastered in the cloud, and both federated and password logons are supported. We do not depend on any local accounts on the computer, using tricks such as adding an Azure AD work account to a local account or a Microsoft Account (MSA), this is pure Azure AD.

Connecting Successfully

There are some obvious prerequisites for this to work:

  • The computer must be joined to Azure AD
  • Remote Desktop connections must be enabled and allowed through the host firewall
  • Any other firewall between you and the computer must allow the Remote Desktop protocol

The key to connecting is having Windows 10 present an desktop login screen:


That means that we must disable any form of single sign-on or integrated authentication. This requires the following steps:

  • On the Windows 10 computer; disable Network Level Authentication (NLA) for Remote Desktop Connections
    Open System Properties and navigate to the Remote tab. Under Remote Desktop; make sure Allow remote connections to this computer is enabled, and that Allow connections only from computers running Remote Desktop with Network Level Authentication is unchecked.
    This will disable the ability on the host to require that authentication happens before a user session is created.
  • On the computer you are connecting from create an RDP file and add the following settings to it:
    authentication level:i:2
    Again, these settings disables sending any credentials automatically to the host computer. Leaving Windows with no choice but to display a desktop logon screen. The easiest way to create an RDP file is to open the remote desktop client, enter the name or IP of the computer you want to connect to and then his Save As. This will produce an RDP file that you can add/edit the necessary settings in. For those interested, most of the settings you can specify in an RDP file are listed here. In theory you could also add these settings on the command line, but I have not worked that out.

The last trick to make this work involves the username you specify on the logon screen. It must be in the following format:

AzureAD\<full UPN in Azure AD>

e.g. AzureAD\

This is a non-intuitive format for those of us who have connected to Windows over RDP in the past, but it is what works. I have not been able to connect with any other combination of domain, username, DNS domain or UPN, but this may very well change soon.

UPDATE 2015-11-7: On Windows 10 build 10586 the AzureAD prefix is no longer needed. You can just use your UPN.

Closing remarks

When you are joined to Azure AD we are naturally also authenticating against Azure AD, but it might be that you have federated Azure AD against an ADFS server, in which case authentications are redirected back to on-premises. Depending on your setup for authentication you will see the following differences:

Azure AD authenticated users will display the logged on user as: AzureAD\<concatenated display name>. Federated tenants will display the logged on user as <on-premises NetBIOS domain name>\<on-premises sAMAccountName>. This difference is visible if you use the whoami utility or look at the environment variables. Just to be clear, these differences do not have anything to do with remote desktop connections, they are just a consequence of joining Azure AD.

Connecting with a local account to a Windows 10 computer joined to Azure AD would as it does for any other Windows computer.

This is probably not how Microsoft would like us to connect to Azure AD joined machines so we can expect NLA authenticated connections to work some time in the future.

Happy connecting!


The Case of the Missing Technical Preview build

I am trying out the Windows 10 Technical Preview, and have been running build 9926 for some time. Today (19032015) Microsoft released build 10041 and I installed it immediately, of course. Not surprisingly I had some problems which were so bad that I reverted back to the 9926 build. I later figured out that it might not have been the new build that was the problem, but something else. So I wanted to try installing 10041 again to test that theory. Problem was that 10041 was no longer being offered to me in Windows Update. Turns out Windows keeps track of the builds you have reverted from and hides those from Windows Update. Here is how to make them visible again.

In Registry Editor, navigate to HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsSelfHostApplicability.

This is where all the settings for the preview program are stored. Here is what that key looked like on my system:

BranchName    REG_SZ    fbl_impressive
ThresholdRiskLevel    REG_SZ    low
ThresholdOptedin    REG_DWORD    0x1

10041    REG_DWORD    0x1

Notice the key RecoveredFrom and the value 10041 in it. Delete the RecoveredFrom key and do another check for updates in Windows Update. The build should now be listed.

How to opt in to Microsoft Update with PowerShell

For Windows to retreive updates from Microsoft Update, as opposed to Windows Update (which is the default), you have to opt in. This is usually done through the Windows Update GUI by selecting “Get updates for other Microsoft Products”:


This becomes tedious very quickly so here’s how you can do it with PowerShell:

To see if this was successful you can query the Services property of the $MU object:


You should see something like this:

Name                  : Microsoft Update
ContentValidationCert : {}
ExpirationDate        : 11/18/2014 1:27:43 AM
IsManaged             : False
IsRegisteredWithAU    : True
IssueDate             : 11/18/2011 1:27:43 AM
OffersWindowsUpdates  : True
RedirectUrls          : System.__ComObject
ServiceID             : 7971f918-a847-4430-9279-4a52d1efe18d
IsScanPackageService  : False
CanRegisterWithAU     : True
ServiceUrl            :
SetupPrefix           : mu
IsDefaultAUService    : True

Name                  : Windows Update
ContentValidationCert : {}
ExpirationDate        : 6/18/5254 9:21:00 PM
IsManaged             : False
IsRegisteredWithAU    : False
IssueDate             : 1/1/2003 12:00:00 AM
OffersWindowsUpdates  : True
RedirectUrls          : System.__ComObject
ServiceID             : 9482f4b4-e343-43b6-b170-9a65bc822c77
IsScanPackageService  : False
CanRegisterWithAU     : True
ServiceUrl            :
SetupPrefix           :
IsDefaultAUService    : False

If you only have the Windows Update entry something went wrong.

One of the major benefits of this is that you can do it remotely. I have yet to find another way to do this. If you know, leave a comment.

Data Deduplication on Windows 8 Pro

Due to the modular nature of the Windows platform, it is actually possible to move features between SKUs, and even between server and client. A user at the My Digital Life forum has experiemented with this and has extracted the necessary packages to run Windows Server 2012’s Data deduplication feature on Windows 8 Pro!

If you want to test that out have a look here:


You get no GUI and have to manage Data Dedupe with PowerShell, but that should not be a problem. I was able to save almost 300 GBs on a 500 GB drive storing virual machine images!


If you decide to run this on any production machines take special care when hotfixes and future service packs are released.

More info on the excellent disk deduplication feature here:

What’s special about the builtin Administrator account?

Every installation of Windows based on the Windows NT code base has a builtin admin account called Administrator. Every installation of Active Directory Directoy Services also has a builtin admin account called Administrator. (If you are running a version of Windows other than English, your accounts may be named something else.) This account provides complete access to files, directories, services, and other facilities. But are there other things that make these account special?

  • The Relative Identifier (RID) is always 500
    In Windows each Security Principal is identified with a Security Identifier or SID. The SIDs have two parts; the machine or domain component and the Relative Identifier (RID). The RID is simply a whole number incremented with one (1) each time a new Security Principal, typically a group or user, is created. The builtin Administrator accounts, whether they are in a local SAM database or in Active Directory, always have the RID 500. This means that if you know the domain or machine component of the SID, you also know the full SID of the builtin Administrator. From there it is easy to do a “reverse lookup” and find the actual username of the builtin Administrator, and then to start trying to break into it. (Some older code even lets you authenticate with the SID directly, as opposed to a username.) See next bullet.
  • The account cannot be locked out
    The builtin Administrator account cannot be locked out of the system no matter how many failed logon attempts it accumulates. This makes it a prime target for brute force attacks. Auditing can help you find out if someone is trying to do a brute force attack using the builtin Administrator account. Other, manually created, administrator accounts can be locked out, and therefore do not present a similar threat. Renaming your builtin Administrator account will afford you some protection, but be aware of the limitations of this; see previous bullet.
  • The account cannot be deleted
    At least not using the default Windows tools.
  • The account is disabled on client OSs as of Windows XP
    In Windows XP and onwards, the builtin Administrator account does not have a password and is disabled. During setup you are required to create at least one new account, and this account becomes an administrator.

Troubleshooting Forefront Endpoint Protection 2010 Installations

I had a hand in rolling out Forefront Endpoint Protection (FEP) for a customer recently. Some of our clients did not get FEP installed even though the SCCM client was installed and working correctly, and they had all prerequisites present and had successfully received the advertisement and downloaded the files from the distribution point (DP). It turned out that these clients were already running Microsoft Security Essentials (MSE), which FEP does not detect or uninstall. The solution was to manually uninstall MSE first and then wait for the next installation attempt from the SCCM client.

For future reference; these are the Anti-Malware products that FEP can detect and uninstall before it installs itself:

  • Symantec Endpoint Protection version 11
  • Symantec Corporate Edition version 10
  • McAfee VirusScan Enterprise version 8.5 and version 8.7
  • Trend Micro OfficeScan version 8.0 and version 10.0
  • Forefront Client Security version 1 including the Operations Manager agent

If you want to troubleshoot FEP deployments here are som interesting logfiles:

  • C:Documents and SettingsAll UsersProgramdataMicrosoftMicrosoft Security ClientSupportEppSetup.log
    (This folder also contains other interesting files regarding the FEP install.)

An overview of all SCCM 2007 logfiles is available here:


The Case of The Strange Folder Redirection Error

I was enabling Folder Redirection for some Windows 7 Professional machines, or rather, for the users of some Windows 7 Professional machines. The users already had a server based home directory with a My Documents folder, which also had data. The purpose of the operation was to, firstly, enable Folder Redirectin, but also to merge the contents of the My Documents folder on the client machines with the My Documents folder on the network server. First, to see what kind of conflict resolution Folder Redirection had, I created a file with the same name (but different content) in both the local My Documents folder and the one on the server. After logging on the first time the Folder Redirection policy was active I found this error event in the Application log on the client machine:

Log Name:      Application
Source:        Microsoft-Windows-Folder Redirection
Event ID:      502
Level:         Error
User:          <domain><username>
Computer:      <computername>
Description: Failed to apply policy and redirect folder Documents to \<servername><share><username>Documents.
Redirection options=0x1001.
The following error occurred: Failed to copy files from C:Users<username>Documents to  \<servername><share><username>Documents.
details: This function is not supported on this system.

Originally I thought this was a problem with NTFS file permissions on the file server, but these we OK. After all, other clients were redirecting their folders without problem. Since the error details didn’t give me any clue I decided to try to remove my offending duplicate file. I deleted it from the client machine and on the next logon the My Documents folder redirected without problem.

The error in the log should have a better explanation of what is happening. Folder Redirection is definitely supported on Windows 7 Professional. The Folder Redirection specific event logs didn’t contain any more information either. The error text should have said something along the lines “File conflict; file X already exists”. Maybe in Windows 8.

Unfortunately I solved the problem before I had a chance to enable debug logging for the Folder Redirection Client Side Extension. Maybe that would have told me what the problem was. Should you want to enable debug logging for Folder Redirection you can do so with this command:

reg.exe add “HKLMSoftwareMicrosoftWindows NTCurrentVersionDiagnostics” /v FdeployDebugLevel /d 0x0f /t REG_DWORD

If you are on Windows XP/2003 or earlier this will give you a log file: %windir%debugusermodefdeploy.log. If you are running Windows Vista/2008 or newer you will simply get more events in the Windows event logs.

So, should you find yourself staring at this error in the middle of the night (or any other time), see if you have any duplicate files in the folders you are trying to redirect.

Happy redirecting!

UPDATE: The duplicate files I created were created by a different account than the user owning the client computer and home directory on the server. That means that the user actually owning the folders could not delete or move the duplicate file. That could also be the reason for this error. But the fact remains; it is still a very poor error message.

UPDATE 2: I have now had a chance to test the conflict resolution in Folder Redirection and from my tests it seems that the client wins if the same file (but with different content) exists on both the server where you are redirecting to and on the client. I performed the same experiment as outlined above; two files with the same name, one on the server and one on the client. This time they were both created by the user owning the client and the folder on the server. Upon the next logon the folder redirection policy took effect and the local files were copied to the server, merging them with the content that already existed there. But as I say, the copy of the identical file on the server was silently overwritten by the file on the client. So now you know.