Carl Webster Accessibility Statement

Carl Webster is committed to facilitating the accessibility and usability of its website, carlwebster.com, for everyone. Carl Webster aims to comply with all applicable standards, including the World Wide Web Consortium’s Web Content Accessibility Guidelines 2.0 up to Level AA (WCAG 2.0 AA). Carl Webster is proud of the efforts that we have completed and that are in-progress to ensure that our website is accessible to everyone.

If you experience any difficulty in accessing any part of this website, please feel free to email us at info@carlwebster.com and we will work with you to provide the information or service you seek through an alternate communication method that is accessible for you consistent with applicable law (for example, through telephone support).

  • Microsoft PowerShell and Nested Try/Catch

    April 15, 2016

    PowerShell

    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







    About Carl Webster

    Webster is a Sr. Solutions Architect for Choice Solutions, LLC and specializes in Citrix, Active Directory and Technical Documentation. Webster has been working with Citrix products for many years starting with Multi-User OS/2 in 1990.

    View all posts by Carl Webster →

    Comments are closed.