Lab: Intel NUC with Windows ServerCore 2012R2

Since I’ve decided to get more serious about updating my skills and knowledge again [also why I started blogging], I thought about getting a proper lab setup.

The goal is to have a small, portable but powerful Hyper-V based lab which I can carry along with me from home and to work if need be. Now I tend to have a test setup on my home machine and one on my work laptop, depending on what I need at that moment.
Using this portable lab I want to make everything I need accessible from one location.

The Hardware

Long internal debates on what kind of hardware solution to use…

Go for an Intel NUC solution or Gigabyte Brix?
Or perhaps getting a mini-ATX board and case and configuring the whole thing myself?

After randomly browsing on one of the local Dutch main hardware sites, I found a great offer to purchase an Intel NUC system along with the required RAM and M.2 SSD disk for a very good price.
So good, that I ended up getting it the next morning ūüôā

So here’s the setup:

  • Intel NUC5i5RYK
  • Kingston ValueRAM KVR16LS11/8 [2x8GB]
  • Samsung 850 EVO M.2 250GB
  • Mini-HDMI to HDMI converter

The Installation

One of the great things about Intel NUC [and Gigabyte Brix] systems is that it’s so easy to install.

Unscrew the 4 legs, remove the backplate, plug in the RAM modules and M.2 SSD chip and screw everything back again.
If it takes you 5 minutes, you’re doing something very wrong ūüėČ

Once this was done I needed to decide on Operating System.

I’m not¬†sure if I want to manage only Hyper-V or perhaps set up a test lab domain, so I ended up going for the ServerCore installation using a ZALMAN ZM-VE300 USB3 solution.

I hooked up the NUC to our office’s beamer [as I didn’t have a monitor with HDMI connection, nor a mini-DisplayPort adapter] and booted up the machine with the Windows ISO as Virtual Disk.

Installation was just a few minutes work [literally 2 minutes max], after which I ran into somewhat of a problem: Windows was installed, but it couldn’t find an active NIC. Now that’s annoying for a ServerCore install!

The Problem

Since I only had access to the office’s meeting room for a limited period, I needed to find out how I could resolve this issue…

My main philosophy in my daily work is “if you’re having a problem, chances are someone’s had that same problem as well”, which leads me to one of my best friends in IT:

It seems that there’s quite the issue with NUC NIC drivers for Window Server operating systems, because according to Intel NUC systems are designed as Desktop replacements, hence no server OS support for drivers.

Again, here’s where Google comes in handy.
I found this article by Stephen Owen [@FoxDeploy] where he describes the perfect way download the latest driver for your NUC and modify the .inf file to allow for installation on your Windows Server OS.

Now I ran into a small issue with this article however:
It was written for a Windows Server with GUI install, where you could simply get the Vendor ID and Device ID for the NIC from Device Manager.

As if it was meant to be, on the same day I ran into this problem, Steven posted the following blog on his site: Using PowerShell to find drivers for Device Manager.

Long story short, let’s combine the knowledge of both articles and get this NIC working!

The Code

Since this is a PowerShell related blog, let’s put it to good use to solve this problem!
First of all, we need to find out the Vendor ID and Device ID.
This command gets us all the Devices which aren’t correctly installed along with Vendor ID and Device ID:

Save the resulting piece to a variable for later use:

Make sure to copy the contents of the latest extracted drivers to the ServerCore machine [USB stick recommended]

Now that we have the drivers on the machine, we can use our $NIC-DeviceId to find out which .inf file we need to modify:

This command will display all the .inf files which contain the Vendor ID and Device ID match.
For Windows 2012 R2 you need to check the x64 folders and NDIS64 subfolders, which in my case meant I needed the e1d64x64.inf file.

Ok, here’s what needs to be done in the .inf file:

  • Either remove or comment out [using the ; sign] all the entries under the¬†[ControlFlags] block.
  • Check under the¬†[Intel.NTamd64.6.3.1] block and copy ALL the lines related to your Device ID
  • Paste these lines in¬†the¬†[Intel.NTamd64.6.3] block under the last lines
  • Save the .inf file with the updated entries

Seems quite simple right?

Well, in order to install the drivers, you will need to perform one more magic trick.
Because the drivers are unsigned and edited, Windows won’t allow you to install the drivers, so you’ll need to override these settings by running the following commands:

Once this is done, you can “properly” install the drivers:

You should get a warning message saying that the driver is unsigned, but since we know this, we can choose to Install the driver anyways.

Almost done!
Time to reset the security settings back to default:

Now that we’ve restarted the machine it’s time to put this to a test:

We’re online!!


Stay tuned for more Lab related posts to see more information/tips on how to set up your own Hyper-V lab op Windows ServerCore!




Configuring PowerShell remoting through GPO

I’m loving the way Microsoft is currently pushing PowerShell as THE go-to tool required to manage all your solutions.

I’m¬†at a loss however at why they aren’t providing out of the box solutions so that you can manage all of your workstations/servers through PowerShell.
Sure, you can head over to every machine and configure PowerShell using

However I can understand that people have better things to do with their time [I sure do!]

This sounds like the ideal task for Group Policy Management, a central way to push configurations to all of your Computer Objects within Active Directory.
Using this solution you can ensure that all the required clients will get the configuration that you want them to have, without ever having to leave the comfort of your desk ūüôā

Required Group Policy Objects [GPO]

