I ran up an instance of Windows Server 2012 in my test lab last night so I can play with various new features such as IPAM and PowerShell Web Access, etc.
Today I configured this box as the PowerShell Web Access (PSWA) gateway. I have to say, I am very very impressed! The implementation is easy, took me less than an hour (including time spent reading TechNet articles) and having ability to access PowerShell console on virtually any web browser for all Windows machines in my lab is just fantastic!
Now I can probably get away from using RDP most of the times since I’m pretty comfortable with PowerShell
So, here are the steps I took to setup PSWA:
Add the PSWA feature in Server Manager
Install PSWA web application using PowerShell:
Requested and installed a SSL certificate for the PSWA gateway machine from my Enterprise CA
In IIS, configured HTTPS for the default web site and used the SSL certificate I just installed from previous step.
Created an AD group called PSWA_Users and added few user IDs into this group.
Create PSWA Authorization Rule:
Add-PSWAAuthorizationRule -UserGroupName Corp\PSWA_Users -Computername * -ConfigurationName *
- Since I can’t guarantee that WinRM has been enabled and configured on every machine, I’ve created a GPO to enable WinRM and linked it to the domain root.
Now, PSWA is pretty much ready to go. I launch the web access console on Google Chrome and entered my credential and the computer that I wish to connect to:
And I’m in!
It’s great to see that Microsoft releases a web-based product that runs on browsers other than IE. I don’t think I’ve seen anything like this before!
I started testing by connecting to a SCOM management server and tried to retrieve all SCOM agents in my management group (Only 11 in total so I’d assume not huge amount of data is returned). I used:
$a = Get-SCOMAgent
Interestingly, it failed and the connection to the management server was closed:
Processing data for a remote command failed with the following error message: The WSMan provider host process did not return a proper response. A provider in the host process may have behaved improperly.
This reminded me the default setting for “Maximum amount of memory in MB per Shell” for WinRM, which I blogged previously in this post. The default setting on Windows Server 2008 R2 and Windows 7 is 150MB. This default setting has increased to 1024MB on Windows Server 2012 and Windows 8.
So to test, since I have 3 management servers in the OM12 management group, I’ve increased this setting to 1024 on another management server. It fixed the error:
To further prove this error is actually caused by not having enough memory for the remote shell, I’ve connected PSWA to a Windows 8 machine, which has OM12 console and command shell installed. I used the following commands to connect to the OM12 management group:
It prompted an error saying I don’t have sufficient permission:
This is by design, when using second hop in CredSSP, the credential has to be explicitly specified. so I changed the command to:
New-SCManagementGroupConnection OpsMgrMS03 –Credential (Get-Credential domain\MyID)
after entering the password, I was successfully connected and I managed to retrieve all SCOM agents by using Get-SCOMAgent Cmdlet without issues.
So to fix this issue once for all, I’ve modified the GPO I’ve just created and changed the “Maximum amount of memory in MB per Shell” setting to 1024.
Click here to see settings defined in my WinRM GPO.
I also configured another port forwarding rule on my ADSL router to forward port 443 to the PSWA gateway computer so I can connect when I’m not home.
PSWA on Mobile Devices:
I am able to launch and use PSWA on both my Android tablet (Samsung Galaxy Tab 10.1v running ICS) and my wife’s iPad 3 (running iOS 6) using both built-in browsers and Google Chrome on both devices.
Below are few screenshots from my Galaxy Tab:
Maybe it’s just me being an Apple noob, when I’m on the iPad, I could not find the Tab key on the keyboard, so I couldn’t use the PowerShell auto completion feature. – One more reason that I’m staying away from that product!
by default, the console size is 120x35, which seems like a waste of space when I’m on a big screen.
So I wrote a simple PowerShell script called Resize-Console.ps1 to resize the window:
$bufferSize = $Host.UI.RawUI.BufferSize
$buffersize.Width = 180
$host.UI.RawUI.BufferSize = $buffersize
$WindowSize = $host.UI.RawUI.WindowSize
$WindowSize.Width = 180
$WindowSize.Height = 40
$host.UI.RawUI.WindowSize = $WindowSize
After I ran this script, the console fits perfectly on my Galaxy tab (resolution 1280x800):
This console size also works great on my laptop, which has the resolution of 1366x768. For different resolutions, the width and height need to be adjusted in the script. the only catch is the buffersize cannot be less than the window size (I set the width for both sizes to be the same).
I haven’t managed to work out a automated way to resize the console as when in a PS remote session, there is no $profile so I can’t add scripts into $profile like we normally do on a local console. If I find a way in the future, I’ll post it here.
This is what I found so far. I’ll continue to blog on this topic if I find any other interesting stuff!
By the way, I followed this TechNet article to configure the PSWA: Deploy Windows PowerShell Web Access