• XenApp 6.5 V3.1 Documentation Script Has Been Updated 3-JUL-2013 (May be a Bug in XenApp 6.5)

    July 3, 2013

    PowerShell, XenApp, XenApp 6.5

    A reader, Michael, sent a comment to the website reporting an issue.  It took me a while to reproduce his issue and while fixing his reported issue, I found four other items that needed addressing.

    Michael reported the following error (edited of course for privacy) :

    PS C:\Windows\System32\WindowsPowerShell> XA65_Inventory_V31.ps1 Loading Windows PowerShell snap-in: Citrix.Common.Commands Loading Windows PowerShell snap-in: Citrix.Common.GroupPolicy Loading Windows PowerShell snap-in: Citrix.XenApp.Commands Get-XALoadBalancingPolicyFilter : Error resolving account 0X2/NT/XXXXXXXXXX/S-1-5-21-1234567890-1234567890-123456789-12345 (0x80130002)
    At C:\Windows\System32\WindowsPowerShell\v1.0\XA65_Inventory_V31.ps1:1352 char:63
    +         $LoadBalancingPolicyFilter = Get-XALoadBalancingPolicyFilter
    + <<<<  -PolicyName $LoadBalancingPolicy.PolicyName
    + CategoryInfo          : InvalidResult: (System.Collecti...[System.String]:String) [Get-XALoadBalancingPolicyFilter], CitrixException
    + FullyQualifiedErrorId : ResolveDNToAccountName,Citrix.XenApp.Commands.GetPolicyFilterCmdlet

    This error is caused by an account that no longer exists in Active Directory or as a Local account .  The reason it took me a while to reproduce this error is that the XML Broker caches Distinguished Name resolution queries.  It appears the results are cached between 10 to 30 minutes.  I have asked Citrix for clarification.  When I hear back from them, I will update this article.

    To reproduce this, I created AD and Local accounts and added them to the Load Balancing Policy.  I ran the script and then deleted the two user accounts.  I reran the script and did not get an error.  I then saw where I printed out the Description field even though it was blank.  I don’t know how I missed that and then I saw three other Description fields that should not be printing when blank.  I made all those code corrections and reran the script.

    I am assuming the cached user name query results had expired because now I got the same error Michael reported.

    For the AD account test:

    VERBOSE: Processing Load Balancing Policies Get-XALoadBalancingPolicyFilter : Error resolving account 0X1/NT/WEBSTERSLAB/S-1-5-21-3183340611-3794857548-517421052-1123 (0x80130002)
    At C:\webster\XA65_Inventory_V31.ps1:1354 char:63
    +         $LoadBalancingPolicyFilter = Get-XALoadBalancingPolicyFilter
    + <<<<  -PolicyName $LoadBalancingPolicy.PolicyName
    + CategoryInfo          : InvalidResult: (System.Collecti...[System.String]:String) [Get-XALoadBalancingPolicyFilter], CitrixException
    + FullyQualifiedErrorId : ResolveDNToAccountName,Citrix.XenApp.Commands.GetPolicyFilterCmdlet

    For the Local account test:

    Get-XALoadBalancingPolicyFilter : Error resolving account 0X1/NT/XA65/S-1-5-21-1849613945-2468537564-344248101-1021 (0x80130002)
    At line:1354 char:63
    + $LoadBalancingPolicyFilter = Get-XALoadBalancingPolicyFilter <<<<  -PolicyName $LoadBalancingPolicy.PolicyName
    + CategoryInfo          : InvalidResult: (System.Collecti...[System.String]:String) [Get-XALoadBalancingPolicyFilter], CitrixException
    + FullyQualifiedErrorId : ResolveDNToAccountName,Citrix.XenApp.Commands.GetPolicyFilterCmdlet

    “Fixing” the error that shows when the script was run was simple.  I just  forgot to add –ErrorAction 0 (SilentlyContinue) to the Get-XALoadBalancingPolicyFilter cmdlet.

    But all this brings up an interesting discovery.  If you add an account (User or Group) to a Load Balancing Policy Filter and then that account is deleted from the account database (Active Directory or Local), it can take 10 to 30 minutes before either the PowerShell cmdlet or AppCenter “knows” about the deletion.

    The next time the Load Balancing Policy with the bad account is opened and the User node of the Filter is clicked, this error shown in Figure 1 is given:

    Figure 1
    Figure 1

    The error is from a call to XenAppCOM.IXenAppAccount.get_UserID().  Clicking Continue shows the bad account has been “removed” from the filter (Figure 2).


    I say “removed” because even though the account is not displayed, it must still be somewhere in something in someplace because the error from Figure 1 will be given every time the Users node for the Filter is clicked.  At least that happened to me in my limited testing.  The only way I found around this issue (bug?) was to add another account, save the Load Balancing Policy, modify the Policy by removing the account and saving the Policy.  At this point, the error message from Figure 1 is never seen again.

    Since XenDesktop 7 is now available, I seriously doubt Citrix will do anything about this issue (bug?).

    I also found I missed skipping blank Descriptions for:

    • Load Balancing Policies
    • Load Evaluators
    • Worker Groups
    • Health Monitoring and Recovery Tests in Computer Policies

    Those have all been fixed so the Description is not printed when blank.

    The changes I made to the V3.1 XenApp 6.5 script are very minor.  I changed the internal version number to 3.15 but left the filename unchanged.

    If you have any suggestions for the script, please let me know.  Send an e-mail to webster@carlwebster.com.

    NOTE: This script is continually updated.  You can always find the most current version by going to https://carlwebster.com/where-to-get-copies-of-the-documentation-scripts/

    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

    4 Responses to “XenApp 6.5 V3.1 Documentation Script Has Been Updated 3-JUL-2013 (May be a Bug in XenApp 6.5)”

    1. Eric Says:

      Hi Carl,

      I appreciate the these scripts. I am running this one on a XenApp 6.5 farm and it executes with no errors but I cannot locate the document. Where is the default location for the output?



      • Carl Webster Says:

        The DOCX file named after the XenApp 6.5 farm should be in the same folder as the script. If not, check [environment]::CurrentDirectory. In PowerShell, at the prompt, just type in [environment]::CurrentDirectory and then look in the folder that is returned. Btw, I just learned that yesterday on the MyITForum’s PowerShell mailing list. http://myitforum.com/myitforumwp/services/email-lists-2/#posh




    2. Michael Says:

      Hi Carl

      Thank you for working this out, that is some great work you have done.

      Really appreciate the effort and your script for helping us document XenApp environments.




    Leave a Reply