« Linking a GPO using GPMC and PowerShell | Main | Path PowerLine »
PowerShell Portability
By Adam Bell | May 30, 2007
As we’ve seen there is a lot of product teams within Microsoft adopting PowerShell:
As people start to become aware of the power of PowerShell, we can see vendors starting looking to leverage this also:
Lists taken from PowerShell Home page
I can see that as each product team and vendor take up this new technology they are going to create their own cmdlets to make administration tasks easier. Now I think this is a good thing, the adoption, creating tools to make life easier. However I see a problem that could arise from this.
We are going to see the PowerShell landscape changing from machine to machine depending on what products are installed. Are we going to start seeing scripts fail because they have been written with cmdlet dependencies?
So what’s the solution to this? Should cmdlets be deployed as addons to all PowerShell installations to keep the landscape uniform? What would be the impact on this?
If I’m on a non-exchange 2007 server, and I have the exchange cmdlets installed should they work regardless, so long as they can reach the exchange server in question?
Or is the solution to have our scripts smarter, and exit nicely when the cmdlet isn’t available? This still leaves us with a fractured landscape, and I can see as more products adopt PowerShell a larger difference from installation to installation. Or am I just looking at this all wrong?
- None Found
Topics: PowerShell | 6 Comments »
June 1st, 2007 at 18:09
So basically, we need some kind of “apt get” system for PowerShell, or at the very least, CPAN.
I totally agree.
June 1st, 2007 at 20:52
Hi Peter,
I think what you’re talking about there are mechanisms for maintaining a consistent landscape. So if I wanted to put the Exchange cmdlets onto a non-exchange machine I could do so easily: “apt-get -install exchange-cmdlets” type scenario.
Now you’ll have to excuse me as I have had little to do with any cmdlets yet (my work environment is touchy about this), so I know my exchange example is probably flawed in this case.
But what I’m questioning is the cmdlets themselves. Is the way they are being authored flawed from a design perspective? Is the fact that we can’t install them on every machine PowerShell is deployed to a mistake? My initial feeling is that the answer to this is yes.
From an administration perspective I’d like my scripts to “work” from any PowerShell environment without having to worry that I’m not on a machine with System Center installed, or a DC with the Quest cmdlets available.
Thanks for the comment, it’s good to hear other peoples thoughts!
Cheers
Adam
June 1st, 2007 at 21:18
In an effort to raise some visibility on this subject I have submitted a suggestion over at MS connect.
I believe there is a voting system in place so if anyone feels this worthy of some attention please feel free to visit connect and vote, or of course join the conversation here. :)
Cheers
Adam
July 20th, 2007 at 12:19
Our company uses a global read only repository for a large amount of the applications used today. For example we have Perl deployed via this means and all the supported libraries. We can simple add the next version of Perl and all the libraries that have been tested agianst the newe version. Then people simple load up that version of perl and use it whereever they are in the world.
Using domain DFS this is a simple setup for most companies (replication technology aside) and offers a lot of control and flexanbility to our users.
Nothing new, yet Windows is still a very HOST centric OS, or should I say windows developers have remained HOST specific.
Could we do this with powershell and its miriad of cmdlets?
Should we be able to do this?
If you have 10′s of thousands of hosts central stores are a gift to an administrator who can run scripts anywhere knowing what they need is at the end of one path globaly.
Imagine updating powershell to 1.1 by simply deploying it and changing a Link to use the new version! why should life not be this easy???
August 13th, 2007 at 14:47
Personally, I was impressed by what have been made to Microsoft’s Transporter Suite 2007 to deliver a smooth migration from the domino. Interesting thing there was that they used powershell layer to implemenent some oversurface operations.
November 2nd, 2007 at 06:54
[...] Like MSI, how do you deploy PowerShell out in your environment? and 2) How do you manage your PowerShell landscape of [...]