Recently, my Word 2007 program started experiencing some weird behavior.  When I had a document open and would go to close Word, I’d be greeted by this:

Also, since I’m running Windows 7, when I tried to Right-click the Word icon that I pinned to my taskbar and open a recently opened document, Word would open, but not the document.  I would have to explicitly open the document from within the application.

Initial reports I read pointed to a recently installed patch, but instead of going through my “Programs and Features” uninstalling patches one-by-one, I found an even easier solution on Ed Bott’s blog.

NOTE: The following instructions deal with editing the Windows Registry, which is not for the incautious or faint of heart. It would be a good idea to back up your Registry and/or create a restore point before trying this.

If I haven’t scared you off, open Regedit, navigate to HKCU\Software\Microsoft\Office\12\Word and delete the “Data” Key.  (I did export the “Data” key first, just to be on the safe side.) After deleting the key, Word appeared to open and close properly.  I right-clicked the Word icon on my taskbar, chose a document to open and it opened right up. So far, so good.

I then merged the backed-up reg key back into the registry and tried opening that same recently-used document from the task bar – Word opened, no document.  Then upon closing Word, it crashed again.

From the information in Ed’s blog entry, the cause appears to be related to having Word running at the time a particular “Important” update is applied to the system. Removing this reg key fixed it right up! I saved at least 30 minutes by avoiding having to uninstall and reinstall Office.

A couple months back, I was working on a XenDesktop 3.0 installation.  The customer was having some issues with licensing, so my first thought was to upgrade the license server to the newest version – because historically that’s been the recommended first step in dealing with license issues.  In this case, though, it turned out to break other things – but in the end gave us some very valuable information.

First, a little background information.  XenDesktop uses an agent on the virtual workstation images that communicates with a server piece called the Desktop Delivery Controller (“DDC”).  This agent/server communication happens on TCP port 8080.

Unfortunately, in this specific case, the Citrix License Service was running on the same server as the DDC service. And in the latest version of the license server service, Citrix changed the port that the License Management Console uses to communicate with the license server to…yeah, you guessed it: 8080.

This conflict prevented the XenDesktop machines from checking into the DDC, so the DDC, which, as you might infer from its name, is the broker service that controls the delivery of virtual desktops to client devices that request them, viewed them all as “offline”.  It therefore believed that there were no virtual desktops available, so no connection requests were being serviced. In technical terms, this is what we call a “bad thing.”

The solution in this case was to change the port that the License server and License Management Console communicate on to port 8082 – which just happens to be the port it used in previous versions… hmm…

It should be noted that this can affect more than just XenDesktop Agents.  Port 8080 is heavily used for other Citrix functions, such as the XML service.  Why Citrix would change the license service to port 8080? Why do people jump out of perfectly good airplanes? Guess it seemed like a good idea at the time…to somebody, anyway.

Once we started digging for it, we found detailed steps on editing the license server configuration in the License Server 11.6 readme, and it’s obvious from the text that Citrix knew using port 8080 could cause conflicts:

When you install the license server components, version 11.6.1, on the same server as other Citrix products, the License Management Console is configured to use port 8080, by default, which may conflict with the other Citrix products (for example, they may use the Citrix XML Service which may use 8080 as well). To resolve this issue:

1. Navigate to C:\Program Files\Citrix\Licensing\LMC\tomcat\
   conf\server.xml
2. Open the file in Wordpad.
3. Replace the port number (8080) in the following line with 8082:
   <Connector port=”8080″ protocol=”HTTP/1.1″
   connectionTimeout=”20000″ redirectPort=”8443″/>
4. Save the file.
5. Reboot the server.

The other way we could have solved the problem, of course, would have been to move the license service to a server that had no other Citrix components running on it. We generally recommend that as a best practice, if at all possible (although we realize that sometimes it isn’t).  It just makes things easier in the long run.

We here at Moose have been working with Web Interface 5.2 (hereafter referred to as WI 5.2) more and more these days, and the question was bound to come up, “Can I use the new WI 5.2 with my old Presentation Server 4.0 farm AND my new XenApp 5.0 farm at the same time?”

