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