Categories
exchange IAmMEC

Configuring Trend OfficeScan for Exchange Server

There are lots of articles on configuring Trend OfficeScan on an Exchange Server. They should all be based on the definitive article at http://technet.microsoft.com/en-us/library/bb332342(v=exchg.141).aspx which covers the exclusions needed, but one thing I found typically missing from the configuration.

If you use mount points to map the Exchange database disks to the server, then you need to configure OfficeScan to avoid scanning the \Device\ path. This covers all mount points and is needed in addition to the above exclusions such as C:\Program Files\Microsoft\Exchange Server etc. The path \Device\ is needed and not the longer \Device\HardDiskVolume1\ as it is not always possible to know what number will be used.

At my current client there are 10 mount points into C:\ExchangeDatabases, and on some servers this is seen by Trend OfficeScan as  \Device\HardDiskVolume1\ through \Device\HardDiskVolume10\ but on other servers this is seen as every even number between \Device\HardDiskVolume30\ and \Device\HardDiskVolume48\. So rather than exclude every individual path from \Device\HardDiskVolume1\ to \Device\HardDiskVolume48\ we tested \Device\ and found that to do the same. Adding \Device\ does not include volumes that are mapped to drive letters, so if I had a virus in C:\Users\administrator\Desktop then it would still get picked up.

Finally, and here is a tip I recommend – go to www.eicar.com and get the string that you can use to create a test virus. Create this “virus” and place it in folders that should be excluded from scanning. The test virus should not be deleted/quarantined etc. Now you know that your Exchange Server databases logs etc are not being scanned as well and its a great way to prove that the scan configuration that you the Exchange administrator requested from the security team is actually correct and working.   

Categories
2013 aadrm dirsync encryption IAmMEC journal journaling licence mcm mcsm MVP Office 365 rms transport agent

Managing Azure Active Directory Rights Management

This article is the third in a series of posts looking at Microsoft’s new Rights Management product set. In the previous post we looked at turning on the feature in Office 365 and in this post we will look at how to manage the service in the cloud.

In this series of articles we will look at the following:

The items above will get lit up as the articles are released – so check back or leave a comment to the first post in the series and I will let you know when new content is added.

Once you have signed up for the Azure Active Directory Rights Management (AADRM) Service there are a few things that you need to manage. These are:

  • The service itself
  • Users who are allowed to create RMS protected content
  • Enable and configure Super User rights if required.

Managing AADRM

There is not a lot to do in the Office 365 admin web pages with regard to the management of the service apart from enabling it, which we covered in the previous post and disabling it. Disabling the service involves the same steps as enabling it – you just click the big deactivate button!

AADRM can be further managed with PowerShell though. There are lots of blog posts on connecting to Office 365 using PowerShell, and some of those include the cmdlets to connect to Exchange Online etc. as well. The code below adds to this, and loads the AADRM module and connects to AADRM service in the cloud.

$cred = Get-Credential

write-host "Username: " $cred.username

Connect-MsolService -Credential $cred

Write-Host "...connected to Office 365 Windows Azure Active Directory"

$s = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell -Credential $cred -Authentication Basic -AllowRedirection

$importresults = Import-PSSession $s -Verbose

Write-Host "...connected to Exchange Online"

Import-Module AADRM

Connect-AadrmService -Verbose -Credential $cred

If you save the above PowerShell code as a text file with a .ps1 extension then you can run the script and easily connect to Office 365 with the credentials you enter. Then connect to Exchange Online with the same set of credentials and finally to AADRM with, of course, the same credentials. This allows you to manages users, email and security from a single session.

To get the AADRM PowerShell module on your computer (so that Import-Module AADRM works) you need to download the Rights Management PowerShell administration module from http://go.microsoft.com/fwlink/?LinkId=257721 and then install it.

To install you need to have already installed the Microsoft Online Services Sign-In Assistant 7.0 and PowerShell 2.0. The PowerShell config file needs some settings adding to it, though I found on my Windows 8 PC that these had already been done. See the instructions at http://technet.microsoft.com/en-us/library/jj585012.aspx for this change to the config file.

  1. Run a PowerShell session and load the module with
    1. Import-Module AADRM
    2. Connect-AadrmService -Verbose
  2. Login when prompted with a user with Global Admin rights in Office 365.
  3. Or, use the script above to do Office 365, Exchange Online and AADRM in a single console.
  4. Run Get-Aadrm to check that the service is enabled

