Using PowerShell Remoting for Interactive Remote Shells
Almost anytime I teach a class, I ask how many admins in the room use Remote Desktop as a primary means of managing their servers. I'm often depressed by the result - last time, two-thirds of the room raised their hand. And I'm not talking about admins tasks that require console access - stuff like setting the IP address, which I understand is pretty much impractical to do remotely through any other means. I'm talking about day-to-day stuff, like creating users in Active Directory. "Why," I moaned, "don't you just use the AD console on your local machine?" Remote Desktop does put some additional overhead on your servers. After all, the server has to not only maintain a connection, but it also has to construct the entire graphical user environment, which takes up memory and CPU. Of course, most folks crank the user experience up to full, insisting on 24-bit color, the whole works. Sigh. One person's reasonable answer was "version mismatch." Many of their domain controllers are Win2008R2, and he couldn't get the R2 management tools running on his Windows XP workstation. Okay, fair enough - "but wouldn't you rather create and modify users from the command line?" I asked. "Of course!" they all said. This was a PowerShell class, after all! "But we can't install the AD module on our XP workstations, either!" Ah, but who cares?
September 14, 2010
Almost anytime I teach a class, I ask how many admins in the room use Remote Desktop as a primary means of managing their servers. I'm often depressed by the result - last time, two-thirds of the room raised their hand. And I'm not talking about admins tasks thatrequire console access - stuff like setting the IP address, which I understand is pretty much impractical to do remotely through any other means. I'm talking about day-to-day stuff, like creating users in Active Directory. "Why," I moaned, "don't you just use the AD console on your local machine?"
Remote Desktop does put some additional overhead on your servers. After all, the server has to not only maintain a connection, but it also has to construct the entire graphical user environment, which takes up memory and CPU. Of course, most folks crank the user experience up to full, insisting on 24-bit color, the whole works. Sigh. One person's reasonable answer was "version mismatch." Many of their domain controllers are Win2008R2, and he couldn't get the R2 management tools running on his Windows XP workstation. Okay, fair enough - "but wouldn't you rather create and modify users from the command line?" I asked. "Of course!" they all said. This was a PowerShell class, after all! "But we can't install the AD module on our XP workstations, either!"
Ah, but who cares? One day, I hope we'll install few, if any, admin tools on our desktops. Let the admin tools live on the servers, and let administration become a service that the server provides. But you don't need Remote Desktop: You just need PowerShell Remoting, a much lighter-weight, lower-overhead way of remotely controlling a server. Any server, by the way, all the way back to Win2003. Just make sure PowerShell v2 is installed (it comes with 2008R2). Log onto the server console one last time and run Enable-PSRemoting - you could also configure this globally through a GPO, if you preferred.
Once that's done, you can get a remote shell anytime you like - it's very similar to something like SSH, although under the hood it works quite differently.
Enter-PSSession -computername Server-R2
Will connect you to the server named Server-R2. That Enable-PSRemoting should have configured and started the Windows Remote Management (WinRM) service, as well as put the appropriate exception into the Windows Firewall, if you have it enabled. Provided you and the server are in the same (or trusting) domains, and that you ran PowerShell as a Domain Admin, you should be good to go. PowerShell's prompt will even change to let you know you're on a remote machine:
[SERVER-R2] PS C:>
Run whatever commands you like. You can import modules located on that server (like Import-Module ActiveDirectory) and use commands from those modules. When you're done, run:
Exit-PSSession
And you'll return home, close the connection, and be finished. GPO settings for "Windows Remote Shell" let you control the maximum number of connections a single admin can hold, amongst other settings, so you can finally control how much overhead you're willing to devote to remote administration. All of this works on any machine running PowerShell v2 - including WIndows XP - and you only have to run Enable-PSRemoting on the machines that need to accept incoming connections (although being able to "SSH" into your client computers can be tremendously useful, and I see a lot of folks enabling remoting on all of their computers).
There's a lot more you can do with PowerShell remoting, but this is probably the simplest, most straightforward place to start. If you'd like to learn a bit more, hop over to http://www.windowsitpro.com/blogs/PowerShellwithaPurpose/tabid/2248/entryid/13059/Default.aspx, where until September 30, 2010, you can download a longer article on remoting, view a demo video, and even provide some feedback to help shape the book that this article will become a part of.
About the Author
You May Also Like