.: Enow Solutions Engine

Introducing the new ESE Consultants' Corner

2010-04-27T08:22:00.001-07:00

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:

Send your questions to ese@enowinc.com.

ENow will select the best questions and answer them in the next edition of the Constultant Corner.

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:

The spec adjusted megacycles for a 24 core Intel Xeon X7450 server is 35237.
The spec adjusted megacycles for an 8 core Intel Xeon X5570 server is 44122.

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

Exchange 2010 Site Disaster Recovery on a Dime! Part 2: Navigationg the Failover Process

2010-04-13T07:55:00.000-07:00

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.

All for one and one for all: The key to a successful Office Communications Server Deployment

2010-03-30T09:31:00.000-07:00

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

Migrating to Exchange 2010 Part 1: Preparing your Exchange environment

2010-03-15T22:00:00.000-07:00

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.

Understanding Exchange 2010 Storage Architecture: Part 3

2010-03-02T14:00:00.000-08:00

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.

Exchange 2010 Site Disaster Recovery on a Dime! Part 1: Building the Solution

2010-02-16T08:33:00.000-08:00

By Lasse Pettersson, Exchange MVP

Since Microsoft has made significant improvements to how Exchange handles disaster recovery of databases, many organizations have started to wonder how they can effectively prevent site, datacenter and other such disasters from occurring. But not every company has the budget to implement a new infrastructure, so how can such companies still take advantage of these new techonolgies? The answer is in this article -- I will explain how this can be accomplished with only two Exchange 2010 servers. In Part 1 we will discuss how to build the solution; then in Part 2 we will move on to discover how to activate the disaster recovery site.

Please note that this solution does not give you High Availability, but it will provide you with a solution for site and server disaster.

This solution builds and depends upon the Exchange 2010 feature called Database Availability Group (DAG). DAG is the new High Availability feature of Exchange 2010 that is the evolution of the Exchange 2007 CCR, LCS and SCR replication technology. A DAG can be built with as little as 2 Exchange server mailbox roles, and with as many as 16, making this a very flexible solution. The beauty of the Exchange 2010 DAG feature is that can also contain other Exchange server roles such as CAS and HUB, which is an attractive option for smaller organizations. To demonstrate the scalability of the DAG feature, I will use only two servers in my example – one in the production site and one in the Disaster Recovery site. This represents the smallest installation that can be done for DAG, but remember this is a flexible solution so at any point if you need to scale out with multiple DAG members the steps you would perform are nearly identical.

Building the solution.

In both the production site and the Disaster Recovery site we need a server with Windows Enterprise edition since DAG relies on Microsoft Failover Clustering which is only available in the Enterprise edition. (Remember that Exchange comes in either Standard or Enterprise edition. The Standard edition can be used with up to five databases, but if you need more than five then it is necessary to utilize the Enterprise edition of Exchange.) Both sites also need Domain Controllers and Global Catalog Servers. The DR (Disaster Recovery) site is most likely a different site in Active Directory to prevent users from accessing it.

Installing Exchange.

To install Exchange, you simply perform a standard Exchange installation in both sites. When you are finished you will have one Exchange server in the production site and one Exchange server in the DR site. Both servers can have all standard roles (i.e. Mailbox, HUB and CAS), but you can also install them on separate servers and have multiple roles on multiple servers.

To test that everything is functioning properly, I recommend creating a mailbox on each database that is mounted on each server, and then sending a test email from one mailbox to the other. Our configuration thus far is very basic since no clusters or DAGs have been built yet. At this point, our example consists of two Exchange servers located in different Active Directory sites.

Since DAG is one of the hottest new features in Exchange 2010, many articles have been written on the subject. Hence, I will walk you through the steps of creating a DAG fairly quickly.

Creating a DAG.
In the Exchange Management Console, under the Organization Configuration, Mailbox and the ‘Database Availability Groups’ tab, right click and select ‘New Database Availability Group.’

The Create a DAG wizard starts.

Next, enter a name for your DAG. If you have a server with a HUB role but no mailbox role, then the wizard will select the HUB server and create the witness directory for you. If you don’t have an available HUB server, then you must manually specify the ‘Witness Server’ and a ‘Witness Directory.’

At this stage I need to caution you that a permission issue might occur when creating the File Share Witness directory. This is because it’s not the logged on users security context that is utilized when creating the File Share Witness directory, but rather the Exchange server computer account. The solution is to add the ‘Exchange Trusted subsystem’ group to the witness server local administrators group. This is also necessary becasue in order to create a DAG you must also create a computer account in Active Directory. Thus, you might need to delegate ‘Exchange Trusted subsystem’ group to create and manage the computer account in Active Directory, or at least in a pre-populated disabled computer account.

Exchange Management Shell or Wizard?

If you prefer Exchange Management Shell over the Wizard, below is the command you need to create a DAG:

New-DatabaseAvailabilityGroup -Name DAG1 -WitnessDirectory C:\DAG1 -WitnessServer FQDNofaServerinPrimarySite -DatabaseAvailabilityGroupIpAddresses 192.168.15.233,192.168.25.233 -Verbose

The Exchange Management Shell is a better approach than the Wizard when you consider the following: with the Wizard you cannot set a fixed IP on your DAG. Instead, it will use DHCP to assign an IP. This is important to consider since it is recommended that you have an IP in every subnet that contains DAG members. The reasoning behind this is that when DAG moves to a different IP subnet, it needs to have a valid IP address on that IP subnet.

Adding the parameter Verbose will allow you to receive clues in case something goes wrong as the command runs and pulls more information for you.

Why is having fixed IP for your DAG preferable to using DHCP?

Remember that a DAG is actually a failover cluster, and in order for the cluster to function IP must be up and running. Since not every company uses DHCP on the server subnets (some only use it on client subnets), it is often more convenient to have fixed IP.

The next step is to add your Exchange mailbox servers to your DAG.

Click ‘Manage Database Availability Group Membership’ and then add the mailbox server to it.
If everything works out accordingly, then the Failover Cluster role will be installed on the servers you added to your DAG. You can start the Failover Cluster Management tool and see that there is a cluster called DAG1 that contains your two mailbox servers. The computer account should also be enabled, and the witness directory should be shared and also populated with a couple of files.

Below is the Exchange Management Shell comand that you must run one time for mailbox server that you add:

Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer FQDNofMailboxServer –Verbose

Remember to allow AD replication between each step, otherwise you may not be able to join servers to your DAG.

You should also see that a DAGNetwork has been created, and if you have multiple networks on your mailbox servers then there should be multiple DAGnetworks. Even though you should run DAG on a single network, it is oftentimes better to have mutiple NIC and networks in your server because it gives you the ability to separate MAPI, Cluster and replication traffic into different networks.

The next step is to add databases to your DAG members in order to enable replication. Up to this point, each server had only one database mounted but now we would like to add more to it.

Click the ’Add Mailbox Database Copy’

Next, select which servers you want to hold a copy of the mailbox database and the ActivationPreference.

Below is the Exchange Management Shell command:

Add-MailboxDatabaseCopy -Identity 'Mailbox Database 2036433681' -MailboxServer FQDNofServerInDRSite -ActivationPreference 2

This step can potentially take a long time since the database is seeded to the DR (Disaster Recovery) site; how long it takes depends on the database size and available bandwidth.

Now we must set some parameters on the mailbox database so that it is not automatically activated.

From Exchange Management Shell (EMS) run the following command:

Suspend-MailboxDatabaseCopy -Identity 'Mailbox Database 2036433681\FQDNofServerInDRSite' -ActivationOnly –Verbose

This will ensure that replication is still happening automatically while ensuring activation will not.

Next, run every mailbox database to both your servers with the ActivationPreference set to 1 on the server in the production site; then, set the database copy on the server in the Disaster Recovery site to ‘suspended’ for activation.

Configuring Replay Lag Time

Configuring Replay Lag time is something that you should seriously consider doing. Lag time is how long the passive copy will wait until the transaction log is replayed into the database. Replication is still happening as fast as possible.

Below is the EMS command:
Set-MailboxDatabaseCopy -Identity 'mailbox database 1976375852\FQDNofServerInDRSite' -ReplayLagTime 0.1:0:0 –Verbose

(Please note: 0.1:0:0 means 1 hour. In real life you should most likely set this to a higher value.)

There is also another paratemeter that you might want to use--the Truncation Lag Time.

Below is the EMS command:
Set-MailboxDatabaseCopy -Identity 'mailbox database 1976375852\FQDNofServerInDRSite' -TruncationLagTime 0.2:0:0

(Please note: 0.2:0:0 means 2 hours. In real life you should probably set this to another value.)

How long you set the ReplayLagTime and TruncationLogTime for depends on two things: 1) How long it takes you to notice a corruption on the production site, and 2) How long it takes to replay all transaction log files if you activate the DR site. For instance, if you know you can detect a corruption in the active datacenter within 10 hours, then you should probably set the ReplayLagTime to 12 hours or so to allow for recovery of all non-corrupted data. Also consider the amount of disk space you have when setting the ReplayLagTime.

More information about Managing Mailbox Database Copies can be found on Technet: http://technet.microsoft.com/en-us/library/dd335158.aspx

For more information on creating a DAG, click here: http://msexchangeteam.com/archive/2009/06/14/451609.aspx

Creating the CASArray.
Now your DAG and databases should be all ready to go! Remember to monitor the replication with Get-MailboxDatabaseCopyStatus –Server FQDNofServer

CopyQueueLength and ReplicationQueueLength should show small numbers if possible, preferably zero or one, but in real life you would see higher values depending on your bandwith, serverload, etc.

Why do you need a ClientAccessArray?

Technically, this is not needed but rather highly recommended because it’s easier to manage a system that has one, and since it’s only a name that you can move to another IP, you can also move your client connection point.

Move client connection point?!

Yes, the Outlook MAPI connection is moved from the Information Store on the mailbox server to the CAS (and the CASArray name if you have one defined.)

New-ClientAccessArray -Name CASArray-HQ -Fqdn FQDNofYourDesiredEndpoint -Site ADsiteInPrimaryDatacenter

For more information on the New-ClientAccessArray, click here: http://technet.microsoft.com/en-us/library/dd351149.aspx

Now configure all your databases to have the CASArray-HQ object as the RPCClientAccessServer. This will ensure that Outlook conencts to CASArray FQDN instead of the actual server name.

Get-MailboxDatabase | Set-MailboxDatabase -RpcClientAccessServer CASArray-HQ

You must also create a record in DNS with FQDNofYourDesiredEndpoint with an IP of your Exchange server in the primary datacenter. Set the TTL to a low value, such as 5 minutes, to make the switchover go faster to the Disaster Recover site.

When Outlook connects, it will now connect to the ‘FQDNofYourDesiredEndpoint’ name. Also, if you look at the MAPI settings, Outlook thinks that the FQDNofYourDesiredEndpoint is the Exchange mailbox server.

Configuring Autodiscover

For Outlook to connect properly you must make sure to configure Autodiscover correctly.

At this point you should have two servers with the Mailbox, HUB, and CAS roles on each one, a DAG with the two servers (one in each AD site), and a CASArray located on the server in the primary AD site.

Failovers will not occur automatically because of the configurations we did on the mailbox databases. Thus, if you reboot the primary server then clients will lose connection to their mail.

I hope you have enjoyed this tutorial on Exchange Server 2010 Disaster Site, and that you were able to follow my instructions and begin preparing your organization for the worst-case scenario: site or server disaster. Now that you know how to build the solution, in Part 2 of this piece we will move on to discussing how to activate the disaster recovery site, at which point I will explain how to backup, test and perform a switchover should your Exchange server fail.

Dude, Where's my Backup?

2010-02-02T06:45:00.000-08:00

By Mahmoud Magdy

When I started writing this post, I couldn’t get the movie “Dude, Where’s My Car?” and its events out of my head for two reasons. The first reason is that the conundrum the film’s characters find themselves in reminds me of a similar event in which one of my customers experienced an Exchange disaster and I was brought in to assist. I realized straightaway the client needed to perform a backup, and when I informed the Exchange Administrator of this he frantically turned to his Backup Administrator and asked him, ‘Dude, where’s my backup?!’

The second reason this movie reminded me of that incident is because the same clueless looks that the film’s starring actors had on their faces when they awoke after a crazy night to find their car missing were identical to the looks on the faces of the Exchange and Backup Admin when I asked them to perform a backup. In fact, I see that look on many of my customers’ faces when I ask them to restore an Exchange backup set for me! Those days of panic-stricken looks and long hours spent worrying over data loss, log deletion, and mailbox restoration are now over. Join me as we explore one of the undocumented features of Exchange 2010: the backup-less deployment.

Backups in Exchange have always been a point of concern for me due to my experiences while working as an Infrastructure Manager. In one instance I thought I had done everything I should have: I had everything in place, our Exchange was up and running and I had assigned a team to backup Exchange, AD, SQL and most of our critical systems. We tested the restore steps and everything ran smoothly, but when we had a disaster you can already predict what happened – we experienced another backup set failure which cost us two hours of downtime.

The secret to successfully restoring Exchange has always been a mystery. A successful restore even for an Exchange guru is a tedious task! We are fortunate that today we have assistance in the form of DB portability, power shells, and wizards for backups and restores; but even with this help, the task of restoring Exchange remains tedious.

Other issues that arose with the introduction of Exchange 2007 were the single item and single mailbox restoration. It is now possible to restore a single mailbox, or better yet a single item, but clever software is needed to perform the task. You must also properly train and prepare your IT staff, and remember that the software and hardware requirements for either type of restoration are expensive. You must carefully compare your options when purchasing decent backup software since their prices can be high.

You say you want a revolution…

Well you know, when Microsoft introduced Exchange 2010 that’s exactly what they brought. For the first time, Microsoft is recommending that administrators perform backup-less deployments. When I heard that I laughed out loud, as I am sure many of you are, since for years as consultants and as customers we have always been told to backup everything, most importantly our Exchange data, so just exactly how will this revolution of backup-less Exchange deployments change the world?

So Microsoft has a real solution…

Would you like to hear the plan? If you are shocked by this new recommendation then let me set your mind at ease: ‘it’s gonna be alright.’ If you feel like it will take awhile for you to trust Microsoft’s recommendation then you are not alone. It took me, a technically savvy (and extremely humble) guy nearly 3 months to accept this fact, but what it really took was for me to design a backup-less configuration for the first time. After designing this configuration I have learned the benefits of going backup-less, so please join me as I explain them to you.

Backups’ Background:

Historically, I have always considered Exchange backups to be more important than Exchange itself. ‘Why?’ you might ask. My answer is multi-fold: because it guarantees that I will be back online in the blink of an eye if the system goes down. Plus , it will enable me to recover items for users that have been hard deleted, and more importantly this is the only way to flush and delete the logs of the mailbox database (previously this was tied to the Storage Group.) The other not-so-popular method of deleting such logs is known as circular logging.

Backup in Exchange 2003 was straight forward, but with Exchange 2007 Microsoft introduced the concept of database copies which provided a new way to backup your Exchange data.

Now you can perform a backup from the passive copy, which provides enough data to help you discern what the online copy is suffering from (i.e. IOPs, users’ access, AV Scan.) When you back up the passive copy, and the backup to the passive copy is complete, then the database is marked as backed up and logs are deleted from passive and active copy.

As mentioned previously, doing Exchange backups historically required costly backup software as well as hardware, including storage, backup tapes, tapes libraries, and backup hustle.

Microsoft made a bold decision to change the Exchange world by introducing backup-less configuration, which I will now discuss in more detail.

Less is more, don’t you agree?

What does backup-less really mean? It simply means that you do not have to backup your Exchange data, or at the very least it gives you the ability for the first time to not have to back it up.

I can completely understand many of you doubting that this is in fact a possibility, to never have to backup your Exchange data, but before you make your decision let us explore backup-less architectures and learn how they really work.

Backup-less Architecture:
As stated above, backup in E12 could be done to the passive copy but this is only true for CCR or LCR. At the time, this was a viable option: to backup the passive node and then once backup is done the passive copy updates the database header, notifies the active node, and the active node deletes the logs.

Issues to consider before designing or deploying a Backup-less configuration:
- Data protection, Database health, Database recovery.
- What to do when you lose data.
- How to delete your logs.
- How to restore items and mailboxes like before.

In order to address these issues, you must understand how Backup-less Configurations work:

When you want to configure your Exchange in backup-less, you should have at least two copies of the data (Active/Passive.) Microsoft recommends doing backup-less in more than 3 copies (Active/Passive/Passive) configuration. In order to configure your infrastructure to be backup-less, you must obtain three copies of the data and configure circular logging on the mailbox database.

I can hear you saying, ‘Circular logging?! No way!’ And I understand your reaction, but keep in mind we never do circular logging unless we have strong reason to, so let us see how circular logging works with the backup-less.

Real World Example:
To illustrate how circular logging works with backup-less, let us consider the following example:

You have a mailbox store called MB1 that has 3 copies of it on Servers 1, 2 and 3. MB1 is active on Server 1 and has two copies on Servers 2 and 3. Now you want to configure it in Backup-less. All you have to do is configure the mailbox database to do circular logging, and once you do so Exchange will change its architecture slightly and perform circular logging in another way.

When circular logging is enabled on the database, the logs are written to the Hard disk. Once the data is committed to the database, logs will be flushed. In Backup-less (DAG environment only) this changes the Exchange behavior: logs are written but never get flushed until logs are replicated and marked as checked at the other database copies.

To understand this, let us go back to our example: MB1 has log E01 that is waiting to be written. E01 is written to the DB and now it gets held in Server 1 when before it would have gotten flushed.

Server 1 replicates E01 to Server 2, Server 2 copies the log and it remains in Server 1 where it checks the logs and marks it as healthy/inspected and notifies Server 1. Server 1 does the same with Server 3 and once Server 3 verifies its logs and reports to Server 1 that its copy of E01 is healthy/inspected, then Server 1 deletes and flushes the logs.

There are 2 questions that might arise at this point:
- Why didn’t Exchange wait until the log is replayed at Server 2 and Sever 3?
- Does Server 1 wait until it replicates the data to all of its adjacent servers? (In our example server 2 and server 3)

The answer to the first question is Exchange will not wait for the log replay because you might have a lagged replay configured on your DB copy. This means that you might replay the logs 48 hours later which translates into huge numbers of logs for Exchange.

I do not have a confirmed answer to the second question yet, but if you attended an Exchange 2010 Advanced storage session you would know that an Exchange server can recover and resend the logs, and even better, the specific bits in case of database corruption. But if Server 1 deletes its logs and the same for Server 2, then where does Server 3 get its logs from?

Hopefully by now the answer to that question is a little bit clearer. Exchange now has a self-based mechanism to flush its logs, but Backup-less configuration is not a specific setting that you assign to Exchange. By that I mean you don’t go to the options page and check the box stating this is a Backup-less organization; rather, this is a group of configurations that you apply to Exchange so you can deploy a Backup-less configuration. It is important to remember that this behavior is the same if you have 2 copies and do circular logging, even if you do backup.

There are several pertinent questions that we should answer one at a time:
- What about the health of my Database, Database availability, and uptime?
Exchange 2010 has a self-healing mechanism. What that means is that if page No. 485950 gets written to a bad block, or gets corrupted logically or physically, then Exchange 2010 can replicate this page from another server by copying only the required page with the next replication cycle. This keeps the Exchange database healthy and minimizes the replication requirements.

If Exchange cannot make the active database healthy then we have DAGs that pick the best available copy and make it an active copy. Typically if a physical server failed, a Hard disk failed, or a database failed physically or logically, you would not need your backup since you already have two copies. This means you don’t need your backup! (Are you becoming a backup-less fan yet?)

Now the other dimension is minimizing the storage cost. Since you have three copies of the database, and since Exchange 2010 has 70% less IOPs, you no longer need expensive SCSI disks, or even a SAN. I recommend using a JBOD configuration which is much more cost effective than any other storage option. Thus, in a backupless configuration, you can have three copies of your data and reduce both the backup software and hardware cost. (Considering jumping on the backup-less bandwagon now?)

- What should I do if I want to replace a single item or a mailbox?

Before answering that, first ask yourself how many times as an Exchange admin you had to do that (restore an item or mailbox for a user). In my career, I only had to do it at most three to five times. It might be different in your organization, but in general most Exchange administrators do not need to do that on regular basis.

Since we have cheaper storage we can increase the mailbox store dumpster. It is set at 14 days by default, but now you can increase it and ask the users to recover their mailbox store. You can also use the new RBAC (role-based access control) model and give helpdesk personnel the permission to search the Exchange dumpster and perform discovery within it using PowerShell in order to recover items for users…..meaning you as the Exchange Admin does not have to!

- Don’t I need a backup at all?

I will not say that you don’t need to backup the Exchange system at all, but you might want to consider backing it up as a second layer of protection. If you do perform a backup-less configuration, then your first line of defense is not the backup sets any more, it is your Exchange 2010 Backup-less configuration,. In other words, it is done automatically.

I know after being told for years to backup everything, most especially Exchange data, that it will be difficult to change your thinking radically with a single article. You probably have legislations that make you comply with 3 years’ restore SLA. But if you are one of the Exchange admins that do not have to abide by such legislations, then you should consider Backup-less Configuration.

Hopefully you now understand the architecture change of the circular logging, DAGs, and how to do backup-less configurations. Backup-less configuration is still an un-documented feature of Exchange 2010 and you will not find much information about it. My recommendation is that you open your mind to the idea and take care in calculating the total cost required for backup gear as compared to the B-less cost, without forgetting their technical and operational requirements as well. I cannot say that backup-less is for everyone, but it is a great option that can save you money, and one you should give decent thought to.