Enabling Super User Rights

Super Users in RMS are accounts that have the ability to decrypt any content protected with that RMS system. You do not need Super User rights to use RMS, nor do you need anyone who has Super User rights to use the product. But there are times when it might be required. One example would be during a discovery or compliance process. At this time it might be required that someone is able to open any RMS protected document to look for hits on the compliance issue in question. Super User gives that right, but would be needed just for the duration of the task that requires these rights. Rights to be Super User would be granted as needed and very importantly removed as needed.

Another example for the use of Super User is when a process needs to see content in its unprotected form. The common use case for this is Exchange Server and its transport decryption process. In Exchange Server you have agents that run against each message looking for something and then acting if that something is found. For example you would not want an virus to bypass the built in AV features of Exchange Server 2013 by protecting it with RMS! Or if you had a disclaimer transport rule or agent, you would not want the disclaimer or DLP feature to not see the content and act upon it because the content was encrypted. The same goes for journaling and the ability to journal a clear text copy of the message as well as the encrypted one if you wish.

To do all this in Exchange Server, the RMS Super User feature needs to be enabled and we will come back in a later post on the specifics of doing that for Exchange, but first we need to enable it in AARMS and set the users who will be Super Users and then, when we are finished with whatever required Super User, we need to turn it off again.

The Rights Management super users group is a special group that has full control over all rights-protected content managed by the Rights Management service. Its members are granted full owner rights in all use licenses that are issued by the subscriber organization for which the super users group is configured. This means that members of this group can decrypt any rights-protected content file and remove rights-protection from it for content previously protected within that organization.

By default, the super users feature is not enabled and no groups or users are assigned membership to it. To turn on the feature run Enable-AadrmSuperUserFeature from the AADRM PowerShell console. The opposite cmdlets exists to turn the feature off again – Disable-AadrmSuperUserFeature!

Once it is enabled you can set Office 365 users as Super Users. To do this run Add-AadrmSuperUser –EmailAddress user@domain.com where the user is either a cloud only Office 365 account or one that you have pushed to Office 365 using DirSync from your on-premises Active Directory. You can add more than one user, each user is added as a separate running of the cmdlets.

To see your list of Super Users, run Get-AadrmSuperUser. To remove users either take them out one by one (Remove-AadrmSuperUser –EmailAddress user@tenant.onmicrosoft.com) or just turn off the Super User feature with Disable-AadrmSuperUserFeature.

Adding AADRM Licences to Users

Once you have AADRM activated you can give your users the rights to create protected content. This is done in the licencing page of the Office 365 web admin portal or via PowerShell. The steps for adding user licences in the shell are discussed at http://c7solutions.com/2011/07/assign-specific-licences-in-office-365-html. That article was written some time ago, so the following are the changes for AADRM:

  • The SkuPartNumber for AADRM is RIGHTSMANAGEMENT_ADHOC
  • The Service Plan for the AADRM SKU is RMS_S_ADHOC
Categories
2013 exchange IAmMEC search

Rebuilding Search Catalogs on Exchange Server 2013

In Exchange 2010 there was a PowerShell script for rebuilding the search catalog. This is depreciated in Exchange 2013. TechNet contains instructions on copying the catalog from a working server in the DAG – but what about if the database is not a member of a DAG or all the catalog’s in the DAG are broken?

This blog post will attempt to answer this:

Ensure all Search Services are Running

If you cannot complete a search in OWA or you are using Outlook in Online mode (or searching in Outlook 2013 beyond the default one year of cached content) then you return to the server for the search to take place. Therefore on the server that is active for your mailbox database the following services need to be running:

  • RTM: Microsoft Exchange Search Service
  • CU1 and later: Microsoft Exchange Search Service and Microsoft Exchange Search Host Controller

Ensure that these services are running before attempting to complete a search.

Once they are running, check the health of the search catalog with the following cmdlet in Exchange Management Shell: Get-MailboxDatabaseCopyStatus

The last column will display the state of the index. Anything other than Healthy needs to be checked. Crawling as a response means the index is currently being created and updated.

Checking for Corrupt Search Catalogs

