Thursday, December 11, 2008

How long does it take for an Exchange 2007 Transport rule to re-check a group membership?

Exchange 2007 Transport rules are a GREAT feature to control mail flow for business and security reasons. One of my favorite uses is to base a rule on group membership. Unfortunately, the first time I tested this, I was making a rule to block Internet Email from members of the "No Internet Email" group. I created the group, added myself, and created the rule.

It worked flawlessly, and I then removed myself from the group. Then I tested again and found I still got a bounce error from the rule firing.

I found out (quickly) that restarting the transport service fixed this, but I never did find the reason why this was occurring.

Then I found this article that explains it all:

"Each Hub Transport server maintains a recipient cache that is used to look up recipient and distribution list information. The recipient cache reduces the number of requests that each Hub Transport server must make to an Active Directory domain controller. The recipient cache updates every four hours. You can't modify the recipient cache update interval. Therefore, changes to transport rule recipients, such as the addition or removal of distribution list members, may not be applied to transport rules until the recipient cache is updated. To force an immediate update of the recipient cache, you must stop and start the Microsoft Exchange Transport service. You must do this for each Hub Transport server where you want to forcibly update the recipient cache."

So in short, testing can be unpredictable because once the transport rule fires on a DL membership rule, it caches that membership for 4 hours.

Saturday, December 06, 2008

Hyper-V - Code 12 on Virtual Machine Bus and Integration Tools not working

Stumbled upon this and found the fix here:

(2/29? Yea, so this is OLD news, but a nice fix either way!)

Was getting this error:


Monday, December 01, 2008

Performing an Exchange 2007 mailbox restore using Backup Exec 12.5

  1. Create the recovery storage group using the Exchange Management Console's toolbox. Confirm you will have enough disk space to do the restore to the drives it chooses!
  2. If you run the "restore wizard" in Backup Exec 12.5, it doesn't prompt for redirection options. However, Exchange 2007 by default will find and use a RSG for you. If there is not an RSG, the job will fail.
  3. I used the non wizard in the screenshots below to create a Restore job, selecting the Exchange Storage group and Database to be restored, and choose the RSG redirection as well as unchecking the "commit after restore" (the restore will work either way, I just like manually mounting stores) Remember, you do NOT need to restore all databases, only the one you want data from!

  4. Mount your RSG database

  5. Launch the Exchange Recovery Toolbox again, and it's now time to "Merge or copy contents"

  6. Here is where I found a very ODD issue. As you can see above, the DMNotify mailbox is in the High limit store, and this is the one I restored from. However, When I go to merge data, the Staff and High limit DB's are flip flopped. So even though Backup Exec 12.5 restored the data, when I go to mount the databases, the high limit is 2gb (empty) and the staff is 17GB (the size of my data restored)

  7. However, I was still able to merge the mailbox I wanted out by choosing the Staff DB

  8. Mail data was all successfully restored!