FAQ’s - Exchange Server Transport Agent
1. On our end, what does the DynaSend software require?
Your company’s email needs to be processed by Microsoft Exchange Server (version 2010, 2013 or 2016) and you need to have the ability to install, or have someone install, a small software program on the Exchange Server you use. If unsure, just ask someone in your IT Department - they’ll know.
2. Is this a service that constantly runs on the Exchange Server?
The core component of the signature agent runs WITHIN the Exchange Transport Service process - it is NOT a separate service. The type of architecture it uses is called a “transport agent” in the Microsoft documentation and this is the recommended way of creating such an application.
There is also a completely separate service (non-critical) which is used to download updated signatures to the server.
3. What kind of resources does DynaSend utilize?
The extra resources used by both components (transport agent and downloader) are limited to the processing overhead of the text content of the messages, and the bandwidth required to download the signatures. As long as the Exchange environment already meets Microsoft’s guidelines, there shouldn’t be an issue with resources.
4. What happens if the app crashes… What happens to existing mail in our environment?
Because a failing transport agent would be capable of causing mail flow problems, the whole agent runs with error handling set up such that if becomes so badly stuck that it can’t continue, it allows Exchange to continue processing messages as if it were not installed.
Please note however that as a best practice, we still recommend installing and testing DynaSend during off hours as it will require restarting the MsExchangeTransport service on the Exchange Server, and a broken installation (although unlikely) could still lead to mail flow being impacted.
5. How has the DynaSend software been tested?
The Exchange Transport Agent has been tested using dedicated Exchange test environments for versions 2010, 2013 and 2016.
6. Does the installation require a reboot of the Exchange Server?
It is possible that you may need to reboot the Exchange Server if the Microsoft .NET Framework is not installed or if other Windows Updates are required. If the .NET Framework 4.5 is already installed a reboot will probably not be required.
7. Can you further explain the process in which your software installs/attaches itself to the default Exchange transport service?
It installs an Exchange Transport Agent on the Exchange server, which essentially means the Exchange EdgeTransport.exe process calls the signature agent routines. All messages processed by Exchange (other than system messages) run through the agent, which is necessary for it to perform its functions.
8. Explain the “failsafe” process in which your software could potentially crash and still allow the transport service to operate and deliver email.
This is obviously an important design consideration in an agent. All of the functionality of the agent is run with error handling that allows messages to continue to be processed if an error occurs with the agent. It is important to ensure that the agent has installed and registered correctly (to avoid DLL mismatch or version errors which could prevent the agent from loading completely and block the Edge Transport service from running). Once the correct installation has been verified, assuming the DLLs are not tampered with, it is designed to allow mail to continue to flow in every possible scenario. However, due to the way Transport Agents work, and the fact that we obviously don’t have control over the design of Exchange, we can’t guarantee totally uninterrupted operation. We can state that Microsoft’s development guidelines have been followed to avoid destabilizing the Exchange Transport service.
Please do keep in mind that normal servicing with Windows Updates etc. will cause the Exchange Transport service to be stopped, and to ensure uninterrupted mail flow, the redundancy of your Exchange setup and MX backup needs to be provided.
9. Is there built-in alerting/notifications when your agent/service crashes on the transport service?
It writes errors to the Windows event log if the “crash” occurs on one message while it is otherwise still functioning. If the crash was due to the DLLs not being able to be loaded (and therefore our error handling routine would not even run), normal monitoring of the Exchange Transport service would apply.
10. What is your Exchange version compatibility matrix? What is your upgrade process as it relates to Exchange upgrades?
Exchange 2010 Service Pack 3 (currently tested up to rollup 11 which is the latest at the time of writing) Exchange 2013 Service Pack 1 (currently tested up to Update 10 which is the latest at the time of writing)
We have not tested Exchange 2010 or 2013 without the respective service packs - please consider this to be unsupported. The agent has been designed to support cumulative updates and rollups immediately, without modification. If for some unforeseen reason such an update caused an issue we would issue an urgent fix. In our experience with Exchange add-ins, this is not usually necessary with rollups or updates.
The service pack compatibility needs to be checked prior to doing such an upgrade. As we do incremental improvements to the software, we always re-test with the latest service pack at the time of doing the development, and we would support service packs as soon as possible after their release. Usually no changes are required to support a newer service pack.
11. What is your product development timeline as it relates to newer versions of Exchange?
A major new version of Exchange would require a new version to be released. In the case of Exchange 2016 (our most recent update) it was a reasonably straightforward process because it was not a major architectural change from 2013.
The answer to this question would depend on the version of Exchange, so it is hard to provide an exact answer into the future. However, the last time Microsoft changed Exchange in such a way that significant redevelopment would be required (and consequently a long timeframe) was the upgrade from 2003 to 2007.
12. What is the processing overhead for your software on the Exchange hub transport servers? Additional CPU/memory requirements? We already do a lot of processing on our hub transport servers (e.g. enterprise journaling), so I would like to understand additional resource requirements and/or any limitations/recommendations/guidelines for the number of users being processed per hub transport server.
The agent is designed to work within an existing Exchange environment that is within the Microsoft’s recommended guidelines. Due to the complexity of Exchange capacity planning it is very difficult to provide numbers on how the overhead would affect your setup. As a general rule, if the servers are close to capacity (80% plus) some careful consideration may be required. Obviously the performance is an important design consideration, but signature injection by nature involves manipulating the contents of outgoing messages. The main load additional load would be CPU load, if that helps, it should not affect disk usage significantly and the additional memory requirements would be modest.
13. What are your support options (business hours/after-hours/24-7) in the event there is a disruption in service?
We do not offer 24-7, after hours support (support is from Australia so the time zones are considerably different than in the USA). In case of an emergency, the workaround is to temporarily disable the signature agent service, which is a very simple process. This needs to be kept in perspective with other potential support issues in Exchange, in our experience it’s not common to have a 24x7 contract with Microsoft to support Exchange if they had a support issue that went outside the capability of their own Exchange admins.
14. Can your software detect messages sent via mobile devices (i.e. iOS, Android, Windows) and render the signatures/logos/embedded images (html/plain-text) properly?
This is dependent on the mobile devices not changing everything to plain text in the first place. If the mobile device allows the message to stay as HTML it will work as intended.
15. How do I set up Office 365 permissions?
- Download Microsoft Online Services Sign-in Assistant to sign into Office 365: https://www.microsoft.com/en-us/download/confirmation.aspx?id=41950
- Download Azure Active Directory (AD) Module so that you can perform administrative tasks in Office 365: http://go.microsoft.com/fwlink/p/?linkid=236297
- Run PowerShell as an Administrator (in the “Discovery Management” role) and run the following PowerShell commands:
Import-Module MSOnline Connect-MsolService -Credential $credential (Enter your admin credentials to Office 365) Set-ExecutionPolicy RemoteSigned $session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $credential -Authentication Basic -AllowRedirection Import-PSSession $session
To grant full access to all mailboxes in your Office 365 environment:
Get-Mailbox | Add-MailboxPermission -AccessRights FullAccess -InheritanceType All -User **admin user email address** Then to verify the permissions, run the following. Every mailbox should be listed with FullAccess next to the rights: Get-Mailbox | Get-MailboxPermission -User **admin user email address** | fl Identity,User,AccessRights
Note: After changing the permissions for Office 365 mailboxes, it can take an hour or longer for the permission changes to take effect. The signature deployment tool may still report access denied errors until Office 365 has propagated the permissions completely during this window. The delay can be avoided by setting the permissions before attempting to use the admin tool, thereby avoiding the initial “access denied” error which will get cached by Office 365.