I look forward to bringing you another thought-provoking article within a month, and until that time I wish you the best uptimes and the fastest Exchange servers!

Understanding Exchange 2010 Storage Architecture: Part 2

2010-01-19T11:00:00.000-08:00

By Mahmoud Magdy

In Part 1 of our series on the Exchange 2010 storage architecture, we went back to the basics by reviewing Microsoft’s ESE (Extensible Storage Engine), then moved on to discuss the new enhancements that further reduce IOPS (Input/Output operations per Second.)

In Part 2, we will continue our journey through the Exchange 2010 storage enhancements by exploring the concepts of logical and physical changes to the Microsoft ESE database. But first I would like to revisit a few important topics that deserve elaboration--namely, the SIS (Single Instance Storage) removal and the Lazy View Updates.

SIS (Single Instance Storage) Removal:

SIS, or single instance storage, was introduced to the Exchange server product suite in Version 4.0 and remained there until the release of Exchange 2007 (Version 12). The role of SIS was to store a single copy of an email or attachment in a Mailbox database, thus allowing any recipients within that database who received the message to be able to access it via a single instance. The greatest asset of SIS was its ability to prevent attachments from being duplicated, engendering huge space savings on the disks.

SIS in Action:

Consider the following example:

When User A sends a message with a 1 MB attachment to a DL (Distribution List) or a group of 100 users, SIS steps in and delivers only 1 copy of the attachment to the mailbox store on which this particular group of users is located. Thus, instead of User A forcing that database to store all 100 MB, or 100 copies of the attachment, he or she saves approximately 99 MB of space on the Mailbox store.

Many people were concerned when they heard SIS was being removed from Exchange Server 2007, but one must trust that Microsoft has their reasons. In 1996 when Exchange 4.0 was released, disks were bigger, slower and more expensive in comparison to current storage prices. Since SIS is only effective when used within a single database, SIS was the perfect solution to reducing the size of mailbox stores in a time when many companies only had one database. The trend in storage architecture shifted as disks became smaller, faster, and cheaper, meaning that most companies now have multiple databases storing more users on fewer disks.

As disk storage became less expensive and the database engine itself evolved from the mid 1990s through the turn of the century, Microsoft admitted that the benefits of SIS were no longer as beneficial as they used to be. In fact, studies have indicated that the 20% database reduction savings were never fully realized, and that the more accurate figure was closer to 10% and in some cases as low as 5%. If you recall from Part 1 of our series, Microsoft decided to make a dramatic change to the ESE, but in order to do so they had to make a choice: keep SIS or provide better performance? To provide better performance meant Microsoft had to increase the IO size to 32KB and force the ESE to make larger IOs and reduce the frequency of read/writes. Incorporating these changes for the sake of better performance required bidding the SIS farewell.

After implementing these changes, however, Microsoft found that space hints and the new B+ tree architecture added approximately 20% space to the Exchange 2010 database, so Microsoft introduced a new feature called the Database Compression or LV (long value) Compression.

Before we dive into Long Value Compression, let’s first answer the question of what is a long value (LV)? As many of you know, in Exchange 2010 the boundary of a page size was increased to 32 KB, and to understand why you must first understand the basics of how data is stored in Exchange databases. In Exchange, all data stored in databases is held in B+ trees which are further divided into pages. The unit size used for caching in databases is the page size, which is the minimum size required for reading and writing to the database. Since performing operations by memory is much faster than reading directly from the disk, by increasing the page size to 32 KB it allowed the ESE to reduce IOPS. The result of the reduction in IOPS is improved performance since the larger page size is cached in the memory.

Now back to the explanation of Long Values. Since the page size in Exchange 2010 is 32 KB, the emails larger than this value end up consuming extra pages and space within the database. LV Compression is the solution to this problem: it defines another table to be used by those emails, and then they are compressed to provide better space saving.

The above figure illustrates the database file analysis and comparison between E12 and E14. E12 wins in the analysis for RTF files; however, as you all know most of the emails are text or HTML-based, so using the LV compression technique renders a better space saving. Even with the removal of the SIS, the Exchange 2010 DB file is reduced by about 12% less than the E12 database size.

Lazy View Update:
Another dramatic change to the ESE brought about by Exchange 2010 is the Lazy View Update. To examine this in further detail, let’s consider the following example:

In E12, if a User (who is using OWA or Outlook Web Access) has 5 views in his inbox, then the next time the User gets an email Exchange instantly updates all of the 5 views. While this improved the end-user experience, it forced Exchange to do 2 things:
1. Perform unnecessary IOPs. (i.e. The user might be out of office, or the email might have been received in the middle of the night, thus forcing Exchange to pay for IOPs that are not necessary.)
2. Since the update is done per email, it made Exchange create excessive small IOPs to update the views.

Microsoft has solved this problem with the introduction of Lazy View updates. Going back to our example, if the above User is using OWA or Outlook Online, the view will not be updated until that User opens the view. Although this might be slower on the backend than in previous versions, the larger and now sequential IOs that are performed prevent the User from noticing any performance impacts during viewing or opening the views.

ESE Logical Contiguity:

Microsoft has made dramatic changes to the ESE storage in order to allow better IO utilization using sequential IO; a single hard disk cannot exceed 200 random IOs, while a regular SATA disk can do 300+ sequential IOs easily.

Now to better reflex the changes in the ESE architecture, try to envision the following scenario in your head. (I recommend this approach as it has greatly helped me during my own Exchange sessions.)

Imagine that you are looking at the ESE database through two transparent films: one is a logical film and one is a physical film.

The logical film is how data is structured in the ESE database, and includes tables, indexes, LV (Long Value) tables, etc. Once data is located, you must go in and find its reflex and physical location within the ESE database. (Remember this is where the pages, which are stored directly on the hard disk, are stored inside the ESE database file.)

In Part 1 of this series, we introduced the concept of logical contiguity. Let us complete our exploration of this topic by looking at the following diagram:

Microsoft has changed the table architecture in the mailbox store from a table per database to a table per mailbox. This allows fewer yet larger size sequential IOs to be committed against the ESE database, and thus optimizes the IO operations at the logical layer.

SIS removal, table architecture change, LV Compressions and Lazy View Updates are all fundamental components of the logical architecture changes to the ESE engine.

ESE Physical Contiguity:

Now that we have explored logical contiguity, let us take a look at the physical structure inside the ESE Database. Recall from Part 1 that the ESE data is stored based on the B+ tree model, which consists of properties which are stored in records which are in turn placed in a node that is stored in a page.

In the previous versions of Exchange (E14 and below), data was stored inside the database in a random matter, which was the reasoning behind having to place logs in separate disks or spindles apart from the database files. This was done because logs used to commit sequential IO while Exchange used to commit Random IOs.

This behavior negatively impacted the Exchange storage design and performance, and over time the database became fragmented and offline defragmentation of the database was necessary. In order to improve this behavior, Microsoft has changed the ESE writing behavior so that it stores the ESE pages in a contiguous manner.

To understand it better, one must visualize the design. Take a look at the following diagram:

The above diagram compares the B+ tree in the previous version of Exchange to the current Exchange 2010 version. As you can see, in Exchange 2007 pages are committed to the database in a random manner, causing the database to become fragmented over time and forcing Exchange to commit IOs in small random orders.

In Exchange 2010, the B+ tree design has been modified: pages are now stored in a contiguous manner where they are written and read in a sequential manner, thus improving the physical contiguity of the ESE file.

There remain some missing pieces to the puzzle. For instance, what happens if a read/write IO has to be committed and it cannot be done sequentially? This mystery, along with others, will be discussed in Part 3 of this series.

Understanding Exchange 2010 Storage Architecture: Part 1

2010-01-05T14:00:00.000-08:00

By Mahmoud Magdy

In this article, we will take a close look at the Exchange 2010 Storage architecture, but first let us go back to the basics by reviewing the ESE engine storage and then delve into the new enhancements that were introduced with Exchange 2010. First, a brief review of the ESE basics: Microsoft’s Extensible Storage Engine (ESE) is an ISAM (Indexed Sequential Access Method) data storage technology. The purpose of the ESE is to allow applications to store and retrieve data via indexed and sequential access. The ESE is suitable for server applications since its transactions are highly concurrent; but at the same time it is lightweight enough that it also works well for auxiliary applications. Worried about losing stored data in the event of a system crashing? The ESE provides transacted data update and retrieval, meaning that data consistency is maintained should your system crash via the ESE’s crash recovery mechanism.

As you all know, ESE relies on the B+ tree in order to store data. The following diagram features a simple tree that illustrates how information is stored in the data tree:

Since sorting and searching through mounds of data is time-consuming, ESE stores data in trees in order to optimize their sorting and searching behavior. In addition, the regular tree model has been updated using the B+ tree to allow for faster, more efficient sorting of data.

There are 2 types of data sorting: either internal or external. Internal data sorting means that the system can store and sort the data in the memory. However, since it is impossible for each system to sort its data within the memory, the system is forced to store data on the disk and then begin using the B+ Tree.

Data in the ESE is stored based on the following hierarchy:

A property is created, generated and placed in table record. Keep in mind that MAPI uses properties in order to define data and their structure at the lowest level.

Multiple properties are placed in a record.

The record is stored on a node, and a corresponding key is used to both index and vastly access the record. One thing to remember is that the leaf nodes (the end nodes) are logically linked together to allow the horizontal crawling and movement of data within the B+ Tree.

A record is placed into lines which are then stored on a page, with the page being the smallest element of the hard disk. Storage sizes in previous versions of Exchange: In Exchange 2003 the hard disk size was 4 KB. That number doubled to 8 KB in Exchange 2007, and then quadrupled to 32 KB in Exchange 2010.

How did Microsoft improve the storage engine in Exchange 2010?

Exchange 2007 introduced significant enhancements for the storage usage and optimization, however Microsoft wanted to further improve these enhancements with the release of Exchange 2010. While doing preliminary research to determine the most pertinent areas in storage use and optimization that need attention, Microsoft found that enterprises suffer from several challenges with the current storage technologies, including but not limited to:

Random IO and disk limits: The current technologies provide limited random IOs throughput; however, most of the current systems can perform several hundred requests on sequential IOs.

Storage Design flexibility: As email communication increases, enterprises are continually demanding improved and flexible options for storing users’ growing amounts of data.

Using SATA Disks and JBOD technologies: Enterprises were limited to their capacity limits by the SAS/SCSI disks; however, there are currently 2 TB SATA disks (even though Exchange should be able to work with the limited throughput of the SATA disk.)

Task 1: change the ESE storage scheme:

In previous versions of Exchange, as illustrated in the first diagram, there were multiple tables per database that contained the users’ data. In figure 2 (and in Exchange 2007) there were multiple tables (for example: mailbox table, folders table, messages table, etc) per mailbox database. Thus, in order to open a user’s mailbox, Exchange required multiple small IOs to be performed.

In Exchange 2010, Microsoft moved to a table per mailbox, making it faster and easier to open a user’s mailbox. With Exchange 2010, opening a mailbox requires fewer and larger IOs in order to open a user’s mailbox and read specific email messages stored inside. This is due to the fact that the underlying architecture of the storage design was modified in Exchange 2010 in order to reduce IOPS (input/output operations per second). Microsoft dramatically reduced IOPS with Exchange 2010 to a full 70% reduction over 2007 and a 90% reduction over Exchange 2003.

In addition to the aforementioned features introduced in Exchange 2010, other enhancements have also been made to further reduce IOPS, including the Lazy View update and the usage of the ‘pay to play’ method. Remember that in previous versions of Exchange, custom views were updated as soon as the store received an email. Although this technique provided the end users with a better experience, it had a negative impact on Exchange, forcing the Exchange system to continuously update the view and create random small IOs in order to keep the store with the most updated view. With the Lazy View update, the email store is only updated when requested by the end user.

Exchange 2010 utilizes Lazy View technology in which the views are updated when the user attempts to access them. Although this increased the time it takes to open the view, it dramatically enhanced the Exchange IO performance by using the notion that it is faster for the disk to read data stored in larger, sequential pieces versus the disk head having to gather smaller chunks of data spread out across the disk.

In order for Microsoft to create a table per mailbox, they had to remove SIS (Single Instance storage). Some of you may complain about this initially, but never fear: Microsoft provided a work-around known as Database compression. This technology is used to compress the content of the database (especially text and html files), and provides an alternative to the SIS removal issue.

Now take another look at the Exchange 2010 ESE and compare it to Exchange 2007’s ESE. In Exchange 2007, in order to open a message in Joe’s mailbox, Exchange had to open the mailbox table, read the message header, open the message and read the attachment (examples of small random IOs.)

In Exchange 2010, the Exchange system can open the mailbox table, read the message header, and open the message directly. It is important to note that since these tables are now logically connected it is more convenient for Exchange to access them, and thanks to the new page size in Exchange 2010, E14 can read the entire message body in a single IO. If additional IOs are needed they can be done, but in order to streamline the data gathering process, these commands are now grouped in larger, sequential IOs.

Let us pause at this point and revisit our discussion of Microsoft’s enhancements to the ESE in Exchange 2010 in Part 2, at which time we will delve deeper into the topics of physical and logical contiguity.

To virtualize Exchange or not to virtualize Exchange?

2009-12-22T16:00:00.000-08:00

By Lasse Pettersson, Exchange MVP

A very common question I hear when talking to customers is whether or not they should run Exchange in a virtualized environment. The answer I give them is multifold: yes, there are benefits to running Exchange virtually, but you must carefully think first about the prerequisites and make sure it is the best move for your environment.

Virtualization is not magical. Some people have the misunderstanding that because you run virtualized, you don’t need to size your servers. This line of thinking will quickly get you in trouble. You still need to figure out how much RAM, CPU and storage you need, both for volume and for performance reasons. The rules are simple: scale your server in the same way you would if you were using physical hardware, and then apply it to your virtual server.

If you figure out that your server is going to need 16GB of RAM and 1000 IOPS, then make sure that the virtualized server has the same resources available; otherwise, your Exchange servers will have performance issues.

Performance. Think about what virtualization environments look like today when considering your hardware’s performance, you should take into account how virtualized environments are deployed. Most companies deploy one or more physical servers, possibly in a clustered configuration, hosting several virtualized servers on each physical server. This means that each physical server must be able to handle the load for every virtual server instance running on the physical one.

With today’s hardware, this is most likely not a problem if you think about CPU or memory (CPU and RAM are not that expensive and can be added later if needed); but when it comes to storage, that is another story. Every server needs disks, both for booting from and for saving the application data to. If running 5 servers on one physical, then the physical server must have 5 times the disk volume—always keep in mind the importance of performance.

For example, let’s consider the following configuration:

Imagine that you have 5 virtualized servers, each having a 50GB disk for OS and a 100GB disk for storing data, which is 150GB times 5 servers and you end up with 750GB. This is no problem for modern disks since a single disk can easily hold 750GB of data. But if you would have run those 5 servers on physical hardware, then you might have put in 4 spindles and created 2 mirrors with 2 disks each. This would render you a fairly good performance on disk. Then if you also have 5 servers with this configuration, that results in 20 disks.

Now compare that disk performance to the single disk performance. Exchange designers have for a long time been used to and forced to think in number of spindles instead of volume because of the disk performance, but this knowledge isn’t that widespread and there is a chance that the people who maintain the virtualization platforms don’t have this knowledge. With this being said, you most likely end up with your virtualized environment connected to a pretty beefy storage containing a lot of disks to withstand the IO performance need.

Virtual hosts affect each other. With several virtual machines running on a single hardware, one virtual machine that is running very high on CPU can drain the physical server on CPU resources, leaving the other virtual machines with little to no CPU resources, causing them to perform slowly. Virtual platforms have configuration settings to limit this behavior, both from draining resources and for maintaining some amount of resources for virtual machines.

This applies to not just CPU resources, but to all other resources also shared by the physical server.

Virtualization adds complexity. By now you’ve gathered that virtualization adds complexity. The most likely scenario is that you end up with a bunch of virtualized servers with disk files located on a SAN. There is also a good chance that you need some more education to maintain not just the ordinary Exchange server environment, but also to manage the virtualization platform as well as the SAN infrastructure.

There is always going to be a time when something happens to the environment for unknown reasons, which inevitably leads to really complex troubleshooting. In smaller companies there is often one person maintaining everything in IT; but in larger companies there are several departments maintaining one piece of the puzzle, making troubleshooting even more complex! Situations might arise that involve several people blaming each other, saying things like ‘There is nothing wrong with my SAN!’ I’m sure many of you have taken part of such conversations.

Virtualization is not free. The complexity mentioned above is not free, unfortunately. Education costs money and time. If you also add the time spent on maintaining multiple systems and most likely some troubleshooting to get them working together, you can easily see that it will cost more money than a standard windows server with Exchange on it. An ordinary windows technician should be able to maintain a standard windows box with perhaps some local attached disk drives.

On the other hand, what can be free under some circumstances is the software license for the virtualization platform. Keep in mind, however, that this is often a small amount of money compared to all the labor and education costs that will be incurred. Plus, there might be costs associated with putting the environment in a SAN.

Flexibility. Virtualization technology is great for flexibility. It is often very simple to add resources such as disk or memory to a virtualized server, and if done correctly it is easy to add servers as they are needed. With the easy provisioning of servers, virtualization is great for lab environment where you often need to add or restore servers quickly. In a lab you can also test things and don’t need to be afraid of breaking your system since it is easy to restore them.

There is always the element of patching a running system. The process for patching a virtualized server is the same as for a physical one. Some people argue with this and say that they can do a snapshot of the server before patching and if something breaks they will just roll back the snapshot. This, however, is not feasible with Exchange since it relies on the configuration being in Active Directory.

Consider this scenario:

There is a patch for Exchange available that you want to install, so you do a snapshot of your virtualized Exchange server and apply the patch. After the reboot or restart of services you notice that the patch doesn’t work in your environment. ‘No problem,’ you think, ‘I will just go back to my snapshot.’ This is not the best course of action, however. Not only because you will “go back in time”, making people lose mail between the time when your snapshot was taken up to the present time, but also because this patch wrote or changed something in Active Directory. By going back, the installation before the snapshot doesn’t like the information being present in Active Directory, causing Exchange to fail. I don’t think this will be a common problem with Exchange, but it is something to be aware of. My recommendation is to do a snapshot of AD and Exchange at the same time as the rollback, not separate.

Exchange supportability Running virtualized is not limited to use of Microsoft technology with Hyper-V. Microsoft has a program called Microsoft Server Virtualization Validation Program (SVVP) http://www.windowsservercatalog.com/svvp. This program allows other vendors to go through tests so that their virtualization technology can be validated and approved by Microsoft. Being a vendor that is a member of SVVP makes it supportable by Microsoft to run Exchange on; therefore you are not limited to Hyper-V.

Microsoft has published a document with policies and recommendations for running Exchange 2007 and Exchange 2003 virtualized, and can be found here: http://go.microsoft.com/fwlink/?LinkId=124624

Information about Exchange 2010 will be published shortly, but in essence it will be very much the same as for Exchange 2007.

This document should be read carefully by the people doing Exchange design work, otherwise you may be out of support from Microsoft. Most important point to remember is that your storage and high availability are designed correctly.

Security is of course something to think about, and the virtual servers we treat the same way as if they were physical. Those servers must be protected and patched just like any other server. There is also the challenge of who can access and manage the virtualized environment? Running Exchange in a virtualization environment adds complexity in terms of security, and is definitely something to consider carefully.

Ask yourself some questions:
What if someone could get access to the physical servers and simply copy the disk file? That person could then sit quietly and try to withdraw data from the file. Thus, it is important to think about permission on files, servers and management tools.

What about if you move a virtualized Exchange server to a physical server that is not located inside a locked computer room, or to a hardware that doesn’t have the needed resources? As you can see, security around virtualization involves many components.

Now that you have all the information, let’s return to the original question about running Exchange in a virtualized environment. Ready for my final answer? Yes, it can be done and many benefits will be incurred as a result, but you must play close attention to the design outside of Exchange and keep in mind all the prerequisites, pitfalls, and misconceptions that you could face.

Granting Granular Administrative Permissions in Exchange 2010

2009-12-08T13:00:00.000-08:00

By ESE Contributing Author Hans Willi Kremer

Exchange 2010 provides a role-based administration architecture, and consequently permissions can be granted on a very granular level. Built-In groups are available, but a question that might arise in your organization is, How can I grant permissions to a Help Desk colleague so that s/he is only able to modify the SMTP address of a user? What tasks must I perform in Exchange 2010 to accomplish this? To answer these questions, I would like to share with you the below example which demonstrates a very unique requirement and its solution.

The example is based on Exchange 2010 RC with a help-desk user called Garry

1. Create a new management role, wich is derived from role „Mail Recipients" New-ManagementRole -Parent "Mail Recipients" -Name "MgmtRole SMTP Modifcation"The object is stored in "/Configuration/Schema/ms-Exch-Role"

Note: Remove roleRemove-ManagementRole "MgmtRole SMTP Modifcation" -confirm:$False

2. Check which cmdlets are allowed in this roleGet-ManagementRoleEntry "MgmtRole SMTP Modifcation\*" Format-List

3. Remove all RoleEntries from this role except „Set-Mailbox" Get-ManagementRoleEntry "MgmtRole SMTP Modifcation\*" Where-Object {$_.identity -ne "MgmtRole SMTP Modifcation\Set-Mailbox"} Remove-ManagementRoleEntry -confirm:$False

4. Check if all cmdlets in this role are removed except „Set-Mailbox" – additionally check the paramertersGet-ManagementRoleEntry "MgmtRole SMTP Modifcation\*" Format-List

5. Remove all parametersSet-ManagementRoleEntry "MgmtRole SMTP Modifcation\Set-Mailbox" -Parameters $Null

6. Check, which parameters of cmdlet „Set-Mailbox" are allowed in this role(Get-ManagementRoleEntry "MgmtRole SMTP Modifcation\Set-Mailbox").Parameters

7. Add the parameters which can be used by members of role group when they execute cmdlet Set-Mailbox Set-ManagementRoleEntry "MgmtRole SMTP Modifcation\Set-Mailbox" -Parameters Identity, PrimarySMTPAddress, EmailAddresses -AddParameterHinweis: Entfernen eines ParametersSet-ManagementRoleEntry "MgmtRole SMTP Modifcation\Set-Mailbox" -Parameters Identity -RemoveParameter

8. Check that only granted parameters of cmdlet can be used(Get-ManagementRoleEntry "MgmtRole SMTP Modifcation\Set-Mailbox").Parameters
9. Create a new role group and link it with roles and membersNew-RoleGroup -Name "MgmtRoleGroup SMTP Modifcation" -Roles "MgmtRole SMTP Modifcation" -Members Garry

Note: remove a rolegroupRemove-RoleGroup -Name "MgmtRoleGroup SMTP Modifcation"

10. Link a user with a rolegroupAdd-RoleGroupMember "View-Only Organization Management" -Member Garry

Note: removemember from rolegroupremove-RoleGroupMember "View-Only Organization Management" -Member Garry

11. Note: behind the scene a linkobject MgmtRole SMTP Modifcation-MgmtRoleGroup SMTP Modifcation" has been created to link the rolegroup with the role.Get-ManagementRoleAssignment -Role "MgmtRole SMTP Modifcation" fl identityremove-ManagementRoleAssignment "MgmtRole SMTP Modifcation-MgmtRoleGroup SMTP Modifcation"

12. Final test: user Garry executes these cmdlets to try if he can modify some attributes of user be01 in domain xchg10.com

Set-Mailbox be01@xchg10.com -alias "bbbb"expected result: A positional parameter cannot be found that accepts argument '-alias'.

Set-Mailbox be01@xchg10.com -ForwardingAddress administrator@xchg10.com expected result: A positional parameter cannot be found that accepts argument . .

Set-Mailbox be01@xchg10.com -CustomAttribute1 "Text"expected result: A positional parameter cannot be found that accepts argument . .

Set-Mailbox be01@xchg10.com -EmailAddresses "SMTP:bbb@xchg10.com" expected result: this works!

Exchange Server 2010: Database Availability Group

2009-11-24T13:33:00.000-08:00

By Raphael Barini

Now that Exchange 2010 has been officially released, I wanted to start with what I believe is one of the best features added to Exchange 2010. There may be some people who will miss a few features of Exchange 2007 that were removed; however, DAG is a feature that many administrators have been requesting for years. In order to keep the focus on DAG, let’s take a look and recap through Exchange.

Exchange 2007 was launched with some great features, and introduced the LCR, CCR, SCC and SCR.
If you would like more information on the High Availability features in Exchange 2007, check out this great article written by Exchange MVP Andy Grogan, in our ESE Volume 1, Issue 4.

LCR (Local Continuous Replication), this was mainly used in small businesses who wanted to have a local copy of their Exchange database replicated to another disk on the same server:

SCC (Single Copy Cluster) this one is that I call a traditional Exchange cluster, in which you use a shared storage to host the Exchange database.

CCR (Cluster Continuous Replication) was used to replicate Exchange database between two Exchange servers, allowing for hardware and storage redundancy, but it has one limitation—just 1 active and 1 passive node.

SCR (Standby Continuous Replication) was introduced in Exchange 2007 SP1 to provide the ability to replicate Exchange databases to a disaster recovery location.

How we did in the past?

The concept of a DAG and how it functions is easier learned by someone who hasn’t worked with Exchange clusters previously because it is simple and easy to use in comparison to any other earlier version of Exchange.

In Exchange 2007, an Exchange server was installed as either an Active or Passive cluster node at the time setup.exe was run. Depending on which version of Exchange you installed, you had to create an Exchange virtual server (EVS) which was changed to cluster mailbox server (CMS) in Exchange 2007.

When a user connected to Outlook, the mailbox server name was a clustered resource which moved between any number of nodes on the Exchange cluster. This allowed for no end user configuration changes; instead, all the resources moved between physical servers.

An Exchange database was associated with the clustered resource and when you opened EMC/ESM the only Exchange server name that was shown was the clustered node (let’s call is CMSORG1.) That means database one would always belong to CMSORG1 even when this moved between physical machines.

Without further ado, here comes the DAG…

Now it’s time to forget everything that I mentioned previously about Exchange clustering.

What has been removed?
1) No more EVS/CMS
2) Database is no longer associated to a Server but is an Org Level resource
3) There is no longer a requirement to choose Cluster or Non Cluster at installation.

(An Exchange 2010 server can move in and out of a DAG as needed)
4) The limitation of only hosting the mailbox role on a clustered Exchange server
5) Storage groups have been removed as well from Exchange

What still have the same requirements?
1) Windows and Exchange Enterprise Edition is still required since DAG still uses pieces of Windows Failover Clustering

What is new in Exchange 2010 DAG?
1) Other roles can be installed on the mailbox server when it is a member of a DAG
2) A database name must be unique in the Exchange Organization

DAG can also be extended in multiple Active Directory Sites:

Let’s walk through the installation of Exchange 2010 and then setup DAG. To view the video, please click the link below, then click the full screen icon in the bottom right hand corner:

http://www.enowconsulting.com/video/

I hope you enjoy DAG as much as I do, and many thanks to Microsoft and the Exchange Team for this great new feature.

Installation of Exchange Server 2010 Tutorial

2009-11-10T19:30:00.000-08:00

By Ismail Mohammed, Exchange MVP

Since Exchange Server 2010 has been released, I am sure many administrators are eager to get their hands dirty in their Exchange Server 2010 labs. In this article, I will share the prerequisites and guidelines you must meet to ensure a successful Exchange 2010 installation in your lab.

Installation of Exchange 2010 uses the same method as Exchange 2007: the only significant change is the technology support version which needs to be suited for Exchange 2010.

Whenever we are thinking of Exchange 2010/Exchange 2007 installation, there are two major places which we need to focus on-- first one is Active Directory Preparation and the second one is Local Server Preparation.

Active Directory Preparation for Exchange 2010:
· Schema Master : Windows Server 2003 either standard or enterprise edition, recommendation have “windows server 2003 with SP 2,” which can be either 32-bit or 64-bit.
· Global Catalog Master : Windows Server 2003 either standard or enterprise edition, recommendation have “windows server 2003 with SP 2” which can be either 32-bit or 64-bit.
· The Active Directory domain & forest functional level must be Windows Server 2003-native or higher for all domains in the Active Directory forest where you will install Exchange 2010.
· Upgrade Schema - /prepare schema
· Exchange Security Groups & Permission : /PrepareAD
· LegacyExchange Support : /PrepareLegacyExchangePermissions

Existing Exchange 2003 in the Domain:

If you have Exchange 2003 in the organization then ensure that:
· Exchange 2003 has Service Pack 2 Installed
· It should be in the native mode.

Note: Exchange 2010 Beta Upgrade – If you want to upgrade from Exchange 2007, you can’t go with in-place upgrade, and one more thing there is no direct transition from Exchange 2007 to Exchange 2010 Beta . You need to create separate AD Site for Exchange 2010. Exchange 2007 co-existence transition will be supported after the release of Exchange 2007 sp2.

Server-level Specification:

Hardware:
· Processor : Intel 64-bit Processor\ AMD64 Processor (Production)
· Processor supported for 32-bit : Intel Pentium or compatible 800-megahertz (MHz) or faster 32-bit processor

Memory : Depends upon the actual requirement minimum 2 GB plus 2\3.5\4 MB per mailbox and can support up to 64 GB. For more information click here

Mailbox server memory recommendations:

Light = 2 GB plus 2 MB per mailbox
Average = 2 GB plus 3.5 MB per mailbox
Heavy = 2 GB plus 4 MB per mailbox

Source: Microsoft

· Disk Space : 1.2 GB free for the drive where we are installing the Exchange, 500 MB more space if we are installing UM, 200 MB free on the system drive and 500 MB free space for Transport Server role
· Drive : DVD-Rom or Network Access
· Software:Operating System : Windows Server 2008 Standard or Enterprise with SP2 or R2 Edition or just to install the console Vista with latest SP is supported.
· Other Software Requirement : there is other software required and actually it depends upon which roles you are installing and based on that you can select the required one.

Exchange2010 Pre-requisites

My requirement is very simple: a clean installation of Exchange 2010 on windows server 2008 where I will install all the Exchange Server roles except Edge Transport Server Role.

Active Directory Preparation:

· Raising the Domain Function level & Forest Functional Level to Windows Server 2003: Log into to the windows server 2003 domain controller => Administrative Tools => Active Directory Domain and Trusts => Right click the domain name and select “Raise Domain Functional Level” and raise it to “Windows Server 2003”

· Forest Functional Level : Right click “Active Directory Domain and Trusts and select “Raise Forest Functional Level” as Windows Server 2003Server – Level Configuration :

1) Install IIS 7.0 : Inorder to do this, open Server Manager Console => Roles => Add Roles and select “Web Server (IIS)”

Figure2:

Under Role Services Windows select the following component:
· Basic Authentication
· Windows Authentication
· Digest Authentication
· Dynamic Content Compression
· .net extensisbility

Figure 3:

2) Remote Server Administration Tools pack : It is a feature included with Windows Server 2008. You can install the Remote Server Administration Tools pack by using either the Add Features Wizard in Windows Server 2008, or by using a command line to install the feature.Command prompt : ServerManagerCmd -i RSAT-ADDSFrom GUI:
· Open the Server Manager Console
· Click on Features and then Add Features and select Remote Server Administration Tools
· It will ask you to install IIS6 Management Compatibiltiy also select “Add Required Role Service and then click on NEXT

Figure 4:

3) Install HTTP Activation:
· Open the server manager console
· Features => Add Features
· Expand .Net Framework 3.0 Features
· Expand WCF activation and Select “HTTP Activation”

Figure 5:

4) For Unified Messaging Role we need to have "Windows Media Audio Voice Codec" and "windows Media Encoder" this can be installed by installing Desktop-Experience Component via server manager
· Open the server manager console
· Features => Add Features
· Select Desktop Experience

Figure 6:

OR else you can excute the installation of Server Manager Role and Features from the command prompt by running below command:

For Client Access Server Role:

ServerManagerCmd -i RSAT-ADDS
ServerManagerCmd -i Web-Server

ServerManagerCmd -i Web-ISAPI-Ext
ServerManagerCmd -i Web-Metabase
ServerManagerCmd -i Web-Lgcy-Mgmt-Console

ServerManagerCmd -i Web-Basic-Auth
ServerManagerCmd -i Web-Digest-Auth

ServerManagerCmd -i Web-Windows-Auth
ServerManagerCmd -i Web-Dyn-Compression
ServerManagerCmd -i NET-HTTP-Activation
ServerManagerCmd -I RPC-over-HTTP-proxy

For Hub Transport Server Role:
ServerManagerCmd -i RSAT-ADDS
ServerManagerCmd -i Web-Server
ServerManagerCmd -i Web-Metabase

ServerManagerCmd -i Web-Lgcy-Mgmt-Console
ServerManagerCmd -i Web-Basic-Auth

ServerManagerCmd -i Web-Windows-Auth

For Mailbox Server Role:

ServerManagerCmd -i RSAT-ADDS
ServerManagerCmd -i Web-Server
ServerManagerCmd -i Web-Metabase

ServerManagerCmd -i Web-Lgcy-Mgmt-Console
ServerManagerCmd -i Web-Basic-Auth

ServerManagerCmd -i Web-Windows-Author

ServerManagerCmd -i Failover-Clustering (for Clustering)

For Unified Messaging Server Role:

ServerManagerCmd -i RSAT-ADDS

ServerManagerCmd -i Web-Server

ServerManagerCmd -i Web-Metabase

ServerManagerCmd -i Web-Lgcy-Mgmt-Console
ServerManagerCmd -i Web-Basic-Auth

ServerManagerCmd -i Web-Windows-AuthServerManagerCmd -i Desktop-Experience

For Edge Transport Server Role:

ServerManagerCmd -i ADLDS

5) Install .netframework 3.5 Sp1

6) Install Powershell V2

7) Install Windows Remote Management

8) Install Windows6.0-KB950888

9) Install Windows6.0-KB951725

10) Install 2007 Office System Converter :

11) Run Exchange 2010 setup

Figure 7:

Click on Step 4: Install Microsoft Exchange

12) Next Screen will be Introduction page, click on NEXT

Figure 8:

13) Now you will get "Language File Location" in which you can download the other languages apart from English and size of the pacakge will be 200 MB. By default I had chosen the "english"

Figure 9:

14) Next Screen will be "Language Pack Confirmation" - Click on Next

Figure 10:

15) EULA - Select "I Agree" and Click on Next

16) Error Reporting : It is upto you how you to set the option and click on NEXT

17) Installation Type : Select either Typical or Customize Option based on the required role to be installed. I have selected customized options

Figure 11:

Note : The path of the Exchange Database "C:\Program Files\Microsoft\Exchange Server\V14"

18) Server Role Selection: Depends upon your requirement, I had selected Mailbox, Client Access, Hub Transport & Unified Messaging

Figure 12:

19) Organization : If you have not ran /PrepareAd and you are running the setup from GUI it will ask you to provide Organization Name

Figure 13:

20) Cusotmer Experience Improvement Program : You can select either "Join" or "I don't Want to Join"

21) Readiness Check: In this step, Exchange 2010 will check will the required pre-requisite has been met or not like you have required schema master server, global catalog server, domain controller, schema is updated or not, domain functional level setting, all the software has been installed on this specific server or not. In other words it will do a readiness check on the Active Directory requirement part and Server Level Requirement Part.

Figure 14:

22) Click on Install as per the above figure: It will install Exchange Server Roles and then take a reboot of the server.

Figure 15:

Let's take a look at the Exchange 2010 Options under program files:

If you see the above screen, there are two powershell commands:

i) Exchange Management Shell & ii) Exchange Management Shell (Local Powershell), Console View: Some of the new changes (marked one) -

This is just a glance view:

You can see that database is in the organization level, under recipient configuration we have "mailbox migration."

There is a lot more to come on the way...

Reference:Microsoft Exchange Server 2010 (Beta)

Thinking about Exchange 2007 SP 2?

2009-10-13T12:23:00.000-07:00

By Raphael Barini, MCITP Enterprise Messaging Administrator

For many longtime Exchange administrators, the return of native backup capabilities for Exchange servers deployed on Windows Server 2008 servers is exciting news. Under Exchange 2003 systems, administrators could make ad-hoc backups using Windows’ built-in backup utility. Much to peoples’ dismay, this capability did not make its way into Exchange 2007 on Windows Server 2008. With the installation of SP2, Exchange administrators running on Windows Server 2008 receive a VSS plug-in that enables Windows Server Backup to address this negative situation. To see more information about Backup in-box running on Windows Server 2008 please visit the following link: http://msexchangeteam.com/archive/2009/05/13/451311.aspx

In order to deploy Exchange Server 2010 into an existing Exchange 2007 organization, the Exchange servers in the Exchange 2007 organization must be updated to Exchange 2007 SP2. This is mostly due to the fact that, with Exchange 2010, Microsoft is making major changes to the way Outlook clients communicate with Exchange mailboxes. Under Exchange 2007, Outlook clients communicate directly with mailbox servers, bypassing the Client Access server role used by other communications methods, such as Outlook Web Access and IMAP. Under Exchange 2010, Outlook 2010 clients will also communicate with Client Access servers rather than directly with mailbox servers.

In an increasingly regulated business environment, one can never have too much in the way of auditing capabilities. This is another area in which Exchange 2007 SP2 doesn’t disappoint. SP2 adds significant access auditing capabilities that can track such events as folder and message access events, making it possible to determine who has opened a particular folder or message. Access auditing can be configured on different levels of verbosity so you can track only what you need. If you suspect that someone is gaining unauthorized access to someone else’s mailbox, this new feature can be a very powerful sleuthing tool.

Although public folders are, in my opinion, becoming more and more of a nuisance, they are supported in Exchange 2007 SP2. Under Exchange 2007 SP2, Microsoft has replaced the legacy public folder management paradigm with new commandlets and parameters that enhance public folder administration.

Exchange 2007 SP2 is cumulative upgrades, meaning that you can use the SP2 media to upgrade from any version of Exchange 2007 — RTM or SP1. The SP2 installation does make Active Directory schema changes, so make sure that you have appropriate rights before you kick off the upgrade. In fact, the SP2 installer extends the Active Directory schema with Exchange 2010 RTM extensions.

Further, Exchange 2007 SP2 requires that Windows Installer 4.5 be installed. If you’re installing Windows Server 2008 SP2, you’re all set. If, however, you’re running Windows Server 2003 or Windows Server 2008 SP1, make sure you upgrade Windows Installer.

Microsoft recommends that you update to Exchange 2007 SP2 in the following order:
· Client Access servers
· Unified Messaging servers
· Hub Transport servers
· Edge Transport Servers
· Mailbox servers

Exchange 2007 SP2 pre reqs:

1) Extend the your Active Directory Schema
2) Prepare Active Directory
3) Have Installed into each exchange server box the Windows Installer 4.5
4) Uninstall Interim Updates, these are the updates that you had installed for a specific reason in your exchange server box, and is not included into the Cumulative Packages or Service Packs, this should be done first to install SP2, if you don’t uninstall your SP2 installation will fail
5) Remove any Unified Messaging Language Pack that you had installed in you Exchange UM server, the SP2 needs to have just English version installed, after you apply the SP2 you can install your UM Language Pack back again

If you have a SCC or CCR cluster, you should apply your SP2 in your passive node first, than restart the server, perform a failover from the active to passive node, than apply the SP2 in the current passive node, after you did that you should rung UpgradeCMS cmdlet to upgrade your Clustered Mailbox server.

For CCR cluster checks these steps:

1) In the passive node run: Setup.com /Mode: Upgrade

2) Setup runs the exchange pre-requisites check for the mailbox role:

3) Setup successfully finishes:

4) Once the passive node is upgraded, restarted and is back online, run the following command:

Stop-ClusteredMailboxServer MBX –StopReason “SP2 Upgrade” (where MBX is the name of your CMS)

5) Confirm the steps:

6) Check if cluster status is Offline:

7) Move the mailbox from active to passive node:

Move-ClusteredMailboxServer MBX –TargetMachine CCR2 –MoveComment “SP2 Upgrade” (MBX is your CMS and CCR2 is your current passive node that was upgraded with SP2)

8) Upgrade the CMS:

Setup.com /UpgradeCMS

9) Upgrade the initial Active node: setup.com /Mode:Upgrade

10) Check the pre-requisite and the success of your SP2 upgrade:

11) Restart the server and now you have an Exchange 2007 SP2 CCR

For AD preparation and extend the schema

You should extract the SP2 files into each Exchange box them run the following steps:

1) Extend the schema-- I recommend you to have a System State backup first from your Schema Master domain controller and if you are running a Virtualized environment or have a lab server, apply the Extended schema changes into these environment and if everything is working fine you can go ahead and apply into your production server:

setup.com /PrepareSchema

2) In order to prepare Active Directory you must meet all the pre-requisites:
· You must be running the Exchange 2007 setup with a domain account that is a member of the Enterprise Admins security group.
· The machine on which you run the Exchange 2007 setup schema extension process must be a member of the same domain and Active Directory site as the Schema Master.
· The machine on which you run the Exchange 2007 setup schema extension process must be:
o Windows Server 2003 SP2 with Windows Installer 4.5 installed
o Windows Server 2008 with Windows Installer 4.5 installed
o Windows Server 2008 SP2
o To extend the schema, you simply run this command from an administrative command line:

setup.com /PrepareAD
Upgrade other Exchange server roles

For the other Exchange roles, just run the command: setup.com /Mode:Upgrade

Accept all default options when you perform the steps from the command line.

I hope all those new features are good for your organization and if you have any doubts, please contact me. Also I recommend you to check the following links:

Exchange Server 2007 SP2 release notes:
http://download.microsoft.com/download/8/3/E/83E9DB24-0041-4F7E-A0DD-26043BBF7CAA/RelNotes.htm

Download Exchange Server 2007 SP2:
http://www.microsoft.com/downloads/details.aspx?FamilyID=4c4bd2a3-5e50-42b0-8bbb-2cc9afe3216a&displaylang=en

What is new in Exchange Server 2007 SP2:
http://technet.microsoft.com/en-us/library/ee221150.aspx

Exchange 2010: The New Archiving Feature

2009-10-13T11:00:00.001-07:00

By ESE Contributing Author Lasse Pettersson, Exchange MVP

There is a lot of buzz surrounding the new archiving feature in Exchange Server 2010. But where there is buzz there are always the unavoidable rumors and misunderstandings surrounding the new feature.

When you ask an Exchange administrator about archiving, most of them think of the archiving product as a tool that replaces messages and/or attachments with a shortcut often called a stub, and then takes the original item and stores it in the archive system. This is a deeply-entrenched misunderstanding, and when Microsoft revealed that the Exchange 2010 archiving function does not take items away from Exchange store, people started to shout and exclaim, This is not a true archiving solution! I admit that at first I agreed with this outcry from the Exchange community, but the more I thought about it, the more I realized there are good reasons to keep items inside Exchange.

