Home » upgrade

Tag: upgrade

Citrix Storefront Upgrade Failure 2.x to 3.9


When trying to Upgrade our Citrix storefront servers from a 2.x version to 3.9 of storefront we encountered the following error: This meant the installation failed with the previous storefront version removed completely, and all configuration lost, and we were then unable to install any further version of Citrix Storefront.

Application Log Error, Source: Citrix Extensible Meta-Installer EVENTID: 0
Timestamp: 05/07/2017 19:04:43
Category:Error, WinError
Message:Unexpected exception. Message: Exception has been thrown by the target of an invocation.. Stack Trace =    at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor)
   at System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal(Object obj, Object[] parameters, Object[] arguments)
  at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
   at Citrix.Cxmi.CustomSandbox.ManagedDllLoader.CallStaticMethod(String typeName, String methodName, Dictionary`2 methodParams)
   at Citrix.Cxmi.Workflow.ExecuteTask.Execute()
   at Citrix.Cxmi.Workflow.WorkflowSequence.Execute()
   at Citrix.Cxmi.Workflow.WorkflowSequence.Execute()
   at Citrix.Cxmi.Workflow.WorkflowExtension.Run()
   at Citrix.Cxmi.Core.Engine.Run()
   at Citrix.Cxmi.Core.Program.Main(String[] args).

Things Tried:

Deletion of all local temp files – Failed

Complete uninstall and reinstall of Storefront versions – Failed

Reinstall of old version 2.x – Failed

Install of new 3.x  version as different user – failed

We had no choice but to revert the VM snapshot to recover the production Web server.


Upgrade to Storefront 3.0 First, then attempt to upgrade to a higher version.

Should I upgrade Citrix XenServer 6.2 to XenServer 6.5?

In Short … HELL YES, see this PDF from Citrix with the large list of the improvements in XenServer 6.5

The new console is sleek and quick and a hell of an improvement over the previous with a number of bug fixes (notably for vGPU / VDI settings). It has a couple of new views (similar to the VMware Client), and from rudimentary tests the VMs on 6.5 are performing marginally better than 6.2.

xensrver_6.5_console_view2       xensrver_6.5_console_view1

The in place upgrade tested was flawless and preserved existing VMS on the host, including snapshots and templates. (it does however wipe out the XenServer backup directory so be prepared if you have any backups saved). Overall the entire upgrade process for one host (Dell R720) took around 8 minutes for the upgrade to complete (not including reboot time)




Benchmarking for GPU / VDI Passthrough

VM with 4vCPU, 90GB RAM, 150GB Local disk, Client with receiver 4.2 and local resolution of 2 x 1400 x 900, Running XenDesktop 7.6 on a Dell R720 Server. (3 benchmarks were run consecutively to ensure the results were not a one off – Final result was recorded)

  1. Grid K2 GPU in W7 XD VDI Passthrough on 6.2 – Heaven benchmark Score 1631
  2. Grid K2 GPU in W7 XD VDI Passthrough on 6.5 (without tools upgrade) – Heaven benchmark Score 1666
  3. Grid K2 GPU in W7 XD VDI Passthrough on 6.5 (with tools upgrade) – Heaven Benchmark Score 1666 (marginally higher FPS – but every bit helps in the world of VDI right?)


Its worth noting the below results are only really recording the performance of the GPU not the over all VM, its ability to serve applications or open files etc and a load testing solution like Edgesight Load testing or LoginVSI should really be used in a production scenario to determine a more ‘real end user load’. It is nice to see however that even from this rudimentary test the performance is heading in the right direction!

Heaven Benchmark XenServer 6.2 vs 6.5 FPS Min FPS Max FPS
XS 6.2 64.7 19.1 139
XS 6.5 w 6.2 Tools 66.1 19.4 141.6
XS 6.5 w 6.5 Tools 66.2 22.3 142.1

Results Graph


Note: the VM tools were upgraded with the GPU removed and direct from the Xenserver 6.5 console, I did not remove the VDA or Nvidia drivers first (experience shows that this is a best practice)


Citrix Storefront 2.1 Upgrade to 2.5 – Issues Experienced

 STOREFRONT 2.5 UPGRADE from 2.1 – Notesstorefront-storeweb

We were running Storefront 2.1. It was installed and working fine for all normal storefront web and support for SSON legacy clients with a 2 node storefront farm via a load balanced netscaler setup.

We decided to install the Storefront 2.5 over the top – just to see how it would behave. We downloaded the new version, took a server snapshot, and then ran the install as administrator.

First and foremost its identical to the 2.1 installation and actually looks like brand new install. During the install it mentions nothing upgrading, just simply installs and takes a good 20 minutes, with little in the way of feedback along the way.

The following problems were experienced after the upgrade of our Storefront servers.

  1.        Clients can no longer SSON through the PNAgent
  2.        Storefront webpage only displaying 1 of the 2 delivery controllers configured. (legacy xenapp 4.5, nothing from xenapp 6.5)


We ended up wiping the store configuration entirely and starting again.

No amount of changing or disabling and reenabling the existing store would work, and its not like its that difficult to recreate the same site with the same name. This would be frustrating if we had many multiple stores.

All testing was carried out without the netscalers or the LB services. This was to be sure it wasn’t adding its own complexities or problems to the setup.

During testing the local hosts file was updated so I could be sure I was targeting the individual storefront servers I was upgrading at the time.

Further details / Troubleshooting steps.


Tried Reboot – didnt fix

Tried the PS Script to enable SSON for legacy – didnt fix

Checked the settings for the legacy clients – it was enabled and store correctly listed

Disabled legacy support

Re-enabled Legacy support (without SSON)

Online Legacy client prompts for user and password, could authenticate successfully only displaying the legacy 4.5 apps from one of two delivery controllers listed.

Run  powershell command as administrator on the Storefront server

& “C:Program FilesCitrixReceiver StoreFrontScriptsEnablePnaForStore.ps1” -SiteID 1 -ResourcesVirtualPath /Citrix/Store -LogonMethod sson – to re enable the legacy SSON

Legacy clients get error messages popup saying its authenticating,

Citrix Onling Legacy client attempting to authenticate
Citrix Onling Legacy client attempting to authenticate

Then the server could not be contacted.


Online legacy client unable to authenticate to upgraded storefront server
Online legacy client unable to authenticate to upgraded storefront server

Then magically refreshes a 3rd time and just logs in anyway!?



Removed XENAPP65 Delivery controller and readded settings for 2 ZDC’s – Didnt work

Added just one of the ZDC’s as an IP address – still not working, website now slower and authentication takes twice as long.

Removing store entirely.

Readded the store entirely, connected XA65 first and tested – both website and PNAGENT Legacy worked (once again running the Powershell PNAgent command

& “C:Program FilesCitrixReceiver StoreFrontScriptsEnablePnaForStore.ps1” -SiteID 1 -ResourcesVirtualPath /Citrix/Store -LogonMethod sson

Powershell output from the command that enabled SSON for storefront legacy support
Powershell output from the command that enabled SSON for storefront legacy support

If the client had connected while the authentication method was reset you will see

Legacy online plugin will change the authentication method automatically
Legacy online plugin will change the authentication method automatically

It logged in! Success!

Propogate changes to the other server (also just upgraded) – DONE.

Piece of cake… *ahem*

Netscaler upgrade to breaks authentication policy

Situation: We upgraded our Netscaler VPX from to and we were then unable to authenticate to the netscaler console using our LDAP credentials and users were unable to authenticate at the Access Gateway pages.

Solution: During the VPX upgrade the Netscaler truncated the first 2 characters of each line of the Authentication server section (including the password)

Either manually restore the information or copy the authentication lines from a backup of the previous ns.conf


VMWare Tools 7.0 upgrade on Windows NT 4.0 Server

Situation: We were running Windows Nt 4.0 on VMWARE with Vmware Tools 4.0.
We needed to upgrade to VMWARE Tools 7.0 (including the Hardware)

The tools upgraded easily (surprisingly) but after the power off, snapshot, and upgrade HW of the virtual server, the network stopped working.

Logging on the server was using cached credentials (first obvious error)
Secondly trying to start the device (Start > control panel > devices > VMware Virtual Ethernet Adapter)
Resulted in
“Could not start the VMware Virtual Ethernet Adapter service on \server”
“Error 0031: A device attached to the system is not functioning”

Reinstalling the tools would result in “vmware setup failed to install the vmxnet driver automatically”

Solution: The below attached VMWARE KB article is not entirely correct though was helpful

The process was

1) remove the ethernet adapter entirely (take NOTE OF THE IP address DETAILS FIRST)

2) reboot

3) install a NEW adapter (start > control panel > network > Adapters tab) + Add

4) Copy the driver files for the vmxnet from c:program filesvmwarevmware toolsdriversvmxnet to c:vmxnet

(we had issues with windows nt.40 figuring out the path with spaces – even 8.3 names didnt work)

5) it should discover its a new Adapter and install successfully

6) provide the old IP address details and ENSURE you include a WINS address or on the WINS tab enable DNS for Windows resolution if you dont have a WINS Server

7) restart

8) don’t get scared by the Windows NT 4.0 Startup blue screen of death look alike! 🙂

References: http://kb.vmware.com/kb/1018546