PowerShell - Distributed Solution

Question

I'm new to PS so I may get some of the terminology wrong.

If you want to roll out a custom PowerShell environment (snap-in) for a team of 30 developers/DBAs. What is the best way to do this... if you intend to be rolling out new functionality once a week? Does PowerShell 2.0 help in this regards?

Assumption:
There is no issue with everyone on the team installing PowerShell (v1 or v2)

Update: Also see Jeffrey Snover's answer about v2 below.

Bostic

Answer 1

It will depend to a certain extent on the sort of functionality changes that you intend to do. For our environment, we roll out a pretty standard PS install then add one line to everyone's profile to run a script from a shared folder on a server. Then in that script I can do whatever customization that I want to have applied to everyone.

We add the line to the machine specific MS profile (the one in %Windir%) this was an intentional choice. We do it that way so that the users essentially only get this on their production boxes. That way when they write something they can quickly log into a test box and run the script to make sure that the script will deploy without nay dependencies on these customizations.

Currently the customizations are pretty mundane. Mostly just some added functions and aliases. I also have a logger that I wrote in C# specifically for powershell so it loads that up from the dll that is in that same network folder.

Because I play around with my environment so much, I have this in my profile :)

$ProfileDir = ([System.IO.Directory]::GetParent($profile)).FullName
$localMSProfile = "$PShome\Microsoft.Powershell_profile.ps1"
$localAllProfile = "$PShome\profile.ps1"
$userAllProfile = "$ProfileDir\profile.ps1"
$userMSProfile = "$ProfileDir\Microsoft.Powershell_profile.ps1"
$allProfiles = ($localAllProfile, $localMSProfile, $userAllProfile, $userMSProfile)

Digged

+ 1. Cool approach. Can you elaborate a little? When you say profile are you talking about the Window's login profile? Can you talk a little bit more about the customizations that you are doing and how? aliasing? adding cmdlets? snap-ins? This may give me some ideas. – Bostic

Lee Holmes explains the profiles and their locations very well. leeholmes.com/blog/… – Irritating

Answer 2

This is why we added MODULE support in PowerShell V2 - it is the easiest mechanism to xcopy deploy sets of functions. The Module documentation is pretty light at this point but should be much better in a month or two.

Experiment! Enjoy! Engage!

Jeffrey Snover [MSFT] Windows Management Partner Architect

Capon

Thanks I'll check this out. Its so funny that you chose to answer my question... I've been watching all your old Powershell videos on Channel 9 this weekend. Great stuff. – Bostic

Answer 3

If you are rolling out a new version of the snap-in weekly, switching version probably won't help with that part of things. However, you'll be developing on a newer platform, with the advantage of the extended functionality that comes with it.

As already suggested some scripts could ease the deployment pain to the point where you have to do nothing but maintain those scripts correctly and keep producing new builds.

Record