|
Tuesday, April 27, 2010
Introducing the new ESE Consultants' Corner
Welcome to the first edition of the ESE Consultants’ Corner! The ENow Solutions Engine is dedicated to helping the greater Microsoft community by providing an online resource of free articles, video tutorials, and advice on the hottest topics in Microsoft technology today. Instead of us always choosing the topic, we wanted to spice things up a bit. Our ESE writers are renowned experts in their fields, so we want you to put their knowledge and experience to the test!
Our writers consult on a daily basis, and constantly receive calls from either customers or colleagues asking about Exchange, Active Directory, Virtualization, Cloud computing, etc. Some of the questions they encounter are common, but others at times are very weird. The ESE Consultants’ Corner is devoted to answering only the really cool questions our writers get asked on a daily basis. We will share with you their answers to the common questions and the not-so-common ones, so that you can benefit and learn from their expertise. The ESE Consultants’ Corner will be devoted to covering a broader range of topics as well as addressing questions that require fast answers. We want to hear from you! Do you have an advanced technical question that you need answered? Do you have a design or planning issue that you want expert input on? Please send your questions to: ese@enowinc.com. This will give you access to the ESE experts and allow you to ask them questions directly. If we encounter a really tricky question, then we might devote an article to it. The rules for submission are simple:
We want you to have a say in the topics we discuss, so email us your questions today! Before we begin the Consultants' Corner, please note Mahmoud's Magdy's updated OCS-DNS calculator below.
The key to a successful Office Communications Server Deployment: The Errata and new OCS-DNS Certificate Calculator By: Mahmoud Magdy I have received lots of feedback regarding the OCS-DNS certificate calculator. Since there was some confusion, I have written this errata for clarification and also made some corrections to the calculator to make it clearer. Please note the following: - You can use the calculator with OCS 2007 R2 only. You cannot use it with OCS 2007 as we have not tested it against 2007. There are no plans to test it in the future, but it might be something we pursue further down the road.
- You can use the calculator for Exchange 2007 and 2010 deployments; there are no differences between both products in regards to the certificate requirements.
- For HLB (hardware load balancers) the calculator will work if you assigned the edge FQDN to the VIPs. It has been tested and will work very smoothly.
- To generate certificate request, use the OCS installer to create the certificate using the certificate wizard, then copy and paste the names generated by the certificate calculator into the certificate wizard.
- Make sure to import the certificate on the same server you generated the certificate request from and export it along with the private key. This is mandatory to be able to assign the certificate to other servers.
We have uploaded a new version of the calculator that has the following fixes: - If you are using a certificate for Exchange and OCS, the certificate common name must be sip.domain.com or whatever the FQDN that will be assigned to the edge access and web conference. (This is a limitation that comes from the OCS that has been fixed in the current release.)
- If you cannot make the certificate common name the Edge Access FQDN, then you can use a separate certificate for the Access Edge and Web Conference Edge.
- We removed the web conference FQDN selection, since it has to match the FQDN assigned to the access FQDN.
- We added port feature, so now you can assign a port and this will help in configuring the web conference edge.
http://support.enowzone.com/Downloads/OCS-DNS-Certificate-calculator-V1.5.xlsx Credentials
Username: enowzone\freetrial
Password: H3althCh3ck First Consultant’s Corner post: By: Mahmoud Magdy Hello! My name is Mahmoud Magdy and I am honored to be hosting the first ESE Consultants’ Corner. For this edition’s post, I chose to answer several questions I recently received that will benefit our readers the most. Q: I am sending a large amount of emails per day and I am afraid of being listed as a spammer. What are the rules regarding spam? A: You may rest easy because you will not be listed as a spammer just because of the large amount of emails you send. In fact, you will not be listed if you send a single spam email to as many as 1,000 or more recipients. The general rule of thumb regarding spam is this: being listed as a spammer is not related to the amount of email you sent, but rather the content of the emails and to whom they are sent. If you are simply sending advertisement emails to your customers then you will not be listed, but if you send advertisements to a mailing list that you don’t own then you are busted. However, if your email system that is sending these types of messages is not secure and properly configured, then you will be blocked. The most common errors include DNS mis-configuration, SMTP banner and FQDN, and SPF solution, among many others. Q: We have an internal application that sends emails using our internal relay connector. Will these emails be listed as spam? A: For the general rules, please see the answer above. In regards to your particular situation: 1. I recommend that your application uses an email address that exists inside your organization 2. Try your best to authenticate the SMTP connection using your application; this will create an authenticated SMTP connection to your relay and it will be safe. Q: My storage guy is doing a RAID X implementation because he told me this is the best option for my storage and Exchange deployment. Do you agree with him? A: Let me preface this by saying that storage guys usually don’t like me. They are very professional and their work is very scientific, so when an Exchange guy comes in and tells them ‘This is how we should do storage,’ it does not go over well with them! I recommend that you design your Exchange deployment using the Exchange storage calculator or your vendor’s calculator, and ask then storage guys to give you IOPs. Don’t worry about the RAID type as long as you get the required performance. Of course your must determine if the deployment option is the most cost effective method and will provide optimum performance. Storage guys really are the best people to tell you how to design your storage, but again make sure you ask for IOPs and not RIAD. Q: I bought a server with 24 cores, but I heard that Exchange will not benefit from it. What I shall do? A: Multi role deployment works well with 24 cores, and can even reduce issues without using the WSRM (Windows Server Resource Manager.) The problem is more with single role deployment and cross talk, but I must warn you that there is a catch: Microsoft testing shows when environments are sized according to Microsoft current guidance, multi-role systems perform fine without WSRM. (I will put a caveat on this by saying that most of the testing was done on 8-12 core systems.) 24 core systems have been low priority, so if Microsoft does not have a linear scale then these systems may benefit from WSRM. One other thing to be aware of with 24 core Intel systems is that most of the hex core (Dunnington) processors are over 1.5 years old. Until the processor vendors release the next round of 4 socket large core processors, you may be better off running a 2 socket Nehalem quad core system over a 4 socket hex core system. Example: In conclusion, today you can run a higher number of mailboxes on the newer 8 core servers than older 24 core servers. I hope our first edition of the ESE Consultant’s Corner was helpful for you. What challenges are you facing in your environment? Need an expert opinion on an upcoming project? Feel free to email us your questions at ese@enowinc.com. I look forward to hearing from you. Until the next post, wishing you faster processors and bigger RAMs… Mahmoud Labels: Exchange Support, Exchange Tips, Office Communications Server R2
Tuesday, April 13, 2010
Exchange 2010 Site Disaster Recovery on a Dime! Part 2: Navigationg the Failover Process
By: Lasse Pettersson, Exchange MVP
In Part 1 of this series I explained how to build a low cost site or datacenter disaster recovery solution using Microsoft Exchange’s new DAG feature. In this article, I will endeavor to explain what manual steps are required to failover to your other site in the event of a disaster.
First of all let’s discuss what types of problems can occur. There are a variety of problems that can happen ranging from simple disk failure to a tornado smashing the datacenter in the primary site. In this article, I would like to address how you would manually activate your backup Exchange server if your primary server’s mother board or disk failed. Next, I will outline the steps to take if you experience the dreaded total site failure. Finally, I will conclude with how to fail back to your primary site when everything returns to normal.
OK, so how do we recover from for example a motherboard failure?
If you find yourself in this situation, you can be sure that your primary Exchange server will be offline and not functional. The good news is that in this situation all your other core infrastructure will be up and working, including critical items like your domain controllers and DNS servers.
The first thing you will notice is that your Outlook clients will still try to connect to the original MAPI endpoint (RPC Client Access Service located on CAS). To quickly rectify this situation, simply change the A record in DNS for the ClientAccessArray to the IP of CAS in the DR site. The Time To Live on this record should be a couple of minutes making the change to a new IP as fast as possible. Another thing you should also consider is the time it takes for DNS replication/updates to propagate throughout the network.
Next it will be time to get the databases up and running on your DR server.
First verify that all Exchange services are running on the DR server. If the services have been turned off this could cause other problems with transaction log replication.
The easiest step is to move all active databases from the primary site to be activated on the DR site. The following command should be run on a server in the DR site, most likely from the Exchange server.
First remove the activation block on mailboxes in the DR site.
Resume-MailboxDatabaseCopy 'mailbox database name\FQDNofaServerinDRSite
Perform this step on every mailbox database you want to activate. There is a chance that databases will mount automatically when resuming mailboxdatabasescopies. You can verify status by running Get-MailboxDatabaseCopyStatus on Exchange server in DR site.
Get-MailboxDatabaseCopyStatus -server FQDNofaServerinDRSite fl Name, Status, ActivationSuspended, ContentIndexState, Activecopy
If databases are mounted and the ActiveCopy is True, then you are done with the activation and outlook should now be able to connect and start receiving and sending mail internally. Next reconfigure services and applications to make Exchange reachable from Internet with SMTP, Outlook anywhere, OWA, Active Sync etc. If you have ISA or other reverseproxy server, reconfigure it to the server in the DR site instead of the server in the primary site. Other services that might need to be reconfigured are autodiscover and InternalUrl in several IIS virtual directories.
If mailboxes don’t mount correctly, you can manually run the following command:
Move-ActiveMailboxDatabase –Server FQDNofaServerinPrimarySite –ActivateOnServer FQDNofaServerinDRSite
Depending how Windows and Exchange managed to handle the crash you might encounter some errors, making the activation a little more difficult. Things that might happen range from the index is not up to date on the DR server or all transaction log files have not been copied to the DR server. The solution is to specify some extra parameters on the Move-
ActiveMailboxDatabase command.
For example, -SkipClientExperienceChecks is good to use when index is not up to date.
If you have not configured AutoDatabaseMountDial on the mailbox server, by default it is set to lossless and there is always a chance that replication have not copied all transaction log files to DR server, then you have to use the –MountDialOverride with a parameter such as BestAvailability or GoodAvailability.
Other parameters that might be needed are –SkipLagChecks or –SkipHealthChecks. You might have to use several parameters together to get databases up and running.
Move-ActiveMailboxDatabase –Server FQDNofaServerinPrimarySite –ActivateOnServer FQDNofaServerinDRSite –MountDialOverride:BestAvailability –SkipLagChecks –SkipHealthChecks -SkipClientExperienceChecks
More information about Move-ActiveMailboxDatatabase is found on Technet: http://technet.microsoft.com/en-us/library/dd298068.aspx
When you have replaced the motherboard on Exchange server in the primary site and replication starts going from the DR site to primary site, you’re good and it’s time to plan the switchover to the primarysite. This is done with the same step as above. Plan the switchover to a time during off hours since the switchover will take a couple of minutes due to the necessary DNS updates, AD replication and time it takes to run the commands above.
Finally, you should run the Suspend-MailboxDatabaseCopy again to disable automatic activation of databases in DR site.
Suspend-MailboxDatabaseCopy -Identity 'Mailbox Database 2036433681\FQDNofServerInDRSite' -ActivationOnly –Verbose
This last step is needed because activation is reset when you do a switchover between servers. Be sure to remember to do this for every mailbox database on your servers.
If you can’t get things started on Exchange in the primary site due to problems with corrupt database or transaction log files, you might have to reseed files from the server in DR site. Use the Update-StorageGroupCopy and possibly with the –DeleteExistingFiles parameter.
Recover from a disk failure is pretty much the same as above but it only involve databases and transaction log files located on the faulty disk. Another cool thing is that you can even test a database switchover in production. To do this, first create a database in the primary site and make a copy in the DR site the same way all the other databases were created. Next create a mailbox in the test database, logon and send some test messages back and forth. Activate the test database on the DR server, edit the hosts file with the FQDN of the CASarrayname and the IP of Exchange in DR site and start outlook again. You should now be able to connect with Outlook to the DR server and use outlook the normal way with disturbing any other users.
Recover from a disaster in the primary site.
This is more problematic scenario, but the steps are basically the same as above. The slightly more complex steps are caused by the fact that you don’t have any servers or network connectivity in the primary site and that your cluster will not have access to its quorum, and as a result it will be in a failed state.
How do you solve this problem?
First you need to make your cluster working.In the DR site, stop the failover cluster service if started and the start it again with the forcequorum switch.
net start clussvc /forcequorum
The next step is to active all databases on the DR server. This is done in the Move-ActiveMailboxdatabase command the same way as before.
You may also have to manually mount the databases.
With a complete site failure in the production site you most likely need to live with the DR site for a while which calls for more actions than just getting your Exchange server up and running.
You also need to get traffic to and from Internet flowing, both mailflow and user access to Exchange. Autodiscover is your friend to update configuration in outlook, so make sure you have configure all URL’s correct.
Overall there is a lot more to reconfigure than just Exchange to do a site failover.
http://technet.microsoft.com/en-us/library/dd351049.aspx
How do you fail back to your primary site after the disaster?
We have forced quorum on our cluster and if we restart the cluster service or reboot the server, the cluster service will fail to get quorum. This is important when servers go online in the primary datacenter since we don’t want to have a forced quorum in the secondary site when servers startup in the primary site.
If everything wasn’t that bad and we could simply power up everything in our primary site, replication should start working again.But you have to do some things like, reconfigure your File Share Witness, restart cluster service on secondary Exchange server, and basically all steps we did to move everything to secondary site but now change everything to point to our primary site again. But don’t rush things here, let Active Directory get to a stable state first and then slowly move things back to normal.
Depending on what state servers are in and what happened you may not want to start Exchange in primary site, but remove it from DAG and rebuild Exchange, join it to DAG etc.
As you have probably noticed, there are lots of variables and therefore it is not easy task to write a step by step guide on what to do for every situation. It would be recommended to write out the basic steps and your configuration information to make the transition easier when you are dealing with the stress of the situation. The best tip I can give to all of you is to learn how things work and play with the various scenarios in a lab. The experience you gain from this will be your best friend when the unexpected happens in real life.
Labels: Exchange 2010, Exchange Tips
Tuesday, March 30, 2010
All for one and one for all: The key to a successful Office Communications Server Deployment
By: Mahmoud Magdy
One of the key factors to ensuring a successful Exchange/OCS deployment is that the certificates and DNS configurations must be setup correctly. I can say that more than 90% of the issues I troubleshoot in Exchange/OCS implementations can be traced back to Certificates and DNS issues.
Exchange and OCS heavily rely on Certificates as a key element of secure infrastructure deployment by using MTLS and TLS. The challenge is that implementing the certificate is confusing and comes with a price.
In this post we will investigate how to overcome these challenges and how you can use a single certificate for our Exchange/OCS deployment. Let us cut to the chase and go to the cool stuff.
Exchange and SSL -- an old story I have to tell:
Exchange started using SSL certificates when Exchange 2003 was introduced. At that time things were simple. To implement the certificate, all you had to do was create a certificate with a single name, for example (mail.domain.com), where it resolved to the External IP that was Nat’d to the Front End Server IP or Virtual IP if you were using several FEs.
As we all know, implementing certificates in Exchange 2007/2010 is more complicated and cumbersome. Now we have your standard mail.domain.com and the new introduced autodiscover.domain.com to deal with. This change also created the need for UCC certificates.
UCC certificates allow multiple names to be included in the certificate. This type of certificate is commonly called a SAN (Subject Alternative Names). For those of you who have worked with ISA 2004 or 2006 this may recall some nightmares as these certificates were not supported.
In order to publish a website over SSL, the “to” field in the ISA publishing rule had to match the certificate’s common name or (subject name), or you would get the famous (the targeted principle name is not correct) error. So we had to use 2 certificates in order to work around that, or use a single certificate, but not use ISA to publish Exchange websites. What a headache!
OCS 2007 R2, like if Exchange is not enough:
When OCS 2007 R2 was introduced, more changes also needed to be taken into account. In OCS 2007 R1, Microsoft decided to use MTLS for server to server communication and TLS for server to client communication. This meant that you needed to use an internal Certificate Authority (CA) in order to issue certificates for internal servers. Implementing remote access solutions in OCS was not as simple as it was in Exchange because it did not work with internally issued Certificates. In addition, OCS required DNS entries internally that is different than your external DNS records. Is your head spinning yet? Let’s take a closer look at internal DNS records used for a typical OCS 2007 R2 Deployment:
 Please note that Those IPs will be VIPs if you use HA deployment. They will be created using HLB (hardware load balancers) since OCS doesn’t support MS WLB.
