Using Powershell for unattended installs

[Gandraw]

I would like to use Powershell for my unattended installs because of some useful features like XML parsing and WMI queries that are really painful to do in batch files. But then you run into a problem that Windows seems to dislike running unsigned ps1 scripts.

Now of course, you can fix that even in unattended installs by running

powershell Set-ExecutionPolicy RemoteSigned -force

in an administrator context in RunSynchronous at some point which will make the scripts run just fine.

But I'm wondering whether it's a good idea to just blanket-enable Powershell scripts. On one hand, I believe that there must have been a reason for Microsoft to disable them by default and I don't just want to go around that without considering the effects.

On the other hand, I really cannot imagine what that reason might be. Sure you can do all kinds of malicious stuff to the current user with scripts, but everything nasty you can do in Powershell you could also do in Batch or VBS files, which have none of the security measures. And UAC again applies to all these scripting languages the same way, so even if you switch the executionpolicy off you still cannot modify system files without UAC confirmation.

So I'm thinking the Powershell signing is just a feel-good measure required by some Microsoft manager that has no real-world usefulness.

Any thoughts about this?

[maxXPsoft]

same thoughts, but if you want then just set the ExecutionPolicy back to normal if you want after your done with it.

Set-ExecutionPolicy Default

Edited December 11, 2009 by maxXPsoft

[Monty Carter]

I would say that, mainly, it's the natural progression of IT and software in general. A big problem with pre-Vista Windows was that administrator access was either all or nothing. UAC is more than just a feel-good measure to reassure enterprise users; it has real-world use cases.

PowerShell is a much better scripting language, in my opinion, than VB and especially batch. Instead of going back and fixing everything in VB, they are pushing the new language.

HTTP got SSL v1, then SSL v2, then SSL v3. Internet Explorer, however, maintains support for the older versions of SSL, because too much is already utilizing the older versions, and there would be a lot of unhappy campers.

But, as maxXPsoft already mentioned, the simple solution is to disable it, and then as the last step in your PowerShell script, simply re-enable the default execution policy.

(By the way... The PowerShell execution policies are very similar to the different zones in Internet Explorer (that is, Internet, Intranet, and Trusted zones)... Here is a decent explanation on the issue: Configuring PowerShell Execution Policies

[MrJinje]

But I'm wondering whether it's a good idea to just blanket-enable Powershell scripts. On one hand, I believe that there must have been a reason for Microsoft to disable them by default and I don't just want to go around that without considering the effects.

Powershell is disabled by default so that people who do not know what Powershell is cannot claim Microsoft left a back door open (like VBS did), turning on Powershell usually requires someone who knows what they are doing.

So I'm thinking the Powershell signing is just a feel-good measure required by some Microsoft manager that has no real-world usefulness.

IMO Powershell signing is only useful in larger corporations who want better control over who can produce scripts in their environment.

Edited December 23, 2009 by MrJinje

[Monty Carter]

Gandraw, when you get PowerShell integrated into WinPE, will you let me know how it went? I really like PowerShell, but for WinPE, I have been mainly using a tool called WinBatch. I have been kind of interested in moving to PowerShell, because it is a more widespread tool, however, I thought there were .NET dependencies for PowerShell.

When you get PowerShell working within WinPE, will you let me know if there was anything additional you had to include in your WinPE boot image, as prerequisites for PowerShell?

I haven't really spent any time trying this myself, but I would be interested to know what is involved with integrating PowerShell into WinPE.

[cluberti]

Considering the heavy WinSxS requirement for .net, I'd be interested to hear if anyone gets .net (full or embedded/compact) to work in WinPE at all. Hopefully (soon) a version of WinPE will ship with .net support inbox, but if anyone gets it working it'd be quite a coup.

You could use this tool (nonfree), although you have to test your code because it's running without the framework, so interesting and undesired things may/can happen in that environment. There's also this "plugin" which was designed for WinPE 2005, and I've not heard of it working in WinPE 2.x or 3.0 (but it would be worth a try, I suppose). Otherwise, you could look into a custom PE like BartPE, which does have reports of .net working there with the previously linked plugin. Not sure how legal or supported it would be, of course.

Given Microsoft's desire that WinPE be locked down and minimalist, however, I can understand the lacking inclusion of powershell, .net, and a whole host of other things as it's meant as a deployment platform only (hence the name, Windows Preinstallation Environment, WinPE). I've gotten by with HTA/vbscript and jscript in a pinch, and a real C++ app when the need arose for something less ugly and more professional, as Microsoft suggests. Technically you can do a lot with script and HTA, and native executables aren't really needed by most. I'd still like .net in WinPE as it would make development for WinPE deployment apps easier and quicker, but it isn't a pre-requisite for doing so. Using C++ takes a little longer, but it does work and I can't really complain much about writing native code over managed code.

[MrJinje]

I probably posted this a few times in other places, but to use .NET from PE, one first needs to capture .NET 3.5 installation + Powershell installation (preferably from an XP machine) into a ThinApp.

Never saw the salamander linker program, that looks like it could work too.

But I do not think the OP is talking about Powershell from PE, more likely talking about Powershell during SetupComplete.cmd or FirstLogonCommands stages. (both are run under the full OS, not PE)

[CoffeeFiend]

I wouldn't necessarily call it a feel-good measure. Securing it was a good idea. There were already some people abusing it and it seemingly stopped that.

As for batch files, you can do some damage to the system if you have sufficient permissions, but making a self-replicating virus-like contraption in batch files would be quite a feat

vbscript/jscript is a lot more powerful, but again, you need permissions to do damage to the system, pretty much all AVs would find a vbs virus (much like the older VBA ones in MS Office docs), and you can also require those to be signed as well (by setting the scripting hosts' trust policy)