Run the Test-ExchangeSearch cmdlet to get back a set of results on the health of your search catalog. This will take a short while, as Exchange will write known content into the Health Mailboxes on each database and then query search for the words that it expects to find. Errors here such as Time out for test thread and Catalog State: FailedAndSuspended should be fixed.

If the mailbox database is part of a DAG and other working copies exist then you can reseed the catalog using Update-MailboxDatabaseCopy faileddb/server –CatalogOnly

If all the copies are failed then stop the services listed in the previous section and delete or rename the catalog folder and restart the services listed above. The search catalog will be rebuilt and will take some time.

The location of the search catalog is always a subfolder of the mailbox database file, and this folder can be found by running: Get-MailboxDatabase -Server servername | fl name,edbfilepath,guid

This will return the name, the path to the mailbox database and the database guid, and then all you need to do is navigate to the folder that contains the database and rename the folder with the GUID as the folder name. Any new name will do. If a folder does not exist of the GUID of the mailbox database then a new one will be created.

Start the services that you stopped above and shortly a new catalog folder will be created. Depending upon the size of the database, rebuilding the catalog could take some time. Run Get-MailboxDatabaseCopyStatus to see when the catalog has finished crawling. Crawling will take additional IO from your disks, and so it is recommended not to run these steps during the day when IO is required, unless fixing your search index is more important!

Categories
EOP exchange Exchange Online Protection FOPE IAmMEC

What is X-Forefront-Antispam-Report-Untrusted?

When a message arrives in Exchange Online Protection (EOP) with an existing X-Forefront-Antispam-Report header, it is renamed to X-Forefront-Antispam-Report-Untrusted.

If the message is then detected as spam and stored in the optional quarantine, upon release it will go back into EOP. Upon entering EOP the previously set X-Forefront-Antispam-Report header is renamed to X-Forefront-Antispam-Report-Untrusted.

Categories
2013 Edge exchange firewall IAmMEC iis networking powershell transport

Secret NSA Listening Ports in Exchange Server 2013? Of Course Not…

But what do those extra ports in Exchange Server 2013 that are listening actually do.

If you bring up a command prompt on an Exchange Server 2013 machine and run netstat –ano | find “:25”. You will get back a list of IP addresses that are listening on any port starting 25. The last number on the line is the process ID for that listening port. So for Mailbox only role servers you are interested in the row that shows 0.0.0.0:25 and for a multirole (CAS and Mailbox) server, the row that shows 0.0.0.0:2525 as shown:

image

Above you can see that process 21476 is listening on 2525 and as this is a multirole server this process ID will be EdgeTransport.exe – you can verify this in Task Manager if you want.

Repeat the netstat cmd, this time for the process ID you have selected: netstat –ano | find “xxxxx” where xxxxx is the process ID for EdgeTransport.exe, as shown:

image

You will now see that EdgeTransport.exe is listening in on a range of ports for both IPv4 and the same ports for IPv6. These ports are 25 or 2525, which is used by 2007 or 2010 Edge role servers, or by other 2007/2010 Hub Transport role servers or by other 2013 Mailbox role servers or by 2013 CAS role servers to send emails to this server via SMTP. Port 465 is the port that 2013 CAS servers proxy authenticated SMTP connections to that they receive on port 587 from mail clients. But what about port 29952 in my example (and on your servers a different port) which changes each time the service is restarted?

If you do netstat again just for this port you will see something like the following:

image

This shows that nothing is connected currently to these ports, and so they seem to be doing nothing. But if on a different Exchange 2013 server you do some viewing of the transport queues then these ports will start to show some activity.

On a different server in my environment I ran Get-Queue –Server remoteservername. If I do this on the local server, then nothing special happens as Exchange does not need to connect to these ports, but if it is run from a different server and I ask it to show the queue on the first server that we have been looking at above, then these ports become used:

image

image

Above we can see Exchange Management Shell on mail5 connecting to mail4 (the original server in this blog post). The second picture from mail4 shows that port 29952 have received a connection from the IPv6  address of mail5 and specifically from port 65172 on that remote server.

If I look finally at the second server in this exercise and see what process is connecting from port 65172 (and again, your ports will be different) I see that process 15156 is doing this (the process ID is the last column in the output)

image

Taking this process ID to Task Manager, I see process 15156 is the IIS Worker Process, which is the process that PowerShell connects to to do its work.

image

Therefore, the random and changing port that EdgeTransport.exe listens on is nothing to do with PRISM, but all to do with your management of remote queues.