Note: You can change comp.domain.com to any name you want, just make sure to enter that name in the setup or modify it using LCSCMD command line tool.
Now let us take a look at the external DNS records used by OCS by an external User:
 Keep in mind that SIP is used for Edge client access, webcon and AVconf are sample DNS entries that could be changed as they are not hard coded.
Combine it all with Certificates:
Now you have a table that lists all of the DNS names that is required, all you need to do is pull a certificate for each name (duh, that is why I am here writing this post, we want them all in one certificate). You can use single certificate, but let us see first the names that I will need to include in the certificate:
 The above table list all the names required for OCS and Exchange, but there are 2 catches here:
- SAN certificates are not supported by ISA2004/2006 for SSL publishing, you will have to use ISA 2006 SP1 or TMG since this issue were fixed in both versions.
- If you use single certificate for Edge web conference and Edge Access, you will find that Edge server requires that names must be matched between Access/web conference IPs (you will note that in the edge server configuration wizard, you will be able to change the name, but it will not take effect), so the name must be matched, thus the same IP must be used so you will have to change the ports between access and web conference (in typical configuration Access/Web conf will use port 443, since OC clients are hard coded to try to use port 443, so you will have to change the web conf port to any other port, use 444 for simplification).
The final note has 2 catches: - 444 is a non standard port so you might have to adjust your firewall.
- If you want to use port 443, then use a separate certificate for the Web Conference edge server IP.
You might wonder how I can change the port of the web conference without affecting the information worker, well the following diagram elaborates how web conference tokens are created:
 The story begins when an external user clicks on the conference link (this external user is either domain user or anonymous user), then the following occurs:
- The users access the Access Edge server and to get authenticated (Kerberos, NTLM for domain users or digest for anonymous users).
- The front End server component contacts the web conf server component, AV component, Web component to add the user to the WEB MCU and AV MCU.
- Pay attention in this step please, the user gets back an authentication token and configuration cookies that has the web conf edge/AV conf edge configuration and this is where the client gets notified about the ports used by the edge servers.
So as you can see web conf and AV conf ports are not hard coded, but are passed to the user in the config tokens. Please note the web conf, front end and AV conf servers are located in the same box, but they were separated to elaborate how they work internally. Avoid this common mistake: One of the most common mistakes that we encounter in OCS implementations is seeing the FQDN for the AV authentication server and the port set to 443. This is not correct and will result in calling errors on the Office Communicator client. Please make sure that the AV authentication service uses port 5062. Now after tons of notes, let’s make our final names table:  If you follow the suggestions listed in this article you will be able to use a single certificate for Exchange and OCS. Please note that I did not cover the internal edge certificate and pool certificate names as they are fairly simple to implement.
To help you, I have created my own Exchange/OCS certificate and DNS calculator. Please note this calculator is not supported by Microsoft and you should verify your configuration with a professional OCS/Exchange consultant. The calculator is very simple to use. All you will have to do is enter the OCS sip domain, host names used by edge server, OCS server type either (standard or enterprise) and DNS names and the certificate configuration will be created for you automatically. To download the calculator, please use the link and credentials below: Exchange/OCS Calculator: http://support.enowzone.com/Downloads/OCS-DNS-Certificate-calculator-V1.4.xlsx
Credentials:
Username: enowzone\ese Password: Tool4you
I hope that in this post I was able to help you out in your deployment and eliminate the confusion caused by using a single certificate for OCS and Exchange. Have a nice deployment and see you next time . . . !
Labels: Exchange Support, Exchange Tips, Office Communications Server R2
Monday, March 15, 2010
Migrating to Exchange 2010 Part 1: Preparing your Exchange environment
By Ismail Mohammed
Thinking about migrating to Exchange 2010? Wondering what you need to do to get your environment prepped for the big leap? This article series will teach you everything you need to know before upgrading to 2010.
In Part 1 of this series, you will receive step-by-step instructions for utilizing the Exchange Server Deployment Assistant – a very helpful pre-installation utility from Microsoft that will ensure you are ready to migrate your messaging platform. This tool will be used during the pre-deployment phase to ensure that you are considering all necessary factors before installing Exchange 2010 Server. These points of consideration include Active Directory Prerequisite concerns, Operating System requirements, Firewall Rules, Certificate Configurations and Server side prerequisites.
Why do I need the Deployment Assistant?
The reasoning behind the use of this tool is very simple. Sometimes the implementer or designer forgets the basic requirements needed for achieving successful implementations. If such requirements are left unattended, the implementer could waste his or her time trying to identify the root cause of the problem – a process which can turn into a major task.
How does it work?
The Exchange Server 2010 Deployment Assistant is an advanced version of the Exchange 2003 setup.htm file. Exchange 2003 setup.htm file is server level html, and provides instructions for how to complete the prerequisites for the installation of Exchange 2003. By adopting this URL-based tool, you are not only taking care of prerequisites on the server side, but you are also looking into Active Directory prerequisites as well. Plus, it will teach you how to implement additional configurations based on the Exchange Server Role, like how to install Exchange Server Role, finalize Certificate configuration details and the Help file as well.
The primary advantage of this tool is that it does not force you to go through thousands of pages to cross-check the basic prerequisites. Moreover, it reduces the risks of human error. Since this is purely a URL-based tool, simple click the link below – no installation is required.
Click here
This tool has been created based on the following scenarios, including:
- Upgrade from Exchange 2003
- Upgrade from Exchange 2007
- Upgrade from Exchange 2003 and Exchange 2007
- New Installation of Exchange 2010
Figure 1:
When you click on any of the options, it will take you to a series of questions. For our tutorial, let us assume that I want to do a new installation of Exchange Server 2010, so I will simply click on New Installation of Exchange 2010. Now it will display the set of questions, such as:
- Are you planning to configure HTTPS\IMAP\POP?
- Are you planning to use public folders in Exchange 2010?
- Are you planning to deploy an Edge Transport server role?
- Are you planning to deploy a Unified Messaging server role?
Figure 2:
 Once you click on Next, you will be asked another set of question based on the answers you provided above regarding your new environment’s infrastructure.
