A while back I wrote about named properties and how they could make your databases run out of rows i a table and crash. http://anewmessagehasarrived.blogspot.com/2008/10/named-properties-bloat.html
Rollup 8 for Exchange 2007 service pack 1 changes the behavior a bit and does not propagate x-headers for unauthenticated mail and the upcoming service pack 2 will not even propagate x-headers for authenticated mail. The same goes for Exchange 2010. http://msexchangeteam.com/archive/2009/06/11/451596.aspx
I personally would like an on/off switch for this behavior in order for people to configure this as they please. As stated on the msexchangeteam blog, there could be applications that rely on these properties.
Thursday, June 18, 2009
Thursday, June 11, 2009
Thinking about Exchange 2010? Understand the Prerequisites
Even though Exchange 2010 is not a finished product yet, it seems kind of strange discussing a transition to it at this stage, but there are some things that you should know if you are planning on upgrading your current Exchange environment to Exchange 2010 in the future.
Active Directory Prerequisites:
First there are requirements on Active Directory. All Domain Controllers must be running at least Windows Server 2003 SP2 in sites where you want to deploy Exchange 2010 servers. In addition, your Forest must be at a Windows 2003 functional level.
You can have Domain Controllers running Windows Server 2008 and even RODC, but Exchange will not use them. Domain Controllers should preferably run 64 bit version of Windows to run smoother and better handle the load from Exchange and other clients.
Exchange Prerequisites:
Your current messaging infrastructure cannot have any earlier release then Exchange 2003. If you do, you must first upgrade/transition to at least Exchange 2003.Exchange 2003 must be least Service Pack 2 and Exchange 2007 servers must also be running Service Pack 2 for Exchange.
So you can meet all the prerequisites by upgrading your Exchange servers to 2003 Service Pack 2 and then upgrading all your Global Catalog servers to Windows Server 2003 Service Pack 2.
Other notable items:
Exchange 2010 only runs on a 64 bit architecture. In fact, unlike Exchange 2007, there is not even a 32 bit demo or lab version.
In addition, Exchange 2010 will only work on Windows Server 2008 or Windows Server 2008 R2.
You must also apply schema updates to the Active Directory.
How to make the transition:
The transition begins with building the Exchange 2010 environment in parallel with your current Exchange environment, starting with your sites that are facing Internet. The reason for starting at the internet facing site is that you must start by, not replacing, but standing up a new CAS server, similar to what you did when introducing Exchange 2007. The big difference here is that Exchange 2007 CAS servers can proxy requests going to Exchange 2000 and 2003 backend servers but Exchange 2010 CAS servers cannot and will only send a redirect back to the client to the old Exchange 2003 Front End or Exchange 2007 CAS depending on where the mailbox is located. This means that you cannot replace your current Front End or CAS server, you must live with both the old and new system together as long as you have mailboxes located on old servers. Another thing you must do is to copy your current certificate to your new Exchange 2010 CAS server and get a new one and place it on the old Front End or CAS server. You will then have, for example, a certificate with the name of “mail.domain.com” on Exchange 2010 CAS and “legacy.domain.com” on the old Front End or CAS server.
When users connects to Exchange 2010 CAS and have authenticated, Exchange will know where the mailbox is located and if it is on the legacy Exchange it will send a redirect to the client to connect to the legacy URL that you configure. If the mailbox is located on Exchange 2010 everything is good and no redirection take place.
To make your life simpler, you should consider consolidating your namespace to only one name otherwise the transition will be more troublesome with more URL and certificates to deploy. Another important consideration to keep in mind is that you will need an extra Internet IP addresses during the transition.
Unified Messaging servers behave the same as CAS servers do, they do a redirect to the old UM server. So make sure that you send the initial SIP communication to Exchange 2010 UM server, and it will redirect if needed. This is true if you don’t have OCS connected to UM, in this case you need to create a new dial plan and assign it to the Exchange 2010 UM server.
An Exchange 2010 HUB server will not talk to an Exchange 2007 mailbox server but will be able to send mail to Exchange 2007 HUB that in turn can communicate with the old mailbox server. To make this work you also need extra HUB server, since the old ones must be around as long as you have legacy mailboxes.
Your existing mailbox servers obviously will have to remain in parallel, since both sets of servers have to be running, to move mailboxes in between them. Legacy mailbox servers can be uninstalled when they don’t have any mailboxes located on them. One of the cool new features in Exchange 2010 is the Online Move Mailbox. This allows administrators to move a mailbox without the user being disconnected during the process until the last minute when all mail have been replicated and Active Directory replication takes place. Online Move Mailbox is possible between Exchange 2010 server and from Exchange 2007 to 2010.
The only server you can replace is the Edge role and this can happen anytime during the transition, as long as you subscribe it to an Exchange 2010 HUB server.Be aware that all of these steps don’t work in the current public beta, but they will work when Exchange 2010 goes RTM sometime later this year. Also please remember as tempting as it might be, you should not put in the current beta in your production environment.
Active Directory Prerequisites:
First there are requirements on Active Directory. All Domain Controllers must be running at least Windows Server 2003 SP2 in sites where you want to deploy Exchange 2010 servers. In addition, your Forest must be at a Windows 2003 functional level.
You can have Domain Controllers running Windows Server 2008 and even RODC, but Exchange will not use them. Domain Controllers should preferably run 64 bit version of Windows to run smoother and better handle the load from Exchange and other clients.
Exchange Prerequisites:
Your current messaging infrastructure cannot have any earlier release then Exchange 2003. If you do, you must first upgrade/transition to at least Exchange 2003.Exchange 2003 must be least Service Pack 2 and Exchange 2007 servers must also be running Service Pack 2 for Exchange.
So you can meet all the prerequisites by upgrading your Exchange servers to 2003 Service Pack 2 and then upgrading all your Global Catalog servers to Windows Server 2003 Service Pack 2.
Other notable items:
Exchange 2010 only runs on a 64 bit architecture. In fact, unlike Exchange 2007, there is not even a 32 bit demo or lab version.
In addition, Exchange 2010 will only work on Windows Server 2008 or Windows Server 2008 R2.
You must also apply schema updates to the Active Directory.
How to make the transition:
The transition begins with building the Exchange 2010 environment in parallel with your current Exchange environment, starting with your sites that are facing Internet. The reason for starting at the internet facing site is that you must start by, not replacing, but standing up a new CAS server, similar to what you did when introducing Exchange 2007. The big difference here is that Exchange 2007 CAS servers can proxy requests going to Exchange 2000 and 2003 backend servers but Exchange 2010 CAS servers cannot and will only send a redirect back to the client to the old Exchange 2003 Front End or Exchange 2007 CAS depending on where the mailbox is located. This means that you cannot replace your current Front End or CAS server, you must live with both the old and new system together as long as you have mailboxes located on old servers. Another thing you must do is to copy your current certificate to your new Exchange 2010 CAS server and get a new one and place it on the old Front End or CAS server. You will then have, for example, a certificate with the name of “mail.domain.com” on Exchange 2010 CAS and “legacy.domain.com” on the old Front End or CAS server.
When users connects to Exchange 2010 CAS and have authenticated, Exchange will know where the mailbox is located and if it is on the legacy Exchange it will send a redirect to the client to connect to the legacy URL that you configure. If the mailbox is located on Exchange 2010 everything is good and no redirection take place.
To make your life simpler, you should consider consolidating your namespace to only one name otherwise the transition will be more troublesome with more URL and certificates to deploy. Another important consideration to keep in mind is that you will need an extra Internet IP addresses during the transition.
Unified Messaging servers behave the same as CAS servers do, they do a redirect to the old UM server. So make sure that you send the initial SIP communication to Exchange 2010 UM server, and it will redirect if needed. This is true if you don’t have OCS connected to UM, in this case you need to create a new dial plan and assign it to the Exchange 2010 UM server.
An Exchange 2010 HUB server will not talk to an Exchange 2007 mailbox server but will be able to send mail to Exchange 2007 HUB that in turn can communicate with the old mailbox server. To make this work you also need extra HUB server, since the old ones must be around as long as you have legacy mailboxes.
Your existing mailbox servers obviously will have to remain in parallel, since both sets of servers have to be running, to move mailboxes in between them. Legacy mailbox servers can be uninstalled when they don’t have any mailboxes located on them. One of the cool new features in Exchange 2010 is the Online Move Mailbox. This allows administrators to move a mailbox without the user being disconnected during the process until the last minute when all mail have been replicated and Active Directory replication takes place. Online Move Mailbox is possible between Exchange 2010 server and from Exchange 2007 to 2010.
The only server you can replace is the Edge role and this can happen anytime during the transition, as long as you subscribe it to an Exchange 2010 HUB server.Be aware that all of these steps don’t work in the current public beta, but they will work when Exchange 2010 goes RTM sometime later this year. Also please remember as tempting as it might be, you should not put in the current beta in your production environment.
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.
Subscribe to:
Posts (Atom)
