New-Datacenter?

Note: This post is to facilitate conversation on the topic of making a new Windows datacenter. This is far from a howto. If you came here looking for that, you will be disappointed.

In the beginning, there was nothing. Then there was the command line.

But more seriously, I've been playing around with the idea of bootstrapping a Windows data center. Assume you have up to some hypervisor. Since we're making a Windows ecosystem, we can assume VMware products. How do you go from "a few ESXi hypervisors" to "a fully-capable Windows datacenter", complete with all the services you expect from Microsoft?

The Dream

A one-touch solution to deploy an entire Windows datacenter.

The Way Forward

The immediate answer is automation. Powershell automation, specifically. But where does the Powershell magic run from? Can't run on the bare hypervisors. Okay, so we'll need a bootstrapping Powershell.... server (a BPS?), of sorts. So assume we have a few hypervisors and a single Windows host (not on the hypervisor since that hasn't been configured yet). 

We'll also need some binaries. So assume all binaries are also on this BPS. Let's also throw some templates in there, just to get a vCenter started up. This is getting long... for the sake of brevity, let's just say we have a set of distinct scripts that, on their own, will give us all the components we need for our Windows datacenter.

How do we tie them all together?

Devil, something something, Details

This is a bootstrapped environment, so we don't have the luxuries of Active Directory or DFS or anything else that makes life easier. We have a bunch of blank Windows installations. First challenge - we have to get the binaries & scripts to the blank VMs. We could set up a share on our BPS, but our blank VMs don't know how to get to it, and we can't even use a Workflow from our BPS because, with no server certs, WinRM will only use the 'default' configuration, which limits you to a single hop for cred-forwarding.

The only thing I've come up with is to set up a minimal IIS installation and have the blank VMs download the necessary files over HTTP. We can use some simpler 3rd party web servers, but then we'd be introducing non-native products, which only complicates things.

Assuming we can transfer the data (binaries) and the instructions(scripts) to the blank VMs, how do we choreograph the installation of the products that make up our datacenter? I'm imagining something like a Master Powershell Workflow run from the BPS that knows the order of operations. 

This is getting complicated. And I'm concerned that it's unnecessarily so.

Externalize Away the Setbacks

And all of this is to say nothing about sustainment. You can create a bunch of stuff. Nice. Now how about configuration management? I don't know either. Maybe this has all been done before and I'm just not aware of it. Sounds like more research...

Welcome to Powershell Workflows. Please Follow These Rules

The most powerful feature introduced in Powershell 3.0 is The Workflow, no doubt. However, workflows are not something exclusive to Powershell. In fact, workflows (that is, the Windows Workflow Foundation) have been around since .NET 3.0 (recall that Powershell 3.0 requires .NET 4.0). When you are using workflows in Powershell, you have left the well-known comforts of Powershell. You are now a guest in the Windows Workflow Foundation.

Activites, not Commands
In each workflow you write, the individual lines are no longer commands. They are individual Activities, as per the Windows Workflow vocabulary. As such, they run in their own process. The implications here are great. For the sake of brevity, I'm only covering the cases that have occupied most of my time.

No Module Imports
Import-Module is one of the (many) disallowed cmdlets in workflows. In order to get around this, we have been given the -PSRequiredModule parameter.

Not this:
Import-Module AwesomeSauce
Import-Module RequiredModule
$goods = Get-OutTheGreat

This:
$goods = Get-OutTheGreat -PSRequiredModules 'AwesomeSauce','RequiredModule'

Snap-In Complications
Add-PSSnapin is also disallowed. This is immediately a problem for fans of PowerCLI, as it's written as a Snap-In, not a module. The best workaround I've found (though it's kludgy) is to wrap the necessary work in an InlineScript.

Not this:
Add-PSSnapin vmware.vimautomation.core
Get-VM

This:
InlineScript{
    Add-PSSnapin vmware.vimautomation.core
    Get-VM
}

No Implied Parameters
When using workflows, you must explicitly spell out each parameter for every cmdlet you use. This can be a bit fun when learning the name of that parameter you've been taking for granted. The new ISE can be helpful with discovering cmdlet parameters.

Not this:
Get-VM BigGiantVM

This:
Get-VM -Name BigGiantVM

Verbose Workflows
One overlooked feature of workflows is the Activity Common Parameters. These are parameters you pass to individual activities. My favorite so far is -DisplayName. With this parameter, you can label the activities in your workflow so they appear more human friendly, such as "Connecting to remote host AwesomeHost" instead of "Workflow: Line 12, Character 8" while executing. 

Creativity Under Constraints
I've found myself complaining about these details along the way. But actually, they may be forcing me to write better code. By disallowing the easy (and unsustainable) path, I'm reducing what used to be complex scripts/functions into more atomic, modular functions/workflows. This is the beginning of your own personal framework. I say embrace the changes. Besides, it's not like we have much of a choice.

I Just Want Powershell Remoting!

In some bootstrapping environments, you don't have fancy things like Active Directory domains or valid DNS entries. You have to connect to machines with IP addresses and no machines have certificates yet. This is the scenario where Workflows can matter most and it's where most Powershell Remoting howto's have failed me. However, there is a fast and (relatively) easy way to have Powershell Remoting (and, thus, Workflows) in such arid, hostile environments.

The Situtation
You're logged into machine Foo. You want to execute remote Powershell scripts (or get a Powershell session) on machine Bar. There is no AD environment and you can only address machines by IP.

The Details
Foo's IP: 192.168.0.1
Bar's IP: 192.168.0.2

Do this
On both machines, in a Powershell session with Admin rights:
Enable-PSRemoting -Force

This enables the WinRM service, pokes a hole in the Windows Firewall, and does a few other things to enable remote Powershelling.

 Then...

Set-Item WSMan:\localhost\Client\TrustedHosts -Value '192.168.0.*' 

This adds the network 192.168.0.* to the list of Trusted Hosts, which is a requirement when you use Remote Powershell with 'default' authentication in WinRM.

You could even run the above commands in an OS template, so that all new Windows machines in your virtual environment will accept remote Powershell sessions.

Test it
On Foo, run:
Enter-PSSession -ComputerName 192.168.0.2 -Credential $(Get-Credential) 

The other requirement when using Remote Powershell with 'default' authentication is that you specify explicit credentials (no pass-through creds). So enter your credentials at the prompt and enjoy your new remote Powershell session. You can also now run Workflows in your environment, so you can get back to bootstrapping your datacenter!