Welcome to our Knowledge Base. Search or browse through the topics below to find answers to your questions.
Categories: Exchange Server Toolbox | Show all categories
You have two options to remove Exchange Server Toolbox from the email processing chain. Either uninstall the Exchange Server Toolbox or use these two commands in the Exchange Management Shell:
After that restart the MSExchangeTransport service. To enable processing again, use the same commands and swap the beginning with "Enable-TransportAgent [...] ". With "Get-TransportAgent [...]" you can check the current status.
Here you can find more information to check if your Exchange Server is responsible for problems.
None of our applications depend on Java Spring or any other Java library and are thus not affected by this vulnerability.
All of our products are being developed in Delphi or C#. Although we use Spring4D(elphi) with some of the components, they are safe to use, because the reported vulnerability applies to Java Spring framework only.
This applies to all versions and editions of our applications (TreeSize, SpaceObServer, SpaceObServer WebAccess, HeavyLoad, SmartPOP2Exchange, Exchange Server Toolbox, SpamAssassin in a Box, SpamAssassin for Windows, SmartCallMonitor, SEPA-Transfer, ServerSentinel, and ShellBrowser). It is recommended to always use the latest available versions though to benefit from the latest patches, improvements, and features.
In this case you will need two Exchange Server Toolbox installations, one for the DMZ mail server and one for the regular mail server.
Configuration for the DMZ Exchange Server Toolbox:
Configuration for the regular Exchange Server Toolbox:
The client installation will now recieve AD information which it can use for processing. The master installation will always be the one responsible for maintaining the archive.
Yes, SmartPOP2Exchange and Exchange Server Toolbox can be installed together on the same server. When doing so, you should take this into account:
Problems with direction detection
In older versions there were problems with direction detection when SmartPOP2Exchange and the Exchange Server Toolbox were installed on the same server. To fix this, a rule is now created when SmartPOP2Exchange is installed that automatically assigns a new header field (X-JamMailSource) with a value (MailGateway) to all emails. In the Exchange Server Toolbox, this header is queried under Settings | Advanced | Mail Direction, and emails with this header field and header field value are always considered Incoming.
You can adjust these values if you want, but please make sure that they are the same in both programs.
Always keep versions up to date
Please note that you must always have the latest versions of both programs installed. Otherwise it is possible that SpamAssassin or ClamAV will be updated to a version that the other program cannot use.
Spam and virus scanning in one program only
To avoid wasting time and resources unnecessarily, you should run the spam and virus scans in only one of the programs. Since SmartPOP2Exchange and Exchange Server Toolbox share an installation of ClamAV and SpamAssassin, the scanning results are identical.
You should consider the following things when deciding which of the programs to use for scans:
Advantages of scans in the Exchange Server Toolbox
The Exchange Server Toolbox offers more configuration options and more rule actions for both scans. Therefore, the scans and especially the reaction to different results can be customized in much more detail.
Advantages of scans in SmartPOP2Exchange
Since in this configuration the Exchange Server Toolbox receives the emails directly from SmartPOP2Exchange, rejecting emails in the Exchange Server Toolbox should be avoided (otherwise this will lead to errors in SmartPOP2Exchange). So it is only possible to reject emails (based on scan results) with SmartPOP2Exchange. However, you should keep in mind that the emails have already been delivered to an account, so SmartPOP2Exchange not picking them up can be legally problematic.
This error is caused by new Windows security settings. To fix it, open the Exploit protection Settings. Here, switch to the program settings and specify all EXE files listed in the error message under Add program. You must overwrite the ALSR settings in each case.
To create a manual backup of the settings, back up the following directories:
To restore the settings, you can copy the directories back to the appropriate locations one by one (to do this, you need to stop the ExchangeServerToolboxService and SpamdServiceControl services).
Alternatively, you can create a ZIP file and select it in the Exchange Server Toolbox under Settings | Advanced | Import settings. The ZIP file must contain the entire folder structure mentioned above. The two folders ProgramData and WINDOWS must be in the top level:
Check the event log of the Exchange Server Toolbox or the Windows Event Viewer under Windows Logs | Application for the following message:
"The request was aborted: Could not create SSL/TLS secure channel"
If this is present, you can fix the problem this way:
You can now copy the contents of the text box under Options | SSl Encryption Collections into a text document. Append the following keys at the end:
Follow the editing instructions in the right part of the window under "Help".
Then copy the text back into the text box and press "Apply" to save the settings. For the changes to be applied, you must restart the server.
All of our products are being developed in Delphi or C#. Although we use Log4Net with some of the components, they are safe to use, because the reported vulnerability applies to Log4J only.
None of our applications depend on Log4J or any other Java library and are thus not affected by this vulnerability.
This applies to all versions and editions of our applications (TreeSize, SpaceObServer, SpaceObServer WebAccess, HeavyLoad, SmartPOP2Exchange, Exchange Server Toolbox, SpamAssassin in a Box, SpamAssassin for Windows, SmartCallMonitor, SEPA-Transfer, ServerSentinel, and ShellBrowser). It is recommended to always use the latest available versions though to benefit from the latest patches, improvements, and features.
This error is caused by missing access rights to a key file. This is located in the folder C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys. You can either change the permissions on the entire folder or check which file needs the permissions.
To find out which file this is, you can use window's own "Procmon". This shows all file accesses. Open the program and set the filter "Path contains C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys". Then check which file the "Jam.EST.Archive.Writer.Service.exe" process tries to accessand allow access to this file.