Tag Archives: registry

Fix OCS 2007 R2 Integration with Outlook 2013 Preview

As noted last week, I installed the Office 2013 Preview and was generally excited about it except for the fact that I wasn’t getting any presence information for contacts from Lync. I assumed this was because I was using an unsupported configuration with my 2010 Lync client connecting to an OCS 2007 server.

I decided that Office 2013 was more important than Lync 2010 and reverted to OCS 2007 in hopes that it would fix my woes, but it did not. After a bit of Googling and tinkering, though, I was able to find a solution to get things back on track.

There’s a registry key that lets Outlook know what the default IM provider is, and this value was set to Lync on my workstation. In looking at the two sub-keys, I could see “Lync” and “Communicator.” So, I took a guess and changed the value to “Communicator,” restarted Outlook, and–voila–I was in business!

Here’s the full registry key and value that I changed to fix it:

[HKEY_CURRENT_USER\Software\IM Providers]

Just as a recap, here’s what I had going on:

  • 32-bit Office 2010 w/ Lync 2010 client and this registry hack¬†on 64-bit Win7
  • Upgraded to 32-bit Office 2013 Preview
  • Uninstalled Lync 2010, installed Communicator 2007 R2
  • Removed the aforementioned registry hack
  • Made the registry changed noted above
  • Restarted Outlook, restarted Communicator

Update 10/26/2012:
I upgraded to the RTM version today, and OCS 2007 R2 is still functional.


An Easy Fix for Registry Access for 32-bit Applications in 64-bit OSes

My company has a 32-bit application that is frequently run in a 64-bit environment. There are some registry settings retrieved by this application that exist in the WoW6432Node in a 64-bit OS, but how can we make our application smart enough to look there without breaking backward compatibility with 32-bit operating systems or sacrificing future compatibility if our application is converted to 64-bit?

One option is to implement a solution like what’s described here. You can add logic to your application to determine whether the OS is 32 or 64 bit and access the appropriate key.

That’s great, but it’s a lot of work for a setting in my application that’s read once during initialization. Instead of going through all that trouble, I just implemented a simple retry algorithm to look in Wow6432Node if the key isn’t found in the default expected location.

var regKey = GetRegistryKey(@"SOFTWARE\MyCompany\Settings");
if (regKey == null)
    regKey = GetRegistryKey(@"SOFTWARE\Wow6432Node\MyCompany\Settings");
    if (regKey == null)
        throw new InvalidOperationException(
            @"Unable to find registry key HKLM\SOFTWARE\MyCompany\Settings");

internal virtual RegistryKey GetRegistryKey(string path)
    return Registry.LocalMachine.OpenSubKey(

It’s simple and it works–terrific!