First, you must put yourself in the shoes of a regular user. He or she often has a mailbox quota enforced and when the user gets a warning message they typically move items away from Exchange and store them in a PST file. This seemingly innocent move causes a very big problem. PST files, as their name implies, stands for Personal Store and should be stored locally on end users’ hard drives. The result? There is no longer any backup on those mail items, and even if you go the unsupported route and save the PST file on a file share somewhere, the backup software often has issues with doing backup of these files since Outlook has them open. What about using special tricks, such as open file agents, you might ask? Unfortunately, the backup software will still experience difficulty in performing the backup of open files even with such tricks. Outlook also changes the archive bit on the PST file, which in turn triggers the backup software to perform a backup even if there is no change in the file from Outlook. This will cause the backup to run for an extensive length of time since there are typically many PST files scattered across numerous file shares.

Another roadblock administrators may face when storing PST files “over the network” is that networks are unreliable and do not always function properly. Even if the networks are working, users are prone to closing the lid on their laptops, causing the network link to close and the PST file to corrupt since it was not properly closed by Outlook. This is also the main reason why PST files are not supported on file shares. The corrupt PST file is also notorious for engendering end users to call the help desk, and essentially forcing the administrator to initiate a restore of the hopefully backed up PST file. Other problems exist with PST files located on a share, including but not limited to: slow network performance when open, and when closing Outlook.

The risk of taking data out of Exchange and storing it inside PST files is that you are moving corporate data from a safe environment located inside Exchange databases to an unsafe environment. Since PST files can easily be corrupted and/or lost, they are not a secure alternative to storing business-critical data. By moving corporate data out of Exchange you may in essence be breaking laws regarding retention and compliance because the administrator no longer has control of email content. Let us not forget that corporate assets are in danger of being lost by moving data out of Exchange.

Other issues to consider include legal discovery and reducing the burden of searching and restoring mail data. When moving data from Exchange to PST files, you have the potential of losing all those things.

Other archiving solutions often solve all or many of the aforementioned problems by using the “stub” approach, and can provide some kind of search capability.

The stub approach is something that most vendors claim to be a viable alternative, but keep in mind this also introduces problems since items are removed from Exchange and are no longer indexed and searchable from a native client, forcing you to utilize the vendor client. That process entails installing and maintaining another client, which can be complex both for the end user and for the administrator. Most vendors also claim that you would reduce the amount of data in Exchange with the stub approach. That is often true, but in many cases you do not reduce the data as much as you expect since the stub is another item in the Exchange database with a couple of Kb in size. By replacing a 10Kb mail with a stub of 5 Kb, you only save 5Kb of data. This is something that you should consider if you import PST files to Exchange and then archive those imported items-- this will in fact increase mailbox size by a couple of Kb per item you import even if you later archive it.

Microsoft’s approach to archiving in Exchange 2010 is not to move items from Exchange and store it somewhere else, but in fact to leave it inside Exchange. There are several reasons for this. By leaving data inside Exchange, both users and administrators no longer need to learn and manage another system. The end user experience is the same as having a PST file connected to Outlook, and users can still drag and drop mail back and forth between their mailbox and the archive, making it incredibly simple for users to take their PST files and import them to the archive. Administrators would be happy since they no longer must cope with all the problems caused by PST files, but users will also be happy since the archive is indexed and searchable. Some companies must also comply with regulations and policies that force them to do searches across multiple mailboxes. This is also built in and is performed from the Exchange Control Panel (ECP) by users that have the delegated permission to do so. You can also turn a mailbox on ‘Litigation hold,’ meaning that even if a user deletes items, empties their ‘Deleted Items’ folder, and clears the dumpster area, mail is still maintained in the new Exchange 2010 dumpster version 2 area. This area is not reachable by end users but only by members of the ‘Discovery Management’ role group.

But what about the increased database size in Exchange?

The archive is technically an additional mailbox in the same database as the primary mailbox and shows up in Outlook in the same way a PST file would. People often react and say that the archive must not be in the same database because it should be on cheaper storage-- that’s fair and is most viable if we are talking about Exchange 2003. It’s common knowledge that the IO load that Exchange 2007 places on your storage has dropped by approximately 70% as compared to Exchange 2003, and with all the enhancements done for Exchange 2010, the IO footprint has dropped about the same amount again, making it possible to run all your Exchange databases on cheap and less performing disks. This means that you don’t need the costly SAN for your Exchange databases but in fact can use cheaper storage like SATA disks.
What about backup and restore time?With the increased volume in Exchange databases, you may think that the backup time will increase, but that is not entirely true. The streaming backup API is taken away from Exchange 2010 and what is left is the VSS API for backup. With VSS, you only do backup of the changed blocks on disk and most of the mail in the archive is just sitting there, and therefore the block on disk is never changed. Sadly, the story for doing restore is not improved, and with the increased volume you also get increased restore time. But there is a simple solution for that-- don’t do backup. This is a very controversial thing to say, but with Exchange 2010 Database Availability Group (DAG), you can replicate data to several mailbox servers (up to 16) and if a database or disk blows up, another copy of your databases will be set as primary, and most likely will not even be noticeable to the end user since all client connections don’t go direct to mailbox servers but instead go to Client Access Servers (CAS). You can also stretch members in the DAG across datacenters to solve the case where a datacenter stops working. It also provides a replica of your data offsite. So the question to ask is, Why do you backup your Exchange data? http://anewmessagehasarrived.blogspot.com/2009/05/why-do-you-backup-exchange-databases.html

Why bother creating an archive mailbox at all?

The reason for creating an archive mailbox is probably something you base on the size of each user’s data volume. It is only the primary mailbox that is synced to the cached Outlook, and Outlook has issues with performance if the OST file is growing large. Therefore, by moving data to the archive the OST file will be smaller and Outlook will in turn perform better in cached mode. To see the archive, you must be online and have contact with Exchange and be using Outlook 2010 or OWA 2010, hence the name ‘Online Archive.’

Must users manage their archive manually?No, the administrator can create policies that either move mail from mailbox to archive or delete mail. This is similar to what was first introduced in Exchange 2003 as recipient policies that were often used for clearing things out of the mailbox to the ‘Deleted Items’ folder or delete items completely. In Exchange 2007 this feature was enhanced a bit and changed its name to Message Record Management (MRM), and displays as Managed Folders in EMS and EMC. Exchange 2007 also introduced ‘Organizational Folders’ that could hold certain policies regarding how long mail must be maintained and what to do when they expire.The problem with MRM version 1 was that it could only be applied to a folder or type of message, not one individual mail. With Exchange 2010 the administrator can still use the old way of applying policies on folders, but there are also new policies that allow users to apply a policy directly to individual mail items, (MRM version 2 if you will.) Policies are created by the administrator and if applied to folders, then users have the option to apply policies on individual mail items depending on how the policies are created.

The administrator can set different quotas on the primary mailbox and the archive. An example would be that the primary mailbox quota is 2GB and the archive is 15GB. With a couple of policies the administrator can choose to delete everything older than 10 years, and messages older than 1 year are moved to the archive. There also exist a couple of user policies that a user can set, allowing them to: ‘Keep this message for 5 years,’ ‘Keep this message for 1 year,’ ‘Delete this message in a month’ or ‘Delete this message in 5 months,’ giving a very flexible and efficient way of managing messages in Outlook.

Microsoft definitely has a good thing going with their Exchange 2010 archiving solution. For those of you not swayed yet, keep in mind that this is the first version of archiving within Exchange. The archive makes it possible to get rid of PST files and along with them all the problems they cause. Any administrator would agree that having data safely inside the Exchange store, managed and searchable with Exchange native tools, instead of having extra software and hardware to maintain, is worth disregarding any rumors or misconceptions surrounding this brand new feature.

Looking for an easy way to synchronize GALs between organizations?

2009-09-08T11:00:00.000-07:00

By ESE Contributing Authors Hans Willi Kremer and Jay Gundotra

Communication Shifts and Demands:

In today’s ever-changing marketplace, many companies have made strategic shifts and are acquiring smaller firms or merging with larger ones to maintain their competitive position. Even outside of the M&A trend that has been witnessed across numerous industries, is the trend towards globalization. No matter what size, small or large, any company working on an international level must manage multiple Active Directories and multiple Exchange organizations. To streamline the communication between employees working with various divisions or OUs (organizational units) within their same organization, Outlook users can save pertinent information such as all email addresses and phone numbers for other colleagues in their Global address list.

Country boundaries are not the only barrier to communication within companies with multiple ADs and OUs. Even if you work for a small domestic firm, you still need a way to effectively combine Global Address Lists if your firm decides to synchronize all of its crucial operational data with a parent company.

When you open Office Outlook, compose a new email, and click on the “To” button, then all email addresses of your companies’ employees will appear. When dealing with multiple divisions, OUs, or even two different companies working together consistently, the question arises, What about your colleagues working in the other company or OU? Isn’t their email and contact information just as important?

Common Scenario:

A well-known US health company has more than 30 subsidiaries. Each subsidiary typically has its own Active Directory with Exchange.
It is obvious that the users in these two organizations know each other, but they do not have a centralized repository of data that is necessary for consistent mail communication. The faster employees can communicate with the necessary people, the more productive and happy everyone in the organization will be.

Challenges Faced When Communicating without Synchronized GALs:

One of the disadvantages of this topology is that Outlook users can only list the mail addresses of their own Active Directory in Outlook’s Global Address List (GAL). What happens to all the people who must communicate regularly with a colleague who is not listed in a centralized repository? The solution seems simple, but like everything else that seems too good to be true, it is! The temporary solution might be simple, but it is tedious and time-consuming, since employees add the missing contact information of colleagues to their personal address books. This is only a quick fix, however, for the next time something changes in that colleague’s contact information (i.e. phone number), the personal address book will not recognize the change, and the next phone call will mismatch. This will cause the user to have to manually make the change themselves, instead of having a simple software solution that does all the synchronization automatically.

Current Solutions in the Marketplace:

Microsoft Identity Integration Server and IIFP

ILM 2007 Architecture:

With Microsoft Identity Integration Server, Microsoft took a first crucial step by offering a newly- developed software product to synchronize identity information between different data sources. MIIS 2003 offered a lot of agents for multiple data sources such as database servers, flat files and Active Directory. This powerful yet complex identity management system offered all features for the synchronization of users’ metadata data. This is needed in companies where users’ attributes are administrated in different sources.

Example: A user’s phone number is administrated in an Oracle database used by the phone system, but the user’s name is administrated in Active Directory, and the department is administrated in an ERP-system.

As part of their Identity Integration Server, Microsoft offered a cost-free solution called Identity Integration Feature Pack 2003 (IIFP), which was limited to Active Directory and ADAM as data sources.

Customers could now realize a synchronization of Global Address Lists between different forests using IIFP without requiring licenses.

Even with the help of the IIFP, there are several hoops an administrator must jump through before implementing the synchronization. For instance, it was recommended that a dedicated SQL Server host all Delta data. Administrators needed to spend nearly a week if not longer to understand, implement and configure the product, which brought its own host of new terminology for the administrator to learn, deriving from Identity Management systems. Due to this complexity, most often this work was performed by external consultants specializing in MIIS. Support for MIIS/IIFP was finished in 2008.

Identity Lifecycle Manager 2007 (ILM) is MIIS’ successor. ILM “2” also provides self-service capabilities for end users, for example self-service tasks such as group and credential management via Microsoft Office and Windows.

Unfortunately, a cost-free solution like IIFP is not intended by MS.
Microsoft decreased pricing for ILM 2007 (from $10,000 up) but the inherent challenge with the software still existed—its complexity. For E-mail and messaging there are Management Agents available for Microsoft Exchange 2007, 2003, 2000 and 5.5, Lotus Notes 7.0, 6.x, 5.0, and 4.6.

Getting GAL in sync between forests ILM 2007 is certainly a viable option, but it requires extensive preparation on the administrator’s part. Another stumbling block for IT teams attempting the synchronization of GALs is that there must be a direct connection between the data sources, which most companies prohibit due to firewall restrictions.

GALsync:

In order to keep the software more configurable and easier to implement, GALsync is focused only on synchronization of Global Address Lists between multiple Exchange Organizations; it is not intended to act as general identity management software.
The sync is done by an export of data from source Active Directory and an independent import at target side.

Data might be exchanged using ftp-server or a common Windows share, but the most powerful feature is using SMTP as protocol. This enables all companies with restricted firewall policies to exchange GAL data over the internet. In addition, data can be secured by a built-in encryption method.

Installation and customization of the software requires only 1 or 2 hours. Administrators are walked through the process by an easy-to-use, wizard-based graphical user interface. Scheduled jobs are run by an independent service.

At export side, the selection of objects is customizable (i.e. OUs, groups, etc), along with the properties included for sync. At import side, attributes’ values might be customized (i.e. suffix appended to display name), as well as some extended features for multi-organizations sync.
No additional soft- or hardware is needed-- GALsync can be installed on any domain computer and works with Microsoft Exchange organizations based on 2010, 2007, 2003 and 2000. Pricing depends on number of forests and objects to sync (from $750 up).

To have GALs in sync between forests, GALsync is an affordable and flexible solution that does not burden the Exchange administrator with extraneous, complex identity management features. GALsync is developed by the German company NETsec which specializes in Active Directory and Exchange.

To learn more about these GAL synchronization tools, please visit:

ILM 2007: http://www.microsoft.com/windowsserver/ilm2007/overview.mspx
GALsync: http://galsync.netsec.de/

