Deploying the Outlook Plug-in for Exchange Integration via GPO

The Sage CRM Blog

Articles of general interest about Sage CRM, the community, add-ons and general news!

Deploying the Outlook Plug-in for Exchange Integration via GPO

  • Comments 1
  • Likes

Sage CRM v7.1 now has the feature of being able to deploy the new Outlook Plug-in for Exchange Integration as a Microsoft Active Directory Group Policy Object (GPO) which is a very useful feature if you are rolling out to large sites. However, dig a little deeper and it’s not quite as straightforward as it may first appear.

Group Policy deployment only supports the roll out of files with either a .msi or .msp extension. The Outlook Plug-in for Exchange Integration ‘Sage CRM Client Applications.msi’ is in this .msi format so no problems there. The catch comes when you look at the pre-requisites that the plug-in requires. These being;

• Microsoft DotNet Framework v4.0

• Visual Studio Tools for Office Runtime (VSTOR)

• Microsoft Office Primary Interop Assemblies (PIA)

The Microsoft Office PIA is already in .msi format so no issues there but both the DotNet 4 Framework and Visual Studio Tools for Office Runtime (VSTOR) are only available in setup.exe format which can’t be deployed via GPO. Grr!

Fear not, with a bit of lateral thinking it is possible.

Firstly the DotNet Framework. Now this isn’t deployable via GPO and due to its size and complexity you probably wouldn’t want to deploy it via GPO anyway. However, it is available either via the Windows Update service, or if you have a larger infrastructure, it can be easily deployed using Windows Server Update Service (WSUS). Also, many programs are now reliant on the DotNet 4 Framework so you may find it is already installed on your client machines anyway.

The Visual Studio Tools for Office Runtime is a bit more of a challenge. It isn’t included in the Windows Update Service and isn’t available for deployment via WSUS. This is where you need to be a bit cleverer and perform an administrative installation to extract out the msi file.

Firstly create a shared folder on your server. I called mine c:\Vstor on my pc NET01

From the Windows Run command, execute c:\Program Files\Sage\CRM\CRM\WWWRoot\Plugin\vstor40_x86.exe /a

The /a switch is going to perform an administrative install which extracts out all the files.

Run through the Administrative Install Wizard and tell it to put the source files into the shared folder you created. Mine being \\net01\vstor. Remember to use a UNC path for this.

Once the install has finished you will now have the extracted out contents of vstor40_x86.exe within the shared folder and one of these files will be vstor40_x86.msi!

Copy the entire contents of the shared folder to the deployment area on your domain controller (or wherever you deploy GPO software from).

From within Group Policy Management, you can now create a new policy pointing to the extracted vstor40_x86.msi file to roll out the Visual Studio Tools for Office Runtime to all your client machines.

A couple of additional notes if you are planning to roll this out.

The Outlook Plug-in for Exchange Integration must be rolled out using a Machine Based policy not a User Based policy.

If you find you are having issues rolling out the plug-in it is also worth ensuring that the .msi file doesn’t have any spaces in the name as this can sometimes cause issues. So it may be worth renaming Sage CRM Client Applications.msi to CRMPlugin.msi before deploying it.

Gpupdate /force is your friend when rolling out via GPO. Use it on the client machine to force a refresh of the policy.

Also, take care when initially compiling the Sage CRM Client Applications.msi file in Orca. I personally have had issues with the file size reducing after saving changes but it may just be my environment. Make sure your Sage CRM Client Applications.msi is 5.79MB in size before deploying it.

 

Comments
  • Great post Paul thanks for that!

    It might also be useful to note that while the Outlook Plug-in for Exchange Integration must be rolled out on a per machine basis this does not mean that every user that logs onto a machine (where the plug-in has been installed) has to be exposed to the plug-in.

    Where many users log on to the same machine - it is entirely possible to restrict specific users from ever seeing the plug-in in their Outlook client via a simple HKey Current User registry key.

    This is especially useful in Citrix/Terminal Services environments or in hot desk/kiosk environments where many users are logging onto the same machine (and all using the same Outlook install) but only certain users need to work with the plug-in or are supposed to have access to it.

    Utilising this registry key is the recommended way if controlling "user specific" access to the plug-in where many users log onto the same machine.

    How to set up this registry key is described in full in the Exchange Integration chapter of the Sage CRM v7.1 System Administrator guide.

    Thanks,

    Frank