The counter list and portability (read I/O operations)

An ExRAAP scanning detected this issue “The read I/O operations latency is greater than expected for an Exchange database” with an advice I started to monitor related performance counters according to post Analysing Exchange Server 2010 Jetstress BLG Files By Hand which contains also the following table:

7- 8- 2014 12-15-22Time to time I needed to check read I/O operations without a Data Collector Set, but I did not want to have the counter list/settings dependent on particular server (i.e. the server below hosts mailbox database MDB01 or MDB05 but not MDB02 and I want to have counters for all of them and I do not mind that some counter will not work).

7- 8- 2014 12-03-147- 8- 2014 12-44-28Well, I saved the settings from the server into HTML file and modify its content for 18 databases.

  • Changing value: <PARAM NAME=”CounterCount” VALUE=”18″/>
  • Adding parameters for missing databases (be careful you have to always use unique PARAM NAME):7- 8- 2014 12-59-42After that I could check the latency by pasting the same counter list on any server.

7- 8- 2014 13-12-18

 

How to alter Retention policies in Exchange 2013

One of my friends want to alter automatic deletion of Junk Email folder so, that it contains only 30 days of messages. The way how it should be done is simple. We can create new retention policy or add Retention policy tag to existing one.

Theory

Exchange 2013 (as well as Exchange 2010) contains a set of Retention policy tags grouped in Default Retention and Archive policy. Retention policy tag says, what action will be done with item (for example all Messages calls) within specified Retention period and defined folder. Retention policy can be assigned to mailbox in 1:1 ratio, meaning only one Retention policy can exist on mailbox. It is not supported to have no retention policy on mailbox or to have Retention policy without any Retention policy tag, which might cause, that no item in mailbox will expire. More info about Retention policies and tags can be found here: http://technet.microsoft.com/en-us/library/dd362328(v=exchg.150).aspx Retention Tags and Retention policies are described here:http://technet.microsoft.com/en-us/library/dd297955(v=exchg.150).aspx

Retention policy can contain several types of Retention policy tags:

  • One or more retention policy tags (RPTs) for supported default folders
  • One default policy tag (DPT) with the Move to Archive action
  • One DPT with the Delete and Allow Recovery or the Permanently Delete action
  • One DPT for voice mail
  • Any number of personal tags

Retention policy is then added to mailbox and it is up to administrator to configure how often Managed Folder Assistant will process mailboxes. I picked up and option to add Retention policy tag to existing policy and here is the result:

Creation of Retention policy tag

To create Retention policy tag we must be sure what action to perform and to what folder type. In my case to delete and allow recovery on all items older than 1 month in folder type Junk Email. Here is the command:

New-RetentionPolicyTag -Name "Junkmail Cleanup" -MessageClass * -AgeLimitForRetention 30.00
:00:00 -RetentionAction DeleteAndAllowRecovery -Type JunkEMail

RetentionPolicy_AddedTAG_EAC

Assigning Retention policy tag to Retention policy

To add Retention Policy tag to Retention policy use the following commands:

$TagList = (Get-RetentionPolicy "Default Archive and Retention Policy").RetentionPolicyTagLinks
$TagList.Add((Get-RetentionPolicyTag 'Junkmail Cleanup').DistinguishedName)
Set-RetentionPolicy "Default Archive and Retention Policy" -RetentionPolicyTagLinks $TagList

RetentionPolicy_AddedTAG

Assigning Retention policy to mailbox

First gather what retention policy is used and if different, add needed retention policy to mailbox:

Get-Mailbox zbynek | select *ret*
Set-Mailbox zbynek -RetentionPolicy "Default Archive and Retention Policy"

Force running Retention policy

Start-ManagedFolderAssistant -Identity zbynek

Assign Retention policy and cleanup

Change Retention policy cycle

The default is to run policy for all mailboxes daily, but it can be changed altering mailbox server property ManagedFolderWorkCycle. In my example there will be 10 days cycle to run Retention policies on all mailboxes on the server.

Set-MailboxServer EX13NODE2 -ManagedFolderWorkCycle 10

Result

Before:
Junkmail_Before

After:
JunkmailAfter

IMAP connection settings and workload management on Exchange 2013

One of my Exchange 2013 customers currently running Exchange 2013 CU2v2 started to have problems with IMAP connections to his server. IMAP log stated, that conection limit has been reached:

IMAP_Connection_limit_reached

