Lab: Configure PowerShell WebAccess for management

Now that I have my Lab configured and set up to accept remoting from my Client machine, I want to set up a small Hyper-V lab onto this Host.

Since my goal is to manage as much as possible through PowerShell, my current setup will run into the following problem:
I can remote into my lab host, but due to single-hop remoting, it is not recommended to daisy chain sessions.

In case you DO want this, you can look at the following articles that will give you more insight on multihop remoting.
A small insight on what is required:

What is the goal and what is required?

The goals I have are quite simple:

  • PowerShell access to my Host machine
  • PowerShell access to my Guest VM’s
  • It has to be secure, following Best Practice

In order to obtain these goals I first have to figure out what the best practice is, since I can already access Host machine.

According to a PowerPoint presentation made by  Lee Holmes [part of the PowerShell team since v.1] CredSSP should only be used in case of Highly Trusted Servers, because otherwise

‘This opens you up to credential theft, so is disabled by default on both the client and the server’

Ok, so I need another way to get access to my Hosts, which allows access to my Guest VM’s without having to multihop remote or RDP to my Host machine.

In comes PowerShell WebAccess!
This allows us to connect to the Host machine as console and through that session I can remote onto my Guest VM’s!

The Code

Getting this all done required 4 steps that can easily be done through PowerShell:

  • Install PowerShell WebAccess
  • Configure the PowerShell WebAccess Web Application – Gateway
  • Configure a restrictive authorization rule
  • Use PowerShell WebAccess

Installing PowerShell Web Access

To install PowerShell WebAccess is quite simple, but first let’s check if it’s not already installed or perhaps requires source media:

In my case this has not been done yet, so we’ll go ahead and install this.
Do note that PowerShell WebAccess required IIS as Web Server, so this will also get installed.

Reboot the machine if required, but normally you should be ready to continue.

Configure the PowerShell WebAccess Web Application – Gateway

Now that we have PowerShell WebAccess installed, we need to configure it for usage.
We can do this using

As the added parameter implies, this will set up a self signed certificate which is recommended for test environments only.
The certificate will expire in 90 days after which you should re-assign a new self-signed certificate.
When setting up a secure production environment be sure to use a valid certificate signed by a CA.

This  command will configure a few things for you:

  • Install the PSWA Web Application
  • Install the PSWA Application Pool
  • Install PSWA within the IIS Default Web Site container
  • Automatically configures IIS to run on the default website under https://[servername]/pswa
  • Bind a self signed certificate to the PSWA Web Application

In case you want to set up a valid certificate, use the following command

And configure the certificate through bindings on IIS Manager.

Configure a restrictive authorization rule

Now that we have the Role installed and the Gateway configured, we need to define who is actually allowed to access PowerShell WebAccess on this machine.
We can do this by explicitly granting access to users through the following commands.
Do note, there is no GUI alternative to add or manage there permissions, PowerShell will be required!

Now in case of a test environment, you won’t to be too picky on who can access your machine, but in case of production you should make sure to configure these settings with care!

As the command implies, all users, connecting to all computers, are allowed granted access to all configurations.

In case you want to restrict this access a little bit more, you can do this by simply defining the provided parameters with more detail.
For my environment I personally restricted the UserName to the local administrator, just because I can 🙂

Use PowerShell WebAccess

Now that everything’s configured, let’s give it a test run!

Open your browser to the server’s name or FQDN


To log in there’s one tiny thing to keep in mind:

In the User name field, be sure to provide it in the format you’ve defined your PswaAuthorizationRule, so in my case CONTOSO-SRV001\administrator instead of simply Administrator.



You have full [secure] access to your Host VM, providing access to all Cmdlets, tab-completion etc. and you can now securely remote onto your Guest VM’s.


Happy scripting! 🙂


Lab: Connect to your ServerCore using remoting – step by step

The next part in my Lab setup now that I’ve gotten network configured is to actually no longer touch my new Lab machine…

While that might sound strange at first, the reason for this is simple.
My Lab should be a headless server, stuffed in a cabinet somewhere with power and a network connection and I should be able to do ALL my management tasks remotely.

This should be a simple task you’d say, but for the sake of clarity [and to learn this process better myself] I have decided to write down all the steps required to do this.

What is the goal and what is required

I think it helps to first define your goals before you start tinkering with a solution, as you might be easily distracted and not reach the goal you had set for yourself.
According to your goals, you note down what steps are required to reach those goals.
Don’t get me wrong, not the immediate script, just the simple text version of what you think you need to do to achieve the goal.

This is especially helpful for me, as I tend to get distracted a LOT!
Think Hammy from Over the Hedge or Dug from UP!

My goal in this case are as follows:

  • Connect to ServerCore using the computername through PSRemoting.

What is required:

  • Add the ServerCore’s computer name to my client’s hosts file
  • Add the ServerCore’s computername to my client’s Trusted Clients settings under WSMAN
  • Connect to ServerCore WSMAN
  • Add the client’s IP address to the ServerCore’s Trusted Clients settings under WSMAN

The code

Client machine Hosts file

Please note: these steps require PowerShell to be run as Administrator.

First of all we want to define some variable which we want to use later on

Of course we want to automate the addition of the ServerCore’s computername to the local hosts file, but in case we’ve already done this, we need to build in a check

To explain: I’m reading the contents of the current Hosts file, located here:  C:\Windows\System32\drivers\etc\hosts .
Just in case you’ve installed Windows in another folder, the script automatically gets the correct location.
It will then check if the Hosts file already contains a line with the ServerCore’s IP address and Name.
If this is not there, it will automatically add this line to the $Hosts variable.
Once this is done it will write the contents of this variable back to the actual file and force it.

Client machine Trusted Hosts

Please note: these steps require PowerShell to be run as Administrator.

Now that you’ve changed the Hosts file, we need to add the ServerCore machine to our WSMAN Trusted Clients.

This will first read out the currently configured Trusted Hosts on your client machine and will then add the ServerCore to this list.
In case you DON’T have any Trusted Hosts configured on your client machine yet it will only add the ServerCore machine.

To check that everything is configured properly [or to check if you have any Trusted Hosts configured on your machine], you can run the following command:

Connect to ServerCore WSMAN

Please note: these steps require PowerShell to be run as Administrator.

While PSRemoting is enabled on Windows Server 2012 R2, it isn’t configured to allow connections from your Client machine.
WSMAN on the other hand is 🙂 .

We can simply create a connection to the machine by using the following commands:

ServerCore machine Trusted Hosts

Please note: these steps require PowerShell to be run as Administrator.

Now comes the tricky part:
We want to automatically get our Client machine’s IP Address and add this to the ServerCore’s Trusted Hosts list.

First we get our Client’s IP Address [requires PowerShell v4 and Windows 8+]:

Now that we have the Client machine’s IP Address, we can add this to the ServerCore’s Trusted Hosts:

Once again we want to check if everything’s properly configured:

The result

Once this is done, you should be able to do the following

Tada!! 🙂



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!