CHAPTER 15

Managing Internet Information Services 7

Internet Information Services (IIS) is the collection of web, FTP, and SMTP services that is shipped with Microsoft's Windows server and desktop operating systems. IIS 7.0 was shipped with Windows Server 2008 and Windows Vista. IIS 7.5 is being shipped with Windows Server 2008 R2 and Windows 7. The Windows PowerShell cmdlets and provider that are used with IIS 7 give you complete control over the web and FTP services available in IIS.

The Windows PowerShell provider and cmdlets give you a robust way of managing web services. Automating management and deployment tasks for IIS is useful for a variety of reasons:

• Controlling the configuration of IIS through scripts allows for less administrator error when moving changes made in development into testing and production environments.
• Using Windows PowerShell as a deployment method for websites means that your code can easily extend to any IIS 7 server. This technique, along with virtualization and cloud technologies, can be used to spin up new servers on demand to meet your processing and bandwidth needs.
• IIS 7 is one of the roles available to Windows Server Core (the stripped-down command line-only version of Windows 2008). Windows Server 2008 R2 added the ability to host .NET code and Windows PowerShell. Although you can use the IIS management tools to manage an IIS server remotely, the fact that the server itself can only be managed via command line at the console makes Windows PowerShell very attractive.

Installing the Necessary Components

The cmdlets that are used to manage IIS 7 come in both snap-in and module form. Starting with Windows Server 2008 R2 and Windows 7, the WebAdministration module is installed automatically when you install IIS 7.5. Windows Server 2008 and Windows Vista (SP1 and higher) require you to install the WebAdministration snap-in that is available on Microsoft's website (in both x86 and x64 formats) in order to manage IIS 7.0.

Installing the Snap-in

If you are using Windows Vista or Windows Server 2008 (not R2), you will need to install the WebAdministration snap-in in order to use the cmdlets. The snap-in is installed with a standard .msi installation package that you must run as an administrator. The installation registers the appropriate DLLs for you. The snap-in works with both Windows PowerShell 1.0 and Windows PowerShell 2.0.

Installing the Web Server Role

The method used to install the web server role varies depending on whether you are running the Server or Desktop version of Windows.

Microsoft Windows Server 2008

If you are using Windows Server 2008 R2, the WebAdministration module is installed automatically when installing IIS. IIS 7 can be installed through the Server Manager GUI on Windows Server 2008 and Windows Server 2008 R2:

1. Click Start All Programs Administrative Tools Server Manager. Server Manager opens up with a connection to the local server.
2. Right-click Roles and select Add Role. The Add Roles Wizard opens up to the Before You Begin page.
3. Click Next. You are brought to the Web Server (IIS) page in the wizard.
4. Click Next. You are brought to the Select Role Services page.
5. Select the options you would like to install. As long as you select any of the IIS components, the WebAdministration module will be installed if you are installing IIS on a Windows Server 2008 R2 server.
6. Click Next. You see the Confirm Installation Selections screen, where you can review your choices.
7. Click Install. Then wait for the installation to be completed.
8. Click Close.

In addition to the GUI method, you can also install the Web Server role with the Add-WindowsFeature cmdlet that comes with the ServerManager module discussed in Chapter 7. The following line installs the minimal amount of IIS features required to install the WebAdministration module:

Add-WindowsFeature Web-Server

Microsoft Windows Desktop Operating System

If you are using Windows 7, the WebAdministration module is installed with IIS. IIS is installed on Windows 7 and Windows Vista by turning on the Internet Information Services feature:

1. Click Start Control Panel. The Control Panel window opens.
2. Click Programs.
3. Click Turn Windows Features On or Off. The Windows Features dialog box opens up.
4. Select Internet Information Services and click OK.

Loading the WebAdministration Cmdlets and Provider

The technique for loading the cmdlets depends on whether you are using the IIS 7.0 snap-in or the IIS 7.5 module.

Using the IIS 7.0 Snap-in

You can load the WebAdministration snap-in with:

Add-PSSnapin WebAdministration

Using the IIS 7.5 Module

