Showing posts with label XenDesktop. Show all posts
Showing posts with label XenDesktop. Show all posts

Thursday, August 18, 2016

StoreFront / Gateway Logoff Error

On occasion you may run into logoff errors for Citrix StoreFront or Citrix NetScaler Gateway similar to the one below.
If any apps are still running, please exit them manually.

I have found two reasons thus for this error to potentially happen. Each has their own time and place as well as a resolution. There is a third resolution as well, that was a bug several years ago with VDI-In-A-Box. This third resolution is actually a workaround, and depending on your environment, may not be suitable.




Scenario/Fix 1

  • In this scenario Receiver for Web is configured for domain pass-through authentication. If this or smart card authentication are in use and XenDesktop Site settings are not configured to trust XML communications (default config) then the error above can be observed.
  1. Load PowerShell on a Delivery Controller
  2. Add the Citrix cmdlets:
    Add-PSSnapin *cit*
  3. View your Site information. It is expected that the trust status is false:
    Get-BrokerSite
  4. Adjust your trust status:
    Set-BrokerSite -TrustRequestsSentToTheXmlServicePort $true
  5. Verify you are now trusted for XML communication:
    Get-BrokerSite


Scenario/Fix 2
  • In this scenario StoreFront is configured for multiple Delivery Controllers across different Sites. One of the sites is down resulting in no Delivery Controller to respond. This will usually be seen in the Event Viewer>Citrix Delivery Services log on StoreFront servers as Event ID 4012. Both the enumeration process and the logoff process (if terminating or disconnecting sessions) will reach out to all configured sites in StoreFront. While enumeration does not present an error to users, log off will do so if StoreFront cannot verify active sessions to disconnect or terminate. This could be very common in Cold DR or Development environment scenarios where everything is passed through one StoreFront portal.
  1. Verify all XenDesktop sites are responding.


Scenario/Fix 3
  • This scenario is not actually a scenario but a work around. As alluded to in the second section above, the error occurs when StoreFront tries to utilize WorkSpace Control and disconnect or log off users sessions but fails. This fix for this is to change your default behavior.
  1. In current versions (3.5 or newer) of StoreFront, launch the console and navigate to Receiver for Web Sites>Manage Receiver for Web Sites>Configure.
  2. Select WorkSpace Control
  3. Change the Logoff action to None:
  4. With the setting at None, no controllers will be contacted and thus no errors shown to the client.
  5. Don't forget to replicate settings to your Server Group.
If you are on a version of StoreFront that does no have GUI configurable WorkSpace Control settings, you can access the web.config file in your IIS home and change the highlighted line below.

Go to C:\inetpub\wwwroot\Citrix\<StoreName>Web and open the web.config file.

<workspaceControl enabled="true" autoReconnectAtLogon="true"
            logoffAction="none" showReconnectButton="false" showDisconnectButton="false" />

Saturday, August 13, 2016

XenDesktop 7.6 - Limiting Desktops

One of the biggest issues (complaints) about earlier versions of XenDesktop 7.x was that you had to present desktops to all users of a delivery group. The truth to this is that you can actually limit this - however it is not part of the GUI until the latest releases of the 7.x platform.

If you are in need of limiting who gets desktops, you need to break out your PowerShell SDK for XenDesktop and look at the Entitlement Policy for your Delivery Group. You can enable the User Filter and in turn assign users or groups to get the desktop.

Below is a sample of this change. Note that you have to have a Delivery Group with Desktops enabled for this to work.


Add-PSSnapin *Cit*

Get-BrokerDesktopGroup *

#Note the Uid of the Delivery Group you are interested in limiting - in this case my sample Uid is 32

Get-BrokerEntitlementPolicyRule -Uid 32 | Set-BrokerEntitlementPolicyRule -IncludedUserFilterEnabled $true -IncludedUsers "MyDomain\MyUserGroup"

#The above will set the entitlement policy object to be enabled and add my limiting group

Get-BrokerEntitlementPolicyRule -Uid 32

#Verify the settings you just configured

Thursday, August 4, 2016

Pesky Icon Data

I ran into an issue with a Citrix XenDesktop environment where application settings had to be recovered but unfortunately none of the Encoded Icon Data was available so all applications had the default citrix application icon with Uid of  1.

I had to get a little creative with PowerShell to get the application's  icon data back. Unfortunately if there were custom icons, this wouldn't work - but in a time of recovery beggars can't be choosers.

