Deep Dive in Windows Server 2016 New Features: PowerShell Direct

Have you ever tried to make a configuration change on a Friday afternoon, right before beer o’clock, and you couldn’t get access to the machine you needed to change? This problem might be caused by out-of-date security settings, the a network change, or something else. All you need to do is execute a couple of lines of PowerShell, but this problem prevents you from making a simple configuration change.

What is PowerShell Direct?

PowerShell Direct promises to solve this problem for you as long as you’re living on the latest releases. PowerShell Direct lets you breach the boundary between hypervisor host and guest virtual machine in a secure way to issue PowerShell cmdlets and run scripts easily. Currently, it’s limited only to Windows 10 and Windows Server 2016 guest living on Windows 10 and Windows Server 2016 Hyper-V hosts; no currently-released operating systems support this feature, although it works in the technical previews for both future versions of the product. Also, Windows Nano Server hosts and virtual machines do not currently work with this either, although you can safely bet that that fact will change in the months to come.

The best part of PowerShell Direct is that it just works, every time, without a bunch of faffing about to get security settings configured, holes poked in firewalls, and flaky remoting set up. From a host, you can open a PowerShell session directly on the guest with just a couple of cmdlets.

First, run Get-VM to get a list of all virtual machines that are running on a Hyper-V host.

Look for the VM name, and then use the next cmdlet to begin a PowerShell Direct session:

Enter-PSSession -VMName VMName

You will be prompted to authenticate to the guest operating system using an account that it accepts, which could be either a local machine account or an Active Directory account if the guest OS is a member of a domain. After authenticating, the session you are dumped into is just like a regular remoting session over the network — you have opened a PowerShell session directly into the guest, and you’re free to do your bidding. It has to be running on the current host, and it has to be Windows 10 or Windows Server 2016, but other than that nearly every cmdlet will work and those that do not yet will eventually get fixed before RTM.

In a script, you can make use of PowerShell Direct through the Invoke-Command cmdlet, which simply accepts the name of the guest VM as a parameter, and then you can input the script you wish to run within the curly braces, like so:

Invoke-Command -VMName VMName -ScriptBlock { insert your scripting magic here }

This only works for guest virtual machines that are directly on the host. PowerShell Direct works in a cluster, but it can only bust through and connect to guest operating systems that are currently hosted on that node.

PowerShell Direct Benefits and Uses.

What are some scenarios where the PowerShell Direct capability is useful?

Firewalls, domain security policies, and network configurations. PowerShell Direct is great for anytime you don’t want to mess with firewalls, domain security policies, and network configurations that get in the way of connecting to your guest virtual machines. With Powershell Direct, you can basically push yourself through the barrier and communicate with the guest OS regardless of what policies are in place security wise. “Oh, is this port open?” “Oh, have I disabled the firewall?” “Oh, man, I didn’t reserve a management network interface card on this host.” All of these excuses go away with PowerShell Direct.

Correcting mistakes. You might have performed a configuration change over a regular PowerShell remoting session and inadvertently locked yourself and anyone else out of the virtual machine. With PowerShell Direct, as long as the guest operating system is booted, you can enter as a local administrator and fix the issue and restore access.

Configuring new virtual machine farms on a Hyper-V host. If you are a systems integrator or consultant, chances are you have a solution stack that you put together made up of the same hardware and software configurations, and you simply deploy it over and over again to different customers. Configuring Exchange, Remote Desktop Services, and SharePoint can only be so much fun, so you can put together PowerShell scripts to deploy each of those workloads on different virtual machines on your host, and you can simply execute them via PowerShell Direct — no messy agent or remoting required.

Status checks and state verification. Ever had a really big workload hosted as a guest virtual machine? You can use PowerShell Direct to execute simple queries to find out if a guest VM is done booting, if it is in a desired configuration, and to use desired state configuration to push or pull the correct configurations to get the guest operating system where it needs to be.

Give it a shot today in the Windows 10 and Windows Server 2016 technical preview.