You can load the WebAdministration module with:

Import-Module WebAdministration

Making Your Scripts Generic

If you are unsure whether the computer that is running your script will have the module or snap-in installed, you can use the following snippet of code to ensure that the proper version is loaded at the beginning of your IIS scripts.

if (Get-Module -ListAvailable WebAdministration) {
  Import-Module WebAdministration
} elseif (Get-PSSnapin -Registered -EA SilentlyContinue WebAdministration) {

Add-PSSnapin WebAdministration
} else {
  Write-Error “Cannot find the WebAdministration cmdlets”
  exit
}
# Add your IIS code here

Installing the WMI Provider

IIS 7 also has a method to manage IIS via Windows Management Instrumentation (WMI). To use the WMI classes, you must install the IIS Management Scripts and Tools feature from either Server Manager (Windows Server 2008) or the Add/Remove Windows Features functionality in Windows Vista and Windows 7. You can install this feature with Add-WindowsFeature as follows:

Add-WindowsFeature Web-ScriptingTools

The WMI provider is created within its own namespace in WMI. To use the Get-WmiObject cmdlet, you will need to specify rootWebAdministration with the -Namespace parameter. For example, to look at the VirtualDirectory class, you would use the following command:

Get-WmiObject -Namespace rootWebAdministration VirtualDirectory

The WebAdministration namespace contains more than 400 classes. You can view them all with the following command:

Get-WmiObject -Namespace rootWebAdministration -List

Browsing IIS :

The WebAdministration module and snap-in come with a Windows PowerShell provider called WebAdministration that can be used to browse, create, modify, and delete items within IIS. When the module or snap-in is loaded, a default WebAdministration drive is created called IIS:.

You can browse to the IIS: drive by using either Set-Location or its alias cd. The root of IIS: has three folders, which are visible when using Get-ChildItem or dir:

• AppPools: Application Pools
• Sites: Web and FTP Sites
• SSLBindings: A collection ofsites that are configured with certificates to use SSL

cd IIS:
 dir

Name
----
AppPools
Sites
SslBindings

Get-ChildItem .Sites

Name     ID   State     Physical Path                           Bindings
----     --   -----     -------- ----                           --------
Web Site 1    Started   %SystemDrive%inetpubwwwroot           http *:80:
                                                                https *:443:

cd .AppPools
 dir

Name                       State                  Applications
----                       -----                  ------------
Classic .NET AppPool       Started
DefaultAppPool             Started                Default Web Site
                                                  /CertSrv

dir IIS:SslBindings

IP Address          Port      Store       Sites
-- -------          ----      -----       -----
192.168.1.100       443       MY          Default Web Site

Scripting Deployments and Changes

Scripting new deployments within IIS becomes a breeze with Windows PowerShell. Once you work out all of the requirements for an application, you can automate the process to build web farms or testing environments for your sites.

Scripting configuration changes is an excellent technique you can use to reduce the risk of making changes to production web servers. You can work out your script in a development environment, test it in a QA environment, and then push that change to production.

Using New-Item

The New-Item cmdlet enables you to create the following types of items within IIS: via the WebApplication provider:

• AppPool: This is an object that represents an application pool. It is the default type that is created when New-Item is used within IIS:AppPools.
• Site: This is a website item. It is the default type for New-Item within IIS: Sites. Within websites, you can create the following types using New-Item:
  • Application: A directory in a website that is specified to run an application, for example, .NET-enabled directories.
  • VirtualDirectory: A directory in a website that is a virtual directory.
• SslBinding: This item represents the collection of properties that make up an SSL binding. This is the default type for IIS:SslBindings.

To create items of the type Application or VirtualDirectory, you must use the dynamic parameter Type that is available only when New-Item is called within the WebAdministration provider.

New-Item also has two additional dynamic parameters when used with this provider. These parameters only exist for New-Item when they are used within the IIS provider.

