Windows – Best way to deploy Powershell 4.0 on Windows 7 sp1 and server 2008

There is no "right" answer here. My personal preference would be use Group Policy for settings/policies, but for application deployment use PowerShell (or even legacy WSH scripts or batch files), assuming you have a single domain with no complex trust issues. However, there are tradeoffs. Doing everything in PowerShell is certainly legal.

Application Deployment (GPO vs Script):

With GPO based software deployment, you are limited to MSI packages. This can be annoying for products that are not distributed via MSI (e.g. setup.exe). In that case, you have to package it up as an MSI. Enjoy Adobe Reader's MSI+MSP distribution (gotta make an AIP). If you need to customize the install, you need to mess with MSI transforms. Something that could be a single line in a script can become a complicated multi-step process.

When everything you are deploying is readily available as an MSI, and you can install it with no special customizations, GPO deployment is pretty smooth. You can use WMI targeting and automatically uninstall stuff that is out of policy. But as soon as you step out of the confines of that box, things get more complicated. Also, when something does go wrong, it can be difficult to figure out what happened from the Event Viewer.

With a script, you can install or uninstall pretty much anything, MSI, EXE, whatever. If you need to do some cleanup work before installing (e.g. purging old registry keys from a previous version that did not uninstall cleanly), you can do it. If something goes wrong, you can add as much debug/retry/workaround code as you need, and you can run msixec with logging enabled.

You script will generally need some conditional logic to check if the software is already installed (and what version), and then invoke the installer if needed. If you do not have a programming background, this can be intimidating. It is no longer a point-and-click solution. There is also more opportunity for you to screw something up since you wrote it yourself.

We switched from GPO to PowerShell for our application deployment, and it made things a lot easier. When a new version comes out, all we need to do is drop the new installer files in our AppDeployment share and update the $expected_version variable in our script. Takes like 1/10th the time.

You can also do a hybrid approach where you use GPO for MSI stuff and scripts for everything else. I am not a fan of this because I like to have one place to go to see what is installed.

Note that with Group Policy, application deployment does not happen until a reboot. If you are using Startup Scripts, this is also true. However if you use PowerShell Remoting or a Scheduled Task you might be able to pull it off without a reboot (could get messy though).

Settings and Configuration (GPO vs Script):

Group Policy Preferences is really simple to use to do things like create registry values, map network drives, create shortcuts, etc. The fact that Group Policy has background refresh is slick because you can apply settings without forcing users to reboot. Item level targeting gives you a lot of flexibility (and this is in addition to the WMI and Security filtering at the GPO level).

However, Group Policy Preferences is far from perfect. Some of my peeves:

1. There are way too many methods to manage Internet Explorer, some of them deprecated, some don't work with the latest IE. I always end up just managing the registry settings directly.

2. Random Errors in the Event Viewer that are stupid. Example: I created an item to delete a Scheduled Task. Great, it's gone from all my workstations. Now the Event Viewer starts filling with Errors "I couldn't delete the task because it doesn't exist". Duh!

3. Apply Once and do not Reapply will screw you at least once in your career.

4. Update vs Replace. Pay attention because you will probably pick the wrong one.

5. There are limits to what you can do with Item Level Targeting. If you need a for() loop or string manipulation (trim characters, adjust case), you will be back to a script.

6. GPP file operations always happen, even if the files has not been changed. Your workstations will keep copying the same file off of the server over and over again, even if they don't need it. This can unexpectedly hammer your server and network. Item level targeting can help mitigate this, but watch if you have the Remove if Not Applied checked.

7. Many of the GPP Errors in the Event Viewer contain no useful information to actually fix the problem. You have to turn on tracing.

You can use PowerShell for settings, but it has some drawbacks too:

1. Managing registry settings with PowerShell gets messy (at least with the native Registry provider). In my opinion Microsoft screwed up when they made registry values "properties" instead of actual items. It makes things way more complex than it needs to be. You need a bunch of conditional logic to test for the registry keys and create them before you create the values. Group Policy is much simpler in this area.

2. There are a lot of "basic" sysadmin tasks that you cannot do natively in PowerShell (e.g. creating a shortcut, managing a scheduled task). You have to invoke Wsh, the .Net Framework, or use a third party module.

3. Scripts run at startup/logon only. No background refresh (unless you setup a Scheduled Task).

4. If you have to call legacy Window commands utilities (net.exe, schtasks.exe), it can be tricky to call the command, and even more "tricky" to get its screen output to play nicely with PowerShell's output. You may have a command that fails and you don't know it.

Some other general comments on scripts (PowerShell or otherwise) vs GPO:

1. Scripts are pretty much programming projects. The code will grow and become more complex over time. If you do not treat it like a "real" programming project, with comments, version history, subroutines, etc, it will grow into an unmaintainable mess that your successor will end up scrapping because he didn't understand it.

2. Sysadmins are (generally) not programmers. They don't know proper programming disciplines (see point #1). Even well-structured code can be intimidating and unreadable for an admin with no programming background. Be mindful of the skillset of your current and future staff.

3. Scripts have an advantage in that they can be checked into version control and diffed. With GPOs this is a little harder to do.

4. Scripts are easier to copy onto a USB key and take with you. That was probably the case for your contractor. He probably had some existing scripts from previous projects that he was able to recycle for your project. In my environment I have two networks that are air-gapped (don't ask), but have similar configurations, so we use PowerShell scripts wherever possible so we can re-cycle code between the two networks.

5. GPOs have an advantage in that you can use tools like RSoP to get a report of all settings applied to a particular workstation/user. This can be important for auditing and troubleshooting.

6. GPOs are more "discoverable". I can come into an unfamiliar environment and pretty quickly get up to speed on what policies and settings are applied. With a script, I have to start studying code and hope it is well commented.

7. PowerShell Remoting can be really handy for a one-off command that you want to run on a bunch of systems, and you don't want it to be a "permanent" policy (e.g. everybody delete this one temp file).

Regardless of the approach you use, make sure things are well-documented. You should be documenting things at the micro-level ("Implemented setting x for all accounting workstations to resolve problem with application y"), and also at the macro-level ("All of our workstation settings are stored in the GPO called x").

FOLLOW-UP EDIT: PowerShell 4 adds a new feature called Desired State Configuration. This looks like it can be used to achieve some of what Group Policy Preferences does. It could be a game changer. Have not worked with it yet but it looks really cool.

FOLLOW-UP EDIT 2: One thing I realized is that I did not properly differentiate between Group Policy Policies vs Preferences. Preferences are pretty much analogous to a PowerShell script. Policies are a little more "rigid", and are trickier to implement in a script. To do so, you have to have your script populate HKLM\Software\Policies, but you have to be mindful of collisions with GPOs. In that case, do one or the other, not both.

See this documentation from Microsoft:

https://docs.microsoft.com/en-us/powershell/scripting/setup/installing-windows-powershell?view=powershell-5.1

In the "Upgrading existing Windows Powershell" section, it says specifically:

The installation package for PowerShell comes inside a WMF installer. The version of the WMF installer matches the version of PowerShell; there's no stand alone installer for Windows PowerShell.

I think this is the answer guys. Run $PSVersionTable.PSVersion to get the version.