Summary: Microsoft IIS MVP, Terri Donahue, talks about her path to upgrading to Windows PowerShell 4.0.
Microsoft Scripting Guy, Ed Wilson, is here. Welcome new guest blogger, Terri Donahue.
Microsoft IIS MVP, Terri Donahue is a systems administrator who has been supporting Internet Information Services (IIS) since version 4.0. Through the years, she has had extensive hands-on experience with many web servers including Lotus Domino, Apache, and of course, IIS. She has a passion for helping people solve technology-related problems. She is focusing on improving her Windows PowerShell skills. She regularly attends the Charlotte PowerShell User Group and volunteers at PowerShell Saturday in Charlotte.
Take it away, Terri...
Windows PowerShell 4.0 is backward-compatible with Windows PowerShell 3.0 and Windows PowerShell 2.0. This means that upgrading to Windows PowerShell 4.0 should not be governed by the necessity to maintain multiple versions of scripts for the different versions of Windows PowerShell. The decision should be determined by the new features that PowerShell 4.0 can provide. Windows PowerShell 2.0 brought us remoting, and Windows PowerShell 3.0 brought us IntelliSense and lots of new cmdlets. As everyone has heard, Desired State Configuration (DSC), is the biggest addition to Windows PowerShell 4.0.
However, there are more new features in Windows PowerShell 4.0 than DSC. The Save-Help cmdlet can come in very handy for downloading a local copy of Help for a given module or modules for use on a computer that doesn’t have Internet access. I imagine this will be a bigger plus than is originally realized—as the offline Web PI command-line utility has been.
One thing to note is that upgrading to Windows PowerShell 4.0 does not ensure that all the new cmdlets will work exactly the same on the upgraded systems. This is the same issue that I encountered when I installed Windows Framework 3.0 on Windows Server 2008 R2. A script that correctly queried a certificate property on my computer running Windows 8 (native Windows PowerShell 3.0) returned the same status code regardless of the setting of the property on a server that had been upgraded to WMF 3.0.
To ensure that it was an operating system dependency rather than an issue with the cmdlet, I used the old school method of querying with crypt32.dll rather than the Windows PowerShell cmdlet. Both methods had the same results on the upgraded server running Windows Server 2008 R2.
I am an administrator who hacks around at script, including Windows PowerShell writing, so being able to debug my script is a necessity. The debugger has also been enhanced in Windows PowerShell 4.0. It now allows for debugging a script running on a remote computer, and it even preserves the debugging session when the remote session is disconnected and later reconnected.
Based on my research, I decided to upgrade my servers running Windows Server 2012 and Windows Server 2008 R2 to Windows PowerShell 4.0.
On a computer running Windows 8.1, there are 548 cmdlets. On a server running Windows Server 2012 R2, there are 693 cmdlets. As you can see from the following table, the number of cmdlets is greatly reduced when you perform an upgrade to a given Windows PowerShell version on a different operating system compared to the native installation on a computer. Therefore, that should not be the driving factor behind deciding to upgrade.
Server version | Cmdlets with WMF 3.0 | Cmdlets with WMF 4.0 |
Windows Server 2008 R2 | 313 | 317 |
Windows Server 2012 | 440 | 444 |
Be sure to read and follow the steps to install WMF 4.0 on your given operating system. I had no problem on my server running Windows Server 2008 R2, but on the server running Windows Server 2012, I kept running into this error message:
Windows update could not be installed because of error 2148098050 "The certificate for the signer of the message is invalid or not found."
The fix was to download the correct installer, which to me was not apparent. The the selected check box next to the installer name in the following image shows the correct installer for Windows Server 2012:
The Windows8-RT naming convention was what threw me off. I kept trying to install the Windows6.1-KB2819745-x64.MultiPkg.msu package. In addition, I went so far as to install Windows Identity Foundation 3.5, which was referenced in many resolution articles—before I actually read the following steps in the release notes for Windows 2012:
Sometimes, even some of us nerdy types need to be reminded to RTFM!
After the upgrade, I decided to play around with DSC some because I hadn’t seen it in action nor tried it. There were some frustrations when I was trying to get it to work as documented on a couple sites that I tried. I could not get it to create the .mof file, regardless of what I did. I went through a couple steps on the server running Windows Server 2012, and that still did not help. For example, I installed IIS and many of the features that I wanted to set up using DSC. I then installed Windows PowerShell Desired State Configuration (thinking that was the missing piece).
The step that I had been missing was actually running the configuration from the Windows PowerShell ISE. This loaded the configuration in the session. This is the same as running a function to initialize it before use. This is a configuration that installs all of the features I use in my IIS setups to ensure that certain components are available and ready for use:
Configuration TestWebsite
{
param ($MachineName)
Node $MachineName
{
#Install the IIS Role
WindowsFeature IIS
{
Ensure = "Present"
Name = "Web-Server"
}
#Install ASP.NET 4.5
WindowsFeature ASP
{
Ensure = "Present"
Name = "Web-Asp-Net45"
}
#Install Request Monitor
WindowsFeature Request
{
Ensure = "Present"
Name = "Web-Request-Monitor"
}
#Install ODBC Logging - required for SMTP Server logging
WindowsFeature ODBC
{
Ensure = "Present"
Name = "Web-ODBC-Logging"
}
#Install Tracing - enables FRT
WindowsFeature Tracing
{
Ensure = "Present"
Name = "Web-HTTP-Tracing"
}
#Install ASP.Net 3.5
WindowsFeature ASP35
{
Ensure = "Present"
Name = "Web-ASP-Net"
}
}
}
As an explanation, each WindowsFeature designation installs the corresponding role or feature. This configuration installs the following features:
- IIS
- ASP.NET 4.5
- Request monitoring
- ODBC logging (which is required for the SMTP server)
- Failed request logging (which, in my opinion, is essential to ensure that you can accurately trace error messages to resolve issues on your IIS implementation)
- ASP.NET 3.5 to support any ASP.NET 2.0 applications that will be running on your IIS server
After entering this configuration in Windows PowerShell ISE, I saved the script as TestWebsite and then ran it. As shown in the following screenshots, the TestWebsite folder was created, and the .mof file was saved in it:
After you have initialized the configuration, you can run the Start-DscConfiguration cmdlet to implement the DSC configuration that you created earlier.
The Start-DscConfiguration cmdlet requires a path to the folder that houses the .mof file. The Force parameter ensures that the configuration runs and the Verbose parameter writes the output to the console. Because this configuration has already been run on my server running Windows Server 2012, the following information is returned:
After I figured out this little nugget, I decided to try the same thing on my server running Windows Server 2008 R2, which had only WMF 4.0 installed. As you can see from the following screenshot, I have no roles installed.
I pasted the configuration in the Windows PowerShell ISE and ran it to initialize it. I then ran TestWebsite –MachineNamelocalhost. This ran the configuration with localhost as the $Machinename parameter. As shown here, after this ran, there is a TestWebsite folder created in the My Documents folder that has a localhost.mof file in it:
On this server, without all of the other attempts to resolve false issues, the command ran as expected. The output shows each feature being installed as it runs in addition to the successful installation and the amount of time to install each feature:
As you can see here, all requested features have been successfully installed and are ready for use:
Because IIS administration is what I do, this makes it easy to ensuring that installations include features that I deem as necessary on any machine that has Windows PowerShell 4.0 installed.
I hope you find this post useful when you are evaluating whether you should upgrade an existing Windows PowerShell 3.0 implementation to Windows PowerShell 4.0.
~Terri
Thank you, Terri, for an interesting and most excellent article. Windows PowerShell Upgrade Week will continue tomorrow when I will have a guest post by Windows PowerShell MVP, Dave Wyatt.
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