• PhysicalPath: Used to specify the physical path for a website, virtual directory, or application.
• Bindings: Used to specify the protocol, address, port, and host headers associated with a website. The Bindings property takes a hash or collection of hashes with two name/value pairs:
  • Protocol: The web protocol for the binding, for example, HTTP or HTTPS.
  • BindingInformation: This is three bits of information separated by colons:
    • IP Address: The IP address to bind to. Asterisks can be used as a wildcard to specify a range of addresses. A single asterisk represents any IP address.
    • Port: The port the site should use.
    • Host header: A host header that signifies that the site should respond to requests when a specific hostname is used. This value can be left blank to associate the site with any hostname.

Creating Sites

Websites and FTP sites can be created very easily with the WebAdministration snap-in or module. As you will see throughout this chapter, there is often both a provider and direct cmdlet way of performing these tasks.

Using the Provider

The following example illustrates how you can create a website using New-Item. Prior to using the New-Item cmdlet, it will create the underlying directory structure if it does not already exist. It also shows you how to use the Bindings parameter to add two bindings to the site.

$dir = ‘C:inetpubwwwrootPowerShellBible’
if (!(Test-Path $dir)) {
  md $dir
}
$bindings = @()
$bindings += @{protocol=‘http’;bindinginformation=‘192.168.1.100:8080:’}
$bindings += @{protocol=‘https’;bindinginformation=‘*:443:’}

New-Item IIS:SitesPowerShellBible -PhysicalPath $dir -Bindings $bindings

Using New-Website

The WebAdministration module also provides a cmdlet called New-Website that creates a site without needing to use the provider. New-Website has the following parameters worth noting:

• Name: Name of the website.
• ID: Optional parameter that allows you to specify a unique ID for the site.
• Port: The port that will be used for the site.
• IPAddress: The IP address for the site.
• HostHeader: The hostname that the site will respond to.
• ApplicationPool: The application pool that the site will use.
• Ssl: This is a switch that enables https as the protocol for the site.

The following example illustrates how this cmdlet is used:

$dir = ‘C:inetpubwwwrootPSBible’
if (!(Test-Path $dir)) {
  md $dir
}

$params = @{
  Name=‘PowerShellBible’
  Port=443
  IPAddress=‘*’
  HostHeader = ‘powertoe.wordpress.com’
  PhysicalPath=$dir
  ApplicationPool=‘AppPool1’
  SSL=$true
}
New-Website @params

Using New-WebFTPSite

FTP sites are created with New-WebFtpSite. This cmdlet is identical to New-WebSite except that it does not have an ApplicationPool or SSL parameter.

Creating Virtual Directories

Virtual directories are web folders within a site that point to a folder that is outside of a site's normal directory structure. They are used to point a site directory to another folder on the server, including those that exist on separate disks.

Using the Provider

Here is an example of how to use New-Item in the WebAdministration provider to create a virtual directory. The example creates a directory in the PowerShellBible website that is pointing to the D drive of the server.

cd IIS:SitesPowerShellBible
New-Item Data -Type VirtualDirectory -PhysicalPath d:

Using New-WebVirtualDirectory

Virtual directories can also be created with the New-WebVirtualDirectory cmdlet. The relevant parameters are:

• Name: Name of the virtual directory.
• Application: If the application is omitted, the virtual directory will be created at the root of the site.
• PhysicalPath: The directory must already exist on the filesystem.
• Site

Here is an example of how this cmdlet can be used.

$dir = ‘C:virtualdir1’
if (!(Test-Path $dir)) {
  md $dir
}
$params = @{
  Name=‘VirtualDir1’
  Site=‘PowerShellBible’
  PhysicalPath = $dir
}
New-WebVirtualDirectory @params

Creating Web Applications

Creating a web application directory is a very simple process whether you use the provider or the cmdlet. The cmdlet methods within IIS are generally more robust and easier to read and modify in scripts, but it is really just personal preference.

Using the Provider

The following example converts a directory in the PowerShellBible website into an application folder via the WebAdministration provider.

cd IIS:SitesPowerShellBible
md App #Creates the App directory on the file system
New-Item App -Type Application -PhysicalPath (Get-Item .App).fullname

