November 28, 2012

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:





 

November 27, 2012

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



November 17, 2012

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


 

November 16, 2012

Mailbox folder permissions



After migrating a Manager and their admin from Lotus Notes to Exchange, there can be some problems experienced with the level of delegate permissions that translate across.

In one case a user on Lotus Notes had "Author" rights which means they have the ability to delete items from their managers calendar. However when they have "Author" access when they are in Outlook, this means that they do not have permission to delete from their managers calendar.

The solution is to apply "Editor" rights to the delegate in Powershell as below:

To view current permission status on a managers account:
get-mailboxfolderpermissions -identity  <the managers id>


To  view the permission status on a managers folder (in this case the calendar)
get-mailboxfolderpermissions -identity <user>:\calendar

To add a users rights
Add-mailboxfolderpermissions -identity <user>:\calendar -accessrights editor -user <adminusername>
To give the admin "Editor" rights on the managers folder:
set-mailboxfolderpermissions -identity <user>:\calendar -accessrights editor -user <adminusername>

"Editor" rights is just for this example, there are of course other levels of permission available, with "owner" rights being the highest permission available.