Categories
2007 2010 2013 encryption exchange IAmMEC TLS transport

Ensuring Email Delivery Security with Exchange 2013

To force Exchange 2013 to guarantee the secure delivery of a message can be done a few different ways. In this version of the product and in previous versions it was possible to create a send connector for a given domain and enable Mutual TLS on the connector. Then all messages to the domain(s) that this connector serviced would need to travel over a TLS connection where the certificate at both ends was completely valid (i.e. valid regards the date, had the correct subject or SAN for the domain, was issued by a trusted certificate authority etc.). In previous versions (2007 to 2010 again) it was possible to enable Domain Secure and add another level of checks to the Mutual TLS session. Domain Secure does not work in Exchange 2013.

And great though these methods of transport security are, they are limited in that they are difficult to set up (require good knowledge of certificates) and needs to be properly configured at both ends of the connection. They are also limited in that they will only secure email to the selected domains. If you need to send a “top secret” email to someone, you don’t really want to have to configure a connector at both ends and force all email for that domain down the same path.

So, in Exchange 2013 you can create a transport rule to force the connection to use TLS, and if TLS fails then have the message queue on the sender until it retries and eventually expires. If TLS is never available, the message never goes out of Exchange – or so it would be if all you read was the description in the documentation!

The RouteMessageOutboundRequireTLS transport rule action (or the Secure the message with > TLS encryption option in the ECP transport rules wizard) allows you to craft a rule for any condition (for example the subject or body contains any of these words: top secret) which will require the email to use an encrypted session for the delivery outside of Exchange Server. Note that for this to work the TLS session does not need to be protected by a given certificate or valid etc., it just needs the receiving SMTP Server to offer STARTTLS and for the encryption to work.

And it needs a source server for sending the message in every Active Directory site within the organization. Currently (as of CU2 for Exchange 2013) if you send a message from a site that does not contain a send connector that can handle the message to the internet then Exchange will pass it to a site that can, but the source transport server will now not enforce the TLS requirement and will send the message unprotected if STARTTLS is not offered.

So if you want to guarantee the use of TLS for certain types of message use the RouteMessageOutboundRequireTLS transport rule condition and ensure that you do not need to do cross site delivery of messages to reach a send connector source server to delivery the message to the internet.

Categories
2007 2010 2013 Edge exchange federation IAmMEC mcm mcsm smarthost transport

Removing Edge Subscription When Exchange 2013 Installed

Exchange 2013 does not have an Edge role (at the time of writing – Aug 2013). It is possible to use Exchange 2010 SP3 and install the Edge role should you need one.

There is a problem though when it comes to removing the Edge Subscription between an organization that contains Exchange 2013 servers and the Exchange 2010 Edge Server. To remove the subscription on the Edge server role you run Remove-EdgeSubscription servername and this removes both the subscription and any subscribed objects from the local AD LDS database on that Edge Server. But if any of these subscribed objects where created on Exchange 2013 after it was installed, then they will have an ExchangeVersion equal to 0.20 (15.0.0.0). The Exchange 2010 SP3 Remove-EdgeSubscription cannot process this object and so fails with:

Remove-EdgeSubscription : Can’t make this change because the object’s ExchangeVersion property is 0.20 (15.0.0.0), which is not supported by the current version 0.1 (8.0.535.0). You will need a newer version of Exchange to make this change. Property Name: ExchangeVersion
At line:1 char:24
+ Remove-EdgeSubscription <<<<  edge2 -Verbose
+ CategoryInfo          : NotSpecified: (0:Int32) [Remove-EdgeSubscription], DataValidationException
+ FullyQualifiedErrorId : D8A49A14,Microsoft.Exchange.Management.SystemConfigurationTasks.RemoveEdgeSubscription

