Microsoft PowerShell and Nested Try/Catch

On a recent project, I learned something new about PowerShell’s Try/Catch. You can nest another Try/Catch in the Catch of the first Try/Catch. When I showed this to my PowerShell mentor, he said he didn’t know that could be done. I figured I might as well make a quick post about it.

I was using some code from Jeremy Saunders to gather CPU information on a XenApp 6.5 farm. the Get-XAServer cmdlet has a property to store the FQDN of a XenApp server but it is not populated. This XenApp farm contained servers in two different forests and two different domains. All my scripts I wrote for the project using the XenApp cmdlets and Get-EventLog stuff worked with no issues. Using Get-WmiObject broke because that cmdlet will not work for computers not in the same forest.

I did a Get-Help Get-WmiObject and noticed a -Authority parameter.

1
2
3
4
Get-WmiObject [-Authority <string>] [-Amended] [-AsJob] [-Authentication {Default | None | Connect | Call | Packet
| PacketIntegrity | PacketPrivacy | Unchanged}] [-ComputerName <string[]>] [-Credential <PSCredential>] [-EnableAll
Privileges] [-Impersonation {Default | Anonymous | Identify | Impersonate | Delegate}] [-Locale <string>] [-Namespa
ce <string>] [-ThrottleLimit <int>] [<CommonParameters>]

The explanation for that parameter:

1
2
3
4
5
-Authority <string>
Specifies the authority to use to authenticate the WMI connection. You can specify standard NTLM or Kerberos au
thentication. To use NTLM, set the authority setting to ntlmdomain:<DomainName>, where <DomainName> identifies
a valid NTLM domain name. To use Kerberos, specify kerberos:<DomainName>\<ServerName>". You cannot include the
authority setting when you connect to the local computer.

I wondered if I could use -Authority ntlmdomain:<DomainName> if the first Get-WmiObject failed.

Jeremy’s code wraps the call to Get-WmiObject in a Try {} Catch {}. So I thought it would be worth testing to see if I could do:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
try
{
}
 
catch
{
    try
    {
    }
     
    catch
    {
    }
}

Sure enough it worked (and surprised me).

Here are the basics of Jeremy’s code.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
add-pssnapin "citrix.xenapp.commands"
 
$names = Get-XAServer -ea 0 | Select ServerName | Sort ServerName
 
foreach($name in $names)
{
    write-host "$($name.servername)"
    Try
    {
        $ComputerInformation = Get-WmiObject -Class Win32_ComputerSystem -computername $Name.servername -ErrorAction Stop
        $Processors = Get-WmiObject -Class win32_Processor -computername $Name.servername -ErrorAction Stop
        $Disks = Get-WmiObject -Class win32_LogicalDisk -computername $Name.servername -ErrorAction Stop
    }
 
    Catch
    {
        Try
        {
            $ComputerInformation = Get-WmiObject -Authority ntlmdomain:domain2 -Class Win32_ComputerSystem -computername $Name.servername -ErrorAction Stop
            $Processors = Get-WmiObject -Authority ntlmdomain:domain2 -Class win32_Processor -computername $Name.servername -ErrorAction Stop
            $Disks = Get-WmiObject -Authority ntlmdomain:domain2 -Class win32_LogicalDisk -computername $Name.servername -ErrorAction Stop
        }
 
        Catch
        {
            $ErrorDescription = "Error connecting using the Get-WmiObject cmdlet."
            $Host.UI.WriteErrorLine("*ERROR*: - $ErrorDescription")
        }
    }
}

None of this would have been necessary if Citrix had populated the ServerFqdn property. If they had, I could have just stripped the domain part off and just used one call to Get-WmiObject.

Hey, learn something new every day in this field.

Thanks

Webster