August 17, 2017

Install Azure Stack in Azure - Part 4

Shew! My fingers are starting to hurt. This is a continuation of previous episodes so start from the beginning or none of this will make any sense.

So, when we were last together, Azure Stack had just created the Domain Controller as a Level 3 nested VM, joined itself to that new domain, rebooted itself and is continuing the installation. Our next data point is to watch for AzS-BPGNAT VM to come online. It can take some time, but pay attention to HyperV Manager.

Azure Stack is also now setting up Failover Clustering and deploying (on those 4 data disks you created) a Scale Out File Server Cluster. This is where all further data is going to go and is wicked cool to look around in (but not touch).

If you watch the verbose script output, you will see it do lots of neat things like setting up Just Enough Administration (JEA) and associated MOFs. It will also create a common Nuget package library disk which takes quite some time.

After a while (by now I had switched from coke to beer), BGPNAT will come online. This is our next moment of get something done quickly(ish). When you see that VM get created, open a NEW PowerShell window as Administrator ON CLOUDBUILDER, NOT HOST. Now, we're going to create the NAT network switch for our Level 3 VMs, exactly like our CloudBuilder VM got from Host, but with a VERY different subnet to keep things straight in our heads. Here's the commands:

$SwitchTest=Get-VMSwitch -Name "NATSwitch" -ErrorAction SilentlyContinue if($SwitchTest -eq $null){ New-VMSwitch -Name "NATSwitch" -SwitchType Internal -Verbose $NIC=Get-NetAdapter|Out-GridView -PassThru New-NetIPAddress -IPAddress -PrefixLength 24 -InterfaceIndex $NIC.ifIndex New-NetNat -Name "NATSwitch" -InternalIPInterfaceAddressPrefix "" -Verbose }

This will output a bunch of stuff and assuming no errors, you now have a second nested NAT switch to work with. Give BGPNAT a few more minutes to get its act together. Now, open up his settings in HyperV Manager and change the SECOND NIC card to use the NATSwitch that you just created. If you don't even see a second NIC card in his settings, you went too fast, cancel out and wait a few more minutes. If you watch the verbose output close enough, you will see it create that NIC on the VM. Then you know you're ready.

In this picture, you see the NAT NIC card says "PublicSwitch" - change it to NATSwitch and then press OK. If you don't do this step in time, the installation script will fail after another 30 minutes or so and you'll be sad.

Watch the Console of BGPNat VM. After a while, it will have joined that shiny new domain and it will be time for it to reboot. When it does, we're going to log into it via the Console. Now, odd...when I did this six times for this blog series, each time, the BGPNat VM came back up ALREADY logged in (auto login). K...if it doesn't for you, just log in as AzureStackAdmin. Now, you need to tell BGPNat to use the new NAT Switch you created. Run these commands from BGPNAT:

netsh interface ipv4 set address "Ethernet 2" static netsh interface ipv4 set dnsservers "Ethernet 2" static primary

You'll note that we have now set the BGPNat's IP address to be on the subnet of the NATSwitch. Now, ping something from BGPNat's command window, like and you should have success!

Whoop!!!! Now, if you logged in to BGPNat, log out. As mine came up automatically logged in, I just closed the console window and went back to the PowerShell verbose logging in CloudBuilder.

If you've made it this far, you are likely on the home stretch. About 4 hours later, give or take, you should get a "deployment complete" message in the PowerShell script. On a few of my runs through this, after this step (a ways) I got a few random errors here and there. That MAY be okay. Simply re-run the installation like this:

.\InstallAzureStackPOC.ps1 -Rerun -Verbose

That's a good command to have around. Random shit can/will break. Study the output window, make any adjustments that seem obvious, etc. If nothing seems obvious, try again, perhaps it will succeed on the second trip through. There are several things about this installation that rely on specific timing, and since we're not on bare metal, that timing can get out of whack.

In my next post, we'll explore Azure Stack and get some Resource Providers installed! For now...more beer.