The way to fix this is to find and manually remove the object with an ExchangeVersion of 0.20 (15.0.0.0) from the AD LDS database and then repeat the Remove-EdgeSubscription cmdlet – as that should now work (unless you have two or more objects with the higher version number to locate and delete).

  1. To find objects with an ExchangeVersion greater than “0.1 (8.0.535.0)”, which is the version Exchange 2010 will process, open ADSIEdit on the Edge server.
  2. Right-click the ADSI Edit node at the top of the window and choose Connect to…
    image
  3. In the Connection Settings dialog (shown above), change the Select a well known Naming Context to Configuration and type the local server name and the AD LDS port in the Select or type a domain or server field. The server:port value should be EDGESERVERNAME:50389
    image
  4. Expand the tree view until you reach CN=First Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,CN={AD258B4D-CCB4-4125-80C1-7B73CE066341}
    image
  5. You now need to look at each object, starting with those you remember having created since 2013 was installed, for an object who’s msExchVersion value is not 4535486012416. For example, in the below screenshot I have an accepted domain made due to Federation in Exchange 2013. This object (under CN=Accepted Domains,CN=Transport Settings,…) has a value of 88218628259840.
    image
  6. To validate that this is the correct object to manually delete, from the Exchange Management Shell on the Edge server, enter Get-Object | FT name,ExchangeVersion where Object is the cmdlet that you are looking to query – in my case it would be Get-AcceptedDomain.
    image
  7. As you can see, this object has a newer ExchangeVersion and so it is (at least) this object that is stopping Exchange EdgeSync from being removed.
  8. Manually delete this object in ADSI Edit (it is safe to do this as it will resync from the Exchange organization if you recreate Edge Subscription later). Do not delete it from the Active Directory with ADSI Edit – just from AD LDS. Take care to only delete this object and not the parent object.
  9. Once this object is gone, try Remove-EdgeSubscription servername again. If this is the only object, then the Edge Subscription will be removed in the Edge Server

You can now carry on with whatever it was that you were doing that required a removal of the Edge Subscription.

Categories
2010 IAmMEC mcm transport

Create Shadow Redundancy Cross Forest in Exchange 2010

 

Send connector cross forest shadow redundancy

New-SendConnector ToTailspin -AddressSpaces SMTP:tailspin.com -SmartHosts mail.tailspin.com -ProtocolLoggingLevel verbose -DNSRoutingEnabled $False -SmartHostAuthMechanism ExternalAuthoritative
Get-SendConnector ToTailspin | Add-ADPermission -user "MS Exchange\Externally Secured Servers" -ExtendedRights ms-Exch-SMTP-Send-XShadow

Receive connector cross forest shadow redundancy

New-ReceiveConnector FromFabrikam -RemoteIPRanges 192.168.100.1 -Bindings 0.0.0.0:25 -ProtocolLoggingLevel verbose -Banner "220 Tailspin XShadow SMTP Server" -AuthMechanism ExternalAuthoritative 
Get-ReceiveConnector FromFabrikam | Add-ADPermission -user "MS Exchange\Externally Secured Servers" -ExtendedRights ms-Exch-SMTP-Accept-XShadow

Categories
2010 2013 exchange IAmMEC mcm mcsm

Formatting Get-ExchangeDiagnosticInfo

For the last blog post for today, this one looks at formatting the output of Get-ExchangeDiagnosticInfo as the XML that this cmdlet returns can be quite long. For example if you want to see if your server is in backpressure then you need to view the output of the ResourceMonitor component, but as this contains historical information on backpressure events its more than enough data to overfill the Exchange Management Shell screen!

So rather than running Get-ExchangeDiagnosticInfo -Process EdgeTransport -Component ResourceManager -Argument verbose you can do the following

$diag = Get-ExchangeDiagnosticInfo –Server xxx –Process EdgeTransport –Component ResourceManager –Argument verbose
$diag.Diagnostics.Components.ResourceManager.CurrentComponentStates
$diag.Diagnostics.Components.ResourceManager.ResourceMonitors.ResourceMonitor | FT –a Type, Resourc*,*Pressure*

This will collect the ResourceManager component from Get-ExchangeDiagnostics and place it in a variable called $diag. The second line returns the state of each backpressure monitor and if it is enabled and the third line displays the results of backpressure on your server (currentpressure) along with the values at which you will change from low to medium (the mediumPressureLimit) or from medium to high (the highPressureLimit) or from medium to low (the lowPressureLimit). For an example see the below picture, from my lab environment, which is currently busy doing nothing!

image

Categories
2007 2010 2013 ADFS ADFS 2.0 certificates exchange exchange online https hybrid IAmMEC ISA Server 2006 mcm Office 365 SSL tmg

Changing ADFS 2.0 Endpoint URL for Office 365

