Renat Tlebaldziyeu

Deploying per-user Office extensions via Group Policy

This is part 6 of the deployment series that targets corporate deployment techniques and provides step-by-step instructions for deploying your per-machine Office extensions via Group Policy. I recommend that you start with reading Part 1 that gives a brief overview of all deployment technologies.

Step 1. Set RegisterForAllUsers = false

If you develop a COM add-in or an RTD server, set the RegisterForAllUsers property of your add-in module or RTD server module to False. If you develop any other Office extension types, go to Step 2.

Set RegisterForAllUsers = false

Step 2. Build your project

If you want to support Office 2010 32-bit and 64-bit applications, set the Platform target property to “Any CPU” before building your project.

Set the Platform target property to Any CPU

Note. If you use a 32-bit component in the Office extension (say a native-code DLL, ActiveX DLL , or .NET assembly) you should compile with the “x86″ target platform. But please be aware that the Office extension will work in Office 2000 – 2010 (32-bit) only and will not work in Office 2010 64-bit.
By analogy, if you use any 64-bit third-party components, you should compile with “x64″, but your Office extension will work in Office 2010 (64-bit) only.
In summary, if you use a bitness-aware component, your extension will work for Office versions of that bitness only.

Step 3. Create a setup project

Add-in Express provides the setup project wizard accessible via Project | Create Setup Project menu in Visual Studio as well as via the context menu of the project item in the Solution Explorer window (shown below).

Create Setup project menu item

In the New Setup Project Wizard dialog fill all the fields (Title, Description, Product name, Company of your Office extension) and click the Next button.

New Setup Project Wizard step 1

You can choose the Localization of the installer UI, Output directory and File name.

New Setup Project Wizard step 2

Click the Finish button. This creates a new setup project.

Step 4. Check the DefaultLocation property

Select your setup project in the Solution Explorer window and open the File System Editor. Select the Application Folder node and check the DefaultLocation property. By default, the setup wizard sets the DefaultLocation property to the user application data folder as follows:


DefaultLocation property

Step 5. Delete custom actions

Select your setup project in the Solution Explorer window and open the Custom Actions Editor. If you used the Add-in Express wizard, then in the setup project that was created by the wizard there are 3 custom actions in which adxregistrator.exe is used. Delete these custom actions.

Step 6. Add new custom actions

In the Custom Actions Editor, add three new custom actions under Install, Rollback and Uninstall by selecting adxloader.dll as a custom action. Then change the EntryPoint property for each of the actions as show below:

Install: EntryPoint = “DllRegister”

Custom action for adxloader.dll

Rollback: EntryPoint = “DllUnregister”

Uninstall: EntryPoint = “DllUnregister”

Rollback custom action for adxloader.dll

Step 7. Set PostBuildEvent

Select your setup project in the Solution Explorer window and edit the PostBuildEvent property as follows:

“{Add-in Express}\Bin\adxpatch.exe” “$(BuiltOuputPath)” /UAC=Off /RunActionsAsInvoker=true


{Add-in Express} is the full path to the installation folder of Add-in Express.

PostBuildEvent property

This executable patches the generated .MSI in the following ways:

  • it hides the “For Me” and “For Everyone” choice in the installer UI.
  • it turns off the dialog asking for administrative privileges; the UAC dialog pops up when a non-admin user runs a setup.exe on Vista/Windows 7/Windows 2008 Server.

The option /RunActionsAsInvoker=true guarantees that the installer will be run with the privileges of the user who started the installer and not with the system privileges. This setting allows bypassing the AlwaysInstallElevated policy, which is described here.

Step 8. Build the setup project

Build your setup project and deliver the generated .msi file to the administrator.

Step 9. Running the installer using Group Policy

Use Group Policy to deploy and automatically install / uninstall your product. You can read how to do it in this article: HowTo: Install a COM add-in automatically using Windows Server Group Policy.

Step 10. Installing a new version of the Office extension

You need to change the assembly version of your Office extension as well as the version of the setup project and rebuild your setup project. The admin needs to remove the installation package and assign a new one as described in HowTo: Install a COM add-in automatically using Windows Server Group Policy.

Note. Don’t change the Product code property of your setup project. By default, when you change the Version property of your setup project, Visual Studio shows a dialog recommending that you change the Product code. Click No or Cancel in this dialog because if you change the Product code, you will get a new Office extension installer, consequently the previous version of your extension may not uninstall correctly when the user launches the new version installation.


  • Bas says:

    Thanks for this article.

    Can I delete the file adxregistrator.exe from my setup?

  • Dmitry Kostochko (Add-in Express Team) says:

    Hi Bas,

    The adxregistrator.exe tool is purposed for registration and un-registration of your add-in on the target machine. So, you needn’t delete this file.

  • Nick says:

    Do you have instructions for achieving the same thing with a Wix setup please?

  • Dmitry Kostochko (Add-in Express Team) says:

    Hi Nick,

    Sorry, we do not have instruction for a WiX setup but I think you can create a default WiX setup project, build it and test its deployment via the Group Policy. I am almost sure the adxRegistrator.exe will work correctly.

Post a comment

Have any questions? Ask us right now!