Archive for July 2011

Re-release of Update Rollup 4 for Exchange Server 2010 Service Pack 1

Note: If you are running Microsoft Forefront, it is important to disable Forefront protection during the update:
Before running patch: fscutility /disable
After running patch: fscutility /enable


How to Increase number of Mailbox move in Exchange 2010

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".


Communicator & Lync Lync Sign-In Troubleshooting Tool Version 3.0

The OCS & Lync Sign-In Troubleshooting Tool V3.0
  1. You can download the tool here (save locally, unzip, and run on a Windows client).
The OCS & Lync Sign-In Troubleshooter helps diagnose Microsoft Office Communicator and Lync clientsign-in issues.
1] DNS Information.  The tool queries for the DNS SRV and A records used by the Communicator or Lync client to automatically locate the OCS or Lync server. It queries the DNS server (as configured on the client machine) and displays the results for the following DNS records:
  1.  _sipinternaltls._tcp.<>
  2. _sipinternal._tcp.<>
  3. _sip._tls.<>
  4. _sip._tcp.<>
  5. sipinternal.<>
  6. sip.<>
  7. sipexternal.<>
The preferred DNS match (that the client will first attempt to use) is then highlighted in the results.
2]  Test Port Availability.  A user can click on any of the DNS sign-in records that returned a match (resolved on the client) and then test the connectivity of the hostname and port associated with that DNS record.
3] Remotely Retrieve Certificate Information.  A user can click on any of the DNS automatic sign-in and remotely retrieve the X509 Certificate information if the port is secured using TLS (or SSL).  Certificate information returned includes the Common Name (CN), Subject Name, Issuer, Certificate Authority, Expiry Date, Creation Date, and Subject Alternative Names (SANs).
4] The tool also retrieves and displays the Installed Version of the Office Communicator or Lync client.

To Use
  1. Click on the Download link and save the file on the client computer where the Lync or Office Communicator client is running.
  2. Extract the MOCLogin.exe file.  Right-click | Properties | “Unblock” it.  Double-click it to run the tool.
  3. Enter a SIP address or SIP domain name, and press Go.
  4. Optionally select a matching DNS record result and test the port connectivity or retrieve the certificate information.
This tool is offered on a best effort basis by Curtis Johnstone. No formal support or warranty is offered, implied or intended.
Tested On
Microsoft Windows XP, Vista, 2003, Windows 7, and Windows 2008 with the latest Service Pack’s (as of July 2011).  The only language it was tested with is English.
 This tool is Copyright © 2011 Curtis Johnstone and cannot be distributed without explicit permission.
Screen Shots
Main DNS Queries (Example)
Certificate Information (Example)


Error code 0X80004002 while doing In-Place upgrade from Exchange 2003 Standard to Enterprise

It's been long time I worked on Exchange Server 2003. I got a chance to work on it this week and it's interesting. Client had Exchange 2003 Std edition and database crossed the 75 GB limit.
The good part was that client got this issue on weekend, hence there were no issues in production.
After long discussion we decided that migrating to Exchange 2010 won;t be possible due to the budget (as if now) hence he asked for the alternate resolution. After checking the event 1221 for Mailbox and Public Folder Store we found that there  is nothing we can achieve even after running the Defragmentation.

We decided to do In-Place upgrade from Standard to Enterprise.The good part is, client had the licensing for Enterprise(I don't know why didn't they installed Ent. edition).
Started the upgrade and it failed. Check the application log and found the below event id.

Event Type: Error
Event Source: MSExchangeSetup
Event Category: Microsoft Exchange Setup 
Event ID: 1002
Date:  7/10/2011
Time:  10:21:37 AM
User:  N/A
Computer: 2003
Exchange Server component Microsoft Exchange Messaging and Collaboration Services failed. 
Error: 0xc107041d - 0xc007041d - The service did not respond to the start or control request in a timely fashion. (EXIFS) 
For more information, click 
Checked the ExchangeSetupLog and got the error:

CComBOIFacesFactory::QueryInterface (d:\jtrs\admin\src\udog\bo\bofactory.cxx:54)
           Error code 0X80004002 (16386): No interface.

After doing little research I found that it's EXIFS which need's be corrected in the registry. 
Changed the value from 2 to 3 on Start key at the below location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\EXIFS\Start
After changing the registry value continued the upgrade and it completed successfully.

Installed SP2 on the server. Restarted the Exchange Server and checked the application log for event  ID 1217 for Enterprise edition and it was present, which says that server has been successfully upgraded to Enterprise edition.

Checked the Mailbox Store and Public Folder Store and they mounted successfully. Created New Mailbox Store without any issue.


Released: Update Rollup 4 for Exchange Server 2007 SP3

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)

Issues that the update rollup resolves:

Accepted Domains, Safe Senders List and You

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.
Screenshot: Adding an accepted domain 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:
“<>” 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
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