If you are configuring single sign-on for Office 365 then you will need a server running Active Directory Federation Services 2.0 (ADFS 2.0). When you install this you are asked for a URL that acts as an endpoint for the ADFS service, which if you are publishing that endpoint through a firewall such as TMG needs to be on a mutually trusted certificate as either the subject name or alternative subject name.

The documentation uses sts.yourdomain.com which means you need to have this as a valid name of the certificate. I use StartCom SSL, which provide cheap certificates (approx. $100 for as many certificates as you like), but to change a certificate to add an additional alternative subject name requires revoking the current cert, and that comes at additional cost.

So I have a certificate with lots of name on it for my domain, just not sts.mydomain.com so I set about changing the endpoint in ADFS 2.0

Firstly open the ADFS 2.0 administrative console and select the root note:

image

Click Edit Federation Service Properties in the Action Pane and modify the three values on the General tab:

image

After clicking OK, restart the AD FS 2.0 Windows Service.

After the restart, create a new Token-Signing Certificate and Token-Decrypting Certificate. These are self signed certificates. To allow you to add these you need to turn off automatic certificate rollover if enabled. This can be done from PowerShell using Set-ADFSProperties –AutoCertificateRollover $false and this cmdlet is available in Windows PowerShell Modules in the Administrative Tools menu.

To update Office 365 start the Microsoft Online Services Module for Windows PowerShell, installed as part of the Office 365 rich co-existence process. In this PowerShell window type Update-MsolFederatedDomain –DomainName yourFederatedDomain.com. You will also need to login to Office 365 in this window first (Connect-MsolService) and set PowerShell with the name of the ADFS server (Set-MsolADFSContext –Computer ADFS_ServerName). Type Get-MsolFederatedDomain –DomainName yourFederatedDomain.com to ensure that the returned URL’s and certificates are correct.

Now its time to update the TMG rule, or create a new one. The listener in TMG must have the same third party certificate and be for HTTPS with the Public Name matching the certificate subject/subject alternative name and the Path value set to /adfs/*. The To page needs to be set with the same URL and internal IP address of the ADFS 2.0 server.

image

And that should be it – after the Update-MsolFederatedDomain –DomainName yourFederatedDomain.com has completed both sides of the federation trust are aware of the certificate change and automatic login to http://outlook.com/yourFederatedDomain.com should work.

Categories
2007 2010 2013 exchange IAmMEC mcm

.DLL Errors and Blackberry Enterprise Server

During a configuration of Blackberry Enterprise Server today I found that I was getting .DLL errors when trying to create a MAPI profile on the BES Server (v5.0.2) when running IEMSTest.

Well it was not the usual stuff – it ended up being the alias that had been assigned to the BESAdmin account. The policy at the company where I am installing Exchange 2010 is last_first@domain.com, but the BESAdmin account does not have a first or last name and so got an email address of _9c73@domain.com, and so though I could login in OWA, I could not do a MAPI login (IEMSTest or Outlook – because the alias was not BESAdmin as they default to).

Once I changed the SMTP Address to BESAdmin@domain.com then it all worked fine.

Categories
2007 2010 2013 exchange exchange online IAmMEC mcm mcsm

Random Chinese Characters in Exchange 2010 SP1 Emails

I have been sent a few emails from a client that start like this:

格tml> 格ead> 猼tyle㰾!– .hmmessage P { margin:0px; padding:0px } body.hmmessage { font-size: 10pt; font-family:Tahoma } –>⼼style> ⼼head> 㰊body class=’hmmessage’>

The HTML characters repeat throughout the message, but not on every message, though those sent from Hotmail are typically affected (but it is not always Hotmail).

The problem is due to the email having character encoding in the charset META tag that differs from the character encoding in the MIME part and a HTML disclaimer having been added. When Exchange 2010 SP1 adds the HTML disclaimer it re-encodes the message and this results in a corrupt message because the wrong character set information is read.

The fix for this has been documented in KB969129, which refers to Exchange 2007, but the same fix is true for Exchange 2010 SP1.

The fix is to add the DisableDetectEncodingFromMetaTag attribute to EdgeTransport.exe.config. This file can be found at \Program Files\Microsoft\Exchange Server\V14\bin and can be opened in Notepad. Make a backup of the file before you change it and then add to the area of the file the following

 

After you save the config file you need to restart the Microsoft Exchange Transport service for the setting to take effect.