The server has just rebooted and IIS is still starting up
A firewall preventing the storefront server(s) getting back to the SNIP of the Netscaler(s)
and now today…
Today I added a new Delivery controller in Storefront 2.5 so I could publish ‘XD’ resources.
In the XD7.6 studio console I created a new machine catalogue and delivery group called ‘J&J Testing’
When accessing the delivery group in the Studio it looked fine
When testing the login process via storefront we received ‘Cannot complete your request’.
Removing the ‘XD’ from the list of delivery controllers in storefront – worked instantly, storefront logins working again
This was not a solution however.
Deleting the delivery group ‘J&J Testing’ and re-adding the ‘XD DDC’ back to storefront as a delivery controller worked straight away.
Solution: Can only assume here that the ‘&’ ampersand in the name of the delivery group killed the publication there of, or the delivery group publication process failed and a recreate was required.
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.
Clients can no longer SSON through the PNAgent
Storefront webpage only displaying 1 of the 2 delivery controllers configured. (legacy xenapp 4.5, nothing from xenapp 6.5)
Solution
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.
PROBLEM 1
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
Then the server could not be contacted.
Online legacy client unable to authenticate to upgraded storefront server
Then magically refreshes a 3rd time and just logs in anyway!?
PROBLEM 2
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
