.: Enow Solutions Engine

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.

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

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.

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.

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.

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

All for one and one for all: The key to a successful Office Communications Server 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.

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:

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:

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.

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.

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.

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

Understanding Exchange 2010 Storage Architecture: Part 3

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

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.

Exchange 2003 / 2007 – IMAP Calendaring Meanderings…

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.

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.

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

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.

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.

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:

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.

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

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

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.

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.

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

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:

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

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.

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

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:

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

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:

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

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

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.

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.

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:

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.

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:

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

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

Introducing the new ESE Consultants' Corner