Mini Hyper-V: Operating System

When we left my project, the new mini server had booted up using Windows Hyper-V Server 2012 R2. This is a server core installation intended to only run Hyper-V, which is perfect for my needs. The server booted up with a temporary name and a DHCP assigned IP address. The next step is configure the server and join it to my test domain.

I could do this all interactively using the sconfig script, but where’s the challenge in that! So I’m going to configure the server from a Windows 8 client with RSAT installed in my target domain. There are ways to configure Hyper-V in workgroup environment but I want to take advantage of domain. It shouldn’t really make any difference but my test domain, Globomantics.local, is running in a Hyper-V environment on my Windows 8 laptop. My mini Hyper-V server will belong to this domain, as will any virtual machines it ends up hosting.

To get started I know the IP address of the new server and credentials for the local administrator account. With this I can use PowerShell remoting, since it is enabled by default in Windows Server 2012. However, on my client, I need to temporarily add the host to the TrustedHosts list. Otherwise, the client won’t trust the server and I won’t be able to connect. In an elevated I’ll run this command.

PowerShell

1

set-itemWSMan:\localhost\Client\TrustedHosts-Value172.16.*-Force

Using -Force suppresses confirmation prompts. This setting will allow me to connect to any host using an IP address that starts with 172.16. I should now be able to use Invoke-Command or run any configuration workflows. In fact, I’m going to use some basic workflows to set the computer name and IP configuration. First, I’ll verify remote connectivity.

PowerShell

1

2

3

4

5

PSC:\Windows\system32>test-wsman172.16.10.122

wsmid:http://schemas.dmtf.org/wbem/wsman/identity/1/wsmanidentity.xsd

ProtocolVersion:http://schemas.dmtf.org/wbem/wsman/1/wsman.xsd

ProductVendor:Microsoft Corporation

ProductVersion:OS:0.0.0SP:0.0Stack:3.0

Looks good. Next, I’ll define some PowerShell variables to use with my workflows.

PowerShell

1

2

3

4

5

$oldIP="172.16.10.122"

$newIP="172.16.30.212"

$NewServerName="CHI-HVR2"

$domaincredential=Get-Credential"globomantics\administrator"

$remotecredential=Get-Credential"$oldIP\administrator"

The first workflow I want to run will perform some basic configuration.

PowerShell

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

WorkflowSet-StandardConfig{

Write-Verbose-Message"Running parallel tasks"

Parallel{

#these are relatively simple tasks that can run simultaneously

#create folders

New-Item-PathC:\Scripts-ItemTypeDirectory

New-Item-PathC:\Work-ItemTypeDirectory

#add features

Add-WindowsFeature-NameWindows-Server-Backup

#set execution policy

Set-ExecutionPolicy-ExecutionPolicyRemoteSigned-Force

#set the time zone

TZUTIL/s"Eastern Standard Time"

}#parallel

}#end workflow

Once this workflow is loaded into my session I can run it and configure the new server.

PowerShell

1

Set-StandardConfig-PSComputerName$oldIP-PSCredential$remotecredential

Next, I want to configure the IP configuration. The new server only has a single NIC which simplifies matters a great deal. Here’s the workflow I’m going to use.

One caveat here is that when you change the IP address you’ll lose your connection to the remote computer. PowerShell will keep retrying. What I probably should have done was to include some parameters to limit the retry count. Eventually, the command will timeout and I can continue.

Again, I’ll splat a hashtable of parameters, this time connecting to the new IP address.

PowerShell

1

2

3

4

5

6

7

8

9

$domainParams=@{

NewName=$NewServerName

Admin=$DomainCredential

PSComputerName=$newIP

PSCredential=$remotecredential

Verbose=$True

}

Set-DomainConfig@domainParams

Eventually the computer will reboot and I’ll get a positive result.

Excellent. Now that the server has rebooted it belongs to the domain and I can use the new name to verify a few things.

PowerShell

1

2

$cs=New-CimSession-ComputerName"chi-hvr2.globomantics.local"

Get-NetAdapter-CimSession$cs|Get-NetIPAddress

I used the new server’s FQDN for the CIMSession name as I couldn’t get the NETBIOS name to work. Probably because I didn’t wait long enough for browser stats to get updated. Anyway, it works and I can also verify Hyper-V is working.

PowerShell

1

Get-VMHost-ComputerName"chi-hvr2.globomantics.local"|select*

The last thing I should do is remove the trusted hosts settings on the client. But because I trust my network and I might need to do this again, I think I’ll leave it for now. But I did it! I now have a Hyper-V server ready for me to use.