Exchange 2003 / 2007 – IMAP Calendaring Meanderings…

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!

Labels: Exchange 2003, Exchange 2007, Exchange Support, Exchange Tips, IMAP

posted by Andy Grogan at 10:44 AM 1 Comments

Exchange 2007 SP 1 High Availability and Disaster Recovery Options

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.

Labels: CCR, Exchange 2007, Exchange Tips, LCR, SCC, SCR

posted by Andy Grogan at 11:40 AM 0 Comments

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

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.

Labels: Exchange 2007, Exchange Migration, Exchange Support, Exchange Tips

posted by Andy Grogan at 11:28 AM 0 Comments

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

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.

Labels: Clustering, EXBPA, Exchange 2007, Windows 2008

posted by Enow Inc. at 4:43 AM 0 Comments

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

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

Labels: Exchange 2003, Exchange 2007, Exchange Information Stores, Exchange Support, Exchange Tips

posted by Enow Inc. at 10:15 AM 3 Comments