Repairing Non-Replicating VMware View Connection Servers

Applies to VMware View 5.2 only
Reference VMware articles:
ADAM replication manual repair
Re-install a replica Connection Server

Bad things happen when the Master has an attitude.

Bad things happen when the Master has an attitude.

We’ve got a simple VMware View architecture setup for testing consisting of two Connection Servers (master and replica) with one Security Server. The Connection Servers replicate to each other via ADAM and AD LDS (Active Directory Lightweight Directory Services).  In our case we have designated one Connection Server for internal use and the other for external by using internal and external IP addresses in the PCoIP Gateway settings in each server.

Unidesk provides the application layering on the virtual desktops and therefore needs to communicate to the Connection Servers. Although both Connection Servers are defined in Unidesk, it will only choose one to communicate with and use the other as a failover. Unidesk assumes replication between the servers is active and therefore doesn’t verify if changes can be seen on all Connection Servers.

VMware Blast is enabled, running and accessible from anywhere. Blast is an important piece as it allows users to access the front gate to their virtual desktop via the web. Both Connection Servers have the Horizon View HTML Access package installed.

Out of freaking nowhere I get an email stating that Unidesk changes are being seen on only one server. In this case, it was the master. The replica was not showing any changes and since it was the one we used for internal testing, new desktop pools created on the master weren’t available.

I remote into the replica and run the following from an elevated command prompt
repadmin.exe /showrepl localhost:389 DC=vdi,DC=vmware,DC=int

The output:
LDAP Error 81(0x51): Server Down

Okay, so what server was down? Looks like the master is angry about something and just didn’t feel like talking anymore:

Rejecting Replication

Manually enabling ADAM replication failed using these commands:

cd \Windows\System32

By fail, I mean replication didn’t resume. It was clear that replication was enabled, but the master had an attitude and after manually enabling replication on each server, the master still refused all requests from the replica.

It was time to replace the replica. The good ole rip-and-replace. Love it. The process is basically uninstalling ADAM and the Connection Server, then re-installing. During the process, you will get warnings about non-replicated data  unable to be deleted. Skip these files and continue with the removal. There was no mention of removing the Horizon-View HTML Access software in the KB articles. Hint: remove it also.

After the re-install of ADAM and the Connection Server, replication ensued and the Unidesk pools were listed in both Connection Servers, but Blast was no longer available. When accessing the web portal, users were greeted with a message that they have to use the View Client to get to their resources and to contact their system administrator, which turned out to be me.

Troubleshooting Blast wasn’t too tough and here are the shortcuts to the fix:
After the rip and replace of the Connection Server on the replica, verify that all VMware firewall rules on both Connection Servers are enabled. Surprisingly, I had to re-enable all View and Blast rules on both. Then rip and replace the Horizon-View HTML Access software on the replica. Once that was done, Blast returned to normal and replication was still working.

To fix broken replication in View 5.2

  1. Confirm broken replication on master and replica(s) using the “repadmin.exe /showrepl localhost:389 DC=vdi,DC=vmware,DC=int” command.
  2. Manually re-enable ADAM replication on the master and all replicas using the following commands and test with step 1 to see if replication has resumed:
    1. cd \Windows\System32
      repadmin /options SERVER_FQDN -DISABLE_OUTBOUND_REPL
      repadmin /options SERVER_FQDN -DISABLE_INBOUND_REPL
    2. Rip and replace the ADAM and Connection Server software from the replica
    3. Re-enable all View and Blast firewall rules on the master and replica
    4. Rip and replace the Horizon-View HTML Access software on the replica

That should put the master and everyone else in a better mood.


Categories: VMware

Tags: , , , , , ,

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

Brad Hedlund

stuff and nonsense


Every cloud has a silver lining.

Live Virtually

A Storage and Virtualization Blog

Virtualization Team

VMware ESX/ESXi - ESX server - Virtualization - vCloud Director, tutorials, how-to, video

Just another site

VirtualKenneth's Blog - hqVirtual | hire quality

Virtualization Blog focused on VMware Environments


Virtually everything is POSHable

Gabes Virtual World

Your P.I. on virtualization

Yellow Bricks

by Duncan Epping

Wahl Network

Technical Solutions for Technical People

Joking's Blog

Phoenix-based IT guy with too much to say...

%d bloggers like this: