Windows cannot complete the extraction. The destination path is too long. rename the compressed (zipped) folder and try again.

Error: 

Windows cannot complete the extraction. The destination path is too long. rename the compressed (zipped) folder and try again.

Symptom:

When in Outlook, you receive some zip attachments. If you double click on a zip file (attachment) by right clicking and selecting open, you might get an error message that says "Windows cannot complete the extraction. The destination path is too long. Rename the compressed (zipped) folder and try again."

Cause: 

In some cases, the error message is correct in describing the problem. If your file path is long and the file name is long then yes this error is valid. But there can also be another reason this happens when opening (in particular zipped PDF's). It happens when you have enabled the "Remove Run menu from Start Menu" Group Policy setting on the computer.

Work around:

1) Drag the file to a new location.

2) Double-click on the file, and then select Save. Then, save to the desktop and rename the file.

Microsoft has a hotfix:

http://support.microsoft.com/kb/981603

 

Tarpit for '0.00:00:09.675' due to 'DelayedAck',Delivered

So whether you are in co-existence between Lotus notes and Exchange or Exchange 2003 and 2010. There will be a time where there will be a delay experienced at some time. It happens to almost every environment.

The SMTP tarpit feature is one of the most useful tools to protect organizations from directory harvesting attacks (DHAs). By default, the tarpit interval, or time before a response, is five seconds, and the error limit is five. 

On the first day we were experiencing 20 minute email delays, nothing too noticeable as this wasn’t consistent either. The second day the delays had reached up to an hour and then 2 hours. Only a few emails were passing through and Lotus notes was showing a considerable queue build up (2000+ emails) in a retry state. Exchange did not have any queues. After much troubleshooting on the network side and Quest co-existence server the next step was to start looking at the problem from the Exchange end as a possible receiving issue. So then the troubleshooting began and we started at the receive connector end.

     1)       First place to start looking with troubleshooting is turning the SMTP logging on the receive connector. Change this from None to Verbose. 

     2)      To do this in EMC, Expand the Server Configuration > Hub Transport node

3)      Select the Hub Transport server you want to configure, and then select the Receive Connector > Properties

4)      On the General tab, change the Protocol logging level from None to Verbose, click Apply and OK.

5)      Locate the logs by opening the following location   C:\Program Files\Microsoft\Exchange Server\V14\TransportRoles\Logs\ProtocolLog\SmtpReceive . There will be a file called RECVYYYYMMDD-1

Started observing this error throughout the logs, which indicated that messages were not coming through to exchange normally:

354 Start mail input; end with <CRLF>.<CRLF>,

Then observed a multiple error messages which triggered our interest:

Tarpit for '0.00:00:09.675' due to 'DelayedAck',Delivered

Investigated the “DelayedAck” (Delayed Acknowledgement) indicates slow email acceptance and generates the error message above, all throughout the Receive connectors SMTP logs.

This means that Exchange has not acknowledged the pending message yet.

So further researching brought me to a few pages. Where the problem was the “MaxAcknowledgementDelay” parameter was not equal to 0.

To first see what my receive connectors were set to the default appeared to be 30.

Get-receiveconnector “connector name” | fl sort-by *max*

MaxInboundConnection                    : 5000

MaxInboundConnectionPerSource           : 20

MaxInboundConnectionPercentagePerSource : 2

MaxHeaderSize                           : 64 KB (65,536 bytes)

MaxHopCount                             : 60

MaxLocalHopCount                        : 12

MaxLogonFailures                        : 3

MaxMessageSize                          : 22 MB (23,068,672 bytes)

MaxProtocolErrors                       : 5

MaxRecipientsPerMessage                 : 200

MaxAcknowledgementDelay                 : 00:00:30

Then ran:

Set-ReceiveConnector "Default connector (Servername)" -MaxAcknowledgementDelay 0

And for verification:

Get-receiveconnector “connector name” | fl sort-by *max*

MaxInboundConnection                    : 5000

MaxInboundConnectionPerSource           : 20

MaxInboundConnectionPercentagePerSource : 2

MaxHeaderSize                           : 64 KB (65,536 bytes)

MaxHopCount                             : 60

MaxLocalHopCount                        : 12

MaxLogonFailures                        : 3

MaxMessageSize                          : 22 MB (23,068,672 bytes)

MaxProtocolErrors                       : 5

MaxRecipientsPerMessage                 : 200

MaxAcknowledgementDelay                 : 00:00:00

This turns this feature off and bingo the queue on the Domino co-existence server quickly disappeared. Email flow is back to normal and no longer has any email build ups.

The cmdlet does have to be run on every single one of your HUB servers, no restart of services or servers required.

Although, do remember to turn off your verbose logging on the HUB server as the logs do fill up very quickly and can cause some issues if you don’t have enough space available.

             1)  To do this in EMC, Expand the Server Configuration > Hub Transport node

2)      Select the Hub Transport server you want to configure, and then select the Receive Connector > Properties

3)      On the General tab, change the Protocol logging level from Verbose back to None, click Apply and OK.

ref: http://technet.microsoft.com/en-us/library/hh184078.aspx

Turn off the scoped option on Send Connector

When a send connector has the “scoped” option enabled, the connector can only be used by Hub servers in the same Active Directory site. If it is not selected, the connector can be used by all Hub servers in the entire environment. 

You can use the EMC to configure this in Organization Configuration>HubTransport>Send Connector, right click, properties.

 

Alternatively you can adjust this in Powershell using:

Set-SendConnector <sendconnectorname> –IsScopedConnector $true/$false