Custom Outlook toolbar’s location

 Default Outlook toolbars save their location in the Outlook configuration file outcmd.dat, part of the roaming profile (in %APPDATA%\Microsoft\Outlook to be precise). This data is remembered when Outlook restarts, even after logging off and on again.

Non-default (custom) Outlook toolbars however are “temporary” in nature (in the sense of they’re not part of Outlook itself and are considered to be initialized/loaded separately each time Outlook loads). Those toolbars don’t save their location data in outcmd.dat, but have to provide their own mechanism. Microsoft offers a default way for such a mechanism, i.e. through a configuration file called user.config in the local part of a user profile (more precisely in %LOCALAPPDATA%\[company]\[application]\[version]). This means custom Outlook toolbar location changes can be saved and reused (even after logging off and on again) if the toolbar is programmed to do so and if so, it can be done through this default mechanism Microsoft provides.

 

Figure 1

 

So far, so good, but what if you’re using roaming profiles? Well, it depends. Custom toolbars don’t save their location data to the profile server (because it doesn’t belong to the profile’s roaming part, which is the part that gets saved to the profile server). If the cached profile is deleted at logoff time this means this location data is lost by definition. And even if it’s not deleted at logoff time, you’re not guaranteed to get the same system again when using multi node farms with more than 1 concurrent node being active. The only way roaming profiles don’t get your location data removed is when you log on to the same system over and over again (but then, why would you need roaming profiles…?). So the bottom line is roaming profiles typically make you lose custom Outlook toolbar’s location data.

 

The solution could have been to remark the folder as roaming (instead of local), but to do that you actually need to remark the %LOCALAPPDATA% as roaming and mark every subfolder of this path as local (because they were initially local J). This is a hell of a job, especially because the subfolders of %LOCALAPPDATA% can change over time, so it’s not an administrator-friendly way. Also, files in the root of %LOCALAPPDATA% will be marked roaming instead of local, which isn’t always something you want… So there is a good chance this solution isn’t right for you. Anyway, if you’re interested in this solution, take a look at the registry key ExcludeProfileDirs in HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Winlogon. The default value since Windows Vista is “AppData\Local;AppData\LocalLow;$Recycle.Bin” and “Local Settings;Temporary Internet Files;History;Temp” for pre-Vista systems.

 

Figure 2

 

A second solution is to adapt the toolbar’s application (which is an add-in of course) and rebuild it, so the roaming part of the profile is used for storing the user.config file (take a look at http://stackoverflow.com/questions/3307699/how-to-save-user-config-to-appdata-roaming-folder-instead-of-appdata-local for more information). This solution could be a problem for software that’s not developed in-house and feature requests are not guaranteed or when some other problems are present (like it takes a lot of time to rebuild, the developer of the add-in has died and there is no replacer, etc. etc. J).

 

Links:

• http://www.outlookcode.com/vsto/toolbarpos.htm
• http://msdn.microsoft.com/en-us/library/ms268891(v=vs.90).aspx
• http://stackoverflow.com/questions/3307699/how-to-save-user-config-to-appdata-roaming-folder-instead-of-appdata-local

 

Oh yes, if you take a look at those URLs, you’ll notice the toolbars are implemented through the CommandBar classes. Always interesting to know J

 

 

Regards,

Pedro