Even Spiderman would envy this web action. Today we're going to walk through setting up a portable PowerShell v3 Web Access demo. Using this demo guide you can explore PowerShell from any web-capable device: your phone, your tablet, or your Raspberry Pi. The links in this post will guide you to all of the key documentation to build your own PowerShell Web Access lab.
Thanks to my buddy Bruce Adamczak for the picture above. Bruce snapped it while I was doing this demo for a customer in the field.
A couple weeks ago I was flying home from helping a customer get their Active directory healthy, and it dawned on me that I had everything I needed for a wow-factor PowerShell demo right there in my backpack. When I landed in Atlanta I put this demo together between flights. I was grinning ear-to-ear with my laptop, Surface, and Windows Phone sprawled out on one of those tiny airport waiting area seats. I know people thought I looked goofy… dude with a goatee grinning at his laptop and tablet and phone all at once.
One of my favorite Iron Man quotes is from the first movie when Obadiah Stane says, "Tony Stark was able to build this in a cave… with a box of scraps!" In other words, this demo will only take a few pieces to get rolling. And I’m not Tony Stark.
The demo consists of a domain controller VM and an IIS VM running on my laptop, both on an internal network. The IIS VM has another virtual network connection configured for the external network with a static IP at the upper end of the same IP range issued from DHCP on the WiFi access point. My phone and tablet are getting DHCP from the same WiFi access point. Technically we could put the DC on the same external network, but using a separate internal network would be more like reality where the web server has a reverse proxy to access internal resources. Here is a crude illustration: (Hey, I’m an engineer, not an artist.)
Here is all you need to get this going:
Any WiFi access point or router should do. Configure DHCP so that you have at least one extra address above the range. This extra address will be statically assigned to your IIS server external virtual NIC. I used the address 192.168.1.200.
You’ll need a 64 bit install of Windows 8. Most newer laptops have SLAT (second layer address translation) built in to support Client HyperV. Install HyperV from Windows Features. Use this post for setup instructions.
Technically you would only need one VM for this demo: a Windows Server 2012 install running Directory Services and IIS. Obviously that would never be recommended in a production environment. I have four VMs for more demo flexibility:
You can download evaluation installs here for your own free testing:
All of the VMs are joined to the test domain on the DC.
This is the tricky part. I'm not a HyperV expert, but I know enough to configure internal and external networks using the virtual switch (after I read the help). VMs on the internal network use the static addresses pictured in my crude illustration above. Then I can use Remote Desktop Connection Manager to RDP into each virtual server from the host laptop where I have a static IP configured on the internal bridge NIC. The RDP part is optional but convenient. Most folks will use the HyperV virtual machine connection to interact with the VMs.
On the web server VM I configured two NICs: one internal and one external. Inside the VM the internal NIC has the static 10.x.x.x address and the external NIC has the static 192.168.1.200 address.
Once you have built your IIS VM you can use this article from the PowerShell team to step through the PowerShell Web Access setup. I was surprised that this only took five minutes in my lab. They did a good job building the setup cmdlets to automate all of the IIS configuration. Call the site "pswa". Here is another link for more setup options. If you want the full textbook documentation it is on TechNet here.
Once you’ve walked through these links and ironed out the kinks you should have a working PowerShell Web Access lab. When you hit the URL you’ll get a page that looks like this. Note that I have filled in the credentials and target computer name.
By the way, you will likely get a security prompt in the browser that the web site’s certificate is invalid. You can safely ignore that, because we’re just using a test certificate in the lab. For Windows clients you may need to launch the browser as Administrator to bypass that warning.
After clicking the Sign In button you’ll get the PowerShell console. As they say in the movies, “I’m in!”
See this article for all of the tips on using the PowerShell Web Access console. You’ve got to try this from your phone. For example, most phone touch keyboards do not have a TAB key for doing TAB completion in the PowerShell console. That’s why we put the little TAB icon on the toolbar at the bottom. We also added up/down arrows for cycling through the command history.
A PFE peer of mine, Rick Sheikh, wrote a very thorough post recently on PowerShell Web Access. I would encourage you to read it for all of the possible configuration and security options you can tweak.
Now what? We’re in. Any way to add some “wow” to this demo? You bet.
Go watch this TechEd session with Travis and Hemant. Fast forward to the 52 minute mark where they discuss disconnected sessions and then transition to PowerShell Web Access. I posted a copy of these demo scripts when I spoke at TechMentor last autumn. (Thanks, Travis and Hemant!) Download the scripts, watch the video demo, and see if you can recreate the part at the end where they “pull a rabbit out of the hat” in the web session. That’s the wow, especially when you do it from your phone. I saved the commands into a demo.ps1 script to run from the phone instead of typing it all during a live demo.
When I do this demo for an audience here are the steps I take to utilize the lab:
As you might guess the setup will require some time on your part. It is not really that difficult, but there are a lot of steps. The fun part is all the learning along the way. And when you’re done it is quite impressive. Sometimes I run the lab on my home network so that I can use my Windows Phone or Surface to play with PowerShell from anywhere in the house. Yip. I’m a geek. And I bet you are, too, if you’re still reading at this point.
Now that you have a super-cool PowerShell Web Access lab what can you do with it? With over 2,400 cmdlets to explore and PowerShell under the covers of all the Windows server products the sky is the limit. Imagine the possibilities for remote administration now across all products and technologies with PowerShell from your phone or tablet.
Typing on the phone keyboard may be tedious, but when you’re offline at a family event it is much easier than driving into the office to take care of business. And that is why we created PowerShell Web Access. Time for some PowerShell web slinging. Enjoy!
If you would like to have me or another Microsoft PFE visit your company and assist with the ideas presented in this blog post, then contact your Microsoft Premier Technical Account Manager (TAM) for booking information.
For more information about becoming a Microsoft Premier customer email PremSale@microsoft.com. Tell them GoateePFE sent you.
Is 2008 or 2012 domain or forest level on the domain required for this to work?
There are no requirements for domain or forest functional level for this to work. The main thing is to have Windows Server 2012 for the IIS box to install PowerShell web access.
Thanks for the confirmation. What I was getting was an error when running Install-PswaWebApplication. It was stating that no webconfiguration could be found. Once I ran import-module webadministration the PSWA install finished successfully.
See this TechNet Edge video for a great demo of PowerShell web access across different non-Microsoft devices.
This is awesome!