I recently went through a small discussion about enabling powershell remoting in my organization. Fortunately, I have the pull to make it policy in my company, but I think it's a topic worth discussing.... how to win the war to enable remoting? I think the easiest way is to prove its usefulness, but what's the best way to do that? I did a quick google search to see if there were any other topics or articles out there that discuss this, but did not see any.This topic came up because of another thread that solved the limitation of the Sharepoint objects in 2007 by enabling Powershell Remoting. 2007 requires you to run all programming objects on the Sharepoint server itself. This seems like a perfect use, but what others are there? I'd love to hear more places where people are using remoting, and the reasons they had to resort to this method. I think hearing these cases will help everyone see exactly why they need or don't need to enable remoting as policy in their organizations.
Well, one of the roadblocks is to make people feel more comfortable when saying that it requires "a web server on the server-end". You can configure IIS to accept the WS-MAN calls, but by default, from my understanding, the kernel-based HTTP.sys is what is used as the server components for WinRM.
Another good use is the ability to use Import-PsSession. Think Exchange 2010 which supports v2. You no longer need to install the E2010 admin tools on all your clients. With v2 on the client and server, you can easily "import" all the E2010 cmdlets to your local system, and use them for E2010 administration just like being on the server. Hopefully more server-based products will support v2 in their v.Next release.
This is a topic i've been thinking about recently, as unfortunately I don't have the clout to make this policy, but am in the position of having my life made much easier if this was enabled on mass. As such, i look forward to any further dialog on the subject...
So far a strong argument internally has been that enabling PS remoting has the nice side effect of allowing the Remote Server manager snappin to function. That argument only really works though in our org as we are lucky enough to have Windows 7 desktops in IT and therefore can make use of this wonderful feature remotely.
Most of the negative reactions i've seen to this concept seems to be based around two camps :
Camp Security - who are concerned either that it's simply another attack vector, or that you can affect that many systems at once. On the latter point i remind them that one badly placed GPO or advertisement in SMS/CCM can cause just as much havoc, yet those systems are in widespread use.
Camp Unaware - people who either don't know about the kind of benefits that remoting can bring, or don't believe in Powershell full stop. Often this camp is open to being proved wrong if you can demonstrate that "Killer" application.
Going back to the original post - I recently used the ServerManager module to install (and then configure) some missing features on all of our IIS 7 boxes to bring them up to a standard configuration. I'm sure we can all do the math on how long it would take to do that on 20+ servers manually...
I definitly agree with Marco on the point of Import-PsSession. It's amazing how many snappins, admin tools and consoles you wind up with installed on your local box to make remote administration a feasable working scenario. Knowing that you can work effectivly from any machine that has v2 installed is definitly a plus.
So, I've been quiet on this thread..... That's because I've been busy stealing your ideas to put together an article that was just published on the Hey Scripting Guy! Blog. I linked to this thread so you can get credit where it's due, and so that we can maybe inspire others to talk about issues we haven't thought of.To summarize the other benefits of remoting that we haven't brought up in this thread yet:
- Ease of administration
- Future management packs may require it - Like the Exchange 2010 cmdlets
- Create an organizational scripting strategy to design all scripts to run locally while having the flexibility to use them on multiple computers from one invoke-command