Non local administrators are unable to browse and access network shares when logged onto Citrix XenApp 6.5 servers

Environment

Citrix XenApp Server Operating System:  Windows 2008 R2

Citrix XenApp Version: 6.5

Citrix XenApp Hotfix: Rollup 1

Citrix Profile Management Version: 4.1

Problem

You’ve received complaints from various users that when they launch applications published on the Citrix XenApp 6.5 servers, they receive Windows Script Host error prompts similar to the following:

Script:

\\domain.internal\SysVol\domain.internal\Policies\{someGuid}\User\Scripts\Logon\logon.vbs

Line: 16

Char: 1

Error: Permission denied: ‘GetObject’

Code: 800A0046

Source: Microsoft VBScript runtime error

To further troubleshoot, you proceed by configuring the XenApp server to allow users to directly remote desktop to the server.  Upon directly logging onto the server with the user’s credentials, the following is displayed:

While troubleshooting the issue, you also noticed that you are unable to browse the path:

\\domain.internal

Windows cannot access \\domain.internal

You do not have permission to access \\domain.internal. Contact your network administrator to request access.

For more information about permissions, see Windows Help and Support

The server also exhibits the same behavior when you browse directly to a server via the name or IP:

What’s strange is that you are able to ping other servers:

You notice that if you add the user to the local administrators group, the error goes away. 

Solution

While the symptoms described in the following KB:

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

… did not directly map to the ones described above, I found that the solution was resolved my issue.  The reason why non local administrators were experiencing these symptoms is because of the UsrClass.dat file located in the following directory when the user is logged onto the server:

C:\Users\Default\AppData\Local\Microsoft\Windows

You will also notice the same file stored on the file server that stores the user’s profile management folder:

\\someFileserver\profilemanagement\someUsername\UPM_Profile\AppData\Local\Microsoft\Windows

The solution as described in the article is to delete this file but note the following:

1. You may not be able to delete the UsrClass.dat file from C:\Users\Default\AppData\Local\Microsoft\Windows while the user is logged in
2. Even if you delete the file while the user is logged off, the saved UsrClass.dat will be copied back to the server from the server

To correctly resolve the issue and remove the problematic UsrClass.dat file, first log off as the user to make sure profile management has saved the user’s profile on the file server and no other sessions will overwrite the profile, then go to the user’s profile on the file server and delete UsrClass.dat.  Once this is done, log back onto the server as the user and and ensure the symptoms are gone.

Installing SQL Server 2008 R2 Management Tools fails with the error: “Another version of Microsoft Visual Studio 2008 has been detected on this system that must be updated to SP1. Please update all Visual Studio 2008 installation to SP1 level, by visiting Microsoft Update.”

Problem

You attempt to install SQL Server 2008 R2 Management Tools on a server or desktop:

but notice that it fails with the error:

Another version of Microsoft Visual Studio 2008 has been detected on this system that must be updated to SP1. Please update all Visual Studio 2008 installation to SP1 level, by visiting Microsoft Update.

Your SQL Server 2008 R2 setup operation has been cancelled.

Another version of Microsoft Visual Studio 2008 has been detected on this system that must be updated to SP1.  Please update all Visual Studio 2008 installations to SP1 level, by visiting Microsoft Update.

You attempt to download Microsoft Visual Studio 2008 Service Pack 1 (Installer) from the following URL:

http://www.microsoft.com/en-us/download/details.aspx?id=10986

… but when running the install throws the following error:

Setup has detected that this computer does not meet the requirements to install this update. The following flocking issues must be resolved before you can install Microsoft Visual Studio 2008 SP1 software update.

Installation Requirements:

A compatible version of Visual Studio 2008 was not detected on the system. This update is designed for only the Microsoft Visual Studio 2008 (ENU) product family, and is not compatible with any Express editions.

Solution

This probably was a difficult one to resolve as it took me quite a bit of searching to find a solution and the time it took to find an answer is why I choose to write this post in hopes that I could help someone who may experience the same problem.  What ended up working for me was instructions a user posted in the following thread:

http://social.msdn.microsoft.com/Forums/en-US/sqlsetupandupgrade/thread/baf09c3f-be97-4bc8-b6d7-bdeea2e3719e

I went ahead and located the SP and SPIndex REG_DWORD attributes in the following registry keys:

• HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\DevDiv\VS\Servicing\9.0
• HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\DevDiv\VS\Servicing\9.0\VSR\1033

… and changed the values from 0 to 1:

Changed to 1:

The user also suggested to change SPName REG_SZ to RTM but I did not have to do this as the install successfully completed with the previous changes:

Citrix XenDesktop 5.6 virtual desktops continuously prompts the message: “You must restart your computer to apply these changes”

Problem

You’ve completed a new build of a Windows 7 master image desktop for XenDesktop 5.6 and proceed with creating the new desktop catalog and add the desktops to a desktop group.  Once the desktops have been deployed, you continue by connecting a desktop in the pool but noticed that you receive the following prompt with the following message:

You must restart your computer to apply these changes

Before restarting, save any open files and close all programs.

You’ve confirmed that your master image does not prompt you for a restart but noticed the desktops in the pool always do.

