I've just installed the RC of the re-named PowerShell (Monad, MSH, etc). To upgrade, you need to de-install the older version of MSH and install the new version of PowerShell. But there are some changes that took a while to work out. If you know MSH and are about to upgrade, there are some changes you need to know about as they may impact you!
First, the name of the exe has changed as has its location in %programfiles%. The target of your shortcut has changed to "%programfile%\Windows PowerShell\v1.0\powershell.exe" (NB: there's a space between the Windows and Powershell.
The first time you run PowerShell, you get the sadly now standard "security" warnings due to the "secure" default setting of Powershell's Execution Policy. The location in the registry where PowerShell stores its policy settings (and where most admins are going to want to change the Execution Policy to Unrestricted) has also changed. The registry key is now: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell. It would also appear that UnRestricted is not quite Unrestricted - every time I run a script off of my Intranet, I get asked if it's OK. YUCK!
Another minor annoyance is that the extension for Powerscript scripts has changed to ps1. What the heck is this name - clearly the markeing droids were on overtime when these names were invented! If you try to run an old MSH script,eg fix.msh, the OS just pops up in the text editor (not quite what was wanted). But a quick rename of my scripts got them working again.
Monad wraps .NET objects with additional properties. These names began with MSH, but now begin with PS. Also, somecmdlet names are different - New-Drive becomes New-PSDrive. If you have used these properties in your scripts you need to change the names - this took some careful editing in my case, but was not a hard problem!
As with earlier versions of Monad, PowerShell has a default profile script that is run at startup. The name of this script is held in the variable $profile. This means you should be able to type Notepad $profile to edit this default script. Well you would if the folders that are pointed to, or the file itself,were actually created by the installation program (as once was the case). The setup routine is distinctly admin hostile. Sadly.
All this means most of my more complex scripts no longer work without modification and setupp/installation takes much more time to setup than should be necessary. Fortunately, the changes are minor, but I'm annoyed at the extra unnecessary work needed. Some of the changes were always going to be necessary - that's a price I'm willing to pay as an early adopter. But some of the work (setting up $profile, making un-restricted mean what I say it means, etc) just seem to be throwing road blocks in the way without good reason.
Allegedly, this stuff is due to "security". However, this level of "security" is just plain overkill in my view. It also ruins the first experience for a new admin since it's just harder than it needs to be in order to get things up and running (and even then why doesn't "unrestricted" actually mean UN-RESTRICTED??). This approach just tends to reinforce bad habits and something to be exploited by social engineering. For example, I run a bunch of scripts off of a remote machine in my intranet - on a mapped X: and M: Drive. These scripts examine files in these mapped drives and print important statistics. Every time I run these remote scripts with PowerShell it asks me for permission to run them (this despite an UnRestricted Execution Policy). Thie means I have to type "r" to run the script, something I find my self doing this without thinking. Due to overuse, the value of this warning is lost and is open to social engineering. This is the same issue plaguging UAC in the latest builds of Vista.
At the end of the day and despite the utterly naff name, I love the product. I love the underpinnings and what you can do with it. But this approach to security is just plain dumb.
No comments:
Post a Comment