This could be done easier, I thought. And so thought many before me.

This is a slight modification of the script by Chris Dent, because I needed different results to link site name (which IISWebServerSetting saves as ServerComment) to the specific logfile directory (which is a mishmash of LogFileDirectory and Name).

Function Get-IISLogSetting {
    param(
       [String[]]$Servers = $Env:Computername
    );

    $Servers | %{
        $Server = $_ ;
        Write-Progress "Scaning" $Server;
        $WMI = New-Object Management.ManagementScope("\\$Server\root\MicrosoftIISv2");
        $WMI.Options.Authentication = "PacketPrivacy";
        $Query = New-Object Management.ObjectQuery("SELECT Name, ServerComment, LogFileDirectory, LogFileTruncateSize, LogType, LogFilePeriod FROM IIsWebServerSetting");
        $Searcher = New-Object Management.ManagementObjectSearcher($WMI, $Query);
        Trap [UnauthorizedAccessException] {
              Write-Error "$($Server): Unable to connect or Access is denied";
              continue;
        }
        $result = $Searcher.Get();
        #$Host.EnterNestedPrompt();
        $result | Select-Object @{
            n = 'Server';
            e = { $Server; }
        }, @{
            n = 'Website';
            e = { $_.ServerComment; }
        }, @{
            n = 'Log Path';
            e = { "{0}\{1}" -f $_.LogFileDirectory, $_.Name.Replace("/",""); }
        }
    }
}

Usage:

Get-IISLogSetting [-servers server1,server2,server3,...]

Any ADSI or WMI query to a list of your group memberships will turn out to 1000 members in Windows 2000 mode, or 1500 in Windows 2003 native mode. Only by using ADO range limits, you can go by this soft limit.

This shouldn’t pose a problem when you are just adding members to an already big group. However, it does.

$userOU = [ADSI] "LDAP://cn=myUser,ou=Users,dc=contoso,dc=com"
$groupOU = [ADSI] "LDAP://cn=myGroup,ou=Users,dc=contoso,dc=com"
$groupOU.Member = $groupOU.Member + $userOU.distinguishedName
$groupOU.SetInfo()

Adding the myUser user to the myGroup group will work fine if the group member count is below 1500. Once above, your group will suddenly loose an amount of members until you are left with a group of just 1500 members, and then added by the new member.

What actually happens is self-explanatory when reading the code: the group members is the group member list plus the new member. When the group member list only returns 1500 members, and then you add one member, you are left with 1501 members, and not your original amount of members + 1.

A workaround is this:

$ADS_PROPERTY_APPEND = 3
$userOU = [ADSI] "LDAP://cn=myUser,ou=Users,dc=contoso,dc=com"
$groupOU = [ADSI] "LDAP://cn=myGroup,ou=Users,dc=contoso,dc=com"
$groupOU.putEx($ADS_PROPERTY_APPEND, "member", @($userOU.distinguishedname))
$groupOU.SetInfo()

In this workaround, we are going to use putEx to append a member to a group, instead of loading the full member list (with a limit of 1500) and then adding a new member.

Source.

Adding to the basic shell functions one would expect, such as file and directory manipulation, reading and writing text files, manipulating strings with regular expressions, Powershell also integrates with .NET 2.0 and higher to communicate with other functions, such as accessing the System.Windows.Forms object to make neat forms equipped with all the controls you would expect in a compiled application, or in this case: manipulating Excel workbooks.

Using Excel together with PowerShell can be very easy. Too bad the documentation is sparse on this topic, and the official documentation makes no mention of a workaround that is needed when using Excel with PowerShell on a machine which is not configured with regional settings set to EN-us.

We start off creating an Excel object, as described in the Scripting Guy post:

$objExcel = New-Object -comobject Excel.Application
$objExcel.Visible = $True
$objWorkbook = $objExcel.Workbooks.Add()
$objWorksheet = $objWorkbook.Worksheets.Item(1)
$objWorksheet.Cells.Item(1,1) = "A value in cell A1."
$objWorkbook.SaveAs("C:ScriptsTest.xls")
$objExcel.Quit()

This little bit wil start Excel, add a worksheet, inset a string in cell A1, and save the Excel worksheet to a file, before quitting. Unless your machine is not set up with regional settings EN-us. Then you are greeted with the next message:

Exception calling "Add" with "0" argument(s): "Old format or invalid type library. (Exception from HRESULT: 0x80028018
(TYPE_E_INVDATAREAD))"
At line:1 char:39
+ $objWorkbook = $objExcel.Workbooks.Add( < <<< )

When looking for this Error, you will run into threads regarding other scripting and programming languages. Most notably, KB320369 has some information.

Ok, there is a workaround. See what this code does:

function Invoke([object]$m, [string]$method, $parameters)
{
$m.PSBase.GetType().InvokeMember(
$method, [Reflection.BindingFlags]::InvokeMethod, $null, $m, $parameters,$ciUS)
} 

$ciUS = [System.Globalization.CultureInfo]'en-US'

$objExcel = New-object -com Excel.Application
$objExcel.visible = $True
$ci = [System.Globalization.CultureInfo]'en-us'
$objWorkbook = Invoke $objExcel.Workbooks Add
$objWorksheet = $objWorkbook.Worksheets.Item(1)
$objWorksheet.Cells.Item(1,1) = "A value in cell A1."
Invoke $objWorkbook SaveAs "C:ScriptsTest.xls" > $null
Invoke $objWorkbook Close 0 > $null
$objExcel.Quit()

Still an error!

Exception setting "Item": "Exception from HRESULT: 0x800A03EC"
At C:scriptingtest.ps1:15 char:25
+ $objWorksheet.Cells.Item( < <<< 1,1) = "A value in cell A1."

Modify the above code a bit, with this line instead of line 14:

$objWorksheet.Cells.Item(1,1).FormulaLocal = "A value in cell A1." 

The result? An Excel-file with data!

If you want to open an Excel-file instead of creating a new one, use the following as a replacement for line 12:

$objWorkbook = Invoke $objExcel.Workbooks Open"c:ScriptsTest.xls" 

And if you want to save the Excel file to the existing name, add this before line 16:

Invoke $objWorkbook Save > $null