How to use PowerShell and PowerShell modules in the enterprise

Question

Recently, I\'ve joined the Windows team in my enterprise and with my developer background (Java, .NET and Web in general), I was pretty quickly interested in PowerShell. I can s

Answer 1

Let's cover each issue by category.

Evangelism

To start off interest in PowerShell to your coworkers, I would suggest starting off with the bread and butter of automation. Find a common pain point that is relatively easy to implement (to get something out there in front of your coworkers quickly) and automate it with PowerShell. Then expand from there.

Another good idea is to start a "Script Club" at your office where you do some training and share ideas or problems about scripting in PowerShell. You can start out with once every few weeks and see how it goes. At my work, we have a book club where we go through various technical books on testing, design, and programming, it works well.

Packaging

• Modules - PowerShell modules are the best form of packaging. They are quite easy to use and offer some nice features such as easy deployment and private variables/functions.
• Scripts - Scripts are a good idea for work-in-progress or to start off since your coworkers will certainly be comfortable with scripts.

Deployment

There are a few options currently for deployment.

• Deploy to every machine - This could avoid some network issues and gives you more flexibility with each machine, but the downside is that updating modules may be more of a pain.
• Central repository (a.k.a. a network share) - You could also store all your modules on a central network share. This would avoid issues with deploying to every machine and you can make the modules read-only if you want to control modifications. But you would still have to deploy a profile to each machine to add the network share to the $env:PSModulePath variable. It would be best to set this in the all-users-all-hosts profile. From then on you shouldn't need to update it unless the path changes.
• NuGet - NuGet is an open source project that is bringing package management to .NET development. What is nice about it is the ability to have public repositories and local/private repositories. There is already an initial version of a PowerShell module that will leverage NuGet for PowerShell module deployment.

Remote Access

Being a build engineer, I have relatively few machines and full control over them. So I have remoting enabled. You would have to ask some IT guys for better advice.