Using New-WebApplication

Application folders can also be created with the New-WebApplication cmdlet. The parameters of importance are:

• Name: Name of the application directory.
• PhysicalPath: The path on the filesystem to the directory that will contain the web application. The directory must already exist.
• Site: The site where the application folder will be created.
• ApplicationPool: The application pool that the web application will use.

The following shows an example of how to use this cmdlet:

$dir = ‘C:inetpubwwwrootPSBibleapp1’
if (!(Test-Path $dir)) {
  md $dir
}
$params = @{
  Name=‘App1’
  Site=‘PowerShellBible’
  PhysicalPath = $dir
  ApplicationPool=‘AppPool1’
}
New-WebApplication @params

Creating Application Pools

Application pools encapsulate applications and sites into groups of worker processes. Whether you are creating these application pools via the provider or the cmdlet, only one line of code is required.

Using the Provider

Creating application pools is very straightforward using New-Item.

New-Item IIS:AppPoolsPowerShellBible

Using New-WebAppPool

This method is also very straightforward. The cmdlet takes a positional parameter that represents the name of the new application pool.

New-WebAppPool PowerShellBible

Configuring SSL

Setting up SSL is a multistep process:

1. You must have a certificate installed that you can use for the binding.
2. You must create a web binding on a website using New-WebBinding that uses the HTTPS protocol.
3. You create an SSL binding in IIS:SslBindings specifying the allowed IP addresses and the certificate you would like to use.

The following example shows how to perform the above steps.

New-WebBinding -Name ‘PSBible’ -Protocol https -Port 443 -IPAddress 0.0.0.0
cd IIS:SslBindings
$cert = Get-Item cert:LocalMachineMy734A6B9F621496813276A7134D64BFEFA5FF5C11
$cert |New-Item 0.0.0.0!443

Using the Provider to Make Changes

Once items have been created, you can use the cmdlets that you use with any Windows PowerShell provider to get information and remove and modify the underlying objects: Get-Item, Remove-Item, Get-ItemProperty, Set-ItemProperty, New-ItemProperty, and Clear-ItemProperty. It's worth highlighting a few examples of how you can modify items in the provider.

In order to bind a site to an application pool, you can use Set-Item as follows:

$website = Get-Item IIS:SitesPSBible
$website |Set-ItemProperty-Name ApplicationPool-Value PSBible

Here is an example of how you can remove all of the existing web bindings and then create a new one.

$website |Clear-ItemProperty -Name bindings
$binding = @{protocol=‘http’; bindinginformation=‘*:80:www.wiley.com’}
$website |Set-ItemProperty -Name bindings -Value $bindings

This example modifies the queue length for an application pool and then recycles that pool.

$pool = Get-Item IIS:AppPoolsPSBible
$pool.queueLength = 3000
$pool.Recycle()

Here is an example of how you can grab one of the properties returned by Get-ItemProperty:

Get-ItemProperty .DefaultAppPool |Select -ExpandProperty processmodel

This example shows how you can use Set-ItemProperty to modify the properties of an application pool. The following two lines of code set a username and password for the application pool to run as:

$properties = @{userName=‘domainIIS_pool’; password=‘password’;identitytype=3}
Set-ItemProperty IIS:AppPoolsPSBible -name processmodel -value $properties

The following line of code is a useful one that moves the location where log files are stored from a site to a new directory:

Set-ItemProperty IIS:SitesPSBible -Name LogFile.Directory -Value ‘d:Logs’

Finally, here is an example of using Remove-Item. The following code deletes a website:

Remove-Item IIS:SitesPSBible

Removing IIS Objects with the Cmdlets

In addition to using Remove-Item to delete IIS objects within the IIS: drive, each New-WebIISObject cmdlet also has a corresponding Remove-WebIISObject that can be used. For example, the cmdlet used to create websites is New-Website and the cmdlet used to delete a website is Remove-Website.

Advanced WebConfiguration Settings

Not all configurations are exposed to the WebAdministration provider. Some settings require you to use the WebConfiguration cmdlets. These cmdlets work with the provider to expose more information about the IIS objects.

