Pages

Tuesday, May 28, 2013

One of the common issues I’ve come across over the past few months for clients was when I was asked to identify which replicas belonged to which virtual desktops in VMware View environments because a lot of my clients suspected that they had orphaned replicas that were not in use. When approached with such a request, I usually perform one of the following 3 options:

Option #1 – Use the SviConfig.exe command to find unused replicas

VMware actually provides an official KB that demonstrates how to use the SviConfig.exe command to generate a unused-replica-*.txt file that lists replicas that it is able to identify as being unused. While I’ve found that this doesn’t always work because I’ve had several occasions where the txt file generated was empty, this is the safest route to take.

Another VMware KB that is available demonstrates how to generate a txt file that contains all of the replica to virtual desktop mappings which can then be used to identify which replicas are actually in use. I find that this process can potentially be prone to human errors so steps such as renaming the identified replica folders and leaving them for a week rather than deleting them outright should be taken. The KB that outlines the steps is the following:

Use the following command to format the replica information dumped into replicalist.txt and output it to replicalist2.txt:

sed s/:/'-->>'/ < replicalist.txt >replicalist2.txt

From here, the KB article suggests to use the less replicalist2.txt command to view the information but I found that it’s not easy to copy the information from the putty session so simply use the cp command to copy the replicalist2.txt file into a regular VMFS store then use the VMware vSphere Client to download it:

cp /replicalist2.txt /vmfs/volumes/LUN01-ISO/

Proceed with downloading the replicalist2.txt file onto your desktop or laptop and opening the file which should look similar to the following:

Note that all each virtual desktop is represented by the block of text similar to the following:

With the replica information in the text file begin traversing through the list of replicas listed in your vCenter:

… and copy each replica:

replica-006164ad-adfe-4fbb-92e6-e32edc60e24f

What’s important to note is that you will need to remove the last string of characters highlighted in red as shown above so that you only have the following:

replica-006164ad-adfe-4fbb-92e6

With the truncated text shown above, perform a search in the text file:

Pay attention to the results that the find feature returns as you are expected to get a return from all of the results because the replicalist2.txt file contains references to the replicas themselves stored on the VMFS stores. The key here is to determine whether the replica ID shows up on a line that is linked to a virtual desktop and in the example below, it doesn’t:

With this in mind, what this means is that we should be able to unprotect the replica:

… rename the folder containing the replica on the VMFS store, and then wait a few days before deleting it. Make sure you’re just renaming the replica in the VMFS folder and not the actual replica in vCenter in case you need to quickly roll back. Once you’ve confirmed that the replica is indeed not in use because all the virtual desktops continue to be in good health, proceed by renaming the folder that was renamed and then right clicking on the replica in vCenter then delete.

As the example above showed a replica that is orphaned, the following is a demonstration of one that is being used:

replica-07c8e7df-449e-4372-8701-b4e7519223e0

replica-07c8e7df-449e-4372-8701

Notice how the following find research brings us to a line that is associated with a virtual desktop named VIEW46-001:

Another option I’ve found to be the easiest way to clean up old replicas is to perform a recompose of all of the virtual desktop pools with a new snapshot then remove any replicas that are not dated the day of the rollout. The reason why we can do this is because if all of the desktops are using the new snapshot that was created, the old replicas should get automatically deleted by View and if they are indeed orphaned then you should at least be able to safe rename the folder in the datastore, wait a few days then delete them.

Unfortunately, the columns referenced in the tables did not appear to show the mappings so while it would have been nice to be able to use SQL queries to identify the orphaned replicas, it does not appear to be possible to do this.

Tuesday, May 14, 2013

You attempt to start your Lync Server 2013’s Edge server’s Lync Server Access Edge service but notice that the service fails with the following message:

Windows could not start the Lync Server Access Edge on Local Computer. For more information, review the System Event Log. If this is a non-Microsoft service, contact the service vendor, and refer to the service-specific error code -2146762487.

Reviewing the System logs on the Edge server show event ID 7024 errors logged:

The Lync Server Access Edge service terminated with the following service-specific error: A Certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider.

You confirm that the root certificate issuing your Edge server’s certificate is listed in the Trusted Root Certification Authorities:

You review the certificate assigned to the external interface for the Edge server in the MMC and notice that the certificates in the chain are all listed as This certificate is OK.:

… will know that I’ve ran into a few challenges with Lync Server 2013 Edge servers on a Windows Server 2012 operating system. As noted in the post above, Windows Server 2012 is more stringent when it comes to trusted certificates and actions such as mistakenly putting an intermediate certificate in the trusted root certificate store can cause replication to stop working between the Edge and front end server. What was interesting about this problem indicated in this post is that I had the issuing root certificate on the server’s Trusted Root Certification Authorities and while all indications point to the server trusting the certificate being used by the Edge server, the services did not. What I ended up having to do to correct this problem was import the intermediate certificate in the chain into my Intermediate Certification Authorities:

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.

… 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:

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

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

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.

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:

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:

Friday, May 3, 2013

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:

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:

Shutdown master image

Add an additional disk by using an existing identity disk from another desktop in a pool

Power on master image

Restart the master image a few times

Shutdown master image

Remove identity disk

Create a new snapshot for the master image

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.

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:

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.