Saturday, May 30, 2009

Start index Office 2007 files in Exchange 2007

Do you want your Exchange server content index to understand Office 2007 file format?

Default installation of Exchange 2007 don't understand how to index office 2007 file format such as .docx files.

This can be discovered by doing a search from outlook in online mode or from OWA for words that you know is in the .docs file. If the search don’t find anything you must enable Exchange to understand office 2007 file format.

This is not difficult. start by download and install the Office 2007 filterpack. Installation is safe and do not stop any services or trigger a reboot.
After installation you must register the new iFilters in order for the Exchange content index engine to use them. This is done by editing the registry so be careful, How to register Filter Pack IFilters with Exchange Server 2007

When you have followed the article and imported the .reg file and restarted services you can try to send a e-mail with a .docx file attached and then search for some words that you know is in the word file. If everything is OK your search should find your word file.

But if your server already contain office 2007 files?
Then you can rebuild your search index on Exchange. This is easy to do. Stop some services, delete the index files and then start services again. To make this easier there is a powershell script that does exactly that. The default location is in the “C:\Program Files\Microsoft\Exchange Server\Scripts” folder and ahs the name “ResetSearchIndex.ps1

Script takes several parameters, but if you want to rebuild index for every database you can run “.\ResetSearchIndex.ps1 -force –all”.

A word of caution when you rebuild your indexes. This will cause your server to run as fast as it’s resources allow it to and this will for sure make the disks spin like crazy and CPU utilization go up a lot. This will make your user experience bad. So the suggestion is to rebuild the indexes outside business hours.

happy searching !

Wednesday, May 20, 2009

Exchange Server 2003 support shift

For you that still use Exchange 2003, Heads up!!

Exchange 2003 is now moved from Mainstream to Extended support on April 14, 2009.
http://support.microsoft.com/lifecycle/Default.aspx?p1=1773

What does this mean? Exchange 2003 is still supported for another 5 years.
Difference between Mainstream and Extended support can be found here http://support.microsoft.com/gp/lifepolicy

  • Non-security hotfix support
  • No-charge incident support
  • Warranty claims
  • Design changes and feature requests

As you can see there is not that much difference, but this is clear signal from Microsoft that Exchange 2003 life is coming to an end. This might be good time to start planning the upgrade to Exchange 2007 or Exchange 2010.

One way of still having full support is to purchase Extended Hotfix support.

Important to say is that you still have support when running Exchange 2003 as long as you pay for your incidents.

Tuesday, May 19, 2009

Why do you backup Exchange databases?

The biggest challenge with Exchange backups facing administrators today is the time factor. This factor comprises both the time necessary to perform the backup and the time necessary to complete the restore. Users want to have more data in their mailboxes; but in order to adhere to the SLA commitment, quotas must be set on users’ mailboxes. The end result? Users get frustrated from having to constantly manage their mailboxes in order to maintain a pre-set quota limit.

This situation is most noticeable if you use the old traditional streaming backup API that has been in Exchange since the beginning and is still there today. Since there has not been any active development, however, the recommended backup method is to leverage VSS (Windows Volume Shadow Copy Service). http://msexchangeteam.com/archive/2008/08/25/449684.aspx

With streaming backup API, you transfer every bit and byte of Exchange database to the backup software while performing a full backup. VSS operates a little differently. Instead of streaming the database file, it reads changed blocks from disk and then hands it over to the backup software. This procedure saves a lot of time when doing differential or incremental backups. Depending on how you configure the backup software to handle VSS, it can perform tasks such as incremental backups while keeping track of which blocks belong where. From that, an administrator can build up a complete backup in case he or she needs to do a restore. The benefit is that small backups are always done--only the restore is large and takes a long time.

When doing backups with streaming API, it automatically performs a consistency check by reading every byte of the database file. With VSS, however, you must tell the backup software to do the consistency check, otherwise you risk backing up a bad database file.

An option is to allow your backup software to integrate with Exchange and permit the storage to leverage functionality found on the storage to handle copies of LUN’s. In this case, the backup will only take a few seconds as far as the Exchange server sees it. You should still complete the time-consuming task of transferring the files located on the backup LUN to tape or other disk. This solution is dependant upon whether or not your storage is configured with this functionality and whether or not your backup software can do the integration.

No matter what backup method you use, all the backup data must be stored somewhere.

What if there was a way to have all your Exchange data spread out to multiple copies that automatically were kept in sync? With Exchange 2007 CCR together with SCR, you could make this happen. CCR is built upon a Window’s failover cluster, and data is replicated between the two nodes automatically. This produces two copies of Exchange data, and by introducing an SCR you can also introduce a third copy.

What happens if you need more? Simply add additional SCR copies. SCR are techniques that do not replay the copied transaction log files at once; they have a “lag” before doing the replay into the Exchange database. Lag time can be configured so that you can run a CCR with instant replaying of transaction log files to have two copies of Exchange data always updated. Then, you can have one SCR copy lagging behind a couple of hours and additional SCR copies lagging behind a couple of days.

http://msexchangeteam.com/archive/2006/08/09/428642.aspx http://msexchangeteam.com/archive/2007/07/19/446454.aspx

A common scenario is a user who has accidently deleted something from his or her mailbox. This delete instruction has replicated to the two CCR nodes, but the delete instruction may not have been replayed to one of your SCR copies. In this case, you can still recover the deleted mail from your SCR copy by stopping replication and then replaying the transaction log to the SCR database. Finally, mount the database and retrieve the data.

Another cumbersome task is managing the huge amount of data in Exchange. This data causes a lot of IO to the disk subsystem where Exchange has its databases and transaction log files. This is another reason to keep the databases small.

With Exchange 2007 the IO drop by 70% so you can allow the databases to grow without spending a fortune on the storage system. http://msexchangeteam.com/archive/2008/07/10/449188.aspx

So what about the idea that you run Exchange 2007 in a CCR and SCR configuration to be sure that you have multiple copies of Exchange data around? You allow users to have large mailboxes and perhaps you switch your storage solution from an expensive SAN, both money-wise and technology-wise (i.e. specially- trained personnel, fiber channel technology etc.), to a cheaper solution like DAS or iSCSI.

The benefits of this switch would include cheaper storage, meaning that users will no longer have to delete items from their mailboxes and move them into a PST file. With large mailboxes, the need for a restore is minimized and, therefore, also the need for doing backups.

But there still can be a need for doing backup and restore if your databases and disk fails. Should this happen, you have multiple copies of Exchange data already. Plus, it is a very simple process to make the other node of the cluster start acting as your Exchange server with a healthy set of data--this is in most cases done automatically. You can also manually activate the SCR copy with its own set of data.

All this information pertains to Exchange 2007, but Exchange 2010 will solve this problem with its new cluster technique, Database Availability Group or DAG for short. http://technet.microsoft.com/en-us/library/dd633496(EXCHG.140).aspx

So the question is why do you do backup of your Exchange data? Some may say that they need to store a copy of all data offsite. Although this is a good and valid reason, it will also be solved by having the SCR copy located somewhere else. It could even be on the other side of the world!
I am not saying that running without backup will suite everyone, but chances are you will discover that backups are not as necessary as you initially thought.

Tuesday, May 12, 2009

Upcoming Exchange 2007 SP2

What’s the deal you may ask, well there is a lot of new cool features in it except from the usual bugfixes.

One most requested feature is the ability to make backup of Exchange with built in tools in windows. With Service Pack 2 you get this with the Exchange Volume snapshot backup snap-in for Windows Server backup.

This is only one feature of many that are added in SP2. Read more at the You had me at EHLO blog site

The Only sad thing is that you have to wait until after the summer to get it.