Practical Reasons for Upgrading to PowerShell 4.0
Summary: Guest blogger and Windows PowerShell MVP, Jeff Wouters, provides several practical reasons for upgrading to Windows PowerShell 4.0. Microsoft Scripting Guy, Ed Wilson, is here. Today we continue our “Why Upgrade to Windows PowerShell 4.0” series with a guest blog post written by Jeff Wouters. Jeff is a Windows PowerShell MVP in the Netherlands, and he is a cofounder of the Dutch PowerShell User Group. Not only that, he is a great guy and a good friend to the Scripting Wife and me. Take it away Jeff… When you are considering upgrading to a new version of Windows PowerShell and remaining on the same operating system version, keep in mind that some products only work with specific versions of Windows PowerShell. When Windows PowerShell 3.0 came out, some people were installing it on many of their systems, and “suddenly” applications such as SQL Server, Sharepoint, and Exchange stopped working properly. This has a main technological explanation and a reason—which, in this case, are not the same.
History 101
The main technological explanation is that in Windows PowerShell 2.0, Microsoft was using the common language runtime (CLR), and in Windows PowerShell 3.0, they switched to using the dynamic language runtime (DLR). These are two fundamentally different technologies! The CLR is the core set of services offered by the .NET Framework, such as a type system and a garbage collector. The DLR is built on the CLR, and it offers services for dynamic languages (such as dynamic types, dynamic method dispatching, and code generation).
The reason is that the people who installed Windows PowerShell 3.0 on those systems didn’t RTFM (read the f*ck*ng manual). The manuals for the applications that broke clearly stated that they were supported on Windows PowerShell 2.0. So those issues could have been avoided with some proper testing. The lesson is: Don’t introduce new software directly into your production environment—test it first.
Practical implementation
Here’s a common scenario that I also use: Upgrade your laptop, desktop, or server from where you run your scripts. Here you can use the full benefits of the latest and greatest release of Windows PowerShell. Then inside the scripts you’re running, use Windows PowerShell remoting to accomplish your tasks on specific endpoints. You don’t have to upgrade the Windows PowerShell versions on those endpoints, and therefore, you won’t break any applications that are installed. That was a little history and practical information… now let’s go to the good stuff: Windows PowerShell 4.0.
Why upgrade?
Why should you upgrade? I’ll discuss some new features and enhancements that have been most important for me, and let you make up your own mind.
Desired State Configuration
To define the state of a type of server in a text file and let the server configure itself based on that definition, simply point the server to that definition and let it do the rest. For example, verify the configuration every XX minutes, and if the configuration doesn’t match the definition, let the server correct itself. Because the definition is simply a text file, you can put versioning on it. There is no longer a need to give a lot of people local administrator rights on servers. Instead, edit the text file and wait for the server to compare itself again to the definition. That’s Desired State Configuration in Windows PowerShell, and what you can accomplish with it!
Workflow
Natively, Windows PowerShell does its tasks in sequence: 1 -> 2 -> 3 -> 4 ->…
Windows PowerShell Workflow is built on Windows Workflows, and it allows you to run tasks in parallel. For me, this has been very useful when running tasks across multiple endpoints. For example, I had a deployment script with 25+ separate tasks. The execution time went from 50+ minutes to about 20.
Now that’s what I like!
Get-FileHash
This new cmdlet returns a file hash in one of several formats for a specified file. It is very useful if you want to know if two files are different. It doesn’t compare the content of the file, but by comparing the hashes of two files, you can easily tell if the files are different.
RunNow parameter for scheduled jobs
Scheduled jobs were introduced in Windows PowerShell 3.0. However, when you created a new scheduled job and wanted it to start immediately, you had to define an immediate starting date and time for the job. In Windows PowerShell 4.0, there is a new parameter for the Register-ScheduledJob and Set-ScheduledJob cmdlets: –RunNow. This allows you to (guess what?)—run the scheduled job now!
RepeatIndefinetely
This parameter has been added to the New-JobTrigger and Set-JobTrigger cmdlets. Previously, you needed to specify a TimeSpan.MaxValue for the RepetitionDuration parameter to run a scheduled job for an indefinite period. The RepeatIndefinetely parameter has made this easier.
Get-Process shows user name
The Get-Process cmdlet now shows a IncludeUserName property. So now it’s rather easy to figure out who is running that process on a device or Remote Desktop Server!
DefaultCommandPrefix
Whenever the DefaultCommandPrefix is used in a module manifest in Windows PowerShell 4.0, the ExportedCommands property of the module shows the command in the module with the prefix. When you run the commands by using the module-qualified syntax, the command names must include the syntax. Useful, right? If you don’t know why you should use a command prefix… This makes your command unique and chances of having command name conflicts become smaller. A prefix usually consists of 2 or 3 characters. Think about these enhancements, investigate what else is new in Windows PowerShell 4.0, and draw your own conclusions! ~Jeff Thanks, Jeff! Why Upgrade to Windows PowerShell Week will continue tomorrow. I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.
Ed Wilson, Microsoft Scripting Guy
Light
Dark
0 comments