I have examined IMAPSettings from Exchange management shell, and here it is. Connection limit per user is set to 16 by default and counters are reset after 240000 milliseconds (4 minutes), which is not enough. First part of this article will be about the possibilities how to set IMAP from connection point of view. Second part is, how to deal with IMAP in case server is under heavy load and it is expected to have IMAP running.

1. IMAP Settings from connection point of view

IMAP connections limits can be set in levels of MaxConnections, MaxConnectionFromSingleIP, MaxConnectionsPerUser. First two limits are very high, but third limit is set to 16 by default and throttling policy let counter reset after 240000 milliseconds by default, which means, that if user make more than 16 connections in 4 minutes, he is banned till next counter reset.

imap limit

So connection limit might be increased by the following command:

Set-IMAPSettings -MaxConnectionsPerUser <Number>
Get-Service *IMAP* | Restart-Service

Result can be seen on the Picture below (Reset of IMAP services must be made):

IMAP_User_connection_setting

imap limita

Details about settings are here: http://technet.microsoft.com/en-us/library/aa998252(v=exchg.150).aspx

2. IMAP settings from Workload management point of view

Limits per user are set and now I would need to fulfill customer needs if server load is increased. In my case customer needs to have IMAP working properly even there is high utilization of system resources. First I went to Technet web link http://technet.microsoft.com/en-us/library/jj150485(v=exchg.150).aspx and selected the best suitable Workload Classification for my customer. Default Workload Classification for IMAP is Internal Maintenance. If one of performance indicators is in Overloaded or pass the Critical threshold, IMAP service might be temporarily inaccessible for users (Monitored system resources are described in the Technet article as well).

So in this stage I have checked tables and according the server utilization I suggested to increase Workload Classification from Internal maintenanace (Picture below) to Customer Expectation, which means, that even the server will be under heavy load, IMAP is going to work for users.

Before Setting (Default Workload Classification):

IMAP_Connection_limit_Workload_management_before

After setting performed by the following command:

Get-WorkloadPolicy IMAP | Set-WorkloadPolicy -WorkloadClassification CustomerExpectation

IMAP_Connection_limit_Workload_management_after Done!

Links:

Exchange federation trust – part 2.

Finally here is the continuation of previous article about Exchange federation trust. So we have established the trust between Microsoft Federation Gateway and our organizations. Next step is to configure inter-organizational behavior. It is a mesh-like net, where 1:1 organization relationship is established.

Prerequisites

  • Autodiscover service must be accessible to at least one CAS server from the internet
  • EWS should be accessible to at least one server and External URL should match the name accessible from  internet and 3rd party certificate SN or SAN name

Organization Relationship

Once we have configured our organizations to trust MS Federation Gateway, we can use it to create organization relationship. We will use

command Get-FederationInformation about opposite organization and pipe it to create new organization relastionship. Access level on both side of relationship should be the same.

In our organization:

Get-FederationInformation -DomainName metrosys.cz | New-OrganizationRelationship -Name "Metrosys" -FreeBusyAccessEnabled $true 
-FreeBusyAccessLevel -LimitedDetails

Or directly:

New-OrganizationRelationship -Name <foreignorganizationname>  -FreeBusyAccessEnabled $True -FreeBusyAccessLeve LimitedDetails -
Enabled $true -PhotosEnabled $true -TargetAutodiscoverEpr https://email.foreigndomain.cz/autodiscover/autodiscover.svc/wssecurity -
DomainNames .cz -TargetApplicationURI http://fydibohf25spdlt.foreigndomain.cz/ -TargetSharingEpr 
https://email.foreigndomain.cz/EWS/Exchange.asmx

Note: Domain names are CASE SENSITIVE!
Result of creation test:

Test-OrganizationRelationship -identity <ForeignOrganizationname> -UserIdentity primarysmtpaddress@salonovi.cz -Verbose

OK success rel test

In foreign organization:

Get-FederationInformation -DomainName salonovi.cz | New-OrganizationRelationship -Name "Salonovi" -FreeBusyAccessEnabled $true -
FreeBusyAccessLevel LimitedDetails

Or directly:

