Archive for 2011

Assume you are doing migration to Exchange Server 2010 and you want to move 50 Mailbox at a time rather than the default number.
Check the reference Tech Net article:
Throttling the Mailbox Replication Service

To increase the number of moves you will have to make the changes in MSExchangeMailboxReplication.exe.config file.
A) Go to all Exchange 2010 CAS Servers, open the below file in notepad or any file editor:
C:\Program Files\Microsoft\Exchange Server\V14\Bin\MSExchangeMailboxReplication.exe.config

B) Change the below values:

1. MaxActiveMovesPerSourceMDB = “50″
2. MaxActiveMovesPerTargetMDB = “50″
3. MaxActiveMovesPerTargetServer = “50″

C) Save the file and restart the “Microsoft Exchange Replication Service".

Cheers,

Description of Update Rollup 4 for Exchange Server 2007 Service Pack 3
Update Rollup 4 for Exchange Server 2007 Service Pack 3 (SP3) resolves issues that were found in Exchange Server 2007 SP3 since the software was released. This update rollup is highly recommended for all Exchange Server 2007 SP3 customers.

Update Rollup 4 for Exchange Server 2007 Service Pack 3 (KB2509911)
http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=26692

Issues that the update rollup resolves:
http://support.microsoft.com/?kbid=2509911

Cheers,

You may have noticed a change in the behavior of the Safe Senders list within Outlook starting in Exchange 2010. Users can no longer add accepted domains to Outlook’s Safe Senders list.

Figure 1: Adding an accepted domain to Outlook's Safe Senders list
This was done as an anti-spam deterrent as we have all seen cases where Joe The Spammer spoofs the mail from your own domain. Adding your own domain to the Safe Senders list would bypass all Outlook client-side anti-spam checks, dumping that message from the Nigerian prince (spoofed using your own domain) into your users’ Inboxes. Not so good unless you were really waiting for that business opportunity.
A valid SPF record and our anti-spam agents (specifically the SenderID agent) would go a long way to block these types of spam. However, many customers out there have not exactly jumped on the SPF bandwagon.
You can learn more about SenderID filtering in Sender ID and Understanding Sender ID. Use the Sender ID Framework SPF Record Wizard to create an SPF record for your domain.
With Exchange 2010, you CAN still add individual email addresses from your own accepted domains to the Safe Senders list - you just can’t add the entire domain, as shown in the screenshot above.

What happens if you DO decide to add the whole domain?

If you try to do this for a user via the Shell, you will get the very helpful error below:
“<@yourdomain.com>” is your e-mail address or domain and can’t be added to your Safe Senders and Recipients list.

Figure 2: If you try to add an accepted domain to user’s Safe Senders list using the Shell, you get an error indicating its your domain or e-mail address
We tell you exactly why we are throwing an error.
How about when a user does this via Outlook? First, Outlook lets the user add a domain.

Figure 3: Although users can add an accepted domain to their Safe Senders list in Outlook, it is automatically removed in a few minutes
However after a few minutes the entry will magically disappear.

The Disappearing Safe Senders List

In Exchange 2010 SP1, a bug was introduced where if the user added the accepted domain to his/her Safe Senders list via Outlook - not only would the accepted domain entry disappear but it would take the user’s entire safe senders list with it. This was fixed in E2010 SP1 RU3v3 where we are back to the expected behavior.

Allowing app servers to send as your own domain

Many customers have various applications that submit mail anonymously to Exchange where the messages come from email addresses from your accepted domains.
Some of you have apps submitting from so many accepted domain addresses that it wouldn’t be feasible (let alone fun) attempting to add all of these addresses individually to the safe senders list in Outlook to ensure these messages do not end up in junk mail.
Now that we can’t add the whole domain, what are our options?

• We know that adding all the addresses manually is an available albeit painful option
• A second option is to disable Outlook’s client side filtering (yeah... not a good idea, so do not seriously consider it. Spam checks out the window!)
• A third and best option is to install the anti-spam agents on your relay hub(s) and add the IPs of your app servers to the IP Allow list of the connection filtering agent as documented here.

When the sending SMTP host’s IP address is on the IP Allow List in Exchange, it bypasses all anti-spam checks (except sender/recipient filtering) and the Content Filter agent stamps an SCL of -1 on the message which Outlook will honor.
Here's what the message header will look like:
X-MS-Exchange-Organization-AuthAs: Anonymous
X-MS-Exchange-Organization-Antispam-Report: IPOnAllowList
X-MS-Exchange-Organization-SCL: -1
So, go ahead and run the Install-AntispamAgents.ps1 from the Scripts folder on your Hub Transport server, and then add IP addresses or subnets of our application servers to the IP Allow List.

Figure 4: Adding IP address or address range of internal app servers to the IP Allow List using the EMC
If using the Shell, use this command to add an IP address to the IP Allow List:
Add-IPAllowListEntry –IPAddress 192.168.10.120

What Not To Do: Using Externally Secured Authentication

Now I know what you’re thinking: Why don’t we just add Externally Secured Authentication as an authentication type on a Receive Connector, scope the connector’s remote IP range to the sending application servers and call it a day?
Well, not so fast... you see, while Externally Secured gives the sending IP the ms-Exch-Bypass-Anti-Spam extended right, this only circumvents the Exchange Anti-Spam checks, not Outlook’s. And it is Outlook that’s moving the message into junk mail in this case.
Also note that Externally Secured does not stamp any SCL X-headers on the message as an SCL of -1 would’ve bypassed Outlook’s checks. The only header this authentication type creates is the one below:
X-MS-Exchange-Organization-AuthAs: Internal
If you're still confused about Exchange and Outlook anti-spam checks, take a look at Exchange anti-spam myths revealed.

Big thanks to Tak Chow for tech reviewing this post.
Tom Kern