Blog: Exchange Server 2007

I worked on a problem the other day in which a user with Outlook 2003 would search for an item in her inbox using a keyword in the subject of an email and the search results would come back empty even though you could clearly see items that should have been returned in her inbox. At first, I thought she just had a setting set incorrectly in her Outlook client, but after trying it with my mailbox, I saw the same behavior. I found the following powershell command VERY useful.

Test-ExchangeSearch –Identity <username>

This command inserts a test message containing a GUID into your mailbox and then searches for it to test the full text catalog. Both with accounts failed this test. Next, I tried to rebuild the index using using the following command.

ResetSearchIndex.ps1 <dbname> [more]

This command stops the MSExchangeSearch service, deletes the full text catalog and restarts the services (which then rebuilds the catalog). I found it interesting that the catalog folders and files were recreated, but the index files never grew. The catalogs for other databases/storage groups were gigs and this one was only 145 kilobytes after 2 hours which should have been plenty of time for the service to at least start crawling the database. I had tried everything I could find from google searches so I started reading through release notes for the Exchange 2k7 SP1 Update Rollup patches (there are currently 5 for SP1 and 7 for pre-SP1). I found fixes for indexing in three of them so I installed the latest one, SP1 Update Rollup 5 at the DR site and moved my mailbox. Everything worked. Moved it back and it was broken again. Pretty convincing. I installed the patch on all production Exchange servers and started another index rebuild. But, I saw behavior differently from I had seen before. When running the Test-ExchangeSearch command with no identity/username, it worked. When I used a real account it didn’t work. I also saw that the event logs said the index service was rebuilding the catalogs, but they were not increasing in size. Very strange…turns out that during a backup operation (which was running at the time when I did the second index rebuild operation), the search service will NOT start a database crawl. It waits until after the backup is done. The next day everything was running normal. Lesson learned…patch and be patient.


The iPhone currently supports the following security policies from Exchange (note: you must have Exchange Server 2003 SP2 or Exchange Server 2007 SP1 or greater):

  • Remote Wipe
  • Enforce password on device
  • Minimum password length
  • Require alphanumeric password
  • Require complex password
  • Inactivity time in mimutes

When you perform the remote wipe from Exchange, it restores your iPhone to factory default (note: this could take up to an hour).  The gotcha – after you perform remote wipe, be sure to “remove mobile device partnership” with your iPhone; otherwise, the next time you try to sync with Exchange it will wipe (restore to factory default) again . . .


Exchange 2007 introduces a concept called back pressure. This is a monitoring feature in the Exchange transport service that watches system resources like available disk space and memory. If a resources exceeds a specified limit, Exchange stops accepting new connections and messages so that it can deliver the existing messages without being completely overloaded.  Exchange starts accepting new connections and messages once resources have returned to normal levels. A large number of event log messages about the back pressure situation are logged.  We had this problem at a customer site recently and had to increase the RAM of the Virtual Machine to fix it. [more]

View the TechNet article on Back Pressure for more details.