Correct way to regenerate Certificates on Vcentre Virtual appliance

I have been working around with virtual appliance and had to regenerate certificates. The trials of getting this done are covered here , but to properly regenerate the certificates without hangs at boot.

  1. Enable the certificate regeneration either by hitting the “Toggle certificate setting” in the web console or by logging onto the VCA via SSH and running from the command linetouch /etc/vmware-vpx/ssl/allow_regeneration
  2. Stop all the vCentre and SSO services on the Vcentre appliance
  3. Regenerate the certificates
    source vpxd_commonutils; regenerate_certificates
    The result of this should be VC_CFG_RESULT=0
  4. Replace all the certs
    source vpxd_commonutils; generate_all_certificates replace
  5. Clean up the regeneration file by deleting the allow_regeneration file
    rm /etc/vmware-vpx/ssl/allow_regeneration
  6. Reboot the machine and check it comes up cleanly

This should resolve the issue

Problems and symptoms

I came across an interesting problem today, one which illustrates a point I’ve always tried to get across when discussing troubleshooting

The issue being reported may just be a symptom of the actual problem. Never assume you have the full picture.

Onto the problem :

This was a Citrix Presentation server 4.5 environment with Internet Explorer , Outlook and some industry specific applications. Virtual IPs were being used in a hosted environment to present IPs to Internet Explorer to allow external filtered internet access. Some users began to experience the following error and sessions were failing to launch.

So what could be the problem? The only symptom we had so far was that the users could not log on because the pool of virtual IPs was exhausted. Not much to go on so far so the best first step is check the VIP config as per the following article :

To sum up the steps carried out here:

  1. Checked the VIPs were configured correctly in the Farm and assigned to the servers
  2. Checked the mentioned registry keys :
    HKLM\SOFTWARE\Citrix\CtxHook\AppInit_Dlls\VIPHook\<Process name>
  3. Check the viphook.dll was loaded into the processes by the use of Process monitor

Nothing was wrong however so it was time to look at the problem a different way. Looking at the Access management console for the affected servers and grouping the users by username displayed the following


Although the usernames are obscured each Red box in the image is a single user. As you can see each user is getting 2 IPs rather than one thus exhausting the IP pool faster. But why?

There is a common misconception with Virtual IPs that they only apply to the application they are assigned to in the Console. This isn’t the case, the IPs can be assigned to applications but in practice they are assigned to each session the user opens on the server. The configuration in the console merely allows that application to communicate with the Network using the Virtual IP address

Looking at the session list gave a clue as to where the problem was coming from. All the users who had the session sharing problem had Outlook open. Session depends on the applications being published with identical settings and the session sharing key matching. The key is composed of the following settings : Color depth, Screen Size, Access Control Filters (for SmartAccess), Sound, Drive Mapping, Printer Mapping

Checking the settings for Outlook confirmed that the session sharing problem was being caused by the Colour Depth being different to the other applications. Changing this back resolved the issue and the sessions started sharing again which eliminate the secondary issue of the virtual IP pool being exhausted and preventing logons.

By making no assumptions and treating all of the problems as a symptom what initially appeared to be a complicated and obtuse problem was actually rather simple to resolve.