ILM 2007 Architecture source:
(http://www.microsoft.com/windowsserver2008/en/us/ida-identity-lifecycle-management.aspx)

Outlook Whenever Wherever – Outlook Anywhere (Shakira, Shakira) – Part 2: Completing the Configuration and Troubleshooting…

2009-08-10T15:22:00.001-07:00

In the last part of this two part series we covered the importance of understanding your DNS domain naming and indeed the correct configuration for your SSL SAN based certificate. We also covered how you can get your SSL certificate issued and indeed how you can install it on your Client Access Server ready for the final configuration steps.

In this part I would like to go through those steps, give you an overview of how you can connect Outlook 2007 / 2003 to OA and some troubleshooting steps which can be used if you hit any problems.

Configuring the Client Access Server for OA (and OWA, and OAB):

Now this is perhaps the most important bit and requires the most concentration – please follow these instructions very carefully.

It is here where the understanding of your Internal and External domains is paramount, and indeed knowing where to use the relevant SAN names which you had placed on your SSL certificate.

All URLS which are used here must point via DNS (either internally or externally) at your Client Access Server.

For the purposes of this article the following is the make up of my URL structure (you will note that all of the following were added to my Example SAN Certificate discussed in the previous section:

Internal URLS:

flangemanifold.local – used as the root lookup for the Autodiscover Service
autodiscover.flangemanifold.local – used as the Autodiscover DNS domain
owa.flangemanifold.local – is used for both Internal OWA, OAB Download and the Web Services URL
FM-EXCAS-01 – NetBIOS name of the Client Access Server

External URLS:

flangemanifold.com – used as the root domain lookup for the Autodiscover Services
autodiscover.flangemanifold.com

Configuring the Autodiscover Virtual Directory:

From the Exchange Management Shell on your Client Access Server type in the following commands:

Set-AutodiscoverVirtualDirectory -id "FM-EXCAS-01\autodiscover (Default Web Site)" -InternalUrl https://owa.root.flangemanifold.local/autodiscover/autodiscover.xml

Set-AutodiscoverVirtualDirectory -id "FM-EXCAS-01\autodiscover (Default Web Site)" –ExternalUrl https://owa.flangemanifold.com/autodiscover/autodiscover.xml

See below:

When you have completed the above you need to ensure that the Authentication Settings are correct on the Auto Discover virtual Directory in order to do this type in the following commands:

Set-AutodiscoverVirtualDirectory -id "FM-EXCAS-01\autodiscover (Default Web Site)” –BasicAuthentication:$True

Set-AutodiscoverVirtualDirectory -id "FM-EXCAS-01\autodiscover (Default Web Site)” –DigestAuthentication:$False

Set-AutodiscoverVirtualDirectory -id "FM-EXCAS-01\autodiscover (Default Web Site)” –WindowsAuthentication:$True

Configuring the Webservices Virtual Directory:

Again from the Exchange Management Shell on your CAS type in the following command:

Set-WebServicesVirtualDirectory –id “FM-EXCAS-01\EWS (Default Web Site)” –internalURL “https://owa.root.flangemanifold.local/EWS/Exchange.asmx –externalURL https://owa.flangemanifold.com/EWS/Exchange.asmx

See below:

Again ensure that your authentication settings are correct by running the following commands:

Set-WebServicesVirtualDirectory –id “FM-EXCAS-01\EWS (Default Web Site)” -BasicAuthentication:$True

Set-WebServicesVirtualDirectory –id “FM-EXCAS-01\EWS (Default Web Site)” -DigestAuthentication:$False

Set-WebServicesVirtualDirectory –id “FM-EXCAS-01\EWS (Default Web Site)” -WindowsAuthentication:$True

Configure the Client Access Server Autodiscover InternalURI:

From the Exchange Management Shell on your CAS run the following command:

Set-ClientAccessServer –id fm-excas-01 –AutodiscoverServiceinternalUri https://autodiscover.root.flangemanifold.local

Configure the OAB Virtual Directory:

From the Exchange Management Shell on your CAS run the following command:

Set-OABVirtualdirectory –id “FM-EXCAS-01\oab (Default Web Site)” –internalURL https://owa.root.flangemanifold.local/oab –externalURL https://owa.flangemanifold.com/oab

See below:

Enable Outlook Anywhere:

Yes – this is it, the final part of configuration (hopefully), from the From the Exchange Management Shell on your CAS run the following command:

Enable-OutlookAnywhere –Server FM-EXCAS-01 –ExternalHostname owa.flangemanifold.com –clientAuthenticationMethod:Basic –IISAuthenticationMethods Basic –SSLOffloading:$False

See below:

You might be presented with a warning message (as per above) letting you know that your settings might not take affect for 15 minutes. Given the configuration changes that we have made – I recommend that you allow for an Active Directory replication to take place and then REBOOT your CAS.

Configuring Outlook 2007 to connect (these steps can also be used for Outlook 2003):

Open the Outlook 2007 Mail Control panel and create a new profile (or edit the existing profile that you have) when you get the Exchange Server and Mailbox Screen provide the details of your MAILBOX Server (not the external DNS name of the CAS).

See below:

Click on the “More Settings” button and from the dialog that appears tick the “Connect to Microsoft Exchange using HTTP” and then click on the “Exchange Proxy Settings” button.

See Below:

From the dialog that now appears in the “Connection Settings” provide the External URL to your client Access Server (we configured it as OWA.FLANGEMANIFOLD.COM) – ensure that the proxy authentication is set to “Basic Authentication” and that the FAST and SLOW tick boxes are ticked.

See Below:

Troubleshooting:

If you perform a search on the Internet for Outlook Anywhere – or Autodiscover you will find lots and lots of avid discussion about issues that can occur.

As I have mentioned previously, a lot of these issues can be traced back to either incorrect DNS configuration between the internal and external URLS – but the most common that I have found and seen is because of the SSL certificate not containing all of the required SAN’s.

If you get a problem – the first stop should be to review your URLS and your SSL configuration.

Failing that (e.g. you are sure that everything checks out) there are a number of troubleshooting tools available to you:

Client Access Server:

If you are experiencing issues with OA – jump onto your Client Access Server, open an Exchange Management Shell and type in the following command:

Test-OutlookwebServices | fl

If things are working correctly you should see an Output which looks like the following:

If the command reports Warnings or Errors then you should take note of the ID’s and the messages and look them up – again I most of the Errors and Warnings are generated from incorrect configuration on the SLL certificate or in DNS – but because of the sheer number of items that can be reported you will need to work on a case by case basis.

Tools from Outlook:

Outlook has some really good inbuilt tools for troubleshooting problems with OA and Autodiscover – the first and most commonly known is accessed by holding down the CTRL key and RIGHT CLICKING on the Outlook Icon in the System Tray which produces the following menu:

Choose the “Test E-Mail AutoConfiguration” option which will present you with the following dialog:

Provide your E-Mail address ensure that all of the Authentication options are chosen and then click on the “Test” button.

From the “Results” and “Log” Window you should be able to see where things are not working or issues are occurring.

Given the above it is possible for the Test E-Mail Configuration tool to report that there are no problems where there still are, so, for the eventuality there is a little known feature (or perhaps well known depending on if you have used it a lot!) which turns on full client logging.

In order to enable Client Logging in Outlook go to [ Tools –> Options ] and from the dialog box that appears choose the “Other” tab:

From the General Section click on the “Advanced Options” button and from the dialog that appears chose the “Enable Logging (troubleshooting)” OK out of the dialog boxes and then restart Outlook.

See below:

When you have opened Outlook again – perform the action which is causing errors (for example trying to set the Out of Office or Download the Offline Address Book) – which will error.

Then go to [ Start –> Run and type in %temp% ] – this will open up the Temp folder for your machine.

Within the Temp folder there should be a file called “Olkdisc.log” – open this file it will entries which look like the following:

For Configurations with Problems:

Thread    Tick Count    Date/Time    Description
2844    8185296    07/02/09 22:05:42    Autodiscover to https://flangemanifold.com/autodiscover/autodiscover.xml starting
2844    8186078    07/02/09 22:05:43    Autodiscover to https://flangemanifold.com/autodiscover/autodiscover.xml FAILED (0x800C8203)
2844    8186078    07/02/09 22:05:43    Autodiscover to https://autodiscover.flangemanifold.com/autodiscover/autodiscover.xml starting
2844    8186125    07/02/09 22:05:43    Autodiscover to https://autodiscover.flangemanifold.com/autodiscover/autodiscover.xml FAILED (0x800C8203)
2844    8186125    07/02/09 22:05:43    Local autodiscover for flangemanifold.com starting
2844    8186125    07/02/09 22:05:43    Local autodiscover for flangemanifold.com FAILED (0x8004010F)
2844    8186125    07/02/09 22:05:43    Redirect check to http://autodiscover.flangemanifold.com/autodiscover/autodiscover.xml starting
2844    8186156    07/02/09 22:05:43    Redirect check to http://autodiscover.flangemanifold.com/autodiscover/autodiscover.xml FAILED (0x80072EE7)
2844    8186171    07/02/09 22:05:43    Srv Record lookup for flangemanifold.com starting
2844    8186187    07/02/09 22:05:43    Srv Record lookup for flangemanifold.com FAILED (0x8004010F)

If you are seeing errors in the log – make a note of them and use Google to troubleshoot – for information the error above was caused by the Users Primary SMTP address being different to the autodiscover domain (by default Outlook’s Autodiscover process will begin its lookup via the domain stipulated by the users Primary SMTP)

You can change how Outlook behaves by following the article here:

http://community.exchangeprovip.com/forums/thread/4610.aspx

For Configurations which work:

Thread    Tick Count    Date/Time    Description
3288    9117781    07/02/09 22:21:15    Autodiscover to https://flangemanifold.com/autodiscover/autodiscover.xml starting
3288    9118109    07/02/09 22:21:15    Autodiscover to https://flangemanifold.com/autodiscover/autodiscover.xml FAILED (0x800C8203)
3288    9118109    07/02/09 22:21:15    Autodiscover to https://autodiscover.flangemanifold.com/autodiscover/autodiscover.xml starting
3288    9120531    07/02/09 22:21:17    Autodiscover XML Received
---BEGIN XML---
<?xml version="1.0" encoding="utf-8"?>

Here the file will continue with the rest of the Autodiscover XML file from your Client Access Server.

Conclusion:

Well that pretty much wraps up my walk though on Outlook Anywhere – I hope that you find it useful. Admittedly it does not cover every single configuration scenario – and indeed needs to be adapted to support situations where, for example NLB is being used on the Client Access Servers (Which is recommended) but that is not a huge problem to work out (just remember that all DNS addresses need to point at the published NLB IP Address).

But, it should give you a good grounding in the hands on steps to get a successful OA and Autodiscover configuration working.

Outlook Whenever Wherever – Outlook Anywhere (Shakira, Shakira) – Part 1: DNS Domains and SSL Planning…

2009-07-14T01:48:00.001-07:00

From the sheer depths of postings and questions and answers on the Internet one could be forgiven for assuming that Outlook Anywhere is almost the Holy Grail of Exchange 2007.

Let’s face it, the ability to point Outlook 2003 or 2007 at a given secure URL and then “bang” you are off with all of the functionality that the Outlook client provides is a really attractive idea, and indeed – when implemented correctly provides a much more rich environment than OWA (although one could argue that OWA presents a far easier solution to both configure and then access – but as this article progresses – I hope to change your minds).

Although this two part series is based around Outlook Anywhere – the one key element to understand – especially if you are using Outlook 2007 Clients, is the principle of the “Autodiscover” service and associated Web Services as it is a core element to all functionality being available in Outlook when OA in configured and in operation.

I will be honest – the whole “Autodiscover” idea and concept has bamboozled quite a lot of people (including me for a period) but, when you get to understand it, and indeed follow some basic pre-configuration rules – a simple setup is very easy accomplish.

The key aspects to a successful Autodiscover (vis-a-vie OA) implementation include the following:

Correct implementation of your Firewall Infrastructure to allow 443 access
Understanding your DNS infrastructure for both internal and external access
Correct DNS Naming on the SSL SAN Cert
Ensuring that your Mailbox Primary SMTP Address domain can be matched to the client access server and a domain registered on the SSL SAN Certificate
The configuration of the OAB
The Configuration of the Web Services Virtual Directory
The Configuration of the Autodiscover Virtual Directory
The Configuration of OWA Internal and External OWA URLS
The Configuration of the OA External URL

Bearing the above in mind, (hopefully) after reviewing this article all of your Exchange mobile services should function correctly – these include:

OWA
Active Sync
Outlook Anywhere
Outlook Offline Address Book Download

So before we begin – what is Outlook Anywhere?

Exchange 2003 introduced the concept of RPC over HTTP if you where using Outlook 2003 or Outlook 2007 – essentially the system worked by encapsulating RPC calls into HTTP. This was a fairly cool idea as it allowed for the normally port hungry, RPC calls of Outlook to be packaged up into port 443.

The net result is when you have a properly configured Outlook Anywhere configuration you can point either an Outlook 2003 or 2007 client at and access your email as if you were on your LAN over an encrypted channel without the need for a VPN solution.

Firewall Configuration:

This can be and often is a pretty subjective as many people use many types of Firewall / Security Access Appliance - therefore producing a “One Size Fits All” guide to getting connectivity to your internet facing Client Access Server can be tough. The general guidance is to ensure that all port 443 (SSL) traffic from your external Interface should be redirected to the internal interface of the Client Access Sever.

You should not place a Client Access Server within a DMZ – therefore if you are looking to optimise security you should look at using ISA Server or a reverse proxy to protect your Client Access Machine – for the purposes of the remainder of this article assume that the Client Access Server has been correctly setup from the Internet via the Firewall / ISA Server using port 443.

Good Rules to follow prior to your implementation:

Essential – Understand your Domain Namespace and SSL Requirements:

Most of the initial implementation problems that I have seen with OA are to do with the companies domain’s and the types of SSL configuration that they have implemented.

Most configurations that I have come across (admittedly not all – but most therefore the following will be the type of configuration that this article will focus on) have a domain configuration like so:

The diagram above depicts a company where the internal clients will access OWA, OA and other Exchange web related Servers via the URL https://owa.mycompany.local – whereas when using mobile clients or indeed home workers outside the network need to connect using the URL https://owa.mycompany.com.

From an Autodiscover point of view this means that it is logical to assume that the following domains will be in play:

mycompany.com (External)
mycompany.local (Internal)

Which means the following SMTP Domains will be used by default:

@mycompany.com (primary SMTP)
@mycompany.local (Secondary SMTP)

Additionally and in accordance with Microsoft best practices the following entries should be added to the SSL (SAN) Certificate:

mycompany.com
mycompany.local
autodiscover.mycompany.com
autodiscover.mycompany.local
NetBIOS Name of your Client Access Server
External Name of OWA (e.g. owa.mycompany.com)
Internal Name of OWA (e.g owa.mycompany.local)
Any other SMTP domain which might be the Primary SMTP Domain (more on this later)

What is a SAN SSL Certificate?

SAN stands for Subject Alternative Name – these are also known as “Unified Communication Certificates” which allow for up to 150 server names to be included on one SSL Instance. They are big news for Exchange 2007 and Office Communications Server as you can stipulate many names for one Exchange installation on one SSL certificate.

There are many vendors in the market whom provide such certificates – my personal preference for this article has been based around “GoDaddy” whom provide a really good trade off between security / cost / amount of SAN names.

Don’t get me wrong – I am not a share holder in “GoDaddy” nor is .:Enow affiliated with them in anyway – but when you look at their pricing schedule it does seems to beat the competition “hands down” for small to large enterprises.

An example being for 10 domains (SAN) over 3 years you can pay $131.94 a year which is very reasonable.

Putting together your SSL SAN Domain Requirements:

As an example – if my company’s External domain was called “flangemanifold.com” with the internal AD DNS Namespace being “flangemanifold.local” with a Client Access Server with a NetBIOS name of FM-EXCAS-01 where the External OWA name was owa.flangemanifold.com and an internal OWA name of OWA.flangemanifold.local and my primary SMTP address for my recipients was <firstname.surname>@flangemanifold.com – I would add the following Names to the SSL certificate:

Common Name: owa.flangemanifold.com
SANS: flangemanifold.local, autodiscover.flangemanifold.local, owa.flangemanifold.local, flangemanifold.com, autodiscover.flangemanifold.com, FM-EXCAS-01

If you use a Primary SMTP address (this is your “Reply To address”) which is different to both the internal and external domains (for example flangemanifold-trading.com) you should also add this to the SAN Certificate (for example autodiscover.flangemanifold-trading.com) as in the default configuration of Outlook it will begin the “Autodiscover” from the domain which is provided as the Primary SMTP address.

Therefore if my SMTP address is andy@flangemanifold-trading.com the Autodiscover lookup will start at flangemanifold-trading.com – then move onto autodiscover.flangemanifold-trading.com and so forth.

Tips on getting your SSL Certificate:

You should ensure that all domains that are being used for the autodiscover and the External / Internal names must point at your Client Access Server.

Additionally when you apply for your SSL certificate – you must make sure that you are the REGISTERED admin contact or OWNER, as referenced in the WHOIS database for you external domains – most SSL certificate issuers (such as “GoDaddy” and “Thwate”) will send an email confirmation to registered OWNER or ADMIN address as provided within the WHOIS database prior to it being issued – therefore if your email address is not down as the contact, you will not get your SSL certificate issued.

For internal (mycompany.local) domains being placed on the SAN Certificate you can provide your own personal email address which will result in the SSL issuer sending the confirmation to your personal address.

Now that we have been through making sure that you have all of the information that you will need during the issuing process – we need to generate the CSR (Certificate Signing Request) that you send to your chosen SSL provider. The CSR is generated on your Client Access Server using the Exchange Management Shell Cmdlet “New-ExchangeCertificate” – however the command syntax can be a little tricky – therefore DigiCert have provided a Web Based interface which allows you to crate the New-ExchangeCertificate Syntax for a SAN SSL certificate here: https://www.digicert.com/easy-csr/exchange2007.htm

Open this site on your Client Access Server and fill in the form then click on the “Generate” button – an example of a completed form looks like the following:

When you have clicked on the “Generate” button – open an Exchange Management Shell Windows (this is on your Client Access Server) then copy and past the text which is located in the “Information” window into the Exchange Management Shell and press <Enter> – this will look like the following if successful:

You will now have a CSR file in the root of the Client Access server’s C:\ drive – this needs to be sent to your SSL issuer.

Before we continue some - Pre-Requisites:

Remember that this article explains the configuration for a vanilla out of the box installation of Exchange 2007 for a single Organization which has two DNS namespaces internally and externally.

The LAB Machine that I have used is based around Exchange 2007 SP1 with Rollup 8 running on Windows Server 2008 Service Pack 2.

The following assumes that you have already installed the required files for an Exchange 2007 installation and indeed have the Exchange Client Access Server role installed.

Windows 2003 – RPC-HTTP Component:

In order for OA to function you will need to install the RPC over HTTP Proxy component on your Exchange 2007 Client Access Server. If you are using Windows 2003 this need to be done via:

[ Add Remove Programs –> Windows Components –> Networking Services ]

Choose the “RPC over HTTP Proxy” and then OK out to install.

Windows 2008 – RPC Over HTTP:

Open a Windows 2008 command prompt with Admin Rights and type in the following command:

serverManagerCMD –i RPC-over-HTTP-Proxy

Back to the Film - Installing your SSL Certificate:

At this point your issuer should have sent you your completed SSL certificate in CRT format.

You will need to copy this to a location of you Client Access Server – when you have done this execute the following command:

Import-ExchangeCertificate –Path <path and name to CRT file>

So if you copied the certificate to the CAS Server’s C: drive the CMDLet would look like the following:

When the certificate has been imported you will be presented with the a completion message (see above) – in order to enable the SSL certificate for use with Exchange copy the value which is presented under the “Thumbprint” heading and then from within the Exchange Management Shell type in the following command:

Enable-ExchangeCertificate –Thumbprint <paste the thumbprint> –Services IIS

See below:

Summary for this part:

By now we should have our SSL certificate installed on the Client Access Server and be getting ready to enter into the main configuration of Outlook Anywhere and Autodiscover – in the next part we will over all the required configuration, setting up Outlook 2007 for connection and some hint on troubleshooting should you run into any problems.

BES co-existence during an Exchange 2003 to Exchange 2007 migration

2009-04-27T09:20:00.000-07:00

By ENow ESE contributing author, Kevin Wilson

Most of us have read the RIM article describing required steps when migrating BES from Exchange 2003 to Exchange 2007. The problem is the article assumes you can migrate all BES users to Exchange 2007 in one quick shot rather than dealing with a period of ‘co-existence’. Essentially the article explains how to reconfigure your BES to work with Exchange 2007 but you lose compatibility with Exchange 2003 in the process so you need to make sure you can get all BES user mailboxes moved over to Exchange 2007 quickly in order to use RIM’s instructions. For most organizations this isn’t feasible so they are faced with a period of co-existence.

A typical migration scenario is:

A single Exchange 2003 organization in the same Active Directory domain
One or more Exchange 2003 BE servers
One or more BES servers
One or more Exchange 2007 mailbox role servers
All users to be migrated from Exchange 2003 to Exchange 2007

In order to co-exist, that is, in order to allow the mailboxes of some BES users to reside on an Exchange 2003 server and at the same time have others reside on an Exchange 2007 server, there are a few simple requirements and steps to follow:

Before moving any BES user mailboxes, set the required permissions for the BES service account (i.e. BESADMIN) on the Exchange 2007 servers. For more information, see KB12483.
Restart all Blackberry services (KB04789) so that the BES service account refreshes and inherits its new permissions.
Ensure all Exchange 2003 and BES servers are running the Exchange 2003 SP2 version of the Exchange System Manager (version 6.5.7638). See KB14502 for upgrade instructions.
Now, go ahead and move some test BES user mailboxes from Exchange 2003 to Exchange 2007 and thoroughly check BB functionality after the move (i.e. mail flow, calendaring and appointments etc.) and also confirm the BES user mapi profile automatically updated to the Exchange 2007 server via the Blackberry Manager (run the HandheldCleanup tool if the mapi profile is slow to update). Repeat this process for test user accounts on each of you BES servers and from each of your Exchange 2003 servers to ensure all scenarios have been tested.¹
The next step is to migrate a real Blackberry user or two. Test user migrations are great but in order to really feel confident about your migration process you need to migrate a real user and let them live in co-existence for a period of time (at least a week). During this time, communicate with this user daily to see if there are any issues (give them a check list of things to test to ensure all functions are covered).
Assuming all has gone well with your testing, you’re ready to start moving the rest of your BES users which brings us to the next question, should I move them in slow batches or all at once. While the above tests should have proved that co-existence works I always recommend that you migrate all BES users at the same time (or in batches as quickly as possible). There is always the chance for unforeseen compatibility issues but you can mitigate the impact to the BES users if the coexistence period is limited to as short a period a time as possible (in other words, try and migrate all BES user mailboxes in a single weekend if possible).
The last BES mailbox to be moved to Exchange 2007 would be the BlackBerry Enterprise Server service account mailbox (i.e. BESADMIN). After this account is migrated, reconfirm the required permissions are set on the Exchange 2007 servers as per KB12483.
Now that all BES user mailboxes are migrated, stop the all BES server services.
Using an account that has full Exchange permissions, uninstall the Exchange 2003 System Manager from your BES server.²
Download and install ‘Microsoft Exchange Server MAPI Client and Collaboration Data Objects 1.2.1’ onto your BES server and then reboot the server.
After the server restart completes log back onto the BES server as ‘BESADMIN’ and go to "Start ->Programs -> BlackBerry Enterprise Server ->Edit MAPI Profile" and ensure you can resolve the BESADMIN mailbox on the Exchange 2007 server (migrated in step 7 above).
Then, go to “Start -> Programs -> BlackBerry Enterprise Server -> BlackBerry Server Configuration -> BlackBerry Server Tab -> Edit MAPI Profile" and ensure you can resolve the BESADMIN mailbox on the Exchange 2007 server (migrated in step 7 above).

Now that you have the process defined, it is time to move on to defining the migration schedule.

Every organization’s needs are different so be sure to take into account any special requirements.

It may be helpful to produce a list of BlackBerry users by department and server. Depending upon if you utilize the user’s Active Directory user properties, security groups, or OUs to organize your BES users ,this may be a consuming task. It is necessary to do this in order to have a good understanding of how devices are currently deployed and to determine when they will be migrated to minimize any impact. I like using a tool called Mailscape that makes finding this information very simple and easy.

Migrations can be very challenging, but with the appropriate tools and planning, you can successfully move your BlackBerry users to Exchange 2007.

Exchange 2003 / 2007 – IMAP Calendaring Meanderings…

2009-03-19T10:44:00.001-07:00

Exchange is Exchange.

It’s a mail server, sends and receives mail, provides shared calendaring, you can connect it to your phone system, does a bit of task management – can be used for workflow – but other than that, and unless you integrate it with other software – that’s it.

Now some of you might be thinking – have I taken leave of my senses? – have I abandoned our favorite product? – Is that what I really think?

No – don’t panic – this was a statement that was made during a recent meeting that I had with a customer and their technical department.

Obviously I (politely) corrected this poor misinformed individual by countering “The space shuttle is a large firework, made from 2000 tons of steel, filled with 2 billion gallons of Hydrogen and Oxygen which is set on fire, and controlled by computers which until comparatively recently were still 386’s”.

The customer said to me “That’s not accurate and you are over simplifying that” – to which my point had already been made :-)

You see with Exchange many people don’t see the complexity and effort (as with the space shuttle) that goes into designing the best possible mail system for a company – and most interestingly – even after implementation, people miss the wonderful challenges that customers whom our using our Exchange systems present to us as either contractors or system administrators.

Now don’t get me wrong, customers are out life blood – and indeed the source of creativity and inspiration and one of the great things about working along side .:ENow is that it gives you real world exposure to customers requirements which to all intents and purposes demand that we think beyond the limitations of software (which can either be Exchange or a related product) or indeed at times think beyond our own personal “hang ups” that we as a system a architect as to what will be best for a customers system.

For example, I am not a fan of IMAP in regard to Exchange implementations.

Again, don’t get me wrong – IMAP is a sturdy protocol, has been used for years and indeed forms the backbone of many stable, high profile mail services on the Internet (along with the timeless POP3 protocol). However when relating it to Exchange implementations I become a bit of a “purest” and believe that when Organizations have the choices of MAPI or Outlook Anywhere or OWA I tend advise customers to not opt for IMAP (or POP3).

I (and this is a personal opinion – not reflective of the views of .:ENow) tend to look at IMAP as an additional complication, more ports to open (if you are using both secure and unsecure), an additional service running (therefore a larger attack surface) and more configuration for an admin to worry about.

Add this to the fact that IMAP is normally used with a different client such as Thunderbird (therefore an additional desktop client support) – and when sizing your Exchange databases if you have a big enough client base which requires IMAP it can represent further increase on required resources from a disk / memory perspective.

However, I cannot get away from the fact that a number of companies despite the above; need / want to use IMAP within their Exchange implementations (and in fairness there are a number of good reasons – licensing for example; you can download a decent IMAP client which will work with Exchange for free – whereas Outlook costs money) so as an Exchange Admin and indeed a service provider to customers I have a responsibility to help out where I can.

One of the most common “talked about” subjects that I (and indeed most Exchange Administrators) come across with customers whom are using IMAP and Exchange is Calendaring Access.

Most of the debate falls into the following categories:

Cannot view other people’s calendars
Cannot agree to, receive updates on or schedule meetings
No Calendaring at all
Calendaring errors with Exchange

Now, being honest with you – this article does not give you clear solutions to the above issues – as indeed some of them just don’t have a solution – they are problems which have existed for quite a long time, and indeed perhaps will continue to do so.

Microsoft nor IMAP client vendors (Mozilla being one example) do not seem to wish to divert huge amounts of development time to getting IMAP calendaring for Exchange working (perhaps it is because that Microsoft seems to include IMAP for legacy reasons but does not wish to have it as a primary connection focus for Exchange; and indeed if IMAP client vendors wrote a client to specifically work for Exchange - then IMAP and their client would cease to be an open standard) – therefore we are at the mercy of the “Add On’s” community to develop plug-ins which might help.

But what I hope to accomplish is to give you a couple of “workarounds” which can be used to make the impact of having to use IMAP clients with Exchange a little less difficult to bear.

My IMAP client of choice for this article is Mozilla Thunderbird version 2.0.0.19 using the Lightning Connector – version 0.9 many people out there will now possibly “balk” at my use of Lightning as it has been described on the web as “clunky” and indeed “under featured” – however my view is that in relation to Exchange and indeed IMAP it is perhaps the best an only solution that I have found that gives IMAP users a chance of getting near some for of calendar functionality.

We also need to understand that Lightning was developed for use as part of the Mozilla Open Source Calendaring Project as well as strong links to a dedicated Open Source IMAP server with groupware calendaring built in (a project called SOGO) therefore it was NEVER going to be all things to Exchange, but we should not over look the fact that it does provide some useful functions within Thunderbird (as Thunderbird has no inbuilt calendaring features in a default install).

Cannot View Other Peoples Calendars:

As mentioned above this article does not provide hard solutions to all the issues above – and this is one element that does not get totally solved but I can offer a work around.

The following does involve a little bit of configuration both from the client perspective and the Exchange Server – however – if you are in a position where your CEO really wants to have the ability to view the Calendars of others – and indeed will not part with Thunderbird – this might be for you.

In order for this to work you will need to ensure that you have configured the LDAP Address book correctly from within Thunderbird (this essentially connects to Active Directory and returns the GAL). For information on how you can do this please review the following link: http://joseph.randomnetworks.com/archives/2006/02/08/active-directory-as-ldap-address-book-for-thunderbird-outlook-and-mailapp/ remember that the bind DN should be your e-mail address.

One of the cool things about Thunderbird is that it is highly customisable – not only does it have a large and well supported “Plug ins” base, it also contains a feature where you can configure elements of the environment to suit your needs.

In this example I will show you how you can make use of a 3rd party plug in called “ThunderBrowse” which when combined with Active Directory script and a modification to the Thunderbird configuration enables you to open the calendars of people where the correct permissions have been granted.

Firstly you will need to download the ThunderBrowse extension from: https://addons.mozilla.org/en-US/thunderbird/addon/5373 to a suitable location on the machine where you have Thunderbird installed.

In order to install the plug in you will need to start Thunderbird then select [ TOOLS –> ADD-ONS ] you will then be presented with the following dialog box:

Click on the install button which will present you with a standard “Windows Open” dialog box – navigate to where you downloaded the “ThunderBrowse” plug-in and select it:

You will then be asked to confirm the installation – there will be a count down as this Plug-in is not signed by the publisher – when the count down is completed click on the “Install Now” button.

You will now to restart Thunderbird – when that is completed you will be taken through a very short configuration wizard – this is pretty self explanatory.

When you have completed the wizard you will be see the following change to the Thunderbird environment:

Now that you have a means of browsing via Thunderbird we now need to complete the configuration of the client before we move onto some of the server side changes that need to be made.

From the Tool menu within Thunderbird navigate to [ TOOLS –> Options ] and from the dialog box that is presented to you click on the “Config Editor” button – see below:

When you have clicked on the “Config Editor” button you will be presented with a screen which looks like the following:

You will need to locate the value <LDAP_REF>.server.default.attrmap.Custom1 (the value of <LDAP_REF> is the ID of the LDAP address book for your AD Domain – you should be able to identify this by finding the LDAP server name that you provided in the Address Book configuration (if you only have 1 LDAP address book configured there is a chance that the value will be the same as mine).

Double click on the entry and at the end add in the value (separated by a comma) “extensionAttribute1” – see below:

What we are doing here is mapping the value within AD of the Exchange Extended Attribute 1 to the Custom1 field in the Thunderbird address book – you might be thinking at the moment – why are we doing this? – well there is a purpose which I thought might be worth showing you before we continue with the configuration – the following Self Extracting Archive (in AVI format) demonstrates how, when you have finished the configuration how you can open other peoples calendars Exchange Calendars from within Thunderbird:

Exchange Calendars in Thunderbird – AVI [ 278KB (Compressed) 9 MB (Expanded) ]

This video is best viewed with VLC Media Player which can be downloaded from here: http://www.videolan.org/vlc/

Populating the Exchange Extended Attribute 1 with the OWA URL for the mailbox:

Now that we have completed the client configuration we now need to make some changes within Active Directory. Now these changes are not extravagant – essentially all we are going to do is put the URL for each user’s calendar via OWA into the Exchange Extended Attribute 1. At this stage you might be thinking “but I have hundreds of users” – so – I have provided a script (which encompasses the configuration for both Exchange 2003 and Exchange 2007).

This script will search through Active Directory finding Exchange recipients – when found each recipients extensionAttribute1 is updated to reflect the OWA URL to their calendar.

The script provided is an example only – you might want to review it and modify to suit your own needs (for example if you do not wish to update every mailbox in the directory) – however I must stress that it is provided “as is” – I have used it within my own LAB environment where it worked fine, however, I recommend that you test them yourself before using them in a production environment.

Neither I nor .:ENow can be held responsible for any undesirable effects that co-incidentally arise as a result of using the following script.

Custom Attribute Modification Script [ 2KB ]

In order to use the script – download it to either a domain controller or Exchange server within your organization, double click on it – where you will be prompted for three items of Information:

1. The name (this can be DNS name) of your OWA Front End or Client Access Server

2. If you are using SSL

3. If you are using Exchange 2003 or 2007

When you have provided the above the script will execute and update extension Attribute 1 of each recipient in Active Directory with the OWA URL to their calendar – see below:

You will now need to ensure that the /Exchange can support anonymous connections – this can be achieved via the Exchange System Manager (within Exchange 2003) by going to [ Administrative Groups –> Servers –> <Server Name> –> Protocols –> HTTP –> Exchange Virtual Server –> /Exchange ].

In Exchange 2007 you will need to ensure that you are logged onto the machine with an account which has permissions on the person’s calendar as Anonymous access is not supported.

Now that we have both the client and the server end configured, the remaining configuration is taken care of by configuring permissions within the mailboxes of people whom you want to grant access to – for example – within my Lab – I want my account (which is configured as the IMAP user and called Andy) to have access to the calendar of the administrator.

What I would need to do is logon as the administrator and assign the correct permissions to the calendar (as you would normally do) – typically I would grant “reviewer” access as the default permission (this will depend on your organisation).

Putting it all together:

Now that you have configured the client (by adding in the LDAP address book, configuring the LDAP mappings, and installing ThunderBrowse) and also configuring the back end – you are now in a position to use Thunderbird to access Exchange calendars as per video example above.

An example of what a populated calendar would look like is below:

Cannot agree to, receive updates on or schedule meetings:

One of the first things that you will notice about Thunderbird is that it does not (in a default install) contain any form of calendaring (not even a personal calendar). This however can be mitigated by downloading another Plug In called “Lightning” https://addons.mozilla.org/en-US/thunderbird/addon/2313.

The Lighting Plug-in is installed in the same way as ThunderBrowse - which I went through above. When installed you will see within the Thunderbird client that you now have access to a calendar – more to the point, when you are sent meeting requests, rather than appearing as plain text e-mails, they will now show up like the following:

As you can see you have the ability to Accept, Decline or Tentatively accept meetings or appointments – which are then added into the calendar. You can also create and send meeting invites – which when combined with the workaround above (for viewing others calendars) give you the chance to see if people are available.

IMAP Meeting errors with Exchange:

I have heard and read about some people experiencing errors within their IMAP clients when trying to open or read calendaring invitations sent from native MAPI Exchange clients.

Typically (although not exclusively) errors manifest themselves in the Exchange event log as (for example):

Event Type: Error
Event Source: IMAP4SVC
Event Category: Content Engine
Event ID: 1023
Date: 8/13/2008
Time: 7:56:47 AM
User: N/A
Computer: <Computer>
Description:
Error 0x7da occurred while rendering message 0001-0000001cded6 for download for user <User>.

For more information, click http://www.microsoft.com/contentredirect.asp.
Data:
0000: 07 0c 0d 00 ....

It is possible that the client will also throw an error when trying to open the offending invite.

Personally I have found that if you use the latest version of Thunderbird and ensure that your Exchange servers is up to date with the latest patches errors such as the above do not happen, however if you encounter such and issue it might be worth following the advice above – and following the processes which are given in the following articles:

http://support.microsoft.com/kb/329168

http://social.technet.microsoft.com/Forums/en-US/exchangesvradmin/thread/c63b8713-9ef9-4076-a11b-5db08255689b/

Summary:

Well that is it for another month – I hope that you have enjoyed this little ramble through the world of Exchange and IMAP – if you should have any questions, please feel free to comment!

Exchange 2007 SP 1 High Availability and Disaster Recovery Options

2009-02-11T11:40:00.001-08:00

With more organizations moving the new Exchange 2007 platform every day, exchange administrators now have more high availability and disaster recovery options available to them.

The goal of this article is to clearly define what built in options are made available in Exchange 2007. While many configurations exist, each has its pros and cons.

Single Copy Clusters [SCC];

I suppose the best way to describe an Exchange 2007 Single Copy Cluster (or SCC) is to think about it in the traditional sense of Exchange 2000 or Exchange 2003 clustering (although with knobs on).

Essentially in production an SCC requires a minimum of two nodes (you can have one, although it defeats the object of clustering), a private link between each node (hear beat) a public connection to your local LAN, and a shared storage array – the diagram below depicts a very basic SCC cluster configuration:

The traditional idea behind this model is that when the primary node fails for any reason, all of the services that the primary node was responsible for will be passed over to the passive node, and normal operation of the Exchange server will resume.

To all intents and purposes the model above looks exactly like the clustering format that was used by both Exchange 2003 and Exchange 2000 – however in Exchange 2007 Microsoft introduced the following improvements:

In Exchange 2003 when you had configured your Windows cluster, you would have the install and configure the clustered MSDTC – then install the Exchange 2003 binaries on the first node, then you would then have to manually in the Windows Cluster Administrator create the Exchange Virtual Server (EVS) IP address, Network Name, allocate storage and then create the Exchange Resources (MSExchangeSA) – however in Exchange 2007 SCC clusters – although you still need to have created an MSDTC resource – the rest of the process is fully automated.
In Exchange 2003 the management of the Exchange Virtual Server (for example starting and stopping services) was accomplished via the Windows Cluster Administrator – in Exchange 2007 you can accomplish all of these tasks via the EMS (Exchange Management Shell) – additionally in Exchange 2007 SP1 (due very soon) the Exchange Management Console (EMC) will also provide this functionality – cluster and application administration all in one place!
Again in Exchange 2003 when you had finally got you Exchange EVS up and running you would still have a number of little things that you needed to tweak – in Exchange 2007 all of this has been done for you (an example would be memory configuration – remember those “interesting” boot.ini and registry tweaks! – stand on one leg, recite the pledge of Allegiance, face north)…..

Some concept changes:

In Exchange 2003 the common term for a clustered Exchange Server would be “Exchange Virtual Server – or EVS” – in Exchange 2007 the term is replaced with “Clustered Mailbox Server” – the reason being that Exchange 2007 clusters do not support roles such as CAS, HUB or Unified Messaging – they are purely mailbox servers – where as in Exchange 2003 your Exchange EVS would also support direct MAPI, OWA, and SMTP.

Each node in the cluster can be in a position to take control of the “Clustered Mailbox Server” – but like Exchange 2003 they still have and retain their own network identity – in essence each node will have a NETBIOS name, and IP address – but they can also take over and support the Exchange Virtual Instance in the event of a fail-over (whether this is manual or as a result of a hardware issue).

Another welcome change is that the concept of Active / Active clusters has been abandoned in full for all forms of clustering in Exchange 2007 – you can no longer have an Active / Active SCC cluster (or CCR for that matter) – there are many reasons for this but essentially it boils down to scalability and performance – Exchange 2003 A/A clusters did not scale much beyond 1900 users, and could end up performing like a dog should one node fail – as Exchange 2007 is 64 bit (for production), you can pile power into your Primary and Passive nodes (for example one of my Primary Cluster nodes has 24GB of RAM and 8 processors) this makes the concept of “Load Balanced” fail-over in Active/ Active redundant.

Pros and Cons of SCC;

As in all scenarios there are pros and cons to any configuration – the following are the arguments for and against SCC clustering in Exchange 2007:

Pros:

It’s a familiar clustering model for those that have setup and configured Exchange 2000 and 2003 clusters
Providing that the the hardware is certified (to the MS HCL) it is a pretty simple type of clustering to setup and configure
Provides a reasonable amount of fault tolerance from a node perspective
Good option for larger companies that are limited on sites – but have the money to invest in a locally fault tolerant solution

Cons:

Is typically expensive to setup – this is mainly down to the fact that shared storage is required between both the nodes – this is usually SAN (FC-AL) based, but in a number of installations is SCSI – generally speaking you will required a significant hardware overhead to accommodate SCC
The Shared storage is a single point of failure – lose the shared disk array = lose the cluster – unless you are employing some form of replication software across sites (more expense – and if you are you need to consider CCR)
Due to the shared storage requirement of SCC both your cluster nodes need to be in the same location
Requires an very specific hardware configuration to run on
Requires Enterprise Versions of Exchange and Windows

However, with the above said – a number of us whom are planning a move to Exchange 2007 will currently have the equivalent of SCC clusters in their Exchange 2003 installations – what do we do about the investment that we have made here?

Well, from my perspective, I plan to relocate a node from my existing Exchange 2003 environment to a remote site and take the shared storage with it – then with the remaining node at my home site plum that into another SAN that we have then configure a CCR cluster between the sites (although I am aware that simplifies the process), however in order to do this I will require a server that can (temporally) take the load of at least one of my clusters (please see the “Bunny Hop” method).

Cluster Continuous Replication [CCR];

Wow – what an idea! – what an implementation!, where has it been all my life (yes I am drooling – and yes it is sad).

CCR makes use of a type of Windows Clustering called MNS (Majority Node Set) which is then combined with a new technology in Exchange 2007 which is part of CCR – called “Log Shipping” – there will be more on that later.

Some of you may not have heard of the “Majority Node Set” idea – if you would like further information on this type of Windows clustering please have a read of the article:

http://technet.microsoft.com/en-us/library/cc784005.aspx

How does it work?

Firstly before we go into the detail of how it works lets have a quick look at the minimum requirements to implement CCR clustering:

Two clusters nodes which roughly meet the following criteria:

Exist in the same rout-able subnet (unless you are running Exchange 2007 SP1 and Windows 2008)
Have enough storage either based around DAS, ISCSI, or SAN – but it is sensible to ensure that each nodes storage is from a capacity perspective a match – remember – each node in this type of clustering uses its own storage to function – not a the shared array principle that we have seen used in Exchange 200 / 2003 and Exchange 2007 SCC
A third server which can perform the role of the File Share Witness (or FSW) – this is normally installed on a Exchange 2007 Hub Transport, but can also work on any Windows server as a file share.

The idea behind CCR is that there are two copies of the Exchange database, one active (which resides on the storage of the primary node) and one passive (which resides on the storage of the passive node) – transaction logs from the active database are asynchronously “shipped” to the passive node’s database and then replayed to give you are fairly current copy of the data – more on this a bit later.

The process of shipping can occur over a WAN link to a separate Data-centre (as long as it exists in the same subnet as the Active node [NOTE: This requirement changes in Exchange 2007 SP1 and Window Server 2008] as log files are around 1024 KB in size – or – the you can have a node in the same Data-centre / Building without the restriction of having to be in the same rack / room as the shared storage aspect is eliminated.

When you Initially install the passive node in a CCR cluster each storage group and associated databases are copied from the Primary to the Passive node (this is called seeding) from there on in log files are shipped to the passive node and replayed on a constant basis.

Logs are shipped from the Primary Node to the passive node when are then “closed” – which results in the passive node not always having a copy of every single log from the primary node this can mean that the database on the passive node might not be totally up to date – however this can be rectified when you have resolved the issues with the Primary node and rectified them – then performed a fail-back.

There is an exception to the situation where your databases is not completely up to date which is when the Exchange Administrator issues the move-ClusteredMailboxServer command from the EMS (Exchange Management Shell) – this would normally be done when maintenance is required on the primary node – but a log Sync is performed between the node when this command is run.

A diagram is provided below which depicts a simplified version of how a CCR cluster can be configured over three sites (two nodes at two separate sites and a third site for the file share witness):

Of course the above diagram does not take into account other roles (such as CAS and Hub) within the respective sites (A) and (B) – this I will be looking at in a separate article, however for information in the example given above you would require a CAS role in Sites (A) and (B) to maintain client connectivity to your Exchange environment should site (A) go down (you could also have both CAS servers running the HUB role).

One key thing to bear in mind with CCR clustering is that unless you are using Windows 2008 and Exchange 2007 SP1 each cluster node needs to be in the same IP subnet – therefore unless you are using some fancy routing between sites you cannot place nodes in disparate IP ranges.

Unless you are planning to use Windows 2008, this might limited the initial attractiveness of CCR – however from a personal point of view is seriously consider Windows 2008 as your Exchange platform of choice – especially if you are working on a “Green Field” build of Exchange.

If you do implement Exchange 2007 SP1 on Windows 2008 you can gain the benefit of having your cluster nodes dispersed over diverse subnets spanning separate sites or perhaps countries (if you have the bandwidth).

Pros and Cons of CCR;

Pros:

When using a multi site scenario it represents an excellent fault tolerant, and high availability solution with DR and Business Continuity
Doesn’t specifically require an special hardware configuration
Not tied to close proximity based clustering
Doesn’t require third party replication tools
Ideal for larger Exchange Organisations with multiple sites where you could locate an additional Exchange installation
Major benefits released when using Windows 2008

Cons:

Not as simple to configure as Traditional Clustering
Works best with multiple sites (from a DR and BC perspective)
Requires the Enterprise version of Exchange and Windows 2003
Can only contain one CCR enabled database per storage group
Major benefits released when using Windows 2008

Understanding the Transport Dumpster:

The Transport Dumpster is a feature which is found on Exchange 2007 Hub Transport servers. Essentially its main task is to managed the delivery of messages in a Hub Transport queue which are destined for mailboxes which reside on a CCR mailbox server (e.g. to make sure that they do not get deleted).

As explained above, the replication between an Active CCR database and a Passive CCR database is asynchronous – which means that the passive database is always slightly out dated (unless you have run the move-clusteredmailboxserver cmdlet). Therefore when a failure occurs on the active node – it is a fair bet that the most recent logs will not have been shipped over to the passive CCR node – this can result in missing mail items.

The Transport dumpster is used in this scenario – essentially when a CCR fail-over occurs, the Hub Transport is asked to re-deliver lost mail. Bear in mind that this process is for mail that has to all intents and purposes already been delivered – and transient mail is held in local submission until the store comes back online.

The Transport Dumpster is configured to work with CCR and LCR (from Service Pack 1) enabled mailbox servers.

Local Continuous Replication [LCR]:

Ok the best way to consider this is the same as CCR clustering however it happens using a single server (well ok that’s not a cluster – but the shipping and replay technology is similar – only it occurs at a disk and controller level).

CCR clustering is often referred to Resilience at a site level, whereas LCR can be considered that at a server level.

What do you need for LCR?

In order to make use of LCR your server should meet the following requirements:

A Server capable of running x64 Exchange 2007
The server should have x 2 independent RAID controllers (you can configure it using a single controller – but, if you lost that controller from the server then you will not get access to the replayed data).
Separate storage per RAID controller (for example on the primary RAID controller you have a single Exchange Database sitting on a RAID 5 array and all of your Logs sitting on a Mirror – these will (and should) represent separate disks – this configuration should be replicated on your passive RAID controller

The following is a simplified diagram which depicts LCR operation – the orange areas of the diagram represent separate disks attached to separate controllers on a single server:

During normal operation when using LCR the active database’s logs are shipped to and then replayed into the passive database, in the event of a fault either on the Primary RAID controller or Primary disk array you can manually “Activate” the passive copy of the Exchange Data. The process of Activation can be accomplished via one of the following means:

Changing the Active Storage group and database paths via the EMS (Restore-StorageGroupCopy) or EMC (Restore-StorageGroup task)
Via the Operating System (reconfiguring Disk mount points / drive paths)

Pros and Cons of LCR;

Pros:

Great solution for smaller firms that have the money to invest in a single well spec’ed Exchange server
Only requires the Standard Edition of Windows and Exchange
For smaller enterprises it represents a good level of fault tolerance within a single box
Easy to setup

Cons:

Not really suitable for larger organisations where mail is critical
Does require a server that can handle enough disks and two RAID controllers for it to really be effective (this could put it out of SME’s price range)
Can only contain one Database per LCR enabled storage group

Standby Continuous Replication [SCR] – Service Pack 1 for Exchange 2007:

SCR is a feature that is introduced in Service Pack 1 for Exchange 2007.

Essentially SCR allows for an Exchange Database to be replicated to a target elsewhere (different data centre / Exchange server) on a per storage group basis. One of the great things about SCR (and a key difference between LCR and CCR) is that you can replicate your data to multiple targets and multiple target types – for example:

Your source Exchange Server can ship its data to an offline standby server in a geographically dispersed data-centre, whilst also shipping data to a specific storage group on a active Exchange cluster within your main building.

The following diagram depicts a basic SCR scenario:

In the example given above, we have site A which is replicating its data to Sites (B) and (C) – site B contains a clustered Exchange SCC instance and site C contains a standby basic instance of Exchange. It is a wonderful “belt and braces” scenario and can be further adapted.

It should be noted that the target in SITE B is the PASSIVE node of a fail-over cluster (SCR).

As you can see SCR has great potential as an additional line of defence from losing your data, however there are some things worthy of note about this configuration:

The database and log paths MUST be the same on the source and target servers
A target standby server must not have LCR enabled for any storage group contained on it
A target must have the Exchange 2007 mailbox role installed (even if it not hosting any mailboxes)
SCR can be administratively delayed

Again as with LCR the process of switching (or Activating) between Active and Passive copies of your database it manual operation.

Pros and Cons of SCR;

Pros:

Highly resilient and allows for multiple targets for your data
Requires only the Standard Editions of Windows and Exchange
Works for Enterprises of all sizes
Allows for a built in delay in replication

Cons:

Can only be managed from the command shell (this means that it could be tricky to setup and manage)
One database per storage group

We hope that you have enjoyed that quick run through of the options available for High availability in Exchange 2007.

An Example Hub Transport Hardware Config for Exchange 2007 Installations of 5000 users….

2008-10-15T07:18:00.001-07:00

Many people whom have been embarking on the migration road from Exchange 2003 to 2007 will have come up against the various sizing calculations which need to be taken into consideration for the various Exchange 2007 roles.

In this article I would like to take you through the how you can simply specify the correct metrics for a Hub Transport Server that will support up to 5000 users.

One of the things that I have noticed when researching the various aspects of Exchange 2007 is that it is very hard to find a reference which answers questions simply at first glance. For example;

“I wish to know what is a good Basic Hub Transport server specification for up to 5000 users, whom send and receive on average 68,245 messages a day (aver –Total);”

In order to ascertain the answer to the above question you will need to spend large amounts of time on various web sites using Sizing Calculators, analysing IO requirements – determining RAM sizes and CPU overhead – which for me is fun, however I have noticed that many Exchange administrators would like to find an article that essentially says –

“Look, buy this server – stick these processors in, with this amount of RAM, and this disk config and you won’t go far wrong…”

In this article I would like to provide a base specification for people whom are looking to size their Hub Transport servers for mail transport of up to 5000 mail users, whereby I cut out the need to in-depth server performance analysis (although I will include much for the technical detail for those whom are interested).

The recommendations contained within this article cover the following aspect of HT server hardware design:

CPU
Memory
Disk (Size, RAID)

I have based this article around the HP ProLiant DL365 Server which is pretty much the dedicated Opteron version of the DL 360. I have chosen this model as it offers a good trade off between cost / performance and capacity, you can view the full specifications of this server here: http://h18004.www1.hp.com/products/quickspecs/12564_div/12564_div.html

It is at this stage that I need to point out that I am a HP (Compaq) server man, this is not because I have shares in the company, nor is it down to HP asking me to write this article – I just like HP in the same way that others like IBM and DELL servers – the specification of the HP server that is provided at the end of this article can easily be replicated into specifications for most other server vendors, so please do not feel that I am encouraging you to run out and buy HP servers – stick with what you are happy with.

Hub Transport – CPU Metrics:

The following information is based upon sizing recommendations as feature in: http://technet.microsoft.com/en-us/library/aa998874(EXCHG.80).aspx

Choosing the Correct Processor;

Choosing the correct processor for Exchange 2007 is an important business, however it is perhaps not as complicated as designing Disk Sub System requirements – as in terms of your processors in Exchange 2007 you have a set of pre-defined rules right from the outset for all production installations of Exchange server:

Your Processors must support either EMT 64 (Intel Extended Memory 64 Technology) or AMD64 Opteron – such processors can be located here (for Intel (http://developer.intel.com/technology/architecture-silicon/intel64/index.htm) or here (AMD): http://www.amd.com/us-en/Processors/ProductInformation/0,,30_118_8825,00.htm
Intel Itanium processors are not supported at all with Exchange 2007
x86 (or x32) bit processors are not supported in production but can form the foundation of test / training labs

So essentially at this stage you have a toss up between modern Intel Xeons or the AMD Opteron range. I have always been an Intel person myself, however I do urge you to seriously look at the AMD Opteron offerings as they can save you a reasonable amount of money on the total cost of the server unit for very little (if at all noticeable) performance drop.

How Many Cores?

We all know that over the last 24 months the big new thing in processor technology is additional processor cores on a single chip – but, does it actually improve Exchange performance?

Microsoft and the Exchange team state very clearly that multiple CPU cores can have a significant impact on the overall performance of Exchange Server and they provide some really interesting reading on the subject here: CPU and Memory Scalability for Exchange 2003 (which can be applied to Exchange 2007) and if you are really interested there is a good article on the MAPI Messaging Benchmarking 3 and how Dual Core processors fare have a look here: http://www.microsoft.com/technet/prodtechnol/exchange/2003/performance.mspx.

However whilst keeping in mind the purpose of the article (keep it simple and HT) – multiple core processors mean better performance at a competitive price – I recently received a quote where the Quad core option was cheaper than the Dual – so shop around is the key.

In practice terms of looking at Microsoft “best practice” for Hub Transport Processors and Cores the following recommendations are made:

Minimum:

x 1 processors cores – Essentially this is the absolute base processor configuration that you will require in order to get Microsoft PSS to talk to you should you have a problem (one would wonder how you could have less than a single processor core) – one assumes that this is based upon being able to handle a Light user message profile (5 messages sent and 20 received at around 50KB per message) – you could potentially also be looking at handling a Average user message profile (10 sent and 40 received at around 50 KB per message) – but be prepared for some potentially small latency under this scenario.

If we assume 5000 LIGHT users sending and receiving mail on an average day here you would be looking at: 125000 messages per day – I have left out the potential space implications as 50KB per message is highly subjective.

If we assume 5000 AVERAGE users sending and receiving mail on an average day here you would be looking at: 250000 messages per day – I have left out the potential space implications as 50KB per message is highly subjective.

Note: The figures given above are based around 5000 people sending and receiving that amount of mail per day (again given as an average based upon traffic that I have seen in my organisation) – it is unlikely that all 5000 people would consistently amount to that level traffic per day – so I would recommend reducing the figures given by around %20 or base them on your own understanding of your mail system.

Recommended:

x 4 processor cores – this recommendation is taken on the basis of the following formula price + memory configuration = performance, essentially if you are using x 4 cores and have the correct memory configuration (see more on this later) – this would the be the best practice configuration you should aim for.

Essentially here you would be looking to effectively handle the Average user message profile (10 sent and 40 received at around 50 KB per message) or the Heavy User Message Profile (20 sent and 80 received at around 50KB per message) but both comfortably rather than in the previous section potentially looking at some form of latency.

If we assume 5000 Heavy users sending and receiving mail on an average day here you would be looking at: 500000 messages per day – I have left out the potential space implications as 50KB per message is highly subjective.

Maximum:

x 8 Processor Cores – One thing to note about the maximum requirement about Hub Transport processor cores is that it should not Unnecessarily be considered the “final say” so to speak. This recommendation is based around HT performing message transport in a very busy environment, however if third party applications are used which interface with the HT role there might be scope for additional processing power – but generally this processor configuration can be considered appropriate for most medium to large scale transport messaging environments of greater than 500000 messages per day.

Summary of CPU Metrics:

There are a number of CPU considerations that can be applied to the Hub Transport role, however given the scenario of the article and indeed the base for the message transactions I would personally recommend a two physical processor server where the two processors in the slots have a pair of cores each (resulting in the recommended four cores) if you are on a budget the AMD Opteron™ Processor 2220 2.80 GHz is a good choice, however if you are a devout Intel server admin then most of their Dual core offerings above 2GHz will also suffice (bear in mind that you might at this stage be able to acquire Quad cores at competitive rates).

Hub Transport – Memory Metrics:

In Exchange 2007 – the more physical RAM that you have generally means more that can be cached – therefore a greater performance gain.

As we all know that server memory comes in many forms however as a basis I would recommend that the modules that you choose confirm to 667MHz PC5300 standard. When looking at the amount of RAM that you place in your Hub Transport the following metrics are recommended:

If you have a server with 4 processor cores you should consider 4 GB of RAM (working on the recommendation of 1GB per core)
If you have a server with 8 processor cores your should consider 8 GB of RAM

The above are based upon Microsoft best practice recommendations – however I would suggest that if you have 4 processor cores consider 6 GB or RAM – this allows for the O/S and Message transport to be taken care of given our 5000 user scenario (you will also find that 6GB or RAM is future proofed for any upturn in user population or message traffic).

Reading though Microsoft white papers you may also see see that the maximum memory recommendation (although as Microsoft are again quick to point out this is not a physical maximum, merely a trade off over performance and price) for Hub Transport RAM is 16 GB – bear in mind that this is based upon 1 million messages averaged on the number of recipients so for the purposes of the article 6GB should be more than enough – even Microsoft states “The Edge Transport and Hub Transport Roles do not require substantial amounts of memory to perform well in optimal conditions”

Hub Transport – Disk Metrics:

Getting the Disk configuration of the Hub Transport correct is a key part of implementing a successful Exchange 2007 implementation – lots of focus is given to getting the Mailbox Server Disk metrics correct, but many people over look the fact that the HT makes use of the same Database Technology as the mailbox server in order to transport Messages.

During my time working with Exchange I have found that the main gripe that users have with e-mail (aside from it not being available) is that it took over 5 minutes for their message inviting everyone out for dinner to arrive with a recipients (Man I remember that days of Microsoft Mail Post Offices – where users were happy if their message arrived at all!). Essentially transport lag annoys people.

Disk Type / Speed and Size:

There are a number of options that you can pursue in terms of the Disk Technology that can be used with Exchange in general. Speaking openly from my own personal perspective there has been a swing from SAN based storage (in Exchange 2003) back to DAS being a recommendation in Exchange 2007 (however you still have the option of SAN storage in 2007 in fact it is likely for large installations with many storage group it will potentially be a requirement – that is unless you wish to consider the now supported iSCSI option).

For the purposes however of the Hub Transport (and this article) we will be looking at Direct Attached Storage.

Firstly what technology should you use? – well disk technology has moved on in recent years with the introduction of SATA and SAS;

SATA:

SATA in my humble opinion is still a little slow for Enterprise class solutions, don’t get me wrong, I know that there is the SATA E class drives which are designed to run 24 x 7 and at speeds of 10K RPM, but I am not certain if there is much of a financial saving between buying SATA E or just opting for SAS.

SAS:

SAS (Serial Attached SCSI) is designed for Enterprise class performance and reliability. Access times and platter speeds are excellent (although when using the smaller form factor drives you are limited to smaller disk sizes – however given the topic of the article the drive sizes should be more than enough the HT role) – HP provide SAS 2.5” and 3.6” in the following capacities:

10K RPM = 36 GB / 72 GB / 146 GB

15K RPM = 36 GB / 72 GB / 146 GB / 300 GB

My personal preference for the HT role would be to use x 6 15K 146 GB or 300 GB drives (this will potentially vary according to budget – if you can opt for the 300 GB drives) the DL 365 G1 has capacity for x 5 2.5” SAS drives (which when configured represent x 3 RAID 1 pairs).

The following diagram illustrates how the disks can be allotted to RAID arrays via the built in P400i – each Array configured on the controller represents two separate spindles configured as RAID 1 (this size of the Array will either be 146GB or 300GB) where each Array is labelled A,B and C – this is all configured from the HP Arrays Configuration utility.

The P400i is supplied with 256 MB of battery backed cache which not only provides backup for the Transport Databases in the event of a dirty shutdown, can when configured correctly provide and additional performance increase in terms of Database transactions – below is a picture of the 400i – this little “mouse thingy” is the battery.

Ok – thats great – but how do you know that 146 GB (or 300 GB) is enough for day to day operation with 5000 system users?:

Firstly lets look at the figures that I have seen within my existing Exchange 2003 environment:

Average Tracking Log Size Per Day (Protocol Logs): 150 MB view to keep for 15 Days = 150 * 15 = 2.25GB + 450 (%20) = 2.7GB

Transport Transaction Log: This by default utilises circular logging Microsoft does suggest that you can leave this on the O/S Mirror, however old habits are hard to break with me, therefore I always give them their OWN Mirror which is shared with the Protocol Logs (see above)

Transport Database: As per Microsoft the Transport Database does not store items Indefinitely, essentially you can derive a rough estimate of space required by taking an average message size (my environment is around 200KB) and then multiply it by the maximum queue size (which I tend to base on the worst case scenario that I have seen in my 2003 environment which was 10,000 items) – so:

200(KB) * 10,000(Items) = 2000000(KB) = 1.953 GB + 20% (Fluff factor) = (about) 2.3GB

You can also work this out against the Microsoft worst case which is like so:

200(KB) * 500,000(Items) = 100000000(KB) = 95 GB + 20% (Fluff factor) = (about) 114GB

Even in the worst case scenario where you have 500,000 items in your queue you will still maintain 32 GB free on the drive (if you are using 146 GB drives), this is clear of the 4GB threshold which invokes Back Pressure.

I use CCR do I need to consider the Transport Dumpster?

The “Transport Dumpster” is a special feature that is located on HT servers within sites that contain CCR or LCR Mailbox clusters.

Essentially the HT will need to have enough capacity factored into the disk subsystem to store mail long enough for all Storage groups located on CCR / LCR clusters in your site. This is used to recover messages that were in transport and destined for mailboxes on cluster node but then the node failed – full details of the Transport Dumpster are beyond the scope of this article – but if you would like to read more have a look here http://msexchangeteam.com/archive/2007/01/17/432237.aspx.

In order to calculate the size of the transport dumpster use the following metrics:

Largest possible message size (which in my environment is 18MB) then add 50% of its size = 27 MB (50% of 18 is 9 – therefore 18 + 9 = 27)

You would then set the MaxDumpsterSizePerStorageGroup to 27 (see the article above) – the total capacity required by the Transport Dumpster is then derived by the number of storage groups contained within the CCR environment – for example if you have 20 Storage groups that calculates as 20(SG) * 27(MB) = 540 MB.

Under best practice guidelines you should set your increase your largest message size by 1.5 before using this calculation – however as you can see, the disk requirements that we have established for our DL 365 G1 are more than happy even in the worst case scenario.

Putting it all together:

Ok at this stage we have a design of a DL 365 G1 with 6 GB of RAM with x 4 Opteron 2220 cores, additionally we have x 6 146 GB (or 300 GB) SAS drives plugged into a P400i RAID controller.

Our Disks are configured on x 3 RAID 1 sets (with two disks per RAID 1 mirror – obviously – this totals x 6 disks).

By rights the above configuration should easily perform that role of transporting messages around your environment. The article was based around 5000 users and average traffic of 68,000 messages per day, however the specification would realistically handle far more than that and arguably sustain quite a few years worth of growth.

So there you have it, if you are considering how to specify your Hub Transport Servers and support between 5000 – 9000 users and have a daily transport rate of around 68 – 80 thousand messages a day – have a think about the server configuration above.

Reproduced with permission from http://telnetport25.wordpress.com

Things that can be missed in Exchange 2007 migration planning...

2008-08-30T11:28:00.001-07:00

Let's be honest - Exchange 2007 is a beast of a product, and indeed potentially a bigger leap in redesign than the jump from Exchange 5.5 to 2000. From a management perspective it has forced many Exchange Administrators to rethink their administration policies and learn new technologies which prior to Exchange 2007 they would perhaps not considered being part of their skills arsenal.

For example; In Exchange versions 2000 to 2003 - Exchange admins did not necessarily need to be a scripting guru in order to do his/her job. However in Exchange 2007 the integration of the Exchange Management Shell (based upon Powershell) and the amount of configuration options that the Management Shell controls which are not in the Exchange Management Console an Exchange administrator needs to develop at the very least, an understanding of basic scripting techniques - even if this is at the single command level.

In the case of Exchange admins whom run larger Exchange 2007 installations (or indeed consultants and architects) the skill with the Management Shell need to be "ramped up" in order for them to achieve their deployment goals - and indeed get the very best out of the product - this can (in some cases not all) move Exchange Admins out of a "comfort zone" and into a world where they are almost part Exchange Systems Admin and part developer (a hybrid).

Of course the changes are not just limited to mere scripting - the major Architectural changes that Exchange 2007 has brought with in - for example the move to x64 Hardware being the only supported production platform.

In previous migrations between Exchange versions we were all safe in the knowledge that we had the option of "in place" upgrades on the same hardware (if it was up to the job) - in many cases now companies are in the position of having to purchase new hardware to meet or indeed supplement the the demands of Exchange 2007.

Closely linked with the above is the inception of "Exchange Server Roles".

Roles are not only just a big conceptual change, but have a significant impact on the specification of your Hardware and topological layout. People whom are embarking upon a migration path to Exchange 2007 need to work through the processes of sizing (specifying their hardware according to the role that it will be performing - examples of good sizing articles on the Web are:

General all in one

Exchange 2007 sizing cheat sheet
Hub Transport / Edge Transport Server

Suggested Hub Transport Hardware Config for Exchange 2007 Installations of 5000 users

Capacity and Transactional IO requirements for Exchange 2007 and Edge Transport and Hub Transport Servers
Mailbox Server

Exchange 2007 Mailbox Server Role Storage Requirements Calculator
Mailbox Server Storage Design
Client Access Server

Planning for the Exchange 2007 Client Access Servers
Unified Messaging

Using Exchange Server 2007 for Unified Messaging and FAX

If you spend time looking through the above you will see that there is a significant increase in the amount of work that is required to correctly size your Exchange installation - there are of course other choices that need to be made - for example:

Do you cluster?
If you cluster - which clustering technology do you use (CCR, SCC?)
If you are not using clustering do you place all the compatible roles on a single server?
If you wish to split the roles out do you choose to have dedicated mailbox servers with HT and CAS running on another server?
Do you use the Edge Transport Role?

All of the above can (and should) take weeks - perhaps months to correctly ascertain - and remember all of this is before you even place the DVD in the drive.

At this stage you might be tempted to overlook the sizing requirements of Exchange 2007 in favour of taking a "Best Guess" - however I urge you not to, Although the sizing calculators and advice look intimidating your should not underestimate the revised Disk I/O and Memory requirements for Exchange - these tools and articles are there to ensure that you do not run into issue later on down the line with the specifications that you have determined.

To add to the complexity of migrating to Exchange 2007 you also need to ensure that your existing Exchange and Active Directory environment meets the recommended specifications and that you are ready for the added administrative overhead that occurs during the co-existence phase of your migration - it is worth reviewing the following articles before you install Exchange 2007 into your environment:

Exchange 2007 System Requirements

Planning for Co-Existence

Managing Exchange 2003 Settings in a Co-Existence Environment

By reviewing the above articles you will reduce the risk of problems during the Schema, Domain and Exchange setup processes however there are some other things that you should take into consideration before you begin:

If possible in your Organisation institute a "Lock Down" policy on Active Directory for the period of the Exchange installations - essentially ban any account modifications and directory structure modifications - this will make the process of a restore much simpler should you need to.
Take backups of ALL FSMO role holders BEFORE you begin the Schema / Domain preparation processes
If you are extra cautious and your schema master is a separate role holder from all the other domain controllers you can perform the Schema updates "offline" so to speak by either disabling replication via RepAdmin tool. This will prevent the changes from being sent to the other directory databases until you have verified that the Schema has been updated properly
You should disable local Anti Virus during any Exchange installation process
When installing the first Hub Transport into your environment it will create a routing group which ensures mail flow between Exchange 2003(2) and Exchange 2007 - you should take an Active Directory backup prior to the installation of the HT role - this will help you roll back should anything go wrong during the process (for example I had a support call where a person had not opted to create the Routing Group and then tried to manually create it - potentially it would have been quicker to restore from backup considering the amount of time that we spent troubleshooting it)

The above are just some of the many things that need to be considered on the road of the upgrading to Exchange 2007 - however to conclude this article the following are a number of other commonly overlooked or indeed misunderstood concepts when migrating:

Store Based Anti Virus Programs are not updated

If your existing Exchange 2003 servers make use of VSAPI based checkers (for example McAfee Group Shield, GFI or Norton) you will almost certainly need to upgrade them for Exchange 2007 - this might represent additional costs for your migration if you do not have Framework licensing for your products.
Backup Tools and Agents

Significant changes have been made to Exchange 2007 at the store level to allow for both streaming (being depreciated and not in Windows 2008) and VSS based backups. You should check that your existing backup product supports Exchange 2007 - and if you have installed Exchange on Windows 2008 you will need to upgrade your backup so that is knows that Streaming has been removed and VSS is the primary backup system.
Archival Products

If you make use of a commercial Compliance product such as Enterprise Vault you will need to ensure that it supports Exchange 2007 - and also that any integration features (for example with OWA) are also fully supported.
Windows 2008

Many people whom are embarking on Exchange 2007 SP 1 migrations will almost certainly be tempted to use Windows 2008 as their Operating System platform (and so they should) - however remember that Windows 2008 is a pretty large departure from Windows 2003 (certainly in terms of IIS and clustering). You should also consider any product that uses an Agent to communicate with Exchange (for example Enterprise Vault) is supported on the Operating System.
Depreciated Support for MAPI and CDO 1.2.1 and ASP Database based applications

MAPI / CDO is no longer supplied as part of the default Exchange 2007 install - therefore you should note that if you have an application which resides on your Exchange servers which makes use of CDO it may cease to function - you can download the components from here: http://www.microsoft.com/downloads/details.aspx?FamilyID=E17E7F31-079A-43A9-BFF2-0A110307611E&displaylang=en.

Additionally if you make use of a ASP based solution which communicates with a Database you need to know that it could experience issues on a x64 platform (you will need to check that there is x64 ODBC driver support).
Remember your Accounts Team

For larger organisations it is possible that you have a dedicated accounts management team. Exchange 2007 re-adopted the Exchange 5.5 administrator model whereby accounts can be created in Active Directory Users and Computers - however the mailboxes need to be created via the Exchange Management Console or Indeed the Exchange management shell.

Again like Exchange 5.5 from the Exchange 2007 Management tools you CAN create both the Active Directory account and the Mailbox - however if you need to add the user to groups and configure Terminal Services profile settings for example you will need to go back to ADUC to finish the job.

What I recommend is that you get your Accounts People to work with the account in ADUC and then supply them with a Powershell script which will configure the mailbox settings as required - all they will then need is a copy of the Exchange Management Tools and Powershell on the machine with the required permissions.
Consider your permissions model

Linked to the above you should give careful thought to the permissions and roles that you assign to people - there is a good article here which will provide you with help in making these choices: http://technet.microsoft.com/en-us/library/aa996881(EXCHG.80).aspx
SSL, the Client Access Server and the Auto Discover Service

If you look at the Exchange server forums which litter the Internet you will find hundreds of posts which deal with the above. The AutoDiscover service is perhaps one of the most complex things to get to the bottom of (as it is linked very closely with correctly configuring SSL, the configuration of Outlook 2007 clients).

Before you deploy users to your 2007 organisation ensure that you FULLY understand Auto Discover and SSL on CAS servers - the following are some very good links which will help:

Whitepaper - Exchange 2007 Autodiscover Service
Exchange Genie - Exchange 2007 Autodiscover Service Part 1
Exchange Analysis Tools

If you make use of any Exchange Analysis or Monitoring tools (for example Mailscape, OmniAnalyser, MOM 2005) ensure that they are compatible with Exchange 2007 - and upgrade them if they are not.

Well I think that I have rambled enough for this particular article - and I hope that it has given you some good pointers and food for thought before you embark upon your own personal migrations.

Anomalies when using the BPA with Exchange 2007 CCR Cluster on Windows 2008

2008-08-30T04:43:00.001-07:00

Reproduced with Permission from: http://telnetport25.wordpres.com

Like many Exchange Administrators whom have embarked upon a few recent Exchange 2007 migrations and deployments, I have chosen to use Windows 2008 as the host operating system and make use of Exchange 2007 CCR clustering capabilities in my overall system.

Although Windows 2008 and Exchange 2007 CCR clusters still make use of the MNS (Majority Node Set) cluster type - there has been significant changes to the underlying management and indeed architecture of the clustering service within Windows 2008.

Before I proceed if you are interested in (and I recommend having a look at) the following link: http://www.microsoft.com/downloads/details.aspx?FamilyID=75566F16-627D-4DD3-97CB-83909D3C722B&displaylang=en

Essentially it contains a number of word documents that give you a good overview of the changes and possible configurations of clustering within Windows 2008 - I especially recommend the following documents:

Windows Server 2008 Failover Clustering Architecture Overview.doc
Overview of Failover Clustering with Windows Server 2008.doc

Now that you have had a chance to look over the possible clustering scenarios (or indeed know you cookies already) I can get back to the article - Like many Exchange Architects before I deploy real life users (and to be honest at many stages throughout an Exchange deployment) I will run a Health Check of the entire environment using the Exchange 2007 Best Practices Analyser tool.

This is located in the Exchange 2007 Management Console - [ START -> Programs -> Microsoft Exchange Server -> Exchange Management Console ] and then navigating to (within the Console) [ Toolbox -> Exchange Best Practices Analyser ] - another quick tip to launch the Exchange BPA on a Windows 2008 Exchange 2007 server is to [ START -> RUN ] and then type “EXBPA” and click on “OK“

NOTE:
It is important to ensure that your copy of the Exchange BPA is using the most current XML definitions supplied by Microsoft. Microsoft updates them frequently with the latest data from their support groups - and indeed corrects “issues” with the BPA via this means.

Many of you will already know how to use the BPA and indeed how to execute a “Health Check” but for readers whom are not as familiar it is as follows:

Execute the Exchange BPA on one of the Exchange 2007 servers within your environment which contains the CCR cluster(s) (using the method above).

When the BPA has loaded (and you have moved past the BPA update screen) you will be asked to either “Select Options for a New Scan” or “Select a Best Practices scan to view” - choose the latter - see below:

You will then be prompted for a Domain Controller to connect to - enter in the details of a suitable DC and then choose the “Connect to the Active Directory Server“

Permissions and network connectivity to your domain controller will be verified when successful you will then be prompted with the “Start a new Best Practices Scan” option - provide a name for your scan - then choose the Exchange servers that you would like evaluated (for the purposes of this article make sure you choose a Windows 2008 based Exchange CCR cluster) and ensure that you have selected “Health Check” option.

Verify the speed of your network and then choose the “Start Scanning Option“

The BPA will then go away and verify your Infrastructure.

Now when the scan has finished you will be asked to view the report of the Best Practices Scan - confirm this option and you will be presented with a view that looks like the following:

Now here you should address all issues which appear under the “Critical Issues” view - but for the purposes of this article we are interested in the Results for your CCR clusters which appear under the “All Issues” tab of the report - click on the “All Issues” entry.

Here you might find two issues which look like the following:

When you expand the definitions of the above entries you will see the following:

Dedicated Heartbeat Priority:

The full BPA definition of the above is available here: http://technet.microsoft.com/en-gb/library/aa997088.aspx

Quorum log too small:

The full BPA definition of the above is available here: http://technet.microsoft.com/en-gb/library/aa995830.aspx

Now the point of this article is not the usage of the BPA tool itself - but the oddity that produces the above messages.

Upon further investigation of the above entries I have found that they either do not exist or indeed are set to the correct values as specified in the articles that have been suggested by the BPA.

I have searched many articles on the Internet and have found nothing that can explain as to why these values appear (under Windows 2008 clustering) as issues within the BPA (especially when they are either not needed, do not apply or exist already) so therefore the only conclusion that I could draw from this was that it is a “Feature” within the BPA itself.

As this was bugging me I contacted a friend in Microsoft whom confirmed to me that the above is indeed an oversight between versions of Windows 2003 and 2008 of with the current version of the BPA and that they intend to correct it very soon.

Therefore if you are running Exchange 2007 SP1 on a Windows 2008 CCR based cluster and are getting the above entries in the BPA Health Check report you can ignore them - but ensure that you update you definitions regularly to allow for the issues to be corrected.

To Offline Defrag or not to Offline Defrag that is the question...

2008-07-08T10:15:00.001-07:00

Reproduced with permission from TelnetPort25.

Many Exchange Admins will come across this conundrum at some point during their careers - essentially when is it good to defrag your Exchange databases. There are of course many different views expressed by many different Exchange administrators on this particular subject - therefore in this article I would like to share some of my own personal thoughts on the subject.

As many of you know ESEUTIL is the tool supplied with Exchange that allows for an Offline Defrag to happen before I begin I would like to do a brief overview of ESEUTIL.

What is ESEUTIL?

ESEUTIL (located in the <Exchange Installation\Bin Folder> – might be considered by many to be the dark over-lord of database utilities which, in the blink of an eye can reduce your information store to a quivering mass of non-functional dog do-do, and accelerate the demise of your career as an Exchange Admin.

However, is ESEUTIL really that bad? – I suppose that the answer to this is yes and no as using the tool incorrectly – or – when it is not need can produce undesirable situations – the following are some quick bullet points about the Pro’s and the Con’s of using the ESEUTILS:

Pros:

Using ESEUTIL correctly and when required (more on this later) can physically reduce the size of your information store databases
When you have no other options left and you have a dead database ESEUTIL can get you some data back (by using the dreaded /P switch)
ESEUTIL can be used in a recovery scenario to roll forward to a specific point post a disaster as long as you have the Transaction Logs (but then again so can most decent backup products for Exchange)
ESEUTIL can be used to check the structural health of your database
ESEUTIL can be used to clone your database

Cons:

Its command line based, messing up a command could leave you with a dead database
Any Database that you intend to run ESEUTIL against must be off-line – therefore users cannot access the system resulting in lengthy down-time
Its slow – Depending on your hardware ESEUTIL will run at around 3 – 6 GB per hour (under a repair) and can be in-determinant during defrags
Its not intelligent – this is dangerous, for example – a Defrag process creates a new database, copies useful data from the old database to the new and then deletes the old PRODUCTION database and renames the TEMP database to the same name as the old – what if power is cut to the server during the Production Delete? and the rest of the process does not finish – ouch!

Generally speaking you should only use ESEUTIL under the following Circumstances (there are generally no exceptions):

When you have no usable backup of your Exchange Databases – Repair Scenarios
When you have had a lot of transient behaviour in the database – Defrag Scenarios – for example;
- A large number of users have either left the company, or moved to another store within the environment
- You have installed a archiving solution into your environment and it has been running for at least 5 months
- You have hit a limit on the Database (in the standard Edition of Exchange only) – this scenario should not happen when using SP2 of Exchange 2003 or Exchange 2007
When you have good reason (good means Application Event Log errors) that suggest a corruption in the Database – Integrity Scenarios
When you wish to replay log files into the Database
When it is recommended by Microsoft Product Support Services, or when you are confident about using the command syntax and you are sure that it is going to be of benefit to you

OK, But I am still interested in ESEUTIL – can you give us some further information?

ESEUtil is designed to check and fix individual database tables based around the JET BLUE engine, however products like Exchange are comprised of many structured and complex pages (which can be either 4 or 8 kilobytes in size) which in turn are linked via indices which are accessed sequentially (this is called ISAM).

As a result ESEUTIL is not Necessarily aware of the data contained within the database pages – nor the relationships between database pages. The results of which when ESEUTIL is used for example using its “Hard Repair” (/P) mode, when it finds a damaged page or index it deletes it, nothing else, just deletes. Given the previous scenario you may of had a database that will not Mount – however /P will potentially get you into the position where it will Mount – but you will normally find missing data within Exchange.

An example of which is many years ago when consulting I encountered an Exchange 5.5 system where the Information Store would not start. There was no backup therefore I had to use ESEUTIL /P in order to get the store to start – ESEUTIL fixed the database and the store service then started, however, every user in the database lost access to all their attachments (the icon would show in Outlook indicating that the message had an attachment, but attachments could be accessed).

Additionally ESEUTIL can be used to de-fragment, check the Integrity of, recover (Hard and Soft), copy, checksum, and dump various informational aspects of your databases.

ESEUTIL – De-fragmentation Mode [/D];

OK, now that we have had a brief look at ESEUTIL and indeed established that it is indeed a tool that needs to be respected - I would like to go over the command switch of ESEUTIL which most people to ask Questions about the DEFRAG – or – the /D Switch.

The de fragmentation Mode of ESEUTIL is designed to reduce the physical size of your Exchange Databases – as online de-fragmentation does not physically reduce the size of the DB – is essentially performs internal maintenance within the Exchange Database.

It does this by creating a temporary Database file, reading through the live database page by page and copying all relevant data into the Temp database (note it skips over white space identified by the online maintenance (event ID 1221) in the Live Database) this process is generally known as re-organisation.

When all of the data from the live database is copied over into the temp database, the live instance is deleted and the temp database is renamed to that of the previous live instances (although this is a very simplified overview of the command).

All indexes in the database are also recreated as part of this process.

You should be aware that you will at least 110% of the size of your production database free on the drive in order to have a successful de fragmentation, although should this not be possible you have the option of either redirecting the Temp file to another disk on the server – or – by following the steps in this article http://articles.techrepublic.com.com/5100-22_11-5285289.html you can copy all of the required files to another server with enough space to handle the defrag, but bear in mind that you will have to copy the database back from the additional server which adds to the overall down-time of your mail system – and also introduces the (small) chance of corruption during the copy back from the source server over the network.

The basic command syntax for the De-fragmentation command is as follows:

ESEUTIL /D <path to database file> – for example ESEUTIL /D x:\EXCHSRVR\SG1\DB\Priv1.edb

There are a number of partner command line switches which accompany the de-fragmentation mode which are as follows:

/S – Specify the location of the Streaming File (this option is not implemented in 5.5 or 2007)

/T – Specify the location where the Temp Database file is to be created (useful if the disk that the database is on does not have enough free space to complete the De-fragmentation)

/F – Specify the location and the name of the temp streaming file (this option is not implemented in 5.5 or 2007)

/I – Do not de-fragment the streaming file

/P – Do not delete the temporary database files at the end of the process

/B – Make a backup copy of the database

Given the above commands and options – if I wished to defrag my Priv1.edb which is located on Drive X:, but place the temp file on L: I would use the following command:

ESEUTIL /D x:\EXCHSRVR\SG1\DB\Priv1.edb /T L:\<tempFile.tmp>

From the above you can derive that the syntax for a successful command is: ESEUTIL /D <Path to DB> <Options – e.g. /T>

One of the questions that many people ask how much space can they generally expect to claim back by performing an off-line defrag on their information store – the answer to which is pretty difficult to give, and should be mainly based around minimum expectation.

For example: the normal and widely accepted way to gain an idea is to check the Event Log for Event ID 1221 – see below:

Essentially the part of the Event Description which states “has ‘n’ megabytes if free space” is the bit that you are interested in.

This the value of ‘n’ in the Event is generally described as the least amount of space that you can claim back (to within one megabyte).

There is another way in which you can calculate the amount of space that you might gain back – however it does require you to take the database off-line to perform the process.

Although this is a pain – I have found this method to be pretty accurate when determining space reclamation metrics:

In the Exchange System Manager Dismount the Database that you wish to process
Open a Windows Command Prompt ([ Start -> Run -> Type CMD the press <Enter> ]) and type in the following command:

ESEUTIL /MS <path to edb file> >c:\Analysis.txt then press enter – see below

This will produce a text file (located in C:\) called Analysis.txt – when you open this file you will see that it is split up into two sections:

SLV Space Dump – this relates to the STM File (not in Exchange 2007) – see below:

At the bottom of the SLV dump (you will find a section entitled “TOTALS”) here there is an entry called “FREE” – the value of this when multiplied by 4096 (this length of a database page in Exchange 2003) will give you the free space in the STM file in bytes – so from my results above:

78 * 4096 = 319488 bytes

319488 bytes = 312KB – space that could be reclaimed

The other section of the report which is called the SPACE DUMP (which is much longer than the SLV dump as it relates to the EDB file) – looks like the following (please note that the following example has been cropped):

At the bottom of the SPACE DUMP on the far right hand side (under the “AVAILABLE” column) you will have a value.

In my case this value is 524, again this is the free space in bytes – therefore in order to determine how much space that I would get back I would use the following calculation:

524 * 4096 = 2096 KB – space that could be reclaimed

Checking the Event 1221 events is easy and does not cause any disruption to normal operations, however using the ESEUTIL /MS does require the store to be off-line – personally I feel that using the ESEUTIL /MS command gives you a more accurate representation of the space that could be recovered, but you need to be aware that it does cause disruption – however if you are considering defragging your Exchange Databases you could build the space analysis in the down-time required.

I would personally only use the ESEUTIL /MS method to check for potential space under the following circumstances:

When a large number of people (much greater than 500 users whom were heavy users) have left the organisation and their mailboxes have been deleted from the store (Purged)
When a company instigates a program such as Mailbox Archiving where mail items going back many years are removed from the store
You know for a fact that there are been no defrag performed on the store for a number of years (at least 3 years).

Now that we have an idea about how much space MIGHT be reclaimed, the question that needs to be answered is – “Do I actually need to defrag the database?”

Do you Need to Defrag Your Database?

OK lets consider the basic reasons why an Exchange Admin would consider De-fragmentation of one of their databases and then go over some explanation of as to why a DEFRAG might not be your first option even though it might seem so:

Performance issues
Running out of space on the Database Disk
General Space reclamation
When asked to by Microsoft PSS

Performance Issues:

One of the first things that I would like to address is that having a large database does not always mean that you will have poor performance.

In Exchange 2003 Enterprise Edition the theoretical maximum size of a single Database can be 16TB (or as often described “unlimited”) whereas in Exchange 2003 SP2 STANDARD Edition the maximum size of the Database is 75GB – however in practicality one would assume that there must be a point where Size = Performance.

I have seen Exchange Database instances which have reached sizes between 190 and 220 GB (and I also know of larger sizes) which perform very well, however the underlying hardware has been specified to cope with the IO and Operation Per Second (IO/OPS) demands that such a size would require. It should also be noted that an Exchange Database should be cared for – they should be monitored, have sensible online maintenance windows which complete and backup regimes that are successful and serviced sensibly.

Diametrically – I have also seen Database sizes of 56 GB which perform very badly, this can be linked to the hardware, online maintenance does not run correctly and no form of checks are made upon them.

So in terms of the [ Size = Performance ] theory (considering the statements above), the outcome means that the formula (as stated) might change to:

Size (of DB) + Administrative Specification + Administrative Habits / User Habits = Desired Deserved Performance

Essentially if you specify your hardware according to accurate load, ensure that required routines run against the databases (and do not overlap with backup schedules) then you can expect the overall physical file sizes to reach significant proportions without manual intervention, however if you do not follow initial sizing guidelines and allow for your Exchange server to proceed un-monitored and do not regulate the actions of your user population then your are asking for trouble.

In terms of my statement “regulating the actions of your user population” – There is another school of thought (on overall performance) right from the development team of Exchange) where it is stated that the amount of items in “Critical Path Folders” – e.g. Inbox, Calendar, and Sent Items can also have an effect on the performance of a user / database – have a look at the following article here: http://msexchangeteam.com/archive/2005/03/14/395229.aspx (and read the comments) – essentially if you allow for your users to use Exchange as a “Filing System” you might (or perhaps will) experience performance issues.

So in summary if you are experiencing performance issues with your Exchange Databases, before you consider using ESEUTIL to defrag, have a look at other root causes. As mentioned above it is possible to have really large EDB files and acceptable performance, so in the first instance use tools such as PERFMON which will give you useful information about what your Exchange Server is doing.

The following is a link to the Microsoft’s Exchange Performance and Scalability Guide here you will find an overview of which counters within PERFMON are relevant to Exchange (http://technet.microsoft.com/en-us/library/aa996078.aspx) I also recommend that you down-load the PerfMON Wizard which automates the configuration of a number of counters that can provide data regarding the performance of your Information Store.

Also if you experiencing performance problems it is an idea to have a check what is going on inside your Exchange databases – this can be accomplished by opening up the Exchange System Manager then navigating to the following: [ Administrative Groups -> Servers -> Your Server -> Storage Group -> Database Name -> Mailboxes ] and have a look under the “Total Items” column readings here will give you an idea if any (or many) of your users are falling into the criteria which the article on the Ms Exchange Team blog describes.

My final comments on performance are that you should ensure that the setup and configuration of you Exchange Disk subsystem is configured and specified to the load and size of the database – if you are experiencing performance problems – before even considering a Defrag have a look at the following:

Are you using the correct RAID levels for your Databases and Transaction Logs (RAID 5 (or 10) for Databases RAID 1 for Transaction Logs)
Have you separated out your Transaction Logs from your Databases
Does each database exist on its own LUN
Move the TEMP/TMP to a high performance drive
Are you using 10K or 15K drives?

If you have gone through all of the above and feel that everything is is, then it might be worth considering Defragging the Database.

Running out of space on the Database Disk:

From what I have seen in the Forums this is one of the most common reasons for administrators wishing to run ESEUTIL /D.

Wherever you can the best option is to add further disk and the move you databases over to the new storage rather than Defrag; I say this as generally you are never looking at huge amounts of space being reclaimed from your Databases when you use ESEUTIL in defrag mode – so in the end you are putting off the inevitable (running out of space) so the best option is to bite the bullet so to speak and add further storage.

To give you an idea of storage reclamation I recently ran a Defrag against my corporate databases and the following are the space saving results (bear in mind that it has been 3 years since I last defragged the stores, and for two of the 3 years we have been using Enterprise Vault:

As you can see for the time periods involved, the amount of users and the presence of an Archiving solution the space savings are not huge.

However if you are not in a position to increase the storage within your server then you would have little choice but to use ESEUTIL /D however I would recommend the following prior to running the defrag:

Examine the Application Event Log for ID 1221 – or perform a ESEUTIL /MS against the databases (then use the method of working out the potential space reclamation from above) - this will help you work out how much space you will get back – you might be faced with a situation where the amount of space that you reclaim is only enough for another month – therefore you will need to present a business case for upgrading the server.
Ensure that you backup your Databases prior to running the Defrag
Prepare your business for down time – depending on the hardware that you have and the size of your Databases ESEUTIL /D can take quite a while to run (for example if you look at my table above SRV2–GeneralStorageDB.edb took 17 hours to complete – and that was without any other databases mounted or being defragged on the same server).

General Space reclamation:

General space reclamation suggests that an administrator is using ESEUTIL /D as part of a scheduled and regular maintenance task. Please do not do this – from the examples that I have given above even with high user turn over, an archiving solution and several years between defrags I only claimed back slightly over 21 GB from 12 Databases if you examine the tables from a per database perspective the actual space reclaimed represents a very small percentage of the overall size of the DB.

Scheduling regular Defrags (for example every 6 months) only guarantees that your database will be off-line for several hours every 6 months.

If you have the inclination to reclaim space periodically and you are Using the Enterprise Edition of Exchange server – then perhaps a better way of doing this is to create a new database and then move your users over to the new database. This eliminates down-time and also serves the same purpose as defragging.

When asked to by Microsoft PSS:

Those of you whom have support agreements with Microsoft may be asked to defrag a database as part of a support call.

Normally PSS will be trying to get an index rebuild rather than being interested in shrinking the size of the database – however, they know what they are doing – but ensure that you follow their instructions to the letter.

Summary:

Ultimately your Exchange database belongs to you, therefore as an Admin you are best placed to make a choice on the course of action that you wish to take. The above is general advice from experience – however it may not fit all scenarios, so just to finish if you are going to perform this task please consider the following pointers:

Always ensure that you have a backup of ANY Exchange Database that you are going to Defrag – ensure that you have tried to restore it prior to starting.
Understand that Defragging is a lengthly process – your database will be out of action for a significant period of time.
Ensure that your server has a working UPS – nothing worse than a power outage right in the middle of using this tool.
If you have the Enterprise Edition of Exchange – consider creating a new store and moving the users over rather than a off-line defrag.
If you have performance issues consider the performance area and the options given there before Defragging – there is nothing worse than taking your database down for 10 hours and then getting no perceivable benefit.
Do your homework on the amount of space you might get back – similar to above, nothing worse than 10 hours down-time and only getting back 1 GB
Don’t use ESEUTIL /D as part of a regular schedule – its not worth it.

This article was provided by: Andy Grogan