The below script will take each application located on a server from a delivery group (I only had one here, but this could be upgraded to walk multiple) and extract the first available icon from the executable of the published application, create the encoded icon data, and then assign the application to that new icon. In my case this took care of most of the applications. I had a couple published batch files that I tweaked after the fact - but this was much nicer than going through the GUI and manually adjusting every application in the environment.

Add-PSSnapin *Cit*

$applications = $null
$applications = Get-BrokerApplication * | Where-Object {$_.IconUid -eq 1}

$sessionhost = $null
$sessionhost = Get-BrokerDesktop * | where-object {$_.MachineUid -eq 1}

$manuallyfix = $null

foreach($app in $applications){
if($app.CommandLineExecutable -like "C:*")
    {
    $localpath=$null
    $localpath=$app.CommandLineExecutable.TrimStart("C",":")

    $path = $null
    $path = "\\"+$sessionhost.HostedMachineName+"\C$"+$localpath

    $icon = $null
    $icon =get-ctxicon $path -index 0

    $newicon = new-brokericon -EncodedIconData $icon.EncodedIconData

    write-host $app.browsername "changing to Icon Uid: " $newicon.uid
    Get-BrokerApplication $app.browsername | Set-BrokerApplication -IconUid $newicon.uid

    }else
    {$manuallyfix+=$app.name+"`n"}

}

write-host "`n`nManually fix these apps: `n"

$manuallyfix


Friday, July 29, 2016

Internet Explorer End of Life Nag

I was at a customer that recently complained that many of their Internet Explorer applications hosted on Citrix XenApp were opening additional tabs for users asking for Internet Explorer to be upgraded. This as it turns out is by design from Microsoft. As of January 2016 IE 8-9-10 are no longer receiving updates from the software giant. They want everyone to move to Internet Explorer 11. This nag screen is actually part of the last update to each to of the legacy browsers - so it is 100% by design.

Of course many enterprise applications were written to work with older versions of IE and development or testing cycles may not be available to simply upgrade. So how to get around this nag window? Fortunately Microsoft has enabled a new feature control registry value that can override this default option. Full details can be found here. I have included the snippet regarding x64 configuration below. Throw this in a group policy preference and apply where needed - no more nag screens!

For x64-based systems

  1. Click Start, type regedit in the Start Search box, and then click OK.
  2. Locate the following registry subkey:
    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl
  3. Right-click FeatureControl, point to New, and then click Key.
  4. Enter FEATURE_DISABLE_IE11_SECURITY_EOL_NOTIFICATION, and then press Enter to name the new key.
  5. Right-click FEATURE_DISABLE_IE11_SECURITY_EOL_NOTIFICATION, point to New, and then click DWORD (32-bit) Value.
  6. Enter iexplore.exe, and then press Enter to name the new value.
  7. Right-click iexplore.exe, and then click Modify.
  8. In the Value data box, enter 00000001, and then click OK.
  9. Locate the following subkey:
    HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Internet Explorer\Main\FeatureControl
  10. Right-click FeatureControl, point to New, and then click Key.
  11. Enter FEATURE_DISABLE_IE11_SECURITY_EOL_NOTIFICATION, and then press Enter to name the new key.
  12. Right-click FEATURE_DISABLE_IE11_SECURITY_EOL_NOTIFICATION, point to New, and then click DWORD (32-bit) Value.
  13. Enter iexplore.exe, and then press Enter to name the new value.
  14. Right-click iexplore.exe, and then click Modify.
  15. In the Value data box, enter 00000001, and then click OK.
  16. Exit Registry Editor, and then restart the browser to enable the new key.

Wednesday, July 27, 2016

XenDesktop 7.x Database Maintenance & Considerations

I recently spent time with a client having SQL issues related to XenDesktop. As it turns out they were exhausting transaction log space. I figured I would throw together a post about some of the considerations and best practices I have seen around this topic.

Considerations N'at

  1. Monitoring: 
    • First and foremost, whatever you design, something-will-fail-eventually. I cannot stress monitoring enough. From simple OS-level monitors such as disk space and event log scraping to more-in-depth (and expensive) end-to-end monitoring solutions. My personal favorites over the years have been ControlUp and Solarwinds. You can write your own via PowerShell with a little research if you can't spring for a third-party product. I just can't harp on this item enough.
  2. One-or-many? 
    • It is recommended to separate the 3 primary DB data sources into separate actual databases. A Site, Logging, and Monitoring DB. In the latest versions this is the option up front. Original releases this had to be done after the site was deployed. 
  3. The Databases:
    1. Site: 
      • Size corresponds to user activity (since session information is tracked). Peak usage = peak size.
      • Two-days worth of connection data is kept in the site DB, thus the largest size will be achieved two days after peak user connectivity.
      • Activity is greatest during high login periods as information is frequently requested.
      • An outage to this DB can cause the inability to launch sessions (session leasing not withstanding)
    2. Logging: 
      • Historical logging of site changes
      • Sizing is not predictable as it depends on the number of changes in the site (including administrative actions in Director)
      • Low I/O needs
      • There is no retention policy so old data must be purged manually.
      • If site policy does not allow changes to be made without the logging DB present, no site reconfiguration will be allowed. 
    3. Monitoring:
      • Used by Director to display data. 
      • Max size is determined by retention period (7 days for non-platinum; platinum defaults to 90 and is configurable). Peak size will be when this period is reached.
      • Data is collected in a manner that limits transactions, thus lowering I/O needs
      • Data flushing occurs overnight. 
      • An outage prevents collection of historical data
  4. The TempDB:
    • The SQL Temporary DB impacts the performance of SQL and the performance of XenDesktop. Usually I will configure SQL with specific drives for Data, Logs, Backups (depending on solution), and the TempDB. This allows for flexibility in regards to sizing and performance. The purpose of the TempDB is to eliminate locks on the Site DB (and others) which in a large scale environment could lead to slow performance. This DB is usually small, and a sizing guide is in the references section. 
  5. Use Read-Committed Snapshot Isolation:
    • Say what? In short, this isolation improves performance, particularly during intense login periods. If you have a larger environment, users of Studio and Director will thank you.
  6. Sizing:
    • As much as I would love to write a novel about DB sizing - the below table from the Citrix document linked under references sums up a ballpark for your site-DB sizing needs. The other DBs are tougher to predict and should be monitored and are more variable. The Monitoring DB will likely grow the largest of all three. There are some estimates in the sizing guide on pages 6 & 7 if review is desired.
  7. CPU Usage:
    • Summary of Citrix's intensive testing of SQL performances recommends a single quad-core SQL server for XenDesktop deployments. 
  8. DB Maintenance:
    • Usage of DB Mirroring or Always-On features results in full transaction logging mode. This results in the transaction logs of all three DBs to continue to grow until a log backup is taken. This will cause issues without monitoring (disk space utilization, performance).
    • It is recommended to back up transaction logs regularly if utilizing one of the mentioned high availability methods. This could be done with scheduled backups or with SQL Server Agent. 
    • Citrix recommends Index rebuilds occur over night or on weekends. Page 13 of the Sizing Guide provides more details on scripts for this. (They actually recommend using the Windows Server Update Services script modified for XenDesktop.)



References (just so you know I didn't make all of this up).

Saturday, November 29, 2014

Disappearing Citrix Policies?

Ever have your Citrix policies disappear for some unknown reason? You may need to update your Citrix policy engine. 

Symptom:
  • Your Citrix Policies disappeared – shortly followed by lots of cursing.


Issue:
  • During times of high memory consumption the policy engine can truncate Citrix policies thus leaving your environment without them.


Impact:
  • Any XenApp 6.5/XenDesktop 5.5/6 Farm. Both AppCenter/Studio IMA and Microsoft Active Directory based policies will be deleted.


Resolution:
  • Install http://support.citrix.com/article/CTX140488 on ALL workstations used to manage Citrix policies. This is a Limited Release Hotfix, but given the nature of the issue it resolves, I recommend pre-emptive installation when appropriate. Recovery of lost policies is not part of this release – that requires either a manual backup from before they were lost and subsequent restoration; or in the case of IMA policies a backup of the DB from which one may restore settings.


Office 2013 over VDI

If you plan to deploy Microsoft Office 2013 over VDI keep an eye out for issues with screen flickers or audio pops. These are a side effect of a default Office option for hardware acceleration.


Issue:
  • When using XenDesktop/XenApp 7.x with Office 2013 installed, there can be speaker popping, Office application windows can randomly go black, and there can be screen flickers.


Reason:
  • Hardware acceleration with Office 2013


Resolution:
  • On clients (server or desktop OS) with Office 2013 deployed: disable hardware graphics acceleration. 

This checkbox is available in all (I believe, only checked Outlook, Excel, and Word) the Office applications.

This setting may also be applied via the Office ADMX template in Group Policy.

Reference: KB2768648

Thursday, October 30, 2014

Need Windows Search with PVS?

By default the optimization wizard for imaging XenApp/XenDesktop server and desktop operating systems disables Windows Search features. This is a best practice from Citrix. In some cases users may need this functionality. If you need to turn it on, be sure to utilize the group policy below to adjust the scanned areas and limit the scope of indexing as much as possible.

A reason why you may need to enable search? Disabling Windows Search will disable search features in Outlook 2013.

Keep in mind that the Windows Search feature works with the Indexing Service, which is also disabled.

For details on both of these services and their impact, review the Optimization Guide linked below.

Group Policy for Windows Search

Optimization Guide

Thursday, July 17, 2014

First Recommended Hotfixes for XenDesktop/XenApp 7.5 Released

On July 10th the first recommended hotfixes for XenDesktop 7.5 were released. Additionally, on today July 17th, a private hotfix to fix the policy management console was finally released. Hopefully this will go public soon as I have run into the errors outlined in that hotfix on numerous occasions. 

Citrix recommended hotfixes from are in bold. 

Delivery Controllers Hotfixes

(Version 7.5.1) (For: Citrix Studio 7.1 and 7.5) (x86 if required: DStudio750WX86001)
  1. This fix addresses a memory issue in an underlying component.

Limited Release: Hotfix GPMx220WX64001 
(Computers running the 64-bit version of Windows 7, Windows 8, Windows 8.1, Server 2008 R2, Server 2012, or Server 2012 R2, with the Group Policy Management Console installed)
  1. The priority order of GPOs is reversed in the following scenarios:
    • After upgrading from Version 1.7 to Version 2.1 of the Citrix Group Policy Management Console.
    • After exporting GPOs from Version 1.7 or earlier of the Citrix Group Policy Management Console and importing them into Version 2.1 or later of the Citrix Group Policy Management Console. 
    • Note: This fix does not address the issue for GPOs that were modified using Version 2.1 of the Citrix Group Policy Management Console; it will prevent the issue only with GPOs you modify going forward. To fix the reversed priority order of existing GPOs you modified in Version 2.1 of the Citrix Group Policy Management Console, you must manually adjust the priority order of the affected GPOs once you install this fix.
  2. When making changes to Citrix policies in Citrix Studio the following error message appears:
    • "Changes made to policies outside of this console, such as in PowerShell or management tools from previous versions, resulted in a discrepancy between policies.
    • The priorities for policy [PolicyA's name] and policy [PolicyB's name] interfere with each other in the "user" and "computer" components. The priorities must be assigned in the same order for both policies."
    • Note:
      • This fix prevents any issues occurring with merged policies. If the error message appears before applying the fix, then you must manually adjust the priority order after installing this fix.
        • For example, if two merged policies, PolicyA and PolicyB, are swapped and a user setting is added to PolicyB, the issue occurs. To prevent the issue from occurring, run the following commands on Citrix Delivery Controller:
          PS>Add-PSSnapin Citrix.Common.GroupPolicy
          PS>New-PSDrive Site –PSProvider CitrixGroupPolicy –Root \ -Controller localhostPS>cd Site:\Computer[Note the PolicyA's computer setting priority]PS> cd ..PS>cd Site: \UserPS>Set-ItemProperty PolicyA -Name Priority -Value [PolicyA's computer setting priority]
      • You can configure user and computer settings in the same policy and both settings can have the same priority order. Occasionally, the priorities for the settings might be different. 
        • For example, PolicyA and PolicyB have the same user and computer settings, but the computer setting priority of PolicyA is higher than PolicyB. In this instance, configure the user setting of PolicyA to be higher than PolicyB.
  3. After editing the built-in "Unfiltered" policy, the following error message appears:
    • "Changes made to policies outside of this console, such as in PowerShell or management tools from previous versions, resulted in a discrepancy between policies.
    • The Enabled Flag for the "user" and "computer" components of the policy Unfiltered must have the same value."
    • Note: This fix prevents any issue occurring with unfiltered policies. If the error message appears before applying the fix, you must manually enable the flag of the "Unfiltered" policy by using PowerShell commands (cmdlet) after installing this fix.
      • For example, if "Unfiltered" has only computer settings configured and the Enabled flag is clear, run the following commands in Citrix Delivery Controller:
        PS>Add-PSSnapin Citrix.Common.GroupPolicy
        PS>New-PSDrive Site -PSProvider CitrixGroupPolicy -Root \ -Controller localhostPS>cd Site:\UserPS>cd Site:\User\UnfilteredPS>Set-ItemProperty . -Name Enabled -Value True
  4. The following error message appears when opening the Citrix Studio and selecting the policy node:
    • "The priority of the "user" and "computer" components of policy <policy name> must have the same value."

Desktop OS x86 & x64 Host Hotfixes

(Server or Desktop VDA x86) [x64 if ever needed see server section]
  1. This fix addresses a session brokering issue.

(Desktop VDA x86) [x64 if ever needed: XD710ICAWSWX64005]
  1. COM port redirection can fail after upgrading Version 5.1 of VDI-in-a-Box to Version 5.3.
  2. This fix addresses various session brokering issues.

(Desktop VDA x86) [x64 if ever needed: XD710ICAWSWX64004]
  1. This enhancement provides additional compatibility with Nvidia's GRID API related to GPU pass-through and vGPU use cases.

(Desktop VDA x86) [x64 if ever needed: XD710ICAWSWX64001]
  1. In Cisco WAAS deployments, the session reliability feature fails to automatically reconnect sessions dropped from VDAs.
    To enable this fix, you must set the following registry key on affected VDAs and then restart those systems:
    HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\XTEConfig
    Name: CgpDisableBranchRepeaterSessionReliability
    Type: REG_DWORD
    Data: 1 (enabled); 0 (disabled)

(Desktop VDA x86) [x64 if ever needed: ICAWS750WX64007
***Replaces XD710ICAWSWX86002, XD710ICAWSWX86003
  1. In sessions on VDAs with Desktop Composition Redirection enabled (default) and Fix #LA5736 (XD710ICAWSWX86003) installed, the mouse pointer might not honor the boundaries of the desktop.
  2. (from replaced hotfix) This enhancement provides better performance when running VDAs on hosts with AMD or Intel graphics (for example, physical PC, pass-through GPU, or vGPU).
  3. (from replaced hotfix) Mouse pointer movement is not visible in the Lync conversation window if you share your virtual desktop.
  4. (from replaced hotfix) After a virtual desktop session reconnects, the VDI log on dialog box does not appear and Lync in the virtual environment is no longer paired with the Lync VDI plug-in.

Server Session Hosts x64 Hotfixes

(Server or Desktop VDA x64)
  1. This fix addresses a session brokering issue.

(Server VDA x64)
  1. In Cisco WAAS deployments, the session reliability feature fails to automatically reconnect sessions dropped from VDAs.
    To enable this fix, you must set the following registry key on affected VDAs and then restart those systems:
    HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\XTEConfig
    Name: CgpDisableBranchRepeaterSessionReliability
    Type: REG_DWORD
    Data: 1 (enabled); 0 (disabled)
(Server VDA x64)
  1. Attempts to open Microsoft Office files in a virtual desktop session might take a longer time to open. Additionally, when a published application is started and then minimized, it can no longer be restored or maximized from the taskbar.

(Server VDA x64)
  1. Certain session time limit policies of Remote Desktop Services might fail to work on Windows Server 2012 VDAs.
  2. The Citrix "Server idle timer interval" policy in Citrix Studio does not work for Windows Server 2012 VDAs.

Limited Release: Hotfix XD710ICATSWX64003 
(Server VDA x64)
  1. The session graphics of certain applications can fail to update. As a result, the session appears frozen.
  2. With the default graphics mode enabled, certain applications can prevent screen updates. As a result, the session can appear unresponsive.

Limited Release: Hotfix XD710ICATSWX64005 
(Server VDA x64)
  1. The Citrix Audio Service exits unexpectedly when logging off from the server.

Limited Release: Hotfix ICATS750WX64007 
(Server VDA x64) 
***Replaces: XD710ICATSWX64002

  1. The Windows Event Viewer occasionally displays the following error message with Event ID 9026. The error is benign and can safely be ignored.
  2. "Error %1 received while obtaining a license for a Citrix XenApp client connection. A grace license has been granted."
  3. (from replaced hotfix) Certain session time limit policies of Remote Desktop Services might fail to work on Windows Server 2012 VDAs.
  4. (from replaced hotfix) The Citrix "Server idle timer interval" policy in Citrix Studio does not work for Windows Server 2012 VDAs.



 References: