Logging into a new XenDesktop session users randomly appear to be stuck on Microsoft Windows logon screen “Applying Group Policy Registry Policy”. However when adjusting the size from window mode to full screen or Full screen to window mode the screen refreshes and users are already logged in and able to start working.

Solutions to correct this are:

• Create a Citrix Policy to Disable Desktop Composition Redirection.
• Enable legacy graphics mode.
• Disable Desktop Window Manager Session Manager.
• Update the VDA version to Feature Pack 3. – Still validating if this is a fix.

Recently I was working on a XenDesktop 7.6 project where we were seeing virtual machines continuously powering on and off occur when more than one machine catalog was added to a delivery group.

Looking at the event logs on the Delivery Controllers, we noticed Event 3013 occurring every couple of minutes (Idle Pool TurnOn and Idle Pool initiated Shutdown).

Event ID 3013-Citrix Broker Service

The Citrix Broker Service successfully performed power action ‘TurnOn’ (origin: IdlePool) on virtual machine ”Domain\Machine Name’.

Event ID 3013-Citrix Broker Service

The Citrix Broker Service successfully performed power action ‘Shutdown’ (origin: Untaint) on virtual machine ‘Domain\Machine Name’.

Our delivery groups are set to ShutDownAfterUse so this would appear to be normal at first glance, but with all the virtual machines being shut down and powered on we were starting to get a lot of unregistered machines and the amount significantly increased when users logged off during shift changes.

To see details on Power Actions being sent to VMware Virtual Center I ran Get-brokerhostingpoweraction -State ‘Pending,Started’ and saw there were 500+ pending power actions queued up.

Citrix PowerShell Reference

Power Actions Script

Next step was to clear up the pending queue as fast as possible before users started calling in with issues connecting to their desktop so I increased the Hosting Connection Maximum new Actions per minute to 45 to temporarily fix the issue of unregistered virtual machines during shift change and clear out the pending actions.

I don’t recommend changing the default value unless you have the hardware and resource to be able to support it.

I first notice the issue when I logged into Virtual Center. I knew something wasn’t right when you continuously see Power On/Initiate Guest OS Shutdown initiated by the XenDesktop Hosting connection service account at continuously occurring. The screenshot only shows events from our testing. In production we saw Power On and Shutdown’s occurring almost every minute.

I still needed to find out why there were so many virtual machines turning off and on when our power policy was set to keep all virtual machines power on 24/7.

Reviewing the power policy and all the relevant Citrix documentation on idle pool management it appeared that we had everything set correctly so I decided to verify that adding more than 1 machine catalog to a delivery group caused our virtual machines to power cycle.

I started with one machine catalog with 500 virtual machines and added that to a new delivery group. Next, I adjusted the power policy to keep the virtual machines always powered on 24/7. After waiting 30 minutes I monitored virtual center tasks & events to see if any virtual machines were being shut down by the hosting connection service account. There were no Initiate Guest OS Shutdown or Power On virtual machine events for 24 hours.

After 24 hours of no power actions occurring, I created another 2 Machine Catalogs with 500 virtual machines each and added these virtual machines to the existing Delivery group with 500 virtual machines. A total of 1500 machines were added to the delivery group and the power policy was adjusted to turn on all 1500 virtual machines and keep them on 24/7.

As soon as these new machines were added we started seeing virtual machines shutting down and powering on randomly.

Machine Catalogs-

Delivery Group-

I also tried adjusting the default values from 10 to 100 for PeakBufferSizePercent and OffPeakBufferSizePercent.

Set-BrokerDesktopGroup “Desktop Group Name” –PeakBufferSizePercent 100

Set-BrokerDesktopGroup “Desktop Group Name” –OffPeakBufferSizePercent 100

Set-BrokerDesktopGroup “Desktop Group Name” –ShutDownDesktopAfterUse $True

Set-BrokerDesktopGroup “Desktop Group Name” –AutomaticPowerOnForAssignedDuringPeak $True

http://support.citrix.com/article/CTX136576

The changes above did not correct our issue and were changed back to the default values.

One other recommendation was to change the MaxRegistrationDelayMin value, but the default is 20 minutes so this was not the problem. We would have seen several virtual machines listed as Powered ON but unregistered.

After all the troubleshooting that we went through here are the 2 recommendations on how to fix this issue-

1. Install the recently released Citrix Public Hotfix Update 3 on your delivery controllers which will allow you to use 1 machine catalog with more that 999 virtual machines. Before this public fix was released you would need to request the private hotfix from Citrix.#LC2873. http://support.citrix.com/article/CTX201881
2. Create a machine catalog of 999 and only one delivery group of the same. Set up your Machine Catalogs and Delivery Groups so that there is always a 1 to 1 relationship. Machine Catalog A virtual machines are added to Delivery Group A, Machine Catalog B virtual machines are added to Delivery Group B.Separate the users into new security groups and add those to the new delivery groups.

Machine Catalog Limits

Outlook has been randomly crashing for some of our users after we applied our monthly Microsoft patches with RTFHTML.DLL and ACTIVEDS.DLL error messages below when they are performing standard tasks such as viewing emails or trying to print.

To fix the issue, we added the following registry keys to our XenDesktop Windows 7 and Windows 2008R2 Images.

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\CtxHook

Vaule Name: ExcludedImageNames

Value Type: REG_SZ

Value Data: Outlook.exe

HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\CtxHook

Vaule Name: ExcludedImageNames

Value Type: REG_SZ

Value Data: Outlook.exe

XenDesktop sessions were not updating their time even after all the correct policies were configured in Citrix Policies and Microsoft Group Policy. This only occurred from workstations in one building and not all our computers across the enterprise. We knew the issue was most likely caused by something on client device.

Installing this Cumulative time zone update corrected the issue when users logged into XenDesktop 7.6. On a side note-We did not see time zone issues when they logged into a XenApp 6.5 Published desktop.

Client Side fix was to install a Microsoft update for time zone information.

December 2014 cumulative time zone update for Windows operating systems

https://support.microsoft.com/en-us/kb/3013410

To correct the issue with screen savers and power-save options in XenDesktop and XenApp 7 add this registry key to your virtual machines or master image.

Hive HKEY_LOCAL_MACHINE
Key path SOFTWARE\CITRIX\GRAPHICS
Value name SetDisplayRequiredMode
Value type REG_DWORD
Value data 0x0 (0)

There are no apps or desktops available to you at this time.

Root cause of this issue was the SQL database transaction log was set to autogrow and filled up the disks. The servers ran out of disk space causing all new logins to fail to enumerate applications and desktops. Existing sessions were not affected.

This fix addresses a session brokering issue.[From ][#LA4447]

(Superseded by BrokerAgent750WX64003)

Here is the response I got from Citrix support.

http://support.citrix.com/article/CTX140723 addresses the session brokering issue and update all the .dll and .exe files mentioned.

It addresses the following scenario:

If a VDA launch is terminated before it is completed and desktop is made available to user, after the credentials were submitted for login to the VDA, the ICA session on the VDA is cleaned up and the VDA becomes available for brokering again.

But logon will continue for the user who submitted the credentials and will be logged in to the console. If this VDA gets brokered to another user, this second user gets the logged in desktop of the first user.

Vulnerability in Citrix XenDesktop could result in unauthorized access to another user’s desktop-

http://support.citrix.com/article/CTX139591

https://support.citrix.com/article/CTX127842

Citrix Hotfix Discussions

The hotfixes for Citrix XenDesktop 7.1 and 7.5 can be downloaded from the following locations:

CTX140362 or CTX140363

One of our clients had an old version of Sage PeachTree that they wanted installed in their XenDesktop image.

After installing the application and restarting the XenDesktop virtual machine I notice the virtual machine showed unregistered in the Delivery Group.

Logging in to the VM and checking the event logs didn’t give much details to why registration failed.

The fix was to run command prompt as administrator and execute lodctr /r then restart the virtual machine.

As soon as it started back up and registered with the Delivery Controller successfully, however every time we rebooted again the virtual machine became unregistered again.

This left us with a couple options-

1. Uninstall Peachtree and let the customer know that it breaks the XenDesktop VDA.
2. Ask them to upgrade the software to the latest version.
3. Open a support request with Sage for an application that is out of support.
4. Configure a GPO with a startup script to run lodctr /r.

We went with option 4 as this was the quickest and easiest way to allow the customer to use their application and maintain registered VMs.

Using System Center Endpoint Protection Anti-Virus with XenDesktop and PVS.

In most environments you want your workstations and servers to be running current AV definitions so the challenge with using PVS images is that your virtual machines would have to download new definition updates every time they restarted. This can cause multiple performance issues if you have a decent amount of virtual machines starting up and rebooting.

To prevent performance issues from occurring you have a couple options. You can disable automatic updates and manually update your images with new definition files or you can redirect your Anti-Virus definition folder location to the write cache drive. Keeping your definitions on the write cache drive will allow your virtual machines to have the latest updates and persist on reboot.

Antimalware Policy-

Exclusion Settings- Add recommended exclusions from http://blogs.citrix.com/2013/09/22/citrix-consolidated-list-of-antivirus-exclusions/  and any other exclusions that you need for your specific environment.

Scan Settings-

Run a scheduled scan on client computers = No.

User control of scheduled scans= No control

Advanced-

Disable the client user interface=Yes

Allow users to exclude files and folders, file types and processes.=No

Set Randomize schedule scan and definition start times (within 30 minutes) = Yes

Definition Updates- 

Check for Endpoint Protection definitions at a specific interval=

Check for Endpoint Protection definitions daily at=

Force a definition update if the client computer is offline for more that two consecutive scheduled updates.=No

Set your source and order for Endpoint Protection definition updates=Configuration Manager, or WSUS.

Base Image changes-

Redirect all SCEP signatures/definitions to the write cache drive so updates persist after reboot.

If SCEP is already installed then Uninstall SCEP.
Delete C:\ProgramData\Microsoft\Microsoft Antimalware folder.
Reboot VM.
Create a folder for definitions on your write cache drive.
Open CMD Line with Administrator rights.
Change path to C:\ProgramData\Microsoft\
Mklink /d /j “Microsoft Antimalware” E:\SCEP
Install SCEP
Reboot
Run updates, scan and install latest SCEP

Remove Unique Virtual Machine Registry Keys-

Since the SEP client is embedded in the OS image, delete the following registry keys that are unique to the virtual machine before sealing up the image.

1. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Antimalware\InstallTime
2. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Antimalware\Scan\LastScanRun
3. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Antimalware\Scan\LastScanType
4. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Antimalware\Scan\LastQuickScanID
5. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Antimalware\Scan\LastFullScanID
6. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\RemovalTools\MRT\GUID

XenDesktop Session Launches Then Disappears

You can update the AutoLogonTimeout registry key, however if your logins are taking longer than 90 seconds you should dig into why logins are so slow.  XenDesktop and XenApp logins should on average take around 30 seconds from launch to being able to work within the desktop or application.

If your logins are are slow, start by taking a look at the Citrix Director and see where slow point is happening in the login process. Director will give you a good starting place.

Location: HKLM\SOFTWARE\Citrix\PortICA
Value: AutoLogonTimeout
Type : DWORD

90 is default. If your modifying this value it should be higher than 90.

Try logging in through the console to get an estimated time it takes to login then modify the value accordingly.

https://discussions.citrix.com/topic/371738-timeout-during-profile-load-in-xendesktop-76/

VDI Session Launches Then Disappears

When you are utilizing a Netscaler load balancer for your XenApp XML Brokers or XenDesktop Delivery Controllers I recommend changing these settings in your web.config file.

Open the web config file with NotePad from C:\inetpub\wwwroot\Citrix\StoreName\web.config.

Change LoadBalance=”on” to LoadBalance=”off”.

Default is ON.

Next change you will want to make is to change bypassDuration=”60″ to bypassDuration=”0″. If the Netscaler LB is monitoring the XML/DDC brokers then the Netscaler will direct connections to the XML/DDC servers that are available. There’s no reason to bypass the single VIP for 60 minutes unless you want your users to have issues logging in.

Configure server bypass behavior:

To improve performance when some of the servers providing resources become unavailable, StoreFront temporarily bypasses servers that fail to respond. While a server is being bypassed, StoreFront ignores that server and does not use it to access resources. Use these parameters to specify the duration of the bypass behavior:

Cant Login to Citrix XenDesktop 7 Studio-

Opening up Citrix Studio users got the following error message when opening Citrix Studio “You do not have sufficient permissions to administer this Site using Studio.”

Event logs from the two Citrix Delivery Controllers showed an issue with the Citrix Configuration Service.

Event ID 1030 Citrix Configuration Service-

Otherwise unhandled exception in WCF call : Citrix.Fma.Sdk.ServiceCore.AuthorizationFailureException: Failed to authorize operation GetServiceStatus. CheckGlobalAccess failed.
at Citrix.Configuration.DelegatedAdminProvider.DemandPermission(String operation)
at Citrix.Fma.Sdk.ServiceCore.LogicBase.DemandPermission(String operation, ServiceRegistrationStates localAdminStates)
at Citrix.Fma.Sdk.ServiceCore.ServiceBase.<>c__DisplayClass10.<GetServiceStatus>b__f()
at Citrix.Fma.Sdk.ServiceCore.ServiceBase.CheckedCall[T](String name, Func`1 operation, Func`2 defaultValue, Enum code)

Event ID 1030 Citrix Configuration Service-

Otherwise unhandled exception in WCF call : Citrix.Fma.Sdk.ServiceCore.AuthorizationFailureException: Failed to authorize operation GetRegisteredServiceInstance. CheckGlobalAccess failed.
at Citrix.Configuration.DelegatedAdminProvider.DemandPermission(String operation)
at Citrix.Fma.Sdk.ServiceCore.LogicBase.DemandPermission(String operation, ServiceRegistrationStates localAdminStates)
at Citrix.Configuration.Logic.CommonGetScopeIds(String operationName)
at Citrix.Fma.Sdk.ServiceCore.LogicBase.CommonGet(String operationName, IDictionary`2 arguments, IDictionary`2 variables, String[] propertyList, Int32 skip, Int32 maximumResultCount, Boolean returnTotalAvailableResultCount, Int32& totalAvailableResultCount, Object[]& records)
at Citrix.Fma.Sdk.ServiceCore.ServiceBase.<>c__DisplayClass1.<CommonGet>b__0()
at Citrix.Fma.Sdk.ServiceCore.ServiceBase.CheckedCall[T](String name, Func`1 operation, Func`2 defaultValue, Enum code)

Troubleshooting the issue, we first verified the SQL Servers, database permissions and ports were open between the Delivery Contollers and SQL servers.

Next step was to confirm applications and desktops launched and users were not experiencing issues.

After confirming that the permissions issue was only causing issues when accessing Studio or Director we restarted one of Delivery Controllers and attempted to launch studio again, but still received the same error.

Digging into the issue further I downloaded CDFContol to see if I could find more details on the permissions error.

Open CDF Control>Select All Modules. Next click Start Tracing.

Open Citrix Studio on your Delivery Controller and reproduce the error. After you reproduce the error go back to the CDF Control Program and click Stop Tracing.

Click Save Viewer Output, type a name for the file and click save.

After saving the output, Open the CSV file to view the contents. Scroll down to the approximate time that you reproduced the error to see if there’s any additional information on why your getting “You do not have sufficient permissions to administer this Site using Studio.”

In our file CDF Trace file, I noticed the error below which shouldn’t be occurring when opening Citrix Studio. The account I was accessing Citrix Studio with, and the Delivery Contollers, and SQL servers are all on the same domain.

“The trust relationship between the primary domain and the trusted domain failed.”

” at System.Security.Principal.SecurityIdentifier.Translate(Type targetType) at Citrix.ConfigurationLogging.ActiveDirectory.UserNameResolverImplementation.GetSAMNameFromWindows(SecurityIdentifier sid, String& samName)”,””

48,3,2016/01/05 01:40:34:97549,15268,15188,0,ConfigurationLoggingLog,_#dotNet#_,0,,1,CDF_NET_ERROR,”GetSAMNameFromWindows() failed: System.SystemException: The trust relationship between the primary domain and the trusted domain failed.”

However we in this environment we have a couple domain trusts and after looking through the event logs on our domain controllers it appears that there was a broken trust with another domain. In the System Log there were several Event 5719.

After correcting the issue with the Active Directory trust, I reopened Citrix Studio and we were able to  successfully manage the XenDesktop site.

I will be updating this post as soon as I find out why a failed domain trust would lock all users out of Citrix Studio. All the XenDesktop Full Admins are members of the same domain as our Delivery Controllers, so the Citrix Delegated Admin service shouldn’t be trying to check the SID of the user against other domains.

I just completed a couple XenDesktop 7.7 Site upgrades and had experienced some mixed results with Zones showing up in Citrix Studio.

Upgrading XenDesktop 7.5 to XenDesktop 7.7 went smooth and completed quickly. So far I haven’t had any issues related to the upgrade. Based on the known issues in edocs that the RoleConfig is not always applied during upgrade, I launched Citrix Studio and verified that the Zones node was visible.

My second upgrade from XenDesktop 7.6 Site to XenDesktop 7.7 finished quickly on the first Delivery Controller. On the second Delivery Controller the installation ended up taking a lot longer to complete, but finished successfully without error.

After the first XenDesktop Delivery Controller and Site Database was upgrade, I noticed in Citrix Studio that the Zone node was missing under configuration. Before running the recommended PowerShell command line listed in Citrix eDocs, I waited for the secondary controller to finish and verified Zones was also missing when launch Studio.

Citrix XenDesktop 7.7 Known Issues

New RoleConfig is not always applied during upgrade. This results in zones not appearing in the Studio display.  Workaround: Run the following command in PowerShell (note the directory) [#610875]:
PS C:\Program Files\Citrix\XenDesktopPoshSdk\Module\Citrix.XenDesktop.Admin.V1\Citrix.XenDesktop.Admin\StudioRoleConfig> Import-AdminRoleConfiguration .\RoleConfigSigned.xml

After running the command. I opened Citrix Studio on both Delivery Controllers and the Zone node was visible.

Citrix XenDesktop 7 PVD Image Update Monitoring Tool

If you want to view the status of your Citrix PVD Image updates there is a tool that Citrix provided on the XenDesktop installation media. It’s a GUI based tool that is very simple to use.  The PVD Tool provides information for all your Citrix Machine Catalogs and gives you insight into the following items: Errors, Low Disk Space, Completed/Updated, Updates In Progress, and Pending Updates.

The Citrix PVD Image Update Monitoring tool also logs all the information into 2 text files in the directory that you launched the tool from.

Two files are created after launching the tool.

PVDToolLog.txtPvdToolErrorLog.txt

Before you start using the Citrix PVD Image Update Monitoring Tool, verify WinRM is enabled. If you need to enable it on your XenDesktop VM’s you can create a GPO.

Configure WinRM using Group Policy and Link the GPO to the correct OU.

1. Set the WinRM service to auto start:
   a.    In the Group Policy Editor, navigate to Computer Configuration> Policies > Windows Settings > Security Settings> System Services.
   b.    Double-click Windows Remote Management (WS-Management) and set it to Automatic.
   
2.   Create the WinRM listener:
   a.    In the Group Policy Editor, navigate to Computer Configuration >Policies > Administrative Templates > Windows Components > Windows Remote Management (WinRM) > WinRM  Service.
   b.    Double-click Allow automatic configuration of listeners and configure the IPv4 filter to *.
   
3. Create a firewall exception for WinRM:
   a.    In the Group Policy Editor, navigate to Computer Configuration> Policies > Windows Settings > Security Settings> Windows Firewall with Advanced Security.
   b.    Create an Inbound Rule for WinRM for port 5985.
4. After configuring the preceding three group policies, restart the server to update the group policies and start the WinRM service.

To start using the tool, navigate to the Support\Tools\Scripts\PVDTool folder and copy the files or folder to your Citrix Delivery Controller.

Launch the PVDTool.exe and click on the Machine Catalog that your updating to start viewing update status.

Machine PVD Errors Tab View- Machines that failed during the image update process.

Updated Tab View- Machines that have been successfully updated

Low Disk Space Errors Tab View- Machines that have not have failed yet but have less than 1GB of space remaining.

Pending Updates In Progress Tab View- Machines with an image update pending. The Citrix Delivery controller is waiting for the VMs to start up.

If you want to adjust any thresholds you can edit the PVDTool.exe.config file with notepad.

<appSettings>
<add key=”RefreshFrequency” value=”120″/>
<add key=”CatalogRefreshFrequency” value=”120″/>
<add key=”NumberOfThreads” value=”8″/>
<add key=”LowDiskSpaceThresholdPvdDrive” value=”1024″/>
<add key=”LowDiskSpaceThresholdSystemDrive” value=”1024″/>
<add key=”ClientSettingsProvider.ServiceUri” value=””/>
<add key=”DDCAddress” value=”localhost”/>
</appSettings>

XenDesktop VM Hosted Applications

One of the last applications we had left to migrate off of our legacy XenApp 5 farms was Synapse. This is one of those really fun applications that only works one specific way and has ties into Internet Explore.

Since we already had the application installed in our base Window 7 XenDesktop Image and the application doesn’t work correctly with Windows Server 2008R2 we decided to do VM Hosted Apps. The staff wanted to be able to launch just the Application and not the full desktop.

I configured a Synapse / PACs VM hosted application and set Keywords:Auto to reduce time and clicks required to launch this application. We also had the icon on the desktop and Start Menu, but sometimes people just prefer a published application over a full desktop.

One of our top priorities is to provide the best user experience we can which ultimately increases end user productivity, reduces complaints and requires less end user training and troubleshooting.

To get started on configuring the Synapse VM hosted application follow the directions below.

1. Open Citrix Studio. Right Click on the delivery group that you want to present applications from and select Edit Delivery Group.

2. Change the Delivery Group Type to “Desktop and Applications”.

3. Next step is to right click on the delivery group and click Add Applications.

4. Click Next at the Getting Started with Applications window.

5. Select the application you want to publish from the list and then click on Application Properties.

6. Modify the application properties. Description and Keywords, Application Name for the users, Application Name for Administrators. (Application Name for Administrators is a useful feature if you have multiple versions or the application configuration is different for other locations or departments and you want to be able differentiate them in the console view.)

7. Modify the Application Delivery Location Information- Path to the executable file, Command line argument, and working directory if needed.

8. Change visibility if to the users or security group that needs access to the new Synapse published application. Click OK when finished with your changes.

9. If you have separate folders for your applications click change and select the folder you want to place the application in. When finished, click next to continue publishing the Synapse application.

10. Verify all the information is correct in the summary and click Finish.

11. Open up a web browser, login to StoreFront and launch the Synapse Cardiovascular published application.

During the upgrading of XenDesktop VDA from 7.7 to Citrix XenDesktop 7.8 I ran into an issue.

We don’t currently use Personal vDisks and the Personal vDisk check box was not selected when I ran the upgrade.

The following error occured. “Installation of MSI File ‘personalvDisk_x64.msi’ failed with code InstallFailure (1603).”

Installation of MSI File ‘PersonalvDisk_x64.msi’ failed with code InstallFailure (1603)

Error Id: XDMI:05A54B0F
Exception: Citrix.MetaInstaller.MetaInstallerException Installation of MSI File ‘personalvDisk_x64.msi’ failed with code ‘InstallFailure’ (1603).
at Citrix.MetaInstaller.Msi.InstallProduct(InstallationContext context, String msiPath, String parameters)
at Citrix.MetaInstaller.MsiComponent.Install(InstallationContext context)
at Citrix.MetaInstaller.InstallationManager.InstallComponent(IInstallableComponent component, InstallationContext installContext)

Installation Log-

XenDesktopSetup:About to install MSI File ‘C:\Windows\TEMP\Ctx-3A92CBD6-2410-4D61-8E95-38A2549C6113\Extract\Image-Full\x64\Virtual Desktop Components\personalvDisk_x64.msi’ using params ‘INSTALLLOCATION=”C:\Program Files\Citrix” ARPSYSTEMCOMPONENT=”1″ MSIFASTINSTALL=”1″ MSIRMSHUTDOWN=”2″ BASEIMAGE=”0″‘ log file is ‘C:\Users\%Username%\AppData\Local\Temp\Citrix\XenDesktop Installer\MSI Log Files\personalvDisk_x64936050165.txt’

11:23:50.4364       : XenDesktopSetup:Starting synchronous process ‘msiexec’ with args ‘/i “C:\Windows\TEMP\Ctx-3A92CBD6-2410-4D61-8E95-38A2549C6113\Extract\Image-Full\x64\Virtual Desktop Components\personalvDisk_x64.msi” /lv “C:\Users\%Username% \AppData\Local\Temp\Citrix\XenDesktop Installer\MSI Log Files\personalvDisk_x64936050165.txt” /quiet INSTALLLOCATION=”C:\Program Files\Citrix” ARPSYSTEMCOMPONENT=”1″ MSIFASTINSTALL=”1″ MSIRMSHUTDOWN=”2″ BASEIMAGE=”0″ CLOUD=False REBOOT=ReallySuppress’

I performed the following steps to correct this issue:

Downloaded the old Citrix XenDesktop VDA 7.7.

Extract the installer by going to the Start Menu > RUN.

Type in C:\CitrixVDA\VDAWorkstationSetup_7.7.exe /extract C:\CitrixVDA

Next go to Start Menu again and Click on RUN. Type in Regedit and click OK.  Navigate and scroll through the list until you find Citrix Personal vDisk.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\

Right click on UninstallString, click Modify and copy the value data.

Paste the ValueData MsiExec.exe /X{B5E79306-AE30-4906-8377-D21A7E03196F} REBOOT=ReallySuppress /qb! into the Run command window and click OK.

I was prompted to locate the installation source files which is why the Citrix XenDesktop 7.8 VDA failed to upgrade when the installer couldn’t uninstalled the old files correctly.

When prompted for the personalvDisk_x64.msi file, browse to the extracted installation files for the old VDA and click OK to continue.  This is the path that I extracted the VDA installer to. C:\CitrixVDA\Extract\Image-Full\x64\Virtual Desktop Components\WS.

After successfully removing this, I was able to rerun the Citrix XenDesktop 7.8 VDA installation successfully.

XenDesktop VDA Installation – Optional Components The exclude switch might have helped, but I didn’t get a chance to test.

How to Manually Uninstall Virtual Delivery Agent (VDA) Components

Beta VDA Removal Tool-

http://support.citrix.com/article/CTX209255

XenDesktop 7.8 Virtual Delivery Agent Upgrade

Start up your master/golden image and mount the XenDesktop 7.8 ISO. Click on AutoSelect.exe to begin the installation.

Click on Virtual Delivery Agent for Windows Desktop OS.

Select Automatically to accept the default Firewall Ports or Click Manually if you want to create firewall rules yourself. Click Next to continue.

Verify all the information is correct on the XenDesktop 7.8 VDA summary. Click Upgrade to start.

Wait for the Prerequisites, Core Components and Post Install to complete.

After the installation completes successfully. Click Finish and restart your virtual machine.

XenDesktop 7 Delivery Controller Address has Changed. Re-enter the controller address or try a new one.

Opening Citrix XenDesktop Studio displayed the following error message.

Valid Delivery Controller Services were not found at the specified location. Reason: Database could not be contracted. Check the status of the database on the SQL server. The database may not be allowing remote connections, make sure the database server is setup correctly and that the firewall is not blocking the connections.

XenDesktop Studio -View Error Details

After looking at the error details, I needed to gather more information and verify the issue was not caused by a change on the XenDesktop Delivery Controllers before contacting the DBAs. First thing I usually do is check the Event Logs and I noticed there were several 1201 events for Citrix AD Identity Service. The Connection to the database has been lost.

“Database Authentication failed”

I also tried entering another controller address, but got the same error message.  I also opened PowerShell ran the following command to get additional information.

asnp citrix*

Get-BrokerServiceStatus

Results showed DB rejected Connection-Login Failed for User “Domain\DDC host Name”

Since this was a newer environment, I suspected that the Citrix Delivery Controller Machine accounts weren’t added to all the SQL servers in the Always-On Availability Group. After checking with the SQL DBA’s, they had failed the databases over to do maintenance on one of the SQL servers and the machine accounts were not created on the new primary SQL server. As soon as they added the DDC Machine accounts, administrators were able to access studio.

Using the same image for multiple XenDesktop/XenApp sites.

Occasionally I have seen virtual machines attempt to register with the wrong site when doing a multi-site implementations and usually this is because the image has the ListOfDDCs incorrect. If you have already changed the ListOfDDCs and your virtual machines are still attempting to register with the wrong XenApp/XenDesktop site you will want to review and remove all items that refer to the previous site from your master image.

1. In the Unfiltered policy or a new policy on both XenApp/XenDesktop sites you will want to set “disable auto-update, disable the Enable auto update of Controllers policy setting.”
2. Create a maintenance version of the image.
3. Power on image updater/Master virtual machine for the image you want to update.
4. Log in to the Image Updater/Master virtual machine with a valid administrator account for the image
   Stop the “Citrix Desktop Service” service
   Edit the registry and update all pointers from XenDesktop Site A DDC’s to point to the XenDesktop Site B DDC’s.
5. Registry Locations to check, only update if entries exist.
   HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\VirtualDesktopAgent\ListOfDDCs
   HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Citrix\VirtualDesktopAgent\ListOfDDCs
   HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Policies\Citrix\VirtualDesktopAgent\ListOfDDCs
   [HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\VirtualDesktopAgent\State] “RegisteredDdcFqdn”
   [HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\VirtualDesktopAgent\Policy] “ListOfDDCs”
   [HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\VirtualDesktopAgent\PreviousState] “PreviousRegisteredDdcFqdn”
6. Show Hidden Files and check the following locations.
7. Delete C:\ProgramData\Citrix\GroupPolicy\
   Delete C:\ProgramData\CitrixCSECache\
   Delete C:\ProgramData\Citrix\PVSAgent\LocallyPersistedData\BrokerAgentInfo\SavedListOfDdcsSids.xml
   Delete C:\ProgramData\Citrix\PVSAgent\LocallyPersistedData\BrokerAgentInfo\GroupPolicyValues.xml
8. Additional you will want to check the PVS Write Cache Disk to confirm the VDAState.ini files is removed if you still have issues with registering to the wrong site. You could run a PSexec command or a script to remove the file from your existing virtual machines.

WriteCache Drive (Drive Letter could be different for your environment) E:\pvsvm\VDAstate.ini

1. Start the “Citrix Desktop Service” service
   Restart the virtual machine to ensure that the old or Site A DDC’s have not been re-injected into the registry.
   Check the event viewer for successful events for the “Citrix Desktop Service” with something similar to the following:
   The Citrix Desktop Service successfully registered with delivery controller DDCSiteB.Domain.com (IP Address 192.168.0.50).

The endpoint address of the controller is https://DeliveryControllerName.Domain.com:443/Citrix/CdsController/IRegistrar. The Citrix Desktop Service successfully registered with delivery controller

Shutdown the image update/virtual machine image and prepare for push to production.

When migrating from XenApp 6.5 to Citrix Virtual Apps and Desktop 7.X we noticed that Citrix display names didn’t reflect what was entered in the Display Name vs how Citrix Receiver on HP thin clients displayed.

The thin clients were configured to auto launch a specific published desktop name and when we added Citrix XenApp 7.15 to the delivery controller lists we noticed that $S1 or $S2 was appended to the resource name and prevented auto launching the specific desktop we had configured on all the thin clients.

To work around this, we had to edit the Citrix Site database because it appears that HP thin clients use the BrowserName property when launching a specific application or desktop.  The BrowserName in 7.X contains the $S2-.

Here’s the steps we used to fix this without reconfiguring all our thin clients.

1.  Login to your SQL server or open SQL Management Studio. Expand your site database and then select tables.

Select the chb_Config.BrowserNames table, then right-click, and Select Top 1000 Rows.

3.  Find the desktop name that you want to change under the BrowserName column.

4.   Right-click your site database and select New Query.

5.  Type the following code into the query window specifying the new BrowserName you want and the SharedDesktopEntitlementUID from the previous step. Then click execute to complete the change.