Powershell.com’s Tip Of The Day–Avoid Use Of Set-StrictMode In Production? No Way!

I appreciate the Powershell tips from Powershell.com.

But the Monday, 3/21/11 tip recommends avoiding the use of Set-StrictMode “latest” in production, and I think that’s bad advice.  Here’s a quote from the tip:

However, Set-StrictMode should only be used on development machines. You should never use it on production machines or in production scripts as PowerShell will not complain about non-existing properties. Have a look:

Dir $env:windir | Where-Object { $_.Length -gt 1MB }

Read the rest of this entry »

Scripting IIS7 Application Pool Configuration in Powershell

I knew that scripting the configuration of a whole environment seemed the right thing to do.  But when we were building up our testing and production environments I was new to some of the technology and we were in a hurry and…you know the rest.  I only did the easy parts.  But now we’re looking at some changes that will require a ground-up reinstall/configuration of our web and application servers.  This time around I’m going to script much more, I hope, subject to time constraints I can’t control.  Today’s topic:  IIS7 application pools.

Incidentally, for a good argument for scripting configuration, see the book I blogged about earlier, which I’m still reading.

We take most of the defaults for IIS7 app pools, overriding a few.  I plan to use Powershell code similar to this: 

   1: if (@(Get-PSSnapin | Where-Object {$_.Name -eq "WebAdministration"}).Count -eq 0)

   2: {

   3:     Add-PSSnapin WebAdministration

   4: }


   6: $cred = Get-Credential "MYDOMAIN\THEuserACCOUNTforTHEappPool"


   8: $userName = $cred.UserName

   9: $password = $cred.GetNetworkCredential().Password


  11: if (Test-Path IIS:\AppPools\MyTestAppPool)

  12: {

  13:     Remove-Item IIS:\AppPools\MyTestAppPool -Force -Recurse

  14: }


  16: $myNewPool = New-Item IIS:\AppPools\MyTestAppPool


  18: $myNewPool.processModel.userName = $userName

  19: $myNewPool.processModel.password = $password

  20: $myNewPool.processModel.identityType = "SpecificUser"

  21: $myNewPool.processModel.idleTimeout = [TimeSpan] "0.00:00:00"

  22: $myNewPool.managedRuntimeVersion = "4.0"   # or 2.0

  23: $myNewPool.recycling.periodicRestart.time = [TimeSpan] "00:00:00"


  25: $myNewPool | Set-Item


A few things to mention:

  • I have verified the correct properties in IIS Manager, and it starts fine, but nothing is using it yet.  I will update this if necessary.
  • You’ll see in the code that I’m setting the pool’s identity to a domain user.  If you do this, use the minimum possible permissions.  Consider using Application Pool Identities instead for greater security.  In fact, for the web servers (not application servers) I plan to experiment with this.  I was not familiar with it until yesterday.
  • One of the links I read seemed to indicate that using this method would leave the password in plain text in the IIS config file.  I tested it, and no, the password is encrypted as it should be.
  • Also note that I’m prompting for the credentials to use for the identity.  This keeps passwords out of the script.  In real use, the user name will vary between environments so I’ll need to pull this information from somewhere.

As is often the case I had to poke around a bit to find the information I needed.  Here are some useful links.




New-Service cmdlet vs. InstallUtil.exe

I like using Powershell cmdlets (where possible) rather than command-line utilities. It keeps the syntax consistent and often makes things easier in general.

But this is an exception. In most cases, if you want to create a Windows service based on a .Net assembly, I recommend that you use InstallUtil.exe, not New-Service.

InstallUtil uses reflection to find installers for the service, so the developer can put that information right into the .Net solution. This includes specification of the service name, display name, and description. When you use New-Service you have to specify these properties, and then ensure that you take any other special steps to install the service.

Both ways offer convenience, but using InstallUtil you can get consistency across all your development, test, and production environments without having to know anything but the assembly name.

For more information, see the InstallUtil reference on msdn and the New-Service reference on TechNet.