Friday, June 27, 2014

View Client Certificate authentication phenomenon and fix - Quick N Dirty

Deployment of View Client 5.4.x in production environment.
Massive delay on connection to connection server from client.

Background & Troubleshooting:
"2014-06-27","11:03:40","ComputerName" / Latency "1.37 ms", / WRITE "453.5648800", /READ "Mbps","205.2395120","Mbps”
Connection to VIEW CONNECTION SERVER is 5 seconds from alt hardware (My laptop) using on floor network cable and port.

Speed tests on alternate hardware showed  a connection at over 400 Mbps (10 test AVERAGE)


Testing the local system again shows surprisingly fast results with transfer times @ 1/10th of a second per 1MB. (10 test AVERAGE)
Connection to VIEW CONNECTION SERVER is 60+ seconds from production hardware using on floor netowork cable and port.

At this point it looks like the client and not the wire are having problems.

Re-ran setup batch file to remove and reinstall View client.
Testing with a direct connection to the server IP not using Citrix load balancer.
-       -    No effect on delay

Trouble appears to be at connection to connection server post connection View maintains good functional speed.

Troubleshooting local hardware View Client:
-          Disabled auto connection
o   No effect
-          Enabled auto connection
-          Disabled All unused protocols
o   No effect
-          Enabled unused protocols
-          Installed different version of View Client
o   No effect
-          Reran default install scripts
-          Test for UDP connections with Citrix load balancer VIP and connection server passed
-          Check local PC certificate config
o   All required root certificates already installed (Validated)

SSolution / Workaround:
-          Disabled certificate validation in View Client
o   Resolved connection hang
-          Tested on three workstations all showed significant speed increase at connection to connection server

Dropped connection time from 60+ seconds to an average of 6 seconds.

Connection bottleneck identified as View Certificate security checks initiated by client:
Proposed current resolution:
Modify installation batch file to add reg DWORD value to local workstation:
HKEY_LOCAL_MACHINE\Software\VMware, Inc.\VMware VDM\Client\Security DWORD Value: CertCheckMode Value: 0

 reg add "HKEY_LOCAL_MACHINE\Software\VMware, Inc.\VMware VDM\Client\Security" /v CertCheckMode /t reg_dword /d 0 /f

Proposed long term resolution:
Use VMWARE VIEW ADM template to create View GPO policy applying this setting from the domain to the workstations running View.
Will allow for seamless upgrades of the View Client software.

Hopefully this will save someone a bit of troubleshooting time and hair pulling.
I will be working at a root issue but as of right now I am comfortable with this temp work around.
We are currently automating access to our View environment using Imprivata's SSO OneSign.
The connection to the View Connection Server's URL is enforced by policy and users can not modify any settings on the endpoints.

Additional Info:


(All on one line)

All of the described is a workaround and not a true solution to the issue. Disabling certificate checking can leave endpoints vulnerable to man-in-the-middle attacks and prevents the View client from behaving in a secure manner. Use at your own risk.

Wednesday, April 9, 2014

VMware Tools on Linux - Quick-N-Dirty

I have found myself doing a lot of work on Linux VMs lately.
Thus a lot of VMware tools installs on systems I am not at home in.

This method from VMware Support resources works on every flavor I have used to date:

NOTE: This was written for 5.0 but works for any version. Just check your mounted CD for your version as it will change the command structure.

3. As root (su -), mount the VMware Tools virtual CD-ROM image, change to a working directory (for example, /tmp), uncompress the installer, then unmount the CD-ROM image.

Note: Some Linux distributions automatically mount CD-ROMs. If your distribution uses automounting, do not use the mount and umount commands below. You still must untar the VMware Tools installer to /tmp.

Some Linux distributions use different device names or organize the /dev directory differently. If your CD-ROM drive is not /dev/cdrom or if the mount point for a CD-ROM is not /mnt/cdrom, you must modify the following commands to reflect the conventions used by your distribution.

mount /dev/cdrom /mnt/cdrom

cd /tmp
(I use the root of my home folder ~/ lets me keep the tools around for re-install as needed.)

Note: If you have a previous installation, delete the previous vmware-distrib directory before installing. The default location of this directory is

4. Untar the VMware Tools tar file:

tar zxf /mnt/cdrom/VMwareTools-(Your Version Here).tar.gz

umount /dev/cdrom

Where <xxxx> is the build/revision number of the VMware Workstation release.

Note: If you attempt to install a tar installation over an rpm installation — or the reverse — the installer detects the previous installation and must convert the installer database format before continuing.

5. Run the .tar VMware Tools installer:

cd vmware-tools-distrib


Respond to the configuration questions on the screen. Press Enter to accept the default value. (Note: All defaults here should work just fine)

Thursday, March 20, 2014

Exchange 2010 DAG - Cluster Event 1579

I am in the process of changing my backup structure to EMCs Avamar and Datadomain.
Avamar provides a granular restore functionality for Exchange 2010 and using a DAG component for the VSS enabled backup of your data stores.
Part of the setup process is to create a DNS entry for the cluster object manually before running Avamar's DAG configuration tool. After running the tool and setting everything up I noticed this warning and error in my clusters event log:

Warning Event ID: 1196
Cluster network name resource 'YourClusterNameHereresource' failed registration of one or more associated DNS name(s) for the following reason:
DNS operation refused.

Error Event ID: 1579
Cluster network name resource 'YourClusterNameHere' failed to update the DNS record for name 'YourClusterNameHere' over adapter 'YourAdapterNameHere'. The error code was 'DNS operation refused. (9005)'. Ensure that a DNS server is accessible from this cluster node and contact your DNS server administrator to verify the cluster identity can update the DNS record

I turned to my good friend Google and I was given the follow web site:

After reading all of this === BLAH!

At the very bottom first comment is the answer. You manually created the DNS entry for the cluster. Thus you must grant the cluster AD object ownership of its DNS record.
After going into DNS and granting FULL permissions to the cluster object for its DNS record the problem is solved and event logging happy once again. Thank you very much IronPeddle.

Friday, March 14, 2014

In the beginning of things...

Hello Interweb,
Being a technologist and being able work in technology is a gift.
Being able to write for spit is NOT a gift.

Recently, I had an engineer onsite to work on my companies VDI road map. During our work we got to talking about different emergent technologies and I was impressed with his knowledge of products both recently on the market and pending release. When I asked him how he kept track of it all his response was simple, "I blog." Turns out every time he solves a problem for a client, works through an issue in his home lab, or sees new tech he writes a blog post about it. He has a very large blog.

To that end I am going to attempt the same and hopefully in the process improve my writing skills, my use of punctuation, and overall wordsmithing. (I know that is not a word... off to a great start.)