Jeremy Davis
Jeremy Davis
Sitecore, C# and web development
Article printed from:

Fun with NUC servers

Published 16 June 2014
Updated 06 August 2018

[ Edited to add: Since I wrote this, both the hardware and software has moved on, and I've had some other issues maintaining this server, which you might be interested in...]

I've been building myself a new home server this week and figured I should write down a few things about what I've been up to in case anyone else is trying to do a similar thing and hits the same roadblocks I have...

I've been using a Tranquil PC Harmony server at home for some years, and have been impressed by it's low power and reliability. Hence now that the old 32 bit Atom CPU and the original Windows Home Server O/S are getting a bit passed it, I thought I'd upgrade to one of their new Abel H2 machines, based on the Intel NUC platform. And since Windows Home Server has been retired, I'm left with Windows Server Essentials 2012 R2 as an OS for my Microsoft-centric house.

Having spent a few days getting all of this up to speed, here are a few of the challenges I came across getting that OS set up on the hardware.

Admin in user names

The first issue I hit was something that is almost certainly documented somewhere by Microsoft, but not obviously enough that I spotted it during my brief "how do I install this" research.

When you install Windows Server Essentials, it is done in two parts. The basic operating system install is first, where you are prompted for the password you wish to use for the local machine's administrator account. The second part is a wizard which asks you (amongst other things) for a username and password for your domain administrator account.

When you go through the wizard and fill this in, you must not use the word "admin" (or administrator) in the username. If you do, the wizard will fail further on with the unhelpful error "An error occurred while configuring Windows Server Essentials. Please try again." Once this has happened you will not be able to complete the wizard.

You must re-install the OS, and use a username which does not contain "admin".
I've not tried this myself, but according to a comment below there is a workaround for this issue that doesn't involve a re-install...

I found the answer to this issue via this helpful blog post.

Running headless

Intel's NUC hardware is designed to be a small, efficient desktop PC. It appears it was not created with the aim of running as a headless server – and hence it is not happy booting with no display attached.

I have not been able to find a BIOS setting which allows the machine to boot when there is nothing connected to the HDMI port. There is some discussion of this issue and the associated problems of booting when the machine is attached to the inactive side of an HDMI switch on Intel's support site. But, as far as I can see, no software answers.

It turns out, however, that you can fool the machine into thinking it has a display attached. If you have an HDMI-to-VGA adapter, this appears to work if the adapter is left connected even if the monitor is not attached to the adapter.

You can also use a "fake display" such as the fit-headless dongle if you want something smaller.

Physical network drivers

Another side effect of the NUC hardware being aimed at desktop PCs is that Intel have (unhelpfully) set up some of their driver packages for Windows so that they cannot be installed on Windows Server. I'm not entirely sure why they choose to prevent their physical network drivers from being installed, but allow their wireless drivers to work. But they have done so, and you need to indulge in a bit of hacking to make them install correctly.

The drivers which Intel maintains on their NUC Drivers pages work fine – but you need to modify their .inf file in order to make them install on Windows Server Essentials. The process is described by this helpful blog post (or in more detail for newer versions of the O/S here), however it is discussing a different model of hardware, so you can't modify exactly the same files and settings being discussed there.

To find the correct file to edit, you need to extract the drivers from the package into a folder on your hard drive, and find the folder containing drivers compatible with NDIS63. (NDIS 6.3 is the version of the Windows Network Driver API used by Windows Server Essentials) Inside this folder you then need to find the correct .inf file. You can follow the instructions in the blog post to find the correct device ID for your NIC via Device Manager, and then take the same approach to searching for the right driver file using the device IDs you find on your machine.

Once you've found the right file, follow the same process to remove the restrictions, and update the content of the file, but making use of your hardware ID to find the correct lines to modify.

With this done, you need to follow the instructions to turn off Window's driver verification, and you can right-click the modified .inf file and install the driver. Don't forget to put the driver verification settings back afterwards.


Intel's default WIFI drivers for the NUC hardware install fine under Windows Server Essentials. However, having done this I found myself unable to connect to any wireless networks – even though I knew that there was a network available it would not show up in the list of available networks.

It seems that a default install of Windows Server Essentials does not start the "WLAN AutoConfigure" service that is required to connect to networks.

WLAN AutoConfigure

When I changed this service to start automatically and rebooted the server, I was able to connect to a wireless network.

Health reporting via GMail

Lastly, a more trivial one.

I have a GMail account, and I'd like to have Windows Server send its Health Monitoring reports via Google's SMTP service. There are assorted posts out on the Internet about the correct SMTP settings for Google's SMTP service.

It seems that most of these posts (and the Windows SMTP Settings dialog) all discuss both SSL and TLS for transport security – but they don't really specify which one is actually being used in any given scenario.

SMTP Settings

A bit of fiddling reveals that whilst Windows Server Essentials has a checkbox for "This server requires a secure connection (SSL)" what it really means is that it will use TLS. Hence you have to make sure you use the TLS port on Google's server. This is port 587 not port 465 as specified for SSL.

And now I have a (mostly) working server. Now to migrate my source control repository, get SqueezeServer up and running, and sort out my online backups working for this device. Which should keep me busy for a few days yet...

— Edited to add —

A couple more things have come up, which seem worth writing down:

Letting "Network Service" log on to SQL Server

I have a couple of homebrew web apps running on my old home server, and one of them runs a windows service that does background work and updates a database. I had this running under the Network Service account on my old server, and had granted rights to the appropriate database to this account.

But when I try to use SQL Management Studio to add the Network Service account to SQL Express 2014 on the new server I get an error saying the account cannot be found. That seems odd – as it clearly is there, as the service can start. I'm picking it from the standard Windows Account selection dialog after all...

I'm not quite sure why this is happening, but it turns out that if I run a SQL command to add the user account, rather than trying to add it via the UI, then all works OK:



Allowing machines in a different domain to back up via Windows Server Essentials R2

When you browse to /connect/ on your WSE server and try to install the connector software, it will refuse if the machine you are on is joined to a domain that WSE does not control. I hit this issue trying to add my work laptop (which is part of the my company's domain) to my WSE's backup system.

A bit of head scratching and googling leads to this blog post, which provides a registry hack to bypass this issue:

reg add "HKLM\SOFTWARE\Microsoft\Windows Server\ClientDeployment" /v SkipDomainJoin /t REG_DWORD /d 1


This disables the step of the WSE Backup Connector's installer that tries to make the machine part of the WSE domain.

Stopping your client machines having their DNS settings changed at boot time

After you've installed the WSE connector on a PC, you will find that every time it boots, the network card that connects it to the WSE box will magically get its DNS settings changed to use the server as its DNS server. Whilst this might be useful in a small company, it's not very useful on a home network where you want your computers to use your ISP's DNS.

Again the Internet comes to my aid with this Microsoft support article. To stop the server overriding your DNS settings you need to tell it to stop this behaviour:

reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Server\Networking\ClientDns" /v SkipAutoDnsConfig /t REG_DWORD /d 1


Any machines you join to the WSE server via the /connect/ web page after that change will not have their DNS changed. But you'll have to re-connect any machines that were joined before you made the registry change.

Comment mentioned above:

David Allison says: I have just managed to fix the Wizard issue without reinstalling the OS:

  1. Cancel the Wizard when it appears
  2. Stop the Windows Server Essentials Management Service (no need to Disable)
  3. Run the Wizard again manually by going to Run and entering:

C:\Windows\explorer.exe "C:\Windows\System32\EssentialsRoleConfigWizard.exe

  1. The Wizard will fail again – start the Windows Server Essentials Management Service
  2. Now click Retry and the Wizard should complete

I have only tried this once and I had actually manually installed Active Directory roles by this point, so not sure if this is a pre-requisite, but (somewhat unbelievably!) it worked and the Wizard completed successfully.

EDIT: I had also given ServerAdmin$ Log as service rights by this point as well (

↑ Back to top