Problems installing CodeTwo agent on Exchange 2013 CU11

This article is obsolete and may relate only to older versions of our software.

Problem:

You experience problems with CodeTwo agent of MS Exchange Transport Service during installation of CodeTwo Exchange Rules family software and CodeTwo Exchange Rules Pro in environments with multiple Exchange Servers, from which at least one is Exchange Server 2013 withCumulative Update 11(CU11) installed.

Solution:

So far, when you opened  Exchange Management Shell (EMS) directly on Exchange Server machine (or connected remotely using PowerShell) you were connected directly to the desired Exchange Server. In CU11 for Exchange 2013, Microsoft has introduced mailbox anchoring feature. Basically, this feature checks on which mailbox server resides the database, in which your user's mailbox is located and then it redirects the connection to that particular server. The whole operation is transparent to the user, the  Exchange Management Shell still displays local machine name and address, so a user who is unaware of this feature will definitely not realize the connection is being proxied to a different server. This change affects not only user-started PowerShell/EMS connections but also connections invoked programmatically, hence CodeTwo software failure during agent installation.

CodeTwo Exchange Rules PRO 2.5.2.45 (and newer) and CodeTwo Exchange Rules 2013 2.5.2.47 (and newer) are already implemented a software-side solution to this problem. Keep in mind that all instances of CodeTwo software must be updated.

Following workarounds below is required only for clients who are not eligible for free update to these versions (contact us if in doubt) or for some reason cannot update.

Until either Microsoft changes this unexpected for many behavior (see comments here and here), you can work the problem around by following the steps below:

1. On each server that you will be installing CodeTwo software open Internet Information Services (IIS).
2. Navigate to Sites, Default Web Site, PowerShell, click on Advanced Settings... on the right-hand side pane.
3. Temporarily change thePhysical Path from the default one, which most likely is:

   C:\ExchangeServer\V15\FrontEnd\HttpProxy\PowerShell

   to the one below:

   C:\ExchangeServer\V15\ClientAccess\PowerShell

   Be advised that paths will differ if you installed Exchange Server in non-default folder or on a different drive.

Fig. 1. Changing IIS Powershell Physical Path.

4. Restart the IIS (open cmd.exe as administrator and execute iisreset).
5. Install CodeTwo Software (or reinstall on the top, if you already installed but only agent installation was unsuccessful).
6. Go back and revert changes in IIS, restart the IIS again.

Alternatively, if you cannot allow IIS changes even for a few minutes or the above workaround does not work:

1. Install CodeTwo Software on desired servers. Ignore any errors regarding agent installation.
2. On all machines where CodeTwo software was installed runservices.msc and stop Microsoft Exchange Transport service.
3. Open the below folder:

   C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Shared

   Be advised that paths will differ if you installed Exchange Server in non-default folder or on a different drive.

4. Back up theagents.configfile first by copying it to a safe location.
5. Open the originalagents.configfile with a notepad or any other editor.
6. Review the file, if you find any entries regarding CodeTwo already, skip modifying file on this server.
7. Before the </agentList>tag add a new line and insert the following:

         <agent name="CodeTwoExchangeRulesPro" baseType="Microsoft.Exchange.Data.Transport.Routing.RoutingAgent" classFactory="Agent.CAgentFactoryRouting" assemblyPath="C:\Program Files\CodeTwo\CodeTwo Exchange Rules\CodeTwo.ER.Agent.dll" enabled="true" />

   Be advised that if you installed CodeTwo software in a non-default location, you need to modify value of the assemblyPath above. Also, for CodeTwo Exchange Rules 2013/2016/2019 remove "Pro" from the end of the agent name above.

8. Save and close the file.
9. In services.mscstart Microsoft Exchange Transport service.

After you apply the workaround you can find out if it worked by:

• checking after some time, in the Server Monitor of the Administration Panel if the server in question displays statistics on the number of emails processed by it - this however, might not be 100% accurate as this also depends on how you route mail traffic in your organization,
• checking if the software populated agent folder in the software's log files folder within %programdata%.