Office Communications Server Admin Tools on XP

While working on our customer's deployment of Office Communications Server 2007 R2, we discovered that the Administrative Tools for OCS will only install on Windows 2003, 2008 or Vista. This is unfortunate, because all of our customer's client workstations (including the administrators) are running XP (yeah, yeah, I know... we're working on the upgrade).

Anyway, this left us in a pickle. The administrators use tools installed on their workstations to minimize the need to perform admin tasks right on the servers. Unfortunately, not having OCS admin tools would require accounts to be provisioned at the server.

So this got me thinking... both 2003 and XP are essentially the same software baseline, right? What if the OS version restriction is simply installer based (gasp! you mean Microsoft tries to force you to upgrade)? As it turns out, it is (and they are)! As far as I know (and I can most certainly be wrong), there is no solution to this problem posted to the Internet.

This is how we worked around the issue:

1. On the Communications Server 2007 R2 installation DVD,navigate to the support\i386 directory.This contains x86 installer files (although the server runs on 64-bit only, I am assuming you want to install the tools on a 32-bit XP machine).

2. Copy off AdminTools.msi and OCSCore.msi to a local directory where you can edit the files.

3. Using Orca (which is part of the Windows SDK), edit both files by adding (VersionNT=501) to the boolean condition in the LaunchCondition table for version checking. 501 is the version for Windows XP.



4. Additionally, in OCSCore.msi, you must delete six SCManager related actions (otherwise this will throw a cryptic 'invalid token' error and fail the install):



5. Save the installer files.

6. Install the admin tools. This must be done in a specific sequence:

a. If the Windows Server Admin Tools have not already been installed on the target machine, this is the time to do it.
b. vcredist_x86.exe (C++ 2008 Redistributable)
c. sqlncli.msi (SQL Server native client)
d. OCSCore.msi (use the new OCSCore you just edited)
e. AdminTools.msi (again, use the new file you just edited)

7. Now, when you open your right-click context box for a user, you should now have all of the OCS actions available to you. Additionally, you will have the Communications tab in the user properties window.

SharePoint assemblies and the GAC

One of the more tedious aspects of SharePoint feature development is that the feature receiver must be installed into the Global Assembly Cache. Because of this, the dll has to be strongly named and referenced by its four-part assembly name within the Feature.xml file. The first three parts (name, version, and culture) are pretty easy to figure out. But the last part, the public key token, is not so obvious.

In my opinion, the most elegant way to discover this information is to use the Strong Name tool (sn.exe) provided in Visual Studio (see Wriju's blog entry on this http://blogs.msdn.com/wriju/archive/2008/07/01/how-to-find-public-key-token-for-a-net-dll-or-assembly.aspx).

Not to be outdone, and being a generally lazy guy, I set out to find a way to make this process even easier. So I created a new External Tool command in Visual Studio that runs sn.exe and gets the public key token of an assembly for me and displays it in the IDE's Output window:

In Tools
External Tools, click the add button.

For title, call it something like 'Get &Public Key Token' (for you non win forms developers, the ampersand creates a keyboard shortcut for the command).

In command, enter 'C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\sn.exe' (you may need to modify the path depending on where you have sn.exe installed).

For arguments, enter '-Tp $(TargetPath)'. This ensures that the correct assembly is checked, based on build configuration. Ensure 'Use Output window' is checked. And that's it. Of course, the assembly needs to be signed and you need to build the dll before running this command.

What is up with that %@#*&( batch file?!?!

So I'm working on a batch file to run some post-build events in Visual Studio, but when i run the build I notice something funny in the output window:

{{[[@ECHO OFF is not recognized as a valid command

Disclaimer: That might not be exactly how the error read, because I've already fixed the error and I'm too lazy to recreate it to get the exact wording, but you get the idea.

Now, the first line in my batch file is in fact a valid command, but there are all of these funny characters at the beginning of the line in the output window. So I go back to the actual batch file and those funny characters are not there.
So here I am scratching my head, thinking "I didn't put those characters there, so who did?" Of course, my first reaction is to blame the machine!
After fiddling around with it, I discovered that whenever you create a new text file in Visual Studio and make it a batch file, it introduces these funny characters to the beginning of the file. I can only speculate (since I didn't actually look at the bytes in the file), but I think it might be a Unicode vs ASCII encoding issue.

Long story short: if you want to create a batch file, first create it Notepad. Save it off and then edit it in Visual Studio and you won't have any problems with encoding.