In order to configure this correctly you will need to set the following configuration items within your GPO:

  1. Enable the Windows Remote Management [WinRM] Service and set startup mode to Automatic
  2. Enable the Windows Firewall to allow for WSMAN traffic [TCP 5985]
  3. Configure the WinRM service for listeners

Now¬†personally I’ve added the following 2 steps to my “template” GPO in order to make my life a bit easier:

  • Configure¬†the WinRM to automatically Restart the service on failure and start immediately [I hate having to wait for restarts]
  • Set the Script Execution Policy to RemoteSigned

Of course you can also do those things once you’ve gained access to all the machines, but this is a fire-and-forget thing and would be ideal if it’s automatically configured on each and every machine joined to the domain.


What to configure

Now that we know WHAT we want, the question becomes “How do we configure this?”

Using PowerShell

Since this is a blog primarily aimed at learning PowerShell, this will be the preferred way to create these policies.
This is currently supported from Windows 2008 R2 Server and up.
Unfortunately, currently you can only modify a GPO’s settings through the GUI.

All other management tasks can be done through PowerShell, so we’ll do as much as we can through PowerShell.

  1. Load the Group Policy module in your PowerShell session
  2. Create a new GPO
  3. Link your GPO to the required Organizational Unit [OU]

Once this is done, you can skip to step #4 in Using the GUI.

Using the GUI

If ¬†you have a Windows 2008 Server or aren’t too comfortable with PowerShell yet, you can also use the GUI to create and set new Group Policy Objects.
This part of the guide will assume you know how to manage GPO’s and will only include the bare minimum information.

  1. Open the Group Policy Management console [gpmc.msc]
  2. Create a new Group Policy Object named Settings Р[C] РEnable-PSRemoting
  3. Link the GPO to the correct OU, containing your computer objects.
  4. Now we’re on the same steps as with the PowerShell commands, we need to Edit our GPO:
    1. Computer Configuration -> Policies -> Windows Settings -> Security Settings -> System Services -> Windows Remote Management (WS-Management)
    2. Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Windows Firewall with Advanced Security -> Windows Firewall with Advanced Security -> Inbound Rules -> New Rule
    3. Computer Configuration -> Policies -> Administrative Templates: Policy Definitions (ADMX) -> Windows Components -> Windows Remote Management (WinRM) -> WinRM Client -> Trusted Hosts
    4. Computer Configuration -> Policies -> Administrative Templates: Policy Definitions (ADMX) -> Windows Components -> Windows Remote Management (WinRM) -> WinRM Service -> Allow remote server management through WinRM
    5. Computer Configuration -> Policies -> Administrative Templates: Policy Definitions (ADMX) -> Windows Components -> Windows PowerShell -> Turn on Script Execution
    6. Computer Configuration -> Preferences -> Control Panel Settings -> Services -> New -> Service

It’s as simple as that!

Wait for the GPO to propagate out to the machines and you should have access to the remote machines!

If like me you have multiple customers and would prefer to make 1 template GPO which you can Export/Import into various environments, be sure to change the TrustedHosts from your domain name to something like * or more secure: your subnet [192.168.1.*].


Happy Scripting! ūüôā



Importing users from Active Directory into Office 365

Today I ran into an issue where I had to quickly import x amount of users into an empty trial tenant from
Office 365 in order for to prepare the future mail migration.

Because I’m trying to get everything running through PowerShell, I thought this would be a nice moment to
document everything for future use and for other people to see how it’s done [or give tips ūüėČ ]

Getting user information from Active Directory

First of all I had to get the current user information from Active Directory in a format that I can use in
Office 365.

So we start up PowerShell on the Windows 2008R2 Standard server and get all the details I need:

Now this would give me all the users in the entire domain, something I’m not quite looking for.

So in order to narrow it down, I’ll just query all the users in a specific OU using the SearchBase parameter:

This is better, however now I notice that in my case I have some subfolders with disabled/template users.
Again, I’d like to narrow it down to ONLY the users in the specific OU, no recursion.
For this I will need to further define my query using SearchScope:

This gives me all the results I would like to have, but maybe a bit too much detail for me to export.

In order to see what properties I’d like to export, I need to know what properties I would like to
import on the Office 365 side of things:

    • FirstName
    • LastName
    • DisplayName
    • UserPrincipalName
    • UsageLocation

I can’t get all of those properties from my current AD query, but those that I’m able to get,
I can provide in the format I would like them to be in.

The details I can get from AD are

    • FirstName = GivenName
    • LastName = SurName
    • DisplayName = Name
    • UserPrincipalName = EmailAddress

Using the property parameter we can get the users’ email address and using Select-Object we output the
information in the format we would like to have it:


I can now export this information to a csv file:


Creating Office 365 users based on exported Active
Directory data

Now that we’ve exported our required data, we can simply import this data into our Office 365 tenant

Using the Connect-O365 function which I’ve created in the Connect to Office 365 using PowerShell post,
you can easily perform bulk operations like this:

Once connected, we will need to collect/set some default data required for our bulk user import:

Change the UsageLocation according to your requirements.

Now we’ve got all the information we need to create our new user accounts!

There we go, all the users are imported in your tenant!

Some tips in case you’re running into errors:

    • Be sure to have the email address domain configured in your Office 365 tenant as accepted
    • Be sure to have all your AD information filled in!

You will get automatically assigned passwords for these created accounts and you’re good to go ūüôā