To understand how these cmdlets work, it's important to realize that these settings are maintained within XML files in a series of layers. For example, a website will get its configuration from a combination of the machine.config, the global web.config, the applicationHost.config, and finally through the web.config that belongs to the site. The cmdlets use XPath queries to find the locations you are looking to view and change.

To view these settings, you use Get-WebConfiguration and Get-WebConfigurationProperty.

Viewing Web Configuration Settings

Get-WebConfiguration uses the following important parameters:

• PSPath: This is the location you would like to get information from. It can be a location in the IIS: drive or you can use webroot, apphost, or computer name.
• Filter: This is the XPath query filter. Wildcards (*) are supported.
• Location: This specifies the delegation level you are looking at. This is important only when pushing changes back into the configuration because it allows you to override a configuration that is locked from a parent configuration file.

The following is a snippet of XML that is taken from a machine.config:

<configProtectedData defaultProvider=“RsaProtectedConfigurationProvider”>
 <providers>
   <add name=“RsaProtectdConfigurationProvider”
type=“System.Configuration.RsaProtectedConfigurationProvider,

System.Configuration,

Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a”

description=“Uses;
RsaCryptoServiceProvider to encrypt and decrypt”
keyContainerName=“NetFrameworkConfigurationKey” cspProviderName=“”
useMachineContainer=“true” useOAEP=“false”/>

     <add name=“DataProtectionConfigurationProvider”
 type=<System.Configuration.DpapiProtectedConfigurationProvider,

System.Configuration,
Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a”

description=”Uses
CryptProtectData and CryptUnProtectData Windows APIs to encrypt and decrypt”
useMachineProtection=“true” keyEntropy=“”/>
   </providers>
</configProtectedData>

To view the configProtectedData section for the PowerShellBible website, you would use the following code:

cd IIS:SitesPowerShellBible
Get-WebConfiguration -Filter /configProtectedData |select *

defaultProvider       : RsaProtectedConfigurationProvider
providers             : Microsoft.IIs.PowerShell.Framework.ConfigurationElement
PSPath                : MACHINE/WEBROOT/APPHOST/Default Web Site
Location              :
ConfigurationPathType : Location
ItemXPath             : /configProtectedData
IsLocked              : True
OverrideMode          : Inherit
OverrideModeEffective : Allow
SectionPath           : /configProtectedData
Attributes            : {defaultProvider}
ChildElements         : {providers}
ElementTagName        : configProtectedData
Methods               :
Schema                :
Microsoft.IIs.PowerShell.Framework.ConfigurationElementSchema

According to the output, there are ChildElements that refer to the <providers> section of the XML. There is also an attribute called defaultProvider. To browse all of the <add> elements within <providers>, you could use a filter like this:

Get-WebConfiguration -Filter /configProtectedData/providers/*

To look at the defaultProvider attribute, you can inspect what is returned from Get-WebConfiguration using:

(Get-WebConfiguration /configProtectedData).defaultprovider

As an alternative, you can also use the Get-WebConfigurationProperty cmdlet. Get-WebConfigurationProperty has the same parameters as Get-WebConfiguration with the addition of a -Name parameter to specify the property you would like to view:

Get-WebConfigurationProperty /configProtectedData

-Name defaultprovider|
  Select Value

Modifying Configuration Settings

Sections are added to a configuration using Add-WebConfiguration and Add-WebConfigurationProperty. For example, if you wanted to add a new filename to the default files for the site, you could do the following.

$filter = ‘/system.webServer/defaultDocument/files’
Add-WebConfiguration $filter -AtIndex 0 -value @{value=“default.html”}

Sections are modified using Set-WebConfiguration and Set-WebConfigurationProperty. The following example shows how you can use Set-WebConfiguration. The snippet redirects the PowerShellBible site to wiley.com.

cd IIS:SitesPowerShellBible
Set-WebConfiguration system.webServer/httpRedirect -Value @{
   enabled=$true
   destination=“http://wiley.com”
   exactDestination=$true
   httpResponseStatus=“Permanent”
}

This final example shows how to use the Set-WebConfigurationProperty. Specifically, it shows you how to change the CGI timeout value for the PowerShellBible site.

cd IIS:Sites
$filter = ‘/system.webserver/cgi’
Set-WebConfigurationProperty $filter -name timeout -Value ‘00:20:00’ `
  -Location ‘PowerShellBible’

Working with IIS Modules

In addition to the WebConfiguration cmdlets, there are a few cmdlets that are designed to work with IIS 7 modules:

• Disable-WebGlobalModule
• Enable-WebGlobalModule
• Get-WebGlobalModule
• Get-WebManagedModule
• New-WebGlobalModule
• New-WebManagedModule
• Remove-WebGlobalModule
• Remove-WebManagedModule
• Set-WebGlobalModule
• Set-WebManagedModule

The cmdlets that refer to the global modules have a module type of Managed when looking at the modules with IIS Manager. The cmdlets are very straightforward in their usage. For example, the Get cmdlets will retrieve all of the modules, or you can specify a module name you would like to view information about. All the cmdlets take the name of the module by using the Name positional parameter. For example, the following will disable the AnonymousAuthenticationModule:

Disable-WebGlobalModule AnonymousAuthenticationModule

There are not many properties you can set when creating or modifying a module. Typically, the managed modules can point to a new type or precondition while the global modules can be pointed to a new DLL by using the Image property. The following example shows how you can modify a global and managed module:

Set-WebManagedModule UrlMappingsModule -Type PSBible.Mappings
Set-WebGlobalModule IsapiModule -Image c:customisapi.dll

Managing IIS

In addition to scripting deployments and changes to sites, Windows PowerShell can also be used to perform administrative tasks for IIS. This may be something as simple as controlling the state of IIS services or performing backups or restorations of configuration settings.

Controlling IIS Services

Application pools, websites, and the underlying Windows services of IIS can all be controlled via Windows PowerShell.

Starting and Stopping Pools and Sites

You have already seen that the provider exposes methods on application pools to allow things like stopping, starting, and recycling. You can also use the Stop() and Start() methods on the objects returned by Get-Item when using the cmdlet against items in the IIS:Sites container:

(Get-Item IIS:sitesPowerShellBible).Stop()
(Get-Item IIS:sitesPowerShellBible).Start()

In addition to the preceding technique, there are six cmdlets to help you start and stop sites and application pools:

• Stop-WebSite
• Start-WebSite
• Stop-AppPool
• Start-AppPool
• Stop-WebItem
• Start-WebItem

You can use the cmdlets by themselves:

Stop-WebSite PowerShellBible
Start-WebSite PowerShellBible

Or you can pipe the provider objects into the cmdlets:

Get-ChildItem IIS:sites |Stop-WebSite
Get-Item IIS:sitesPowerShellBible |Start-WebSite

The Start-WebItem and Stop-WebItem cmdlets can be used with either an application pool or a site.

Starting and Stopping IIS Services

While discussing starting and stopping items, it's also important to note that no WebAdministration cmdlets stop and start IIS because the cmdlets built into Windows PowerShell V2 already have cmdlets that do this for you. The only problem is that there is more than one service controlled via iisreset in IIS 7: W3WSVC, WAS, and IISADMIN (installed only if you are using components of IIS 6). You could write a set of functions that would handle this natively in Windows PowerShell, but there's really no reason to because IISReset.exe works fine from within Windows PowerShell — even within a remoting session.

Determining the State of a Site or Pool

The cmdlets and methods you can use to stop and start sites and application pools work regardless of the state the item is in prior to you calling the start or stop methods. In other words, if you call Start-WebSite on a site that is already running, it will not do anything, but it will not fail, either. Even though this logic is built into the cmdlets, you may still be interested in looking at the state for verification or reporting purposes within your script.

As with stopping and starting, you can do this in multiple ways with the WebAdminstration provider and cmdlets. You can use the cmdlets Get-WebSiteState, Get-WebAppPoolState, or Get-WebItemState the same way you use the stop and start cmdlets. You also have the ability to inspect the state property of a website or app pool item returned from the Get-Item cmdlet. For example, each of these will show you the same thing:

Get-WebAppPoolState PowerShellBible

(Get-Item IIS:AppPoolsPowerShellBible).State

$pool = Get-Item IIS:AppPoolsPowerShellBible
$pool.state

$pool = Get-Item IIS:AppPoolsPowerShellBible
$pool | Get-WebAppPoolState

$pool = Get-Item IIS:AppPoolsPowerShellBible
$pool | Get-WebItemState

If you would like to retrieve the state of all of the app pools, you can use either of the following lines of code:

Get-ChildItem IIS:AppPools |Get-WebItemState
Get-WebAppPoolState

Backing Up and Restoring Configurations

If you would like to back up your entire IIS configuration, you can do so with Backup-WebConfiguration BackupName. This creates a folder in $env:windir System32inetsrvackup with the name you supplied to the cmdlet. The data in the backup directory can be restored with Restore-WebConfiguration BackupName. You should ensure that IIS is stopped prior to running the restoration or you will get errors.

Digesting Log Files

Reading IIS log files can be a cumbersome task if it needs to be done manually. Though a lot of tools are available to help you make sense of IIS logs, it's important to note that Windows PowerShell truly excels at this type of data manipulation. There is a slight trick to the technique in order to get the header information, but once that is determined, the process is very simple.

ConvertFrom-Csv

To let ConvertFrom-Csv turn each line of the log file into a Windows PowerShell object, you must first determine the header of the log from the line that begins with #Fields:. Once that is obtained, you can pass a single space character to the -Delimiter property of the cmdlet. Listing 15-1 is a complete script that uses this technique to parse the log file into Windows PowerShell objects.

LISTING 15-1 Parsing an IIS Log File

$site = ‘IIS:sitesPowerShellBible’

#The logfile.directory configuration usually has an environment variable
#Passing it to cmd will get the full path
$log = cmd /c echo (Get-Item $site).logfile.directory

#Get the log file path
$log = Join-Path $log (”W3SVC” + (Get-Item $site).id)

#Get the full path to the log file
$log = Join-Path $log “u_ex$yesterday.log”

$header = @()
$logentries = get-content $log |foreach {
  #Read the log file and look for the first line that has Fields#
  if ($header.count -eq 0 -and $_ -match ‘#Fields: ([sS]+)’) {
    #Split the line by a single space to get the header properties
    #for the log file
    $header = $matches[1] -split ‘s’
  }
  else {
    #Make sure the line does not begin with a comment symbol

if ($_ -notmatch ‘^#’) {
    #Convert the line into PowerShell objects from a
    #space delimited file
    $_ |ConvertFrom-Csv -Header $header -Delimiter ‘ ’
  }
 }
}
#Display the entries to the screen
$logentries

Filtering Tips

Once you have the log entries as Windows PowerShell objects, you can use the filtering, sorting, and formatting cmdlets you are familiar with. For example, if you wanted to filter for a list of 404 errors, you could use Where-Object or its alias where:

$logentries |where {$_.$(“sc-status”) -eq 404}

Sorting can be done by using the Sort-Object cmdlet or its alias sort:

$logentries |sort time-taken

You could just as easily use Export-CSV or ConvertTo-HTML. For example, the following creates an HTML report that shows the date/time along with the client's IP address and browser type. It uses Out-GridView so that you can more easily sort or filter the entries manually:

$logentries |Out-GridView
$logentries |select date,time, ‘cs(User-Agent)’, c-ip |
  ConvertTo-Html |
  Out-File c:
eport.html
Start c:
eport.html

Summary

As is the case with most things in Windows PowerShell, there are often multiple ways to accomplish tasks with the WebAdministration module and snap-in. The path you choose doesn't really matter. The important thing to realize is that you have everything you need to automate, manage, and report on your IIS servers directly within Windows PowerShell.

The next chapter looks at how you can use PowerShell to help manage System Center Operations Manager.