For quite a while I had an issue on one of our Citrix servers (let’s call it termserv1) where I was receiving “This patch package could not be opened”/”Package corrupt” errors when trying to install patches for Presentation Server 4.0. Since the server doesn’t hang directly off the Internet I had put off fixing it for several years in the not unrealistic hope that I might one day be able to ‘upgrade’ out of the issue.
Our other Citrix servers are quite a bit more important and they had to be patched. After every patch I waited for something bad to happen where the newly patched boxes would have some communication issue with the unpatched server. I had gotten lucky for a long time, but this past week my luck finally ran out when I installed the version 6 hotfix rollup (what will probably be the last hotfix rollup for Presentation Server 4.0). The ‘good’ servers reported that they were unable to contact the licensing server. I figured, somewhat incorrectly as it turns out, that the issue was related to the fact that the termserv1, which was the license server, had not been patched.
The reason I had put off fixing the issue is that the fix was rather non-existent. The first step was to delete the Presentation Server install entries by using the Windows Installer Cleanup Utility. The second step was to re-install Presentation Server (which for me also required renaming the files ‘ctxdwavo.exe’ and ‘mfreg.exe’ AND rebooting). The third step was to hope for the best, and barring that, to fix whatever didn’t work, which in this case meant pretty much everything.
The core issue was that termserv1 was the main server that I relied on in our transition from MetaFrame 1.8 to Presentation Server 4.0 and it had taken quite a bit of work and a long phone call to Citrix to get all of the licensing pieces to work. From that point on I relied on termserv1 to be the master browser/data collector and main license server. As it turned out, the licensing issue was related to the fact that the licensing service from Citrix is not patched with hotfix updates and is in fact a separate download. However, after reinstalling on termserv1 the ICA browser was not working and the server would refuse direct connections with either ‘Protocol Driver Error’ or just ‘cannot connect to the Citrix XenApp server’ both of which can be an indication of almost any issue.
Emboldened, I decided to uninstall Presentation Server (now that the installer was working) and reinstall. The uninstall went fine, however when I went to reinstall it refused to join a farm without a SQL database link (we use the included Access database). I wound up having to selectively restore the unpatched Citrix back onto the box. After the restore the browser worked again, but ICA connections to the server did not. Figuring that I would just have to fight my way through it I reapplied the patch and set out to find out what was wrong.
Since I was getting the unhelpful errors from the XenApp client I decided to see if I could get the web interface working to the point that I could get a helpful error or two. This turned out to be a day long time sink; getting the antiquated version of the Citrix web functions working on a newer server (Win2k3 r2) whose own version of Presentation server wasn’t working anyway, was asking too much given the immediacy of the need to get the server back into full operation again (although it hosts production applications, they’re used sparingly). I got to the point of getting the “exception has been thrown by the target of an invocation” when trying to create a new web server before giving up.
Frustrated, I turned back to the regular clients. My first plan of attack was the fact that pointing the XenApp client at one of the two ‘good’ server worked, and termserv1 didn’t, which told me that there was a browser issue of some sort. Somewhere along the line I came across a Citrix forum post that suggested deleting and recreating the ICA connection. After doing that the published items still didn’t work, but direct connections did! After running ‘query farm /load’ I discovered that termserv1 and the other two servers didn’t really see themselves in the same farm (‘query server’ would return all the servers, but ‘query farm /load’ would return incomplete lists). I performed some actions with ‘dscheck’ and ‘dsmaint failover’, but the real fix (I think) was going into the farm properties in the MetaFrame management console and toggling the affinity between the servers. Before doing that the servers had two different affinity sets. Setting it one place made it consistent and everything in Program Neighborhood began working properly.
*UPDATE: If any of the above is helpful it’s a coincidence. After rebooting termserv1 the IMA service failed to come back up and the management console was inaccessible on any of the servers. I hacked around for the better part of a (Sun)day, but as it was closing in on midnight I threw in the towel and rebuilt the farm. I was at least able to rely on a screen shot I had taken as a business continuity hedge so that I’d know which apps I had to rebuild.