New-OrganizationRelationship -Name  -FreeBusyAccessEnabled $True -FreeBusyAccessLeve LimitedDetails -Enabled $true -PhotosEnabled 
$true -TargetAutodiscoverEpr https://mail.salonovi.cz/autodiscover/autodiscover.svc/wssecurity -DomainNames salonovi.cz -TargetApplicationURI 
http://fydibohf25spdlt.salonovi.cz/ -TargetSharingEpr https://mail.salonovi.cz/EWS/Exchange.asmx

Note: Domain names are CASE SENSITIVE!

Finally result of proper configuration is, that you can see Free/Busy limited details of users in foreign organization

Errors you might face

Index error is cause by Case sensitive domain name inserted (in my case Metrosys.cz instead of metrosys.cz or wrong URLs for EWS or Autodiscover.

test-orgrel_indexerror

Errors from the following picture are caused by wrongly or misspelled URLs (Self explaining)

test_org_rel_err2

Usually autodiscover URL is created in format https://autodisvocer.domianname.cz/autodiscover/autodiscover.xml, however Federation trust use autodiscover service, which is created as URL: https://autodisvocer.domianname.cz/autodiscover/autodiscover.svc/WSSecurity where WSSecurity is authentication used by federeation trust:

org_rel_res_our

Links:

SMTP certificate renewal and EDGE subscription

I have had to renew SMTP certificate on EDGE servers. Here is the procedure how to renew certificate and re-create Edge subscription. This procedure starts,when CSR is created and we have received certificate from trusted CA.

1. Import new certificate
To import certificate to local certification store run:

import-exchangecertificate -FileData ([byte[]]$(Get-Content -Path "D:\tempo\certificate_mx1_2013.cer" -Encoding Byte -ReadCount 0))

2. Connect pending request to certificate
If step 1 failed to connect certificates together inside certification store run:

certutil -repairstore my "1268f7300044bc90ff426d5f515d3729"

Explanation can be found in my previous article: http://ficility.net/2013/02/25/exchange-2010-complete-certificate-request-problem/

3. Enable new Exchange certificate for SMTP service
Before certificate can be used, it must have been enabled for particular services.

Enable-ExchangeCertificate  -services SMTP

Result:

[PS] C:\Windows\system32>Enable-ExchangeCertificate 81315B240A62B5B5AD5570AA58A06D90B4B90B7E -Services SMTP

Confirm
Overwrite the existing default SMTP certificate?

Current certificate: 'C661DC9E16FB391EDA2A852C3514AD035D710F68' (expires 4/27/2013 2:59:59 AM)
Replace it with certificate: '81315B240A62B5B5AD5570AA58A06D90B4B90B7E' (expires 4/28/2014 2:59:59 AM)
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help (default is "Y"): y
WARNING: The internal transport certificate attribute for the local Edge Transport server has been updated. If this
Edge Transport server is subscribed to an Active Directory site, you must  subscribe it again by using the
New-EdgeSubscription cmdlet in the Shell, and then restart AD LDS.
[PS] C:\Windows\system32> 

4. Restart transport service and AD LDS service
At this moment e-mail stop to flow to this EDGE server, because AD LDS is using new certificate and Edge is subscribed via old one.

5. Create subscription file (XML) on Edge server ans copy it to HUB server
We don´t need to create connectors for EDGE Subscription, since those are already created. EDGE must be subscribed to AD site within 24 hours after creation of subscription file.

New-EdgeSubscription -FileName d:\subscription_2013.xml -Site <SITE_NAME> -CreateIternetSendConnector $false -CreateInboundSendConnector $false

Result:

[PS] C:\Windows\system32>New-EdgeSubscription -FileName d:\subscription_2013.xml -Site Default-First-Site-Name -CreateIternetSendConnector $false -CreateInboundSendConnector $false

Confirm
The Edge Subscription should be completed inside your organization within the next "1440" minutes before the bootstrap
account expires.
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help (default is "Y"): y

6. Subscribe EDGE server on HUB by subscription file (XML).
We need to re-create trusted connection between Edge server and HUB servers. Subscribtion needs to be re-created, because AD LDS needs to use new certificate instead of old one. It is enough to subscribe each EDGE server once per subsciption.

New-EdgeSubscription -FileData ([byte[]]$(Get-Content -Path "D:\subscription_2013.xml" -Encoding Byte -ReadCount 0)) -Site "Default-First-Site-Name"

7. Restart EDGE server
Just to be sure all settings are applied before tests.

8. Test Edge Subscription
If the test is not successfulm you receive error.

Test-EdgeSynchronization -FullCompareMode

Successful result:

[PS] C:\Windows\system32>Test-EdgeSynchronization -FullCompareMode


RunspaceId                  : 4f4c61e7-1059-43fc-963b-877641087e2a
SyncStatus                  : Normal
UtcNow                      : 4/26/2013 6:43:50 AM
Name                        : EDGE
LeaseHolder                 : CN=HUB2,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrati
                              ve Groups,CN=OR,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=SALONOVI,DC=cz
LeaseType                   : Option
FailureDetail               :
LeaseExpiryUtc              : 4/26/2013 7:12:12 AM
LastSynchronizedUtc         : 4/26/2013 6:42:12 AM
TransportServerStatus       : Synchronized
TransportConfigStatus       : Synchronized
AcceptedDomainStatus        : Synchronized
RemoteDomainStatus          : NotSynchronized
SendConnectorStatus         : Synchronized
MessageClassificationStatus : Synchronized
RecipientStatus             : Synchronized
CredentialRecords           : Number of credentials 6
CookieRecords               : Number of cookies 2

9. Test mailflow

10. To start Edge synchronization manually

Start-EdgeSynchronization

Result:

[PS] C:\Windows\system32>Start-EdgeSynchronization


RunspaceId     : 4f4c61e7-1059-43fc-963b-877641087e2a
Result         : Success
Type           : Configuration
Name           : EDGE
FailureDetails :
StartUTC       : 4/26/2013 6:46:45 AM
EndUTC         : 4/26/2013 6:46:45 AM
Added          : 0
Deleted        : 0
Updated        : 0
Scanned        : 0
TargetScanned  : 0

RunspaceId     : 4f4c61e7-1059-43fc-963b-877641087e2a
Result         : Success
Type           : Recipients
Name           : EDGE
FailureDetails :
StartUTC       : 4/26/2013 6:46:45 AM
EndUTC         : 4/26/2013 6:46:45 AM
Added          : 0
Deleted        : 0
Updated        : 0
Scanned        : 0
TargetScanned  : 0

Links:http://technet.microsoft.com/en-us/library/bb310755(v=exchg.80).aspx

Exchange federation trust – part 1.

I need to configure federation trust between two organizations, but what is federation trust? It is secure trusted connection of separate organizations, which need to share their internal data (From Exchange point of view it is Calendar,Free/busy and contact information and others (see Set-OrganizationRelationship) without a need of establishing special Forests/Domains trusts, VPN connections or buying expensive synchronization servers.

Federation trust works based on free Microsoft cloud service Microsoft Federation Gateway. Microsoft Federation Gateway acts like middle authority, with which all Exchange organizations need to establish one time trust before those will be able to communicate with each-other. After one time trust is established, Microsoft Federation Gateway issues SAML tokens for users, which requests to get information about users from federated Exchange organization. These tokens are then trusted by fedetated partners and contain info about user e-mail address, immutable (constant) number and action to which token is issued for.
If we imagine the description above, all Exchange organizations will be trusted with Microsoft Federation Gateway, but it will not allow it to communicate with each-other, before 1:1 trust relationship “Organization Relationship” is not established between 2 Exchange organizations. Organization Relationship connects 2 Exchange organizations and allow them to share data defined by Sharing policies.

In first part of article I will go through prerequisites, you need to start configuring Federation trust, actual configuration of Federation trust with Microsoft Federation Gateway, Configuring of Organization identifier. Preparation for configuration of Organization relationship will be part 2 of this series. Reason is simple. I don´t have DNS records in place during the time writing this article.

For full technology description please visit MS Technet

Prerequisites

  • Autodiscover and EWS virtual directories must be published to internet (or in case internal connection exists between your organizations, these must be accessible in both directions)
  • Federation trust needs to have WSSecurity authentication in place on EWS and Autodiscover virtual directories

Run the following commands to check if all of these are in place:

Get-ClientAccessServer | Get-WebServicesVirtualDirectory |select *auth*

CertificateAuthentication     :
InternalAuthenticationMethods : {Ntlm, WindowsIntegrated, WSSecurity, OAuth}
ExternalAuthenticationMethods : {Ntlm, WindowsIntegrated, WSSecurity, OAuth}
LiveIdNegotiateAuthentication :
WSSecurityAuthentication      : True
LiveIdBasicAuthentication     : False
BasicAuthentication           : False
DigestAuthentication          : False
WindowsAuthentication         : True
OAuthAuthentication           : True
AdfsAuthentication            : False

Get-ClientAccessServer | Get-AutodiscoverVirtualDirectory |select *auth*

InternalAuthenticationMethods : {Basic, OAuth}
ExternalAuthenticationMethods : {Basic, OAuth}
LiveIdNegotiateAuthentication : False
WSSecurityAuthentication      : False
LiveIdBasicAuthentication     : False
BasicAuthentication           : True
DigestAuthentication          : False
WindowsAuthentication         : False
OAuthAuthentication           : True
AdfsAuthentication            : False

As you can see in the result, AutoDiscover virtual directory doesn´t have WSSecurity authentication enabled. To enable it use the command below followed by IIS reset.

Get-ClientAccessServer | Get-AutodiscoverVirtualDirectory | Set-AutodiscoverVirtualDirectory -WSSecurityAuthentication $true

After these are ready, we can continue configuring Federation trust.

Federation trust

  • To get Federation trust working we need to generate self-signed certificate with unique Subject Key Identifier. This certificate will be used to sign and encrypt delegation tokens  (3rd party sign certificate can be used too, but why if we can use free self-signed one with longer validity period).

First command generates unique SKI, second generates the certificate

$ski = [System.Guid]::NewGuid().ToString("N")
New-ExchangeCertificate -FriendlyName "Exchange Federated Sharing" -DomainName "salonovi.cz" -Services Federation -KeySize 2048 -PrivateKeyExportable $true -SubjectKeyIdentifier $ski

Next command creates Federation trust, but we are not able to communicate with MFG yet.

Get-ExchangeCertificate | ?{$_.friendlyname -eq "Exchange Federated Sharing"} | New-FederationTrust -Name "Microsoft Federation Gateway"

To be able to communicate with MFG we must proove, that domains , which will be defined in Federation Organization Identifier are owned by us. This is accomplished by adding HASHES as TXT records to our DNS.
Hashes can be gathered by the following commands. Domain FYDIBOHF25SPDLT.salonovi.cz is used to create namespace for communication between organizations and to be honest I am not sure if this hash needs to be in place, but I put it there to be sure it works.

Get-FederatedDomainProof -DomainName salonovi.cz

RunspaceId : 7b47ba54-c78f-4d73-8337-a457b9ebfd1b
DomainName : salonovi.cz
Name       : OrgPrivCertificate
Thumbprint : 82E68E80B61290475025A0E9737FECE922D4E8C3
Proof      : EmJKFNW+frdgGM+fkDZyKE+nbJzdRaouCKM2NHNzIjgVPB6TuwlEmWdqxCa1BWuxfTth+Do2R+fLLbbahTWmLg==
DnsRecord  : salonovi.cz TXT IN 
             EmJKFNW+frdgGM+fkDZyKE+nbJzdRaouCKM2NHNzIjgVPB6TuwlEmWdqxCa1BWuxfTth+Do2R+fLLbbahTWmLg==

Get-FederatedDomainProof -DomainName FYDIBOHF25SPDLT.salonovi.cz

The format of DNS records is as follows:

salonovi.cz TXT IN <hash>

And live example is

FYDIBOHF25SPDLT.salonovi.cz TXT IN iE64T7bsM8auQUYoAD/Dc/+sEAieDjG6gJFkGvZRIvyb+5FiwjCQY8BiIrrwafVUr7r3VdyAOXm9F/eb0R8kuA==

After hashes are in external DNS, we can set Federated Organization Identifier. It defines which domains of our organizations will be enabled for federation and what federation trust it will use.
Before setting of Federation identifier we get the following results

Get-FederatedOrganizationIdentifier

RunspaceId          : 7b47ba54-c78f-4d73-8337-a457b9ebfd1b
AccountNamespace    : missing
Domains             : missing
DefaultDomain       : missing
Enabled             : False
OrganizationContact : 
DelegationTrustLink : 
Identity            : Federation
IsValid             : True
ExchangeVersion     : 0.10 (14.0.100.0)
Name                : Federation
DistinguishedName   : CN=Federation,CN=SalonoviMail,CN=Microsoft 
                      Exchange,CN=Services,CN=Configuration,DC=salonovi,DC=cz
Guid                : 3a69e332-7156-4251-856c-f3cc17853e39
ObjectCategory      : salonovi.cz/Configuration/Schema/ms-Exch-Fed-OrgId
ObjectClass         : {top, msExchFedOrgId}
WhenChanged         : 1/7/2013 7:18:04 PM
WhenCreated         : 11/29/2011 9:21:30 PM
WhenChangedUTC      : 1/7/2013 6:18:04 PM
WhenCreatedUTC      : 11/29/2011 8:21:30 PM
OrganizationId      : 
OriginatingServer   : DC1.salonovi.cz
ObjectState         : Unchanged

Get-FederationInformation -DomainName salonovi.cz
Federation information could not be received from the external organization.
    + CategoryInfo          : NotSpecified: (:) [Get-FederationInformation], GetFederationInformationFailedException
    + FullyQualifiedErrorId : D04C5818,Microsoft.Exchange.Management.SystemConfigurationTasks.GetFederationInformation
    + PSComputerName        : backend1.salonovi.cz

Federated Organization Identifier

Set-FederatedOrganizationIdentifier -Enabled $true -DefaultDomain salonovi.cz -AccountNamespace salonovi.cz -DelegationFederationTrust "Microsoft Federation Gateway"

Final step is to test if Federation Trust is working. I use verbose parameter to troubleshoot but in this example I was lucky and all worked as expected at first glance.

Test-FederationTrust -UserIdentity zbynek.salon@salonovi.cz

RunspaceId : 7b47ba54-c78f-4d73-8337-a457b9ebfd1b
Id         : FederationTrustConfiguration
Type       : Success
Message    : FederationTrust object in ActiveDirectory is valid.

RunspaceId : 7b47ba54-c78f-4d73-8337-a457b9ebfd1b
Id         : FederationMetadata
Type       : Success
Message    : The federation trust contains the same certificates published by the security token service in its 
             federation metadata.

RunspaceId : 7b47ba54-c78f-4d73-8337-a457b9ebfd1b
Id         : StsCertificate
Type       : Success
Message    : Valid certificate referenced by property TokenIssuerCertificate in the FederationTrust object.

RunspaceId : 7b47ba54-c78f-4d73-8337-a457b9ebfd1b
Id         : StsPreviousCertificate
Type       : Success
Message    : Valid certificate referenced by property TokenIssuerPrevCertificate in the FederationTrust object.

RunspaceId : 7b47ba54-c78f-4d73-8337-a457b9ebfd1b
Id         : OrganizationCertificate
Type       : Success
Message    : Valid certificate referenced by property OrgPrivCertificate in the FederationTrust object.

RunspaceId : 7b47ba54-c78f-4d73-8337-a457b9ebfd1b
Id         : TokenRequest
Type       : Success
Message    : Request for delegation token succeeded.

RunspaceId : 7b47ba54-c78f-4d73-8337-a457b9ebfd1b
Id         : TokenValidation
Type       : Success
Message    : Requested delegation token is valid.

Next part comes soon (tomorrow) continuing with setting 1:1 relationships.

Exchange mass mailing?

Of course it is not recommended and there is much of cheap tools, but if your customer wants to send thousands of e-mails several times a day due to business needs and no delay is allowed, there is a possibility to set this behavior in Exchange:

The goal is to create special receive connector for this application and besides other settings you need (authentication, message size …) you should modify the following parameters:

  • MaxAcknowledgementDelay (Default 30 seconds) – This is time out parameter, if Exchange server cannot confirm delivery of message to all recipients, if the message was received by MTA, which does not support  shadow redundancy feature.
  • TarpitInterval (Default 5 seconds) – This parameter is valid for unauthenticated sources and specifies how much time SMTP response is delayed to source server in case, that Exchange determines source server is abusing connection.

The combination of settings MAxAcknowledgementDelay and TarpitInterval  to small values might put your environment to performance problems and it is NOT recommended to set it on internet receive connectors.

Default:

Get-ReceiveConnector SERVER\Relay | select *ack*,*tarp*,*lim*,iden* | fl

MaxAcknowledgementDelay : 00:00:30
TarpitInterval          : 00:00:05
MessageRateLimit        : Unlimited
Identity                : CHM2\Relay

Settings:

Get-ReceiveConnector SERVER\Relay | Set-Receiveconnector -MaxAcknowledgementDelay : 00:00:01 -TarpitInterval 00:00:00

This will not work in Exchange 2013, since shadow redundancy has been improved and Safety Net feature has been added instead of transport dumpster..

Links: