Important: Since NoSpamProxy requires Framework 4.6.2, the workaround described below no longer works because Exchange 2010 is not compatible with Framework 4.6.2 (https://technet.microsoft.com/library/ff728623(v=exchg.150).aspx).

If NoSpamProxy version 7.7 or later and Exchange 2010 are installed on the same server, the Exchange Management Console no longer works properly. The reason for this is the .NET Framework 4.0. The Exchange Management Console requires the Framework version 2.0 as the default handler, while the NoSpamProxy Management Console only works with version 4.0. To use the correct .NET Framework version by default, the NoSPamProxy setup 7.7 creates an environment variable called “COMPLUS_ApplicationMigrationRuntimeActivationConfigPath”.

This variable refers to a path where a config file with the appropriate settings is stored. When any MMC is called, the corresponding variable, and thus the configuration file, is used. This causes the known problems when opening the Exchange MMC. To be able to use the Exchange MMC again, there is only the following workaround:

The environment variable is permanently deleted and the NoSpamProxy MMC must be called via a batch file in which the corresponding environment variable is defined beforehand. The advantage is that in this case the environment variable is only used for programs that are called from the context of the batch file.

To work around the problem, do the following:

First, open Windows Explorer.

Right-click Computer and select Properties.

In this window, click Advanced System Settings. The following window opens:

Click “Environment Variables” here.

Managment Konsole Umgebungsvariablen setzen

In the “Environment Variables” window, select “COMPLUS_ApplicationMigrationRuntimeActivationConfigPath” in the “System Variables” section and then click “Edit”. Copy the path in the “Value” field to the clipboard. Then delete the complete entry. Click on OK, Apply and again on OK.

Now open Notepad. Paste the currently copied path from the clipboard into Notepad. In addition, add the following lines:

set COMPLUS_ApplicationMigrationRuntimeActivationConfigPath=
mmc.exe "C:\Program Files\Net at Work Mail Gateway\NoSpamProxy Management Console\Net at Work Mail Gateway Configuration Console.msc"

Copy the path from the clipboard behind the first line. The Notepad file should then be structured as follows:

set COMPLUS_ApplicationMigrationRuntimeActivationConfigPath=C:\ProgramData\ComPlus Activation Configurations\
mmc.exe "C:\Program Files\Net at Work Mail Gateway\NoSpamProxy Management Console\Net at Work Mail Gateway Configuration Console.msc"

Please note that the file names of the console may differ depending on the version used. Make sure to find the .msc file in the target directory.

Also, please note that the display of the batch file in this article may be distorted by automatic line breaks.

Finally, adjust the path to the Net at Work Mail Gateway Configuration Console.msc if necessary and save the Notepad content as NoSpamProxy-MMC.bat. If you call the BATCH file, the NoSpamProxy MMC should open successfully. Starting with Windows 2008 with UAC enabled, however, you must always run the batch file as administrator. The Exchange MMC should now also open without errors.

Error:

If smartcard readers are used that are controlled via a network USB port, either the smartcard or the token on the smartcard itself is not displayed.

Status:

This error occurs whenever the connection is established in an RDP session.

Solution:

The smartcard connection via a network-based USB connection should be established via the Hyper-V Manager or the VMWare Manager via a direct connection to the VM.

Error:

The NoSpamProxy Management Console can be started, but crashes if a submenu is opened. This problem does not occur with another or new users.

Status:

The NoSpamProxy Management Console creates temporary files in the temporary folder of the user directory. However, this folder contains more than 65,535 files, which leads to problems in the NTFS file system.

Solution:

The affected user executes the following command via Start -> Run:

rmdir /s /q %temp%

When the operation is complete, the console will function properly again.

Error:

Without a noticeable reason, the services of NoSpamProxy no longer start. Re-installation does not work. The following error is displayed in the event display:

Log name: System
Source: Microsoft-Windows HttpEvent
Date: 14.03.2012 14:42:55
Event ID: 15005
Task Category: None
Level: Error
Keywords: Classic
User: Not applicable

Description:

The underlying transport for [::]:6060 cannot be bound. The list may contain a reference to an interface that may not be present on this computer for IP listening purposes only. The data field contains the error number.

Status:

This problem occurs in conjunction with IPv6. The “Net TCP Port Sharing” service will then be disconnected. The exact cause is still unknown.

Solution 1:

Enter the following command on the command line:

netsh http add iplisten ipaddress=0.0.0.0

Then the services of the Net at Work Mail Gateway will restart.

Solution 2:

Enter the following command on the command line:

netstat -ano >netstat.txt

Check in the netstat.txt whether a process may occupy port 6060. If this is the case, the corresponding PID (Process ID) is displayed. You can then use task manager to find out to which process the PID belongs. Then it is necessary to clarify whether the process can be adjusted accordingly or not.

Error:

When establishing the connection between the intranet role and the gateway role the error message “The security protocol cannot verify the incoming message” is displayed. The dialog terminates in an error message and the connection object is not created afterwards.

Status:

This problem occurs if the two roles were installed on different servers and the times differ by more than 5 minutes.

Solution:

Adjust the times on both systems.

Error:

When receiving and decrypting a 5MB email, the email is rejected and the error “ASN1 not enough memory” is displayed. The same error is also displayed in message tracking.

Status:

This problem occurs because a buffer size is not properly increased by the .NET framework. This problem is known to Microsoft and can be fixed with the hotfix below.

Solution:

To resolve this problem, install the following Microsoft hotfix: http://support.microsoft.com/kb/2480994/de

http://support.microsoft.com/kb/2480994/de

Error:
Emails are rejected by NoSpamProxy even though the Level of Trust Filter has marked them as trusted. In message tracking and in NDR the following reason is given:
“A part of the email could not be decoded. System.formatException: Invalid character in a Base-64 string.”

The following error message is displayed in message tracking:
“The Base64 encoded content was invalid.”

Status:
The problem with the email in question is the NoSpamProxy security check. NoSpamProxy detects a conflict with the RFC’s in the body. It does not have a Base64 encoding and is therefore rejected. This security check can only be disabled in the configuration file of NoSpamProxy.

Solution 1:
Version 7.x and 8.x:

The configuration file to be changed is called “antispamrole.config” and is located in the program directory of NoSpamProxy under “..\nospamproxy\AntiSpam Role\config”. Please note that you can only save the file when the NoSpamProxy service is finished. Otherwise the change will be discarded.

Please search for the following line in the file first:

</netatwork.nospamproxy.proxyconfiguration>

Insert the following key directly above this line:
<dispatchInvalidMails isEnabled="true" />

The result should look as follows:
<dispatchInvalidMails isEnabled="true" />
</netatwork.nospamproxy.proxyconfiguration>

Save the file and restart the NoSpamProxy Service. Now the emails should be received.

From version 9.x:

From Net at Work Mail Gateway 9.x or NoSpamProxy 10.x:
The configuration file to be changed is called “Gateway Role.config” and is located under “C:\ProgramData\Net at Work Mail Gateway\Configuration”. Please note that you can only save the file when the gateway role is finished. Otherwise the change will be discarded. The change must be made on all gateway roles.

Please search for the following line in the file first:

</netatwork.nospamproxy.proxyconfiguration>

Insert the following key directly above this line:
<dispatchInvalidMails isEnabled="true" />

The result should look as follows:
<dispatchInvalidMails isEnabled="true" />
</netatwork.nospamproxy.proxyconfiguration>

Save the file and restart the Gateway Role. Now the emails should be received.

Solution 2:

Version 7.x and 8.x:

Alternatively or additionally there is the possibility of a repair attempt by the Net at Work Mail Gateway. It will then try to ignore the superfluous characters or to fill in the missing characters to get a valid encoding. This does not always work, but can be helpful.

The configuration file to be changed is called “antispamrole.config” and is located in the program directory of NoSpamProxy under “..\nospamproxy\AntiSpam Role\config”. Please note that you can only save the file when the NoSpamProxy service is finished. Otherwise the change will be discarded.

Please search for the following line in the file first:

</netatwork.nospamproxy.proxyconfiguration>

Insert the following key directly above this line:
<encodingOptions invalidBase64LengthHandling="IgnoreExtraCharacters" />

The result should look as follows:
<encodingOptions invalidBase64LengthHandling="IgnoreExtraCharacters" />
</netatwork.nospamproxy.proxyconfiguration>

Save the file and restart the NoSpamProxy Service. Now the emails should be received.

From version 9.x.

The configuration file to be changed is called “Gateway Role.config” and is located under “C:\ProgramData\Net at Work Mail Gateway\Configuration”. Please note that you cannot save the file until the gateway role is closed. Otherwise the change will be discarded. The change must be made on all gateway roles.

Please search for the following line in the file first:

</netatwork.nospamproxy.proxyconfiguration>

Insert the following key directly above this line:
<encodingOptions invalidBase64LengthHandling="IgnoreExtraCharacters" />

The result should look as follows:
<encodingOptions invalidBase64LengthHandling="IgnoreExtraCharacters" />
</netatwork.nospamproxy.proxyconfiguration>

Save the file and restart the Gateway Role. Now the emails should be received.

Both solutions do not work together until version 9.2. If you choose solution 2, there is no fallback to solution 1 if the Base64 decoder cannot repair the email. Starting with NoSpamProxy 10 both can be used together.