Product Review: Exclaimer Email Alias Manager

Product: Exclaimer Email Alias Manager

Product Homepage: Click here

Free 30 day Trial: Click here

Solving an age-old problem

For as long as many Exchange administrators will remember, allowing users to send email from one of their additional email addresses has always been a pain. If you’ve wanted to be able to do this then you’ll have had to resort to unintuitive workarounds. So it’s about time that a third-party stepped up to provide a way to make this easy for end-users to control.

Exclaimer’s approach looks both logical and straightforward. On each Exchange Server hosting a Transport Role, Exclaimer’s Transport Agent is installed, parsing outgoing messages that need their Alias changed. On the client side, an Outlook add-in is installed that allows the user to select from their Exchange email addresses.

Installation and Configuration

Obtaining a trial of Email Alias Manager for Exchange is straightforward, like most Exclaimer products. By default the download of the software is a 30 day trial, making it very easy to test the product before purchase.

Before installation, we took a look at the documentation provided by Exclaimer. Obviously with products like this there is a fine line between too much and too little documentation. For the average administrator, the documentation is great. It covers the installation and configuration of both the product itself, and how to install and use the Outlook add-in.

For our test environment, a multi-server Exchange organization consisting of both Exchange 2010 and Exchange 2013 servers, Exclaimer recommend installing the product on all Exchange Servers with a Hub Transport Role, which means our multi-role Exchange 2010 servers and the Exchange 2013 servers hosting the Mailbox role.

During the installation, we’re only presented with a single option – the installation location. Within this folder we’ll find our install files for the Outlook add-ins, so make a note of this folder so you can find it later.

Figure 1: Choosing the installation location

Next, the installation will begin. Not only does this install the underlying files, it also registers the Transport Agent with Exchange and immediately activates it. One thing that’s not mentioned in the documentation is that during install, it will restart a service:

Figure 2: Installation proceeds, apparently restarting services

Naturally one might wonder what’s being restarted. A quick look at the Services Management Console during installation shows that it’s the Microsoft Exchange Transport service:

Figure 3: Checking to see which service is restarted

Now, although this won’t affect end-users in the way that, say, a restart of the Information Store might… it would be nice to be told about this before it happens, either in the documentation or a confirmation box within the installation wizard.

After the installation completes we can launch the Alias Manager control panel. In the full unlimited version, and the trial, there’s not much to see apart from information about the licence:

Figure 4: Viewing the Alias Manager Control Panel

If you buy the per-user licenced version then you’ll see an additional tab, giving you the ability to select which users each seat applies to, either by individually selecting users or importing information from a CSV file.

Although the Control Panel may look sparse, this is a good thing. This shouldn’t be a product that requires a lot of effort to maintain or configure, as each user’s email addresses are already configured within Exchange and can continue to be managed using native tools.

If we want to have a look in Exchange and verify that Alias Manager is indeed installed correctly, then we’ll need to use the Exchange Management Shell. Using the Get-TransportAgent cmdlet we are able to see the agent listed:

Figure 5: Verification of installation of the Alias Manager Transport Agent

After the installation on the first Exchange Server, we’ll repeat the process on other Exchange Servers. As mentioned above, Exclaimer recommend that the product is installed on all servers hosting the Hub Transport role.

It isn’t enough to simply run the installation wizard on each server required though. Each server will require the licence to be applied, and for smaller organizations using per-user licencing the user list must be re-imported.

As this could be an arduous process for larger organizations, we figured that primarily what we are trying to get Alias Manager to do is process messages as they leave the organization. Therefore it can be installed on servers that are configured as source servers for internet-bound Send Connectors. A quick test in the lab confirmed this was the case.

With the installation and (minimal) configuration complete, the next step is to deploy the add-in to clients. Add-ins are only available for the Windows Outlook client, both 32-bit and 64-bit, and not for Outlook Web App or Outlook for Mac. The add-in is MSI-based which means it can be deployed either manually, or via other deployment methods such as group policy.

Exclaimer provide guidance for deployment via Group Policy therefore we tested their documentation to see if it was indeed trouble-free on our installation – a Windows 8.1 client using Office 2013 Click-To-Run.

The Group Policy configuration took approximately ten minutes to configure from start to finish and is a good reminder of how simple software deployment can be, as well as how underused Group Policy software distribution is.

The end-user experience

After installing it on the servers and deploying the Outlook add-in to clients, it’s time to give Alias Manager a go and see how well it actually works.

In our test Exchange environment, we’ll have a look at one of our example mailbox. As we see the mailbox has a number of Email Addresses defined. In this example [email protected] is the primary SMTP address. We want to be able to send as the [email protected] alternative address on occasion, so we’ll hope to see this address shown within the Outlook add-in:

Figure 6: Email Address Properties

Upon launching Outlook with the add-in installed and creating a new email message we immediately see Alias Manager at work. The SMTP email addresses are all shown in a drop-down list within the new message:

Figure 7: Creating a new message and selecting an email address

There’s nothing fancy or complicated about the way the product works – it’s immediately clear to users that they can change the Send As address to one of their aliases.

After sending the message and verifying it was received as our chosen address, the next check we performed was to see if we could identify which address we’d sent the message as from within Outlook. Giving users the ability to send as a particular address is great – but if we then wanted to send a follow up message to the recipient or double check it was sent from the right address in the future this would be a critical feature. As we can see, the Outlook add-in clearly shows which address the message was send from:

Figure 8: Verification of the address the message was sent as

Another useful feature is the ability for the software to automatically select the right address when replying to messages. Even without needing to send as certain addresses there are many times we as users want to see which address a message was sent to (for example when trying to unsubscribe from mailing lists) so this is a welcome feature in itself; and if you are giving users the ability to send new messages using different email addresses, then it’s going to be pretty essential that the email conversation continues from the same address:

RE: Test to an alternative email address I’ Follow Up” . High Importance Zoom 4. Low Importance Tags r Zoom A ‘V This is a test sent to [email protected] El — Exclaimer Email Alias Manager Send As [email protected] Steve Goodman Test to an a tern at’e era accress” src=”file:///C:\Users\marie\AppData\Local\Temp\msohtmlclip1\01\clip_image018.jpg” width=”567″ height=”471″ v:shapes=”Picture_x0020_4″>

Figure 9: Alias Manager automatically selecting the correct send-as address on a reply

So we’re pretty happy with the functionality of the Outlook add-in. If you picked up on the add-in exposing the Hybrid email address, yes, we will mention that later.

The functionality Exclaimer Email Alias Manager adds within Outlook is so clearly exposed that this feels like it should have always been a part of Outlook and users won’t need training and minimal to no documentation on it’s use.

There are a few inconsistencies though, but to be honest these may be due to limitations in Outlook, rather than the product itself. For example, if users have enabled the From field in Outlook (which isn’t shown by default) there’s two different drop-down lists they can use:

Figure 10: From and Send-As pickers give mutiple options to end-users

Secondly if Shared Mailboxes are in use within your organization then one would expect the Alias Manager to show the email addresses for the Shared Mailbox when sending a message from that mailbox:

Figure 11: Sending from a Shared Mailbox does not show the corresponding Mailbox Email Addresses

However, even with these minor flaws we see a great improvement in functionality.

Outside of Outlook it’s also possible to use Alias Manager’s functionality. We’ll test this out using Outlook Web App, however it’s equally possible that users will want to change their address in ActiveSync or other clients.

The method to change the send-as address outside of Outlook is via appending a sendas: parameter into the subject line. In practice this is fairly straightforward, as shown below:

Figure 12: Using the sendas parameter to change the address via OWA

Upon sending the message, Alias Manager’s transport agent will strip the sendas parameter and address from the message and change the address to the one specified by the user. It’s possibly for this reason that Exclaimer recommend installation of the agent on all servers running the Hub Transport role, ensuring that messages sent this way internally don’t arrive with the sendas text showing.

One flaw we did see with this feature is that if the email address is misspelled, or the user attempts to change the address to one they don’t have permission to send as, the sendas text and email address are preserved. Preventing the message from being sent, along with an NDR message giving helpful tips would be more appropriate.

Overall functionality

This is a product that’s aiming to do one thing, and do it well and it certainly succeeds in doing so. It does exactly what Exchange admins, and users, have been requesting for a long time.

The simplicity of the product also means it’s actually more flexible than we first imagined. As explained earlier, our test environment was a Hybrid Exchange infrastructure with some mailboxes in Office 365. Because the product is based on a Transport Agent this means that so long as we use Centralised Transport (where external mail traverses on-premises Exchange) we can use Alias Manager with Office 365 Mailboxes. A quick test with an Office 365 mailbox showed this worked without issue, and also indicated that Outlook add-in queried Active Directory rather than Exchange for the list of email addresses.

One area of functionality we do think the product would benefit from is the ability to exclude certain domains from the Outlook add-in Send-As picker, such as the tenant.mail.onmicrosoft.com routing domain, or perhaps specific domains that a company still wants to receive mail as but no longer allow users to send as after a merger. How they would implement this without introducing complexity is something we’ll leave Exclaimer to figure out.

The fact that we’re finding features we’d like to see added to the product is certainly a plus. No issues arose in the installation and configuration and the functionality and features the Alias Manager promised were all delivered.

Alternatives

There’s little alternative to this product on the market. Exchange Administrators have instead been forced to use workarounds and train users to work in a way that’s not natural. For example, it’s not unusual to see users with a “personal” Shared Mailbox or Distribution Group simply to allow them to send as a different address.

Exchange Admins have been using these workaround for years, so there might be a good argument to say that we don’t need this product and the alternatives do the job. That’s partly true from an admin’s perspective, if you ignore the administrative overhead. From an end-user’s point of view though this product makes much more sense.

Pricing and Support

The product is licenced either per-user or via a site-licence. If you have multiple Exchange Servers then you’ll probably be looking at the site licence as above 5 users the site licence makes most sense and is easier to administer. During our evaluation of the product we used Exclaimer’s support both to ask questions and to get advice on best practice for implementation. Even with the review conducted over the holiday season we received fast and helpful response from support with no question unanswered.

Final Thoughts

Exclaimer Alias Manager for Exchange met our expectations entirely and left us eager for more. It’s filled a real gap within Outlook and Exchange that won’t be filled anytime soon and immediately feels part of the product. There’s a couple of areas where the product could be improved, such as documenting the service restart during install and excluding domains – however that this product just works and does what it claims to very well makes these points fairly insignificant.

MSExchange.org Rating 4.9/5

Learn more about Exclaimer Email Alias Manager or download the Free 30 day Trial Version here