Exchange/Outlook Hard-Delete

emailWhen typically working with e-mail within Outlook you will read your e-mail, and then perhaps delete it which will move it to the “Deleted Items” folder. From there, you may choose to “Empty” the folder, or you may have some automated policy to delete the contents during logoff, or other automated period. If you are using Microsoft Exchange, then it becomes available for a short period of time in the recovery of the Deleted Items folder. This time period is based on the retention settings configured in Exchange, typically 14 days.

However, there is an additional feature in Outlook called a “Hard Delete”. This occurs when you hold down the shift key while pressing the delete key. When you do this, it performs a Hard Delete. What happens is that the item is then moved immediately to the recovery area on the folder you deleted it from. It skips the Deleted Items folder all together.

What is less known about Item Recovery in Outlook is that in reality each folder has it’s own Recovery Folder, and that my default, Microsoft Outlook 2003 and prior will only show you the option (under Tools) to open the recovery folder for the deleted items folder. However, when you hard delete an item it goes into the recovery folder of the folder from which it was hard deleted from. These recovery folders are hidden by default in Outlook 2003 and prior.

In Microsoft KB246153, we see how to make a registry change to enable item recovery on every folder:
http://support.microsoft.com/kb/246153

As a side note, Microsoft recently added a feature to their support website which is called “Fix it for me” which will perform many tasks such as registry changes for you without requiring a manual edit of the registry.

Also, one final note, once an item has been purged from the recovery folder or the retention period (14 days by default) has passed, the e-mails will no longer be recoverable except via backups. And even still, if a message was received, hard-deleted and purged between backup intervals, the recoverability is next to impossible.

Exchange 2007 Distribution Lists

3d postman with envelope and bagA new default security feature in Exchange 2007 comes for Distribution Lists. In prior versions of Exchange, the default behavior was that anyone could sent an e-mail to a distribution lists. However, beginning in Exchange 2007, this default behavior was changed to be only authenticiated users were authorized to send mail to distribution lists. The rationale appears to be that the vast majority of distribution lists are for internal purposes only, and to expose these distribution lists to external senders, would essentially provide a really easy method to spam a bunch of people.

Think of it this way, does your organization use any othe following distribution e-mail addressses?

  • company@domain.com or domain@domain.com
  • staff@domain.com
  • everybody@domain.com
  • employees@domain.com or allemployees@domain.com
  • managers@domain.com or management@domain.com

However, unfortunately most of us assume that a product continues to work the way it did in prior releases. Then when the product stops working, we need to go back and figure out what we didn’t know we didn’t know. Here is the error message your external sender is likely to receive:

Delivery has failed to these recipients or distribution lists:
sales@company.com
Your message wasn’t delivered because of security policies. Microsoft Exchange will not try to redeliver this message for you. Please provide the following diagnostic text to your system administrator.

At the beginning of the detailed diagnostic message is shows:

#550 5.7.1 RESOLVER.RST.AuthRequired; Authentication required ##.

Now this example may be great, because most of your distribution groups you probably do not want exposed to external senders. However, sales might be one you do want exposed. So how do you do this in Microsoft Exchange 2007?

  1. Within Exchange System Manager
  2. Go to the distribution list’s properties
  3. Click on the Mail Flow Settings tab
  4. Double-click Message Delivery Restrictions
  5. Un-check the box “Require that all senders are authenticated”

There is no need to restart the server or any services. However it may take a couple of brief moments to take effect.

That’s all there is to it. Enjoy!

ExMerge – Archiving E-mail

ToolsWelcome to a brand new segment: Tool Tuesday!

Exmerge is an excellent tool to use when working with importing and exporting from Microsoft Exchange Server. Most documentation points to the use of this tool when migrating from one Exchange serve to another. However another excellent use is for exporting data into a PST file for archiving. While there are excellent archiving tools for the enterprise space, as well as highly recommended archiving service providers, this is a great method for small businesses who want to retain terminated employee mails in a readable format, while removing the data from the Information Store.

This tool can be run against a single mailbox or multiple mailboxes. The documentation is clear and is almost unnecessary as it is very easy to use. However, here are the two most common problems that people encounter because they don’t read the directions:

  1. When you download the tool from the Microsoft website (here), you will have an exe which will extract the files anywhere you want. You must choose the ExchSRVR/BIN for the destination. It will throw a dapi.DLL error if you don’t.
  2. If the process runs very quickly, and results in small PST files, then you likely have a permissions error: see MS KB292509

There are a couple of other common, supported and documented purposes for this tool:

  1. Brick level backup of an Exchange Server (without the added cost of a third party plug in)
  2. Extracting data from the dumpster
  3. Extracting folder rules
  4. Extracting data from a damaged Private Information Store
  5. Removing particular messages from an Information Store

And a few other uses which are a natural use for the tools, not specifically documented, but easy to figure out:

  1. Archiving older e-mails (move data from IS to PST for last year, etc)
  2. Extracting particular messages (by subject line) for litigation purposes
  3. Importing PST from a previous POP3/IMAP implementation into the Exchange Server as part of a large migration project

Enjoy!

Outlook Web Access (OWA) 2000 – Logoff Issue

3d postman with envelope and bagI recently was required to setup OWA 2000 for a client which currently has no plans or budget to upgrade to 2003/2007. And during the setup I encountered a problem I vaguely remembered from back in the 2000 era.

Basically, when using the logoff icon within OWA, you receive a http 500 error message. This is typically, although not always caused by creating a separate IIS Virtual Directory instance for OWA.

From within the properties of the Virtual Directory instance, under Home Page, be sure to Create an Application Pool, set “Script Only” access, and set to High Security.

You should be all set, however a word of caution. The OWA 2000 page is simply a page which says “you must close Internet Explorer” to really log off, and simply click this link to close your IE window. However, that’s it. If you don’t really close IE, you can simply go back into OWA without any problems or security. Also, as I recall, OWA never times out either, so by default you can leave OWA open indefinitely without problems.

Enjoy

Powered by WordPress.com.

Up ↑