Figure 3:
As per the above screen, you will see Navigate your checklist. This option will teach you how to access the tool, how to customize your answers, and in case any failure occurs, how to return to the section where it was discontinued. When accessing this tool for the first time, it will be beneficial to go through the navigate checklist. Once you are done put a tick mark in the bottom right hand corner and click on next -> which will take you to next step: Confirm the Prerequisite steps are done. Am I finished yet?
Figure 4:
 At this step, the tool will ensure that you are installing the CAS as per the proper guidelines put forth by Microsoft. Moreover, it will contain a link for you to learn more about CAS and an additional link to connect you to the latest Exchange Server 2010 updates. When installing CAS for the first time, I would recommend you follow this step properly to ensure zero errors.
Figure 5:
Add Digital Certificate on the CAS:
This step will show you how to add the digital certificate on the CAS. After that, enable Outlook Anywhere.Once you complete the installation, you can check that post installations tasks were completed, like verifying the installation task, entering product key details, transport post deployment task, etc by referring to Post-Installation Tasks.
Figure 6:
The final step is the Checklist Complete. This will show you the completion status of each task; plus, it will help to provide additional tools like Exbpa and some performance check analyzer information.
Figure 7:
Thanks to Microsoft for releasing such a valuable, easy-to-use tool. I believe it is the perfect pre-deployment utility to ensure you are on the right track for a successful migration to Exchange server 2010.
Now that you have successfully completed all the necessary prerequisites, join us in Part 2 of this series as we introduce another valuable tool that will help you prepare for the next phase of your migration to Microsoft’s latest messaging platform.
Labels: Exchange 2010, Exchange Migration
Tuesday, March 2, 2010
Understanding Exchange 2010 Storage Architecture: Part 3
By Mahmoud Magdy
In Part 1 of this series, we reviewed the Microsoft’s ESE (Extensible Storage Engine), and discussed the new storage enhancements that were introduced in Exchange 2010.
In Part 2, we continued our journey through the Exchange 2010 storage enhancements by exploring the concepts of logical and physical changes to the Microsoft ESE database.
In the final part of this series, we are going to explore some very clever changes Microsoft has made that significantly improves system performance. In this article we are going to take a look at the following areas:
- Read/write Coalescing and page compression
- Cache compression
- Online maintenance
Read/write coalescing and page compressions:
In Part 1 of this series, we noted that database page has been changed from 8 KB in Exchange 2007 to 32 KB in Exchange 2010. How does this change improve performance? Let’s compare how Exchange 2007 and 2010 would handle a 20 KB email item. Exchange 2007 would require 3 separate IOs to read this single email item in comparison to one read operation in Exchange 2010. Please see the following diagram to better understand this concept.
To better understand why this change is significant, it is helpful to look back to how data was previously managed in legacy versions of Exchange. Exchange 2003 was much like an infant in that it basically did whatever it needed when it wanted in regards to the database. Most babies eat, sleep, relieve themselves and play on their own schedule, much to their parent’s dismay. That pretty much sums up how Exchange 2003 used to write, read or delete items to the database. When Exchange 2007 was introduced, it was evident that the technologies had grown up. This progression has naturally continued in Exchange 2010.
One big area of improvement is that Exchange 2010 has a much larger page size and manages the read/write operations more efficiently. For example, when a read or write operation is received, the size of the item is compared to the page size to determine if the operation should be committed or to wait to gather more changes so that a single IO can be used. The following diagrams show how Exchange 2010 is much more efficient that Exchange 2007.
Notice how the same Read operation takes 3 transactions in Exchange 2007 as opposed to a single operation in Exchange 2010. The diagram below highlights how a Write process is handled more efficiently in Exchange 2010.
Now that Exchange 2010 has a larger page size, what happens for smaller pages in the cache? Since the cache is in memory and not on the Hard disk, you might assume that the whole 32 KB page would be used and this would result in a waste of memory. The engineers at Microsoft thought about this problem when introducing designing Exchange 2010 and created a nice solution. When a page is not fully utilized, Exchange uses cache compression. For example a page with 7 KB of data will be compressed in memory so that the extra space is not wasted. The diagram below graphically represents this concept.
Online Defragmentation:
In previous versions of Exchange, the maintenance of database was handled nightly by the exchange server. This included page purges and the handling of mailboxes that were deleted.
Due to the many storage related enhancements that were introduced in Exchange 2010, Microsoft wanted to assure that the detection of faults, logically or physically, were detected and handled as soon as possible. For this reason, the way Exchange maintained its databases was changed. Instead of waiting until the evening to perform these important tasks, Exchange now performs maintenance constantly.
You can enable a special option on the database and enable 24/7 database maintenance on the database. This new feature also recovers white space on the fly. This also really eliminates the need to perform off line defragmentations of the database. It also allows the database to recover from logical or physical errors at the database level in real time.
The above diagrams show the new features and architectural changes that occurred to the OLD and thus became OLD2, OLD provides Background/throttled process that maintains contiguity of “Sequential Tables” by rebuilding leaf level of B+ Trees, thus gives the Exchange 2010 the ability to get a defragmented database like below:
The above diagrams shows a live view that compares the Exchange 2010 DB vs. 2007 fragmentation level, it is clear that Exchange 2010 has maintenance over the older technology.
Talking about storage in Exchange 2010 never ends. I like reading and writing about it but at some time it should stop. I hope that I was able to give you a solid view of the Exchange 2010 storage architecture and its new features. In my next article, I will talk about certificate consolidation and considerations for Exchange/OCS deployments. I hope that you liked this series and that you will keep visiting our blog for cool blog entries from fellow ESE writers.Labels: Exchange 2010, Exchange Information Stores, Exchange Support, Exchange Tips
|