Yes, you absolutely can.  The Admin guide for WI 5.2 states that it is compatible with the Windows 2003 and UNIX versions of Presentation server 4.0 up through the current XenApp 5.0 versions.  However, it is not 100% compatible right out of the box.

You can configure your old Presentation Server 4.0 farm in the WI 5.2 farm properties and then login to the WI and see all of your published apps, but when you go to launch one you will receive the following message:

“An error occurred while making the requested connection.”

Screenshot courtesy Citrix’s KB article CTX123003

The solution is detailed below.  These exact steps are from Citrix KB article CTX123003

1. On the Web Interface 5.2 server, locate the WebInterface.conf file (\Inetpub\wwwroot\Citrix\XenApp\Conf) and open it with a text editor.
2. Locate the following entry around line# 169:
   RequireLaunchReference=On
3. Replace it with the following entry:
   RequireLaunchReference=Off
4. Save the WebInterface.conf file and test.
5. Users should be able to launch applications from the XenApp 4.0 farm successfully.

That said, it is important to note that Presentation Server 4.0 hit “End of Life” on Dec. 31, 2009. (Citrix lists product lifecycle information for all of their products on their Web site.) This means that product downloads and hotfixes are no longer available, and tech support is limited to whatever information you may be able to dig out of the Citrix on-line Knowledge Base. So we sincerely hope that the only time you would ever be using the information in this post is when you’re in the process of transitioning from Presentation Server 4.0 to your new XenApp 5 (or, very shortly, XenApp 6) farm!

This post was inspired by my quest to install the newest version of Windows Live Messenger on our 32-bit, Windows Server 2008 servers running XenApp 5.0 here at Moose.  We were previously running Live Messenger 8.5 until it started prompting us that an update was available and would not let us use the program until it was updated.  This update is mandated by Microsoft to keep everyone’s messengers up-to-date to protect against security flaws.

According to the Windows Live Essentials System Requirements, you can install it on Server 2008…HA!  Good luck!  Standard attempts to install just don’t work – it goes through the process and at the end of the installation it rolls everything back. (Note: Click on an image to view full-size.)

Live Messenger System Requirements

By default, the package you download from http://download.live.com to install Live Messenger is a small executable that asks you what other programs you want to install.  Once you’ve made your choices, it downloads the actual installation bits from the Internet.  There is a full download that contains all the installers, but you won’t find it on a Microsoft site (at least I couldn’t).  I ultimately found it on this third-party Web site. You can do the installation with either package, but I did it with the full 140 Mb package, so I know it works that way.

I have not found any way to extract the contents of the full package executable into separate .msi files for each product.  You can browse to c:\program files\common files\windows live\.cache\ and search for the particular piece you’re looking for (Messenger.msi in my case), but it is a silent install, and things still didn’t work after trying to install it on Server 2008.

The solution I found was to actually hack the installer to allow it to install on a server OS.

I found an article via a Google search that is actually for installing Windows Live Wave 3 Beta on unsupported x86 and x64 versions of Server 2003 and 2008, and discovered that the method worked perfectly for Live Messenger as well.

To install Live messenger you will need to download:

1. The full install of Windows Live Essentials;
2. “Resource Hacker” from the link in the article above. I chose the UK mirror.

Customization and Installation steps:

1. Extract the ResHack.zip file to your hard drive (anywhere works, I used the Desktop).
2. Launch ResHack.exe from the extracted files.
3. Open the Windows Live Installer executable (WLSetup-All.exe or WLSetup-Web.exe).


Open the Windows Live installer file

4. Locate CONFIG -> CONFIG0 -> 0.


Using ResHack

5. Select-All and copy the XML code into a text editor such as Notepad (choose Word Wrap from the Format menu in Notepad to make it easier to edit)
6. Find ‘os productType=”workstation”’  and replace ‘workstation’ with ‘server’


Select Text to Replace

7. Copy/paste the XML code back into ResHack, replacing the old code
8. Click ‘Compile Script’


Compile Script

9. Select File -> Save and save the modified executable (Make sure to put .exe on the end of the filename and name it something unique).  It’s 140Mb – be patient as it compiles the executable.
10. Run the modified executable.

The Windows Live applications should now be installed on Server 2008!

Happy Messaging!