Bookmark and Share

(Note: Today's Hey, Scripting Guy! Blog post was written by guest scripter, Tome Tanasovski. Tome is a manager of a team of server engineers in New York City. He is a Microsoft Certified Trainer who specializes in SQL Server, SharePoint, and VMWare. He is a contributor to the Windows PowerShell forum and the Hey, Scripting Guy! forum. Tome is a part-time blogger, and is currently organizing the inaugural meeting of a Windows PowerShell User Group in New York City. 

Tome also wrote yesterday's blog post about Office SharePoint remoting with Windows PowerShell 2.0 and WinRM. Thanks, Tome!)

----------

System administrators face many challenges. Whether it's finding the appropriate software solution for a new or existing problem or finding the appropriate level of caffeine for an all-nighter, each decision has effects which can be both good and bad. Have you ever gone with a piece of software that meets all your requirements only to learn three months later when the first problem occurs that it's nearly impossible to get support on the phone? When you do get them on the line, do you find out that you are the first customer to try to use that much data with their application? Have you ever tried a caffeine drink from a vitamin store? Sure, you're up for hours, but when you're shaking uncontrollably and your fingers hit the keyboard so hard that you start cracking plastic, you realize that you may not have thought this through completely.

We've all made very poor decisions while swimming our way through life, but unfortunately in the IT world, there is very little tolerance for error. Depending on the industry, each mistake could potentially cost your clients or company millions of dollars. So what's the best way to minimize these mistakes? How can I ensure that I've thought of every angle?

Write down your thoughts on a very publicly visited Web site for all the world to see and criticize, of course.

So, without further ado, let's discuss the good and bad about Windows PowerShell remoting to determine whether or not I'm going to enable it on all my servers as a standard. If you are new to the remoting world I suggest reading Ed Wilson’s article as a primer.

The Pros

Ease of administration

There's something to be said about launching a shell into a remote computer to quickly get a piece of information. I personally think the coolest thing in Windows PowerShell is the versatility of the Set-Location and Get-ChildItem cmdlets, which are so affectionately aliased by the comforting DOS names of cd and dir. Traversing the registry has become so much easier from a command line that I constantly use it instead of regedit. Now, open up that power to all of your computers from a single shell running from your workstation. Perhaps you need to verify that an Office Outlook COM add-in is installed on a workstation. What's easier than this?:

enter-PSSession wks1

cd HKLM:\SOFTWARE\Microsoft\Office\Outlook\Addins

dir

cd HKCU:\SOFTWARE\Microsoft\Office\Outlook\Addins

dir

 

While it was a rhetorical question I will answer it by saying, “Absolutely nothing is easier than that!”

You can run commands that are only designed to work locally

As a part-time SharePoint administrator and full-time SharePoint user, this was the most compelling reason for me to look at remoting. Though the concept could apply to other systems, SharePoint screams out to be abused this way. One of the limitations with the SharePoint object model is that your code must run locally on the SharePoint Web interface.

Here’s a sample script that loads the object model, connects to the SharePoint site, and adds a new entry to my main calendar:

$script = {

    [System.Reflection.Assembly]::LoadWithPartialName("Microsoft.Sharepoint")

    $site = New-Object Microsoft.SharePoint.SPSite("http://server1")

    $web = $site.OpenWeb("")

    $list = $web.Lists["Calendar"]

    $item = $list.Items.Add()

    $item["Title"] = "Listen to the Powerscripting Podcast"

    $item["Start Time"] = "Thursday, February 04, 2010 9:30:00 PM"

    $item["Location"] = "Live online!"

    $item.Update()

}

Invoke-Command -ComputerName server1 -scriptblock $script -Authentication Credssp

 

The following image shows the item added to the SharePoint calendar.

Image of SharePoint calendar item


Future management packs may require it

It is extremely important to note that Exchange 2010 requires remoting in order to use the management pack. When you load the Exchange shell on your workstation, it automatically gives you a remote shell to the nearest Exchange server. Is this the future of management packs? Though I haven’t read or heard anything that would suggest that this goes beyond Exchange, it stands to reason that this may be the preferred method for using Windows PowerShell on all future server products.

Run a script on multiple servers from one Invoke-Command cmdlet

This has amazing potential because it theoretically can change the way you approach scripting tasks to ensure that you take the easiest approach.

Certain cmdlets have their own interfaces to get information from remote computers. Take Get-WMIObject for example:

Get-WMIObject Win32_Service -Computername server1

 

This is a great interface for running a command on remote computers, but imagine a more complex process that checks if a service exists, stops that service, and then uninstalls it. To write that for a remote computer is difficult and may not even be possible. With remoting, you can write the script to do this task on your local computer, and then run this script via the Invoke-Command cmdlet on multiple computers:

Image of running script on multiple computers via the Invoke-Command cmdlet

 

Invoke-Command -ComputerName ("server1", "server2", "server3") -FilePath .\RemoveService.ps1

 

If you are aware that remoting is available in your environment, you can create a scripting strategy where you take the easy route in all cases while maintaining the flexibility to run your script on as many computers as you need to with very little effort. We use scripting languages to find the fastest solution to a problem. Using this strategy will only help that effort.

Import remote modules to your computer

After you’ve created a session on a remote computer and loaded the appropriate modules or snap-ins such as the ones provided with SQL Server or Exchange Server, you can run the Import-PSSession cmdlet to add those modules to your local shell:

$session = New-PSSession server1

Invoke-Command -session $session -scriptblock {import-module moduletoimport}

Import-PSSession $session

 

By running that code, you give yourself access to modules that you don’t even have installed on your computer. You can take this a step further and use the Export-PSSession cmdlet to create a module on your computer that will load from the remote computer when you import it. I recommend looking at this article for more information about using the Export-PSSession cmdlet this way.

The Cons

Remoting creates openings for an attacker to exploit

It’s a valid argument in a malware and virus infested world. With properly configured firewalls and a well-designed network with trusted computers, it’s a chance worth taking. There’s a reason we, as administrators, generally leave remote desktop connections enabled even though it too is a risk. If your computer is exposed to the Internet (in a DMZ), however, I think this argument must be acknowledged. I personally would never open a port that is not absolutely needed inbound on my firewalls.

WinRM requires a Web server to run on the server

The real problem with this is pretty much the same as the first point. People don’t want to run unnecessary services on their servers. You can configure WinRM to run under IIS if you are more comfortable or already have IIS running. You should review the installation and configuration document for WinRM. Even though the default settings enforce encryption, it is probably a good practice to spend the time getting SSL to work. You should also consider changing the default ports and possibly changing the default URL prefix.

Summary

While I’m not an expert in WinRM, I know enough about it from the documentation to say that the security risks in a well-designed network are negligible. The more common question you’ll get when trying to implement remoting as policy is, “What will it do for us?” I hope this article will give you some ammunition in that battle. By no means is this, however, the end of the discussion. Your input, the questions you have, and the questions you’ll get when trying to put this in place are what will help the rest decide whether or not we should be implementing it across the board, and whether or not it’s a battle worth fighting. Make sure to weigh in on the Windows PowerShell forum post that is discussing this topic.

I guess I can spill the beans now, and tell you that I have already used these arguments to win the “remoting” battle in my environment. I did it with decent documentation of the pros and cons.