PowerShell Web Access: Testing
We’re back with our in-depth, multi-part look at PowerShell Web Access (PSWA). In the first article I showed how to install PowerShell Web Access remotely on a new web server from a Windows 8 client running Remote Server Administration Tools (RSAT). In part two, I discussed PSWA configuration. In the final article we’ll reconfigure PowerShell Web Access for use in the domain.
How to Test the PSWA Application
First, I’ll open Internet Explorer and go to https://chi-web01/pswa. (Don’t forget to use https.) My web server is CHI-WEB01. I can use the name or IP address. Because I’m using a test certificate I’ll get a security warning in Figure 1.
Say Goodbye to Traditional PC Lifecycle Management
Traditional IT tools, including Microsoft SCCM, Ghost Solution Suite, and KACE, often require considerable custom configurations by T3 technicians (an expensive and often elusive IT resource) to enable management of a hybrid onsite + remote workforce. In many cases, even with the best resources, organizations are finding that these on-premise tools simply cannot support remote endpoints consistently and reliably due to infrastructure limitations.
I’ll continue since this is just a test. This leads to the logon screen as shown below in Figure 2. I’ll fill in my logon information.
Figure 3 also shows optional connection settings. These are the same type of settings you might set with New-PSSession.
For now, I’ll use the defaults. Clicking Sign in brings me to a PowerShell session inside the browser!
From here I can enter just about any command I want.
Click the History arrow to access you command history. Use standard browser short cuts, such as Ctrl+. to increase or decrease the font size.
Now, you might think you could open a new tab and start another session, but as you can see below in Figure 6, that isn’t allowed.
The explanation screen pretty much says it all. But now to the crazy fun stuff. You can connect to the PSWA gateway from anything with a compatible browser. Figure 7 shows the logon screen using Chrome on my Android-based phone via a WiFi connection.
Because I’m still using a test certificate, I was prompted about a potential security hazard. Once you use a valid certificate on the web server you will need to find a way to deploy it to your non-domain devices or live with the browser warnings.
Here in Figure 8 I’m connecting on an HP Touchpad running Cyanogenmod 9, again using Google Chrome.
Notice I’m connecting via IP address. I also did that on my phone. Depending on configuration for these non-PC devices you can use either the web server name or its IP address. Figure 9 depicts a logged on session on the tablet.
If you will be using devices-like tablets, take time to learn cmdlet aliases. Typing on phones and tablets can get tedious, so you definitely want to take advantage of as many keyboard shortcuts as you can.
To end your session you can type Exit and hit Enter, or click the Sign Out.
The last item to test is for unauthorized entry. My test rule only allows Globomantics\Jeff to logon. Even if I use the Administrator account, PSWA refuses access as you can see in Figure 10.
PowerShell Web Access Limitations
The web-based PowerShell console is not without limitations. First, this is only a console. You cannot run graphical applications such as the PowerShell ISE or Notepad. Remember, this is really nothing more than a typical remoting session except it is displayed in the web browser, so you don’t have a profile script. You can run command line tools like Ping and Netstat, but nothing interactive like nslookup or netsh.
Finally, there isn’t any way to save this session and re-enter it later. Using PSWA is the same thing as using New-PSSession, so once you close the session anything you created, such as jobs or variables, are gone.
Once you have configured PSWA all you need is a web browser pointed to https://<web server name>/pswa. You can connect via name or IP address. Once connected, the remoting session is shown in the browser window. The browser can be on a PC, phone, or tablet, and you don’t even need Windows or PowerShell, which is what really makes this feature “PowerShell Web Access Anywhere.”
In the next (and last) installation of this PowerShell Web Access series, we’ll reconfigure PSWA for use in the domain.