Solution

This issue was new to me because throughout all of the deployments I’ve done with XenDesktop, I’ve never encountered this.  The only difference between this deployment and all of the others is that this one is built on vSphere 5.1 with vCenter build 947673 and ESXi build 1065491 hosts (my previous deployments are either 4.1 or 5.0).  A quick search on Google reveals the following Citrix KB:

Case Study: MCS-Created Windows 7 VDAs Display 'You must restart your computer to apply these changes' Error Message when Starting
http://support.citrix.com/article/CTX132721

While the environment described in this article does not directly match mine (especially because the hypervisor is Microsoft Hyper-V 2008 R2), I went ahead and tried using the instructions to see if it would correct my problem.  The following are the steps I performed:

1. Shutdown master image
2. Add an additional disk by using an existing identity disk from another desktop in a pool
3. Power on master image
4. Restart the master image a few times
5. Shutdown master image
6. Remove identity disk
7. Create a new snapshot for the master image
8. Update catalog with new snapshot

The Good News:

One of the unexpected behaviors I noticed was that I did not receive a prompt asking me to restart after adding the identity disk to the master image but I can confirm that after performing these steps, the desktops in the pool no longer prompted me to restart the desktop as if it had found and installed new hardware. 

The Bad News:

This was great news until I logged into the master image and noticed that the name of the master image was now the name of the desktop that owned the identity disk I used to attach to the desktop.  I didn’t think too much about this being issue as I figure it probably copied the identity information from the desktop in the pool but what I noticed was that as soon as I changed the name of the master image back to the original, removed it from the domain and restarted, the radio button to join the desktop to the domain would be grayed out:

What makes it more strange is that if I change it back to the same name as the desktop that I used the identity disk and reboot, the option will be available again:

The Workaround:

This was definitely an odd behavior and I wasn’t about to go live with such an issue.  After trying various operations with the master image without any luck, I went ahead and reverted back to a snapshot prior to attaching the identity disk.  Seeing how it appears adding the disk to the master image and booting it up caused Windows to assume the identity provided by the identity disk, I proceeded to try adding the disk without booting up with it.  With the master image powered on, I went to the master image’s virtual machine settings and performed a hot add of the identity disk:

I continued by clicking OK to apply the changes, went to the console of the master image to confirm that identity disk shows up and then went ahead to remove the disk from the master image:

Once the disk was removed, I restarted the master image a few times, created a new snapshot then updated the desktop catalog.  Once the update to the base disk was complete, I noticed that the virtual desktops in the pool no longer prompted for a restart as if new hardware was found and installed.

Increasing vCPU and memory for Citrix XenDesktop 5.6 virtual desktops

I’ve recently been asked about how to change the amount of vCPU and memory for Citrix XenDesktop desktop catalogs that have already been deployed and as XenDesktop administrators would know, the following screen with configuration parameters to set the vCPU and memory is presented when creating the new desktop catalog:

However, once the desktop catalog has been created, we no longer have access to these options.  Manually changing the master image and/or the VDI desktops doesn’t work because subsequent desktops that are deployed will be configured with the same vCPU and memory as originally specified.

The solution to this is actually quite simple and that is to use PowerShell cmdlets to change the configuration for the desktop catalog.  The following are the PowerShell cmdlets we’ll need to change these settings:

Get-ProvScheme
http://support.citrix.com/static/kc/CTX127254/help/Get-ProvScheme.html

Set-ProvScheme
http://support.citrix.com/static/kc/CTX127254/help/Set-ProvScheme.html

Changing Memory for Desktops

Begin by using the Get-ProvScheme to get the ProvisioningSchemeName for the pool you would like to modify:

PS C:\Users\tluk> Get-ProvScheme

ProvisioningSchemeUid    : 98ba4e9e-4b29-4ca7-885a-f689b664a2ed

ProvisioningSchemeName   : London_svrvcenter03

CpuCount                 : 1

MemoryMB                 : 4096

DiskSize                 : 40

MasterImageVM            : XDHyp:\HostingUnits\svrvcenter03\Normal.resourcepool\win7ent64tmp.vm\Snappy.snapshot

MasterImageVMDate        : 4/26/2013 2:20:41 PM

IdentityPoolUid          : 499727d7-3648-454a-9a30-1c934efffca1

IdentityPoolName         : London

HostingUnitUid           : 935be19a-7941-465e-9377-1673962f7525

HostingUnitName          : svrvcenter03

CleanOnBoot              : True

TaskId                   :

Metadata                 : {Citrix_DesktopStudio_UpdateId = 113152a9-82eb-4595-808e-9d1725d7c6dc:6cea07ff-1c5a-4b1e-80f8-a252e9b7984c}

MachineCount             : 5

ControllerAddress        : {svrctxddc01.domain.internal, svrctxddc02.domain.internal}

VMMetadata               : {H, 4, s, I...}

UsePersonalVDiskStorage  : False

PersonalVDiskDriveLetter :

PersonalVDiskDriveSize   : 0

PS C:\Users\tluk>

Make a note of the ProvisioningSchemeName and then use the Set-ProvScheme to set the new memory:

Set-ProvScheme -ProvisioningSchemeName "London_svrvcenter03" -VMMemoryMB "8192"

Note that you won’t receive an output when executing the Set-ProvScheme cmdlet.

To confirm that the changes to the pool have been applied, use the Get-ProvScheme command to display the pool properties:

Changing vCPU for Desktops

Changing vCPUs (CpuCount) is similar to memory but rather than using VMMemoryMB switch, use the VMCpuCount as shown in the following:

Set-ProvScheme -ProvisioningSchemeName "London_svrvcenter03" -VMCpuCount “2”

--------------------------------------------------------------------------------------------------------------------------------------------------------------------

Note that changing these settings will only apply to new desktops deployed for the pool and not for existing desktops.  This means that if you had 200 desktops in the pool, simply executing updating the catalog with a new snapshot will not change the CPU or memory.  The only way to update them would be to use vSphere PowerCLI to change the settings for the existing VDIs or delete them and recreate the desktops if they are not persistent.

Logging into Citrix XenDesktop with Profile Management 4.1 gets stuck at the “Welcome” screen

Problem

You have a new Citrix XenDesktop 5.6 desktop catalog deployed that uses Citrix Profile Management 4.1 to roam all of the user profile settings that your current Active Directory Redirected Folders doesn’t handle but noticed that after installing your applications and deploying the pool, users attempting to log in gets stuck indefinitely at the Welcome screen:

As a troubleshooting step, you’ve updated Profile Management from 4.1.0 to 4.1.2 (http://support.citrix.com/article/CTX134616) but still notice the same symptoms.

Solution

While I’m sure there are plenty of reasons out there that can cause this issue, the reason why the desktop pool I was working with exhibited this behavior was because we had ESET 5.0.2126.0 antivirus agent installed onto the Windows 7 desktop:

Rather than change the settings of the agent which I didn’t have permissions to, I went ahead to try turning off Profile Streaming in the Profile Management GPO as such:

Computer Configuration –> Administrative Templates –> Citrix –> Profile Management –> Streamed user profiles –> Profile Streaming

 

… which ended up fixing the issue.  I won’t go into the details of what you lose by not configuring this policy but will paste the description for it here:

With profile streaming, users' profiles are synchronized on the local computer only when they are needed. Registry entries are cached immediately, but files and folders are only cached when accessed by users.

Launching a Citrix XenApp 6.5 application published through a Citrix Access Gateway throws the error: “Unable to launch your application. Contact your help desk with the following information: Cannot connect to the Citrix XenApp server. Socket operation on non-socket.”

Problem

You attempt to launch a Citrix XenApp 6.5 application published through a Citrix Access Gateway but the Citrix Receiver throws the error:

Unable to launch your application. Contact your help desk with the following information: Cannot connect to the Citrix XenApp server. Socket operation on non-socket.

Solution

While there are probably various reasons why this error will be thrown but the one of the reasons are describe in the following KB:

Error: "Unable to launch your application." Appears When you Launch Published Applications
http://support.citrix.com/article/CTX134940

While the Maximum Number of Users on the CAG I was working with was set correctly, I noticed that the Virtual Server mode was set to SmartAccess Mode:

Switching it to Basic Mode:

Launching a Citrix XenApp 6.5 published application hangs at: “Please wait for the Local Session Manager…”

Problem

You’ve received complaints from users that they are unable to successfully launch Citrix XenApp 6.5 published applications because while the Citrix Receiver launches and attempts to connect to the XenApp server, it hangs at the:

Please wait for the Local Session Manager…

… stage for a few minutes and eventually disconnects.  Attempting to directly remote desktop to the server exhibits the same behavior:

… but you are able to eventually log into the server.

The users experiencing this problem are already a part of the Remote Desktop Users group and you noticed that this issue goes away if you were to grant the user local administrator permissions.

Solution

One of the first hits I received while Google-ing the issue was a Microsoft KB that supplied a hotfix:

"Please wait for Local Session Manager" message remains for several minutes when you disconnect from a computer that is running Windows Server 2008 or Windows Server 2008 R2 during the logon process

http://support.microsoft.com/kb/2661001

Unfortunately, this applying this hotfix did not correct the issue.  The next search result was the following thread on the Citrix forums:

http://forums.citrix.com/thread.jspa?threadID=291092&start=0&tstart=0

… which showed that users had mixed results with 2 other solutions:

#1 – Delete the usrclass.dat:

Several users has had luck deleting the usrclass.dat hidden file from the directory:

C:\Users\Default\AppData\Local\Microsoft\Windows

… so I went ahead to delete it and restarted the XenApp server but noticed that this did not correct my problem.

#1 – Remove Users permissions to the TSTheme.exe file:

Another solution proposed by a Citrix engineer was to remove the Users permissions to a file named TSTheme.exe that was located in the directory:

C:\Windows\System32\

Note that the file is owned by the TrustedInstaller group so you will need to take ownership over the file in order to remove the permissions:

Once the Users group was removed, users who were not a part of the local administrators group on the XenApp server no longer had to wait for minutes at the Please wait for the Local Session Manager… stage and we’re now able to launch applications through the Web Interface portal.