beingexchanged

Something Old, Something New

2009-11-09T10:18:00.001-05:00

As many of you know, Exchange Server 2010 Released To Manufacturing (RTM) today, with TechNET and MSDN releases to follow later this week. There are a ton of new features, like Database Availability Groups and Archiving and compliance put in place in this version, so it’s a big step for Microsoft. As you might expect, I’ll be writing quite a few articles on the new features as Exchange 2010 rolls out.

In the meantime, a recent 180 degree turn by Microsoft on support for Exchange 2007 has extended the theoretical useful lifetime of that platform by quite a bit. It may not be time to start writing off Exchange 2007 just yet =)

As reported by Mary-Jo Foley in this ZDNet Blog post, MSFT has announced that they will continue to support Exchange 2007 into the Server 2008 R2 platform. Prior to this point, official support for Exchange 2007 would end on the Server 2008 RTM platform, limiting the lifespan of the 2007 product to the 2008 RTM server. That wasn’t going to be tomorrow, or anything like that, but it certainly would be a shorter time-span than if Exchange 2007 got R2 support.

Yielding to immense pressure from the end-user community, MSFT did acknowledge that not everyone was ready to upgrade to Exchange 2010. There were no details on exactly when an update for Ex2007 would be available for R2, but suspicions are that it will be done via either a Roll Up or possibly even a new Service Pack early in calendar 2010. Traditionally, this type of compatibility update had been done as part of a Service Pack, so my bet is riding on that idea.

Either way, the news that Exchange 2007 will live on to Server 2008 R2 is welcome. This allows organizations who are in the middle of roll outs to not worry about if their servers are installed with Server 2008 RTM or R2, and will allow those migrations to complete on the 2007 platform. This, in turn, allows upgrades to 2010 to occur without being rushed due to OS incompatibility issues. There is something to be said for the fact that this decision will slow adoption of Exchange 2010 overall, but it will mean better, more structured roll-outs over time. Safer, stronger and better planned upgrades are never a bad thing.

More Exchange 2007 OS Choice

2009-11-06T08:51:00.001-05:00

A full article is coming early next week, but in the meantime:

Since Microsoft has announced that Exchange 2007 will indeed get support for Windows Server 2008 R2, you’ve got a new choice for running Ex 2007. So what OS are you going with?

Time to pay the bills! Exchange 2003 and GeoCluster.

2009-11-05T15:10:00.001-05:00

Exchange 2007 introduced the idea of Cluster Continuous Replication (CCR) to the world, allowing you to extend an Exchange Cluster between sites (especially on Server 2008) and to create more than one copy of the mailbox data. Exchange 2010 will introduce Database Availability Groups (DAG), further pushing the technology to provide up to 16 total copies of the mailbox data in any number of locations. Both of these technologies are stellar in their own right, but leave those who are still running Exchange 2003 solidly in the dust. Granted, Exchange 2003 is nearing end-of-life, but with a large portion of the market still running on it (at the very least until the upgrades are done), many folks need solutions.

As I work for Double-Take Software, of course I’m happy to advocate our cluster-extending technology to help alleviate the situation on earlier versions of Exchange Server. This is both because they pay me to vocally advocate it (the FCC may be watching) and because it works remarkably well. More so for the latter reason.

GeoCluster (which was once a stand-alone product but is now a feature set of Double-Take Availability), allows you to create a Microsoft Cluster using Microsoft Clustering Services (MSCS) on Server 2003, but to do so without creating a shared-disk configuration that could lead to a single-point-of-failure and will restrict you in terms of how far apart the nodes can physically be. The idea is simple, GeoCluster works under the hood of MSCS, replicating data on each disk resource from the owning node to all potential owning nodes in the cluster. So Exchange sees a traditional cluster, but in reality the disks are replicated, creating multiple copies of the data based on the active node for each disk.

Since GeoCluster can support any valid cluster configuration, you can freely create clusters that span more than 2 nodes, or even more than one physical site. Keep in mind, however, that you’ll still be limited by single-subnet restrictions in Server 2003’s MSCS implementation. The good news is that moving resources from node to node works exactly the same was as it would in a shared-disk cluster, and therefore automatic failover and on-command moves are all possible.

If you lose a node, GeoCluster lets the MSCS engine arbitrate who should take over, then begins replicating data from that new owner to all the other, surviving, potential owners. Once you repair or replace the original node, the system will sync up the volumes and be ready to allow you to move the resources back to the original node if you want to. This replication is all done with the Double-Take Replication Engine, which allows GeoCluster to have the same level of write-order integrity and data reliability as any other Double-Take connection.

So, until you’re ready to make the jump to Exchange 2007 and beyond, or if you cannot take advantage of CCR for whatever reason, have a look at the GeoCluster solution. It is a cost effective and reliable way to make MSCS even more flexible and reliable, and does so without making Exchange work differently than it was designed to function.

Don’t believe me? Check out this TechNET blog post about what the MSFT Virtualization Team does with partners like DBTK. We help them with clustering solutions for Hyper-V, and can help you with that and much more.

Tomorrow, back to my usual, non-vendor-specific stuff =)

Can I get a Witness?

2009-11-04T11:30:00.001-05:00

Continuous Cluster Replication in Exchange 2007 allows for two nodes of a Distributed Failover Cluster (DFC) for Exchange to be held in different physical locations and different physical network segments. This is a good thing to leverage if you’re not concerned with local High Availability, but can lead to some interesting issues if something goes wrong. The two nodes will use their quorum resources to find out which server should be in control of the cluster (and therefore assign resources accordingly) – but that doesn’t help if the nodes cannot see each other due to network failure.

One of two conditions would happen if you ran into this situation as described this far. You could run into split brain, where both nodes thing they’re in charge and bring up Exchange resources. This can take hours or even days of manual work to fix, and therefore Microsoft has taken steps to prohibit it. If either node can’t figure out who’s supposed to be in charge, both go offline to prohibit split brain at all costs.

The second potential situation is the opposite, that neither node can figure out who is in control and both therefore shut down. While this doesn’t put your data in danger, it does effectively shut off your Exchange system, stopping all messaging flow. Neither situation is good, but by default, if arbitration is not possible via either quorum or other means, this safer situation occurs. Luckily, there are “other means,” specifically the File Share Witness (FSW).

FSW is a file share (as its name implies) that both nodes can see under normal circumstances. It must be placed on a server that isn’t part of the cluster. Usually, you find it on a file server within the environment, but be aware that it will need to be at least Windows Server 2003 SP1 or better. The FSW should also be placed either locally to the preferred node (the one you want to “win” in the event of arbitration) or in an independent location that can be seen by both networks where CCR nodes reside.

In a CCR cluster, there are only two nodes, so right off the bat, if an arbitration event occurs, neither node could gain a majority and take over if there was some communication failure or other emergency. The FSW acts as a third resource that can be polled to find out who is in control. Both nodes will attempt to take ownership of the FSW, but due to the physical placement of the Witness Server, only one will successfully do so. That node stays online as owner of the cluster, the other node prohibits resources from going live until the emergency has been resolved. As you can see, placement of the FSW becomes a critical component to the overall success of this arbitration system.

If you have only two physical locations, your best bet is to place the FSW on a server in the secondary site. This allows the cluster to properly arbitrate to the remote site if the production site goes offline. If you have more than two locations, then you can place the FSW on a server at a third location, just make sure connectivity to that site is stable and constant to and from both CCR servers. If that link is unstable to one or more sites, you can create accidental arbitration events when they’re not really needed. The benefit to putting the FSW at a 3rd site is that you can survive a link outage at either CCR node location without having to manually force one node or the other to take control (called a Force Quorum Operation).

Here’s an example of what I mean. If you have only two sites, and place the FSW at Site 2, a network link failure at Site 1 would force arbitration to Site 2 since the CCR node at Site 1 would not be able to communicate with either the node at Site 2 or the FSW hosted there. In this scenario, there may be no value to failing over to Site 2, but you would automatically fail over anyway. If, however, the FSW is hosted at a 3rd site, and both sites can see it, then a network fault between Site 1 and Site 2 would not flip everything to Site 2. Since Site 1 is the preferred owner, and can maintain control of the FSW, it will stay in control of the cluster.

You can find out a lot more about configuring FSW for Exchange 2007 via this TechNET article. The use of FSW technology is mandatory for CCR, and will continue to be a good idea for Exchange 2010 and Database Availability Groups as well. Learning how this technology works today will allow you to create redundant solutions that last through your future Exchange solution sets.

Friday Poll: Public Folder support

2009-10-30T10:23:00.001-04:00

We’ve heard the rumors again and again. Microsoft is not going to support Public Folders in the next version of Exchange. Seeing as how they tried (and failed) to do it with Exchange 2007 and didn’t even try to cut them out in 2010; do you think that “Exchange 15” will offer support for Public Folders, or will it sound their death knell?

Time Keeps on Slippin…Slippin…Slippin into the…past?

2009-10-26T15:22:00.001-04:00

Once again, I grabbed the title of the post from a play on words on lyrics from “Fly Like an Eagle” by the Steve Miller Band. For those of you who have no idea what I’m talking about, see this YouTube video, and know that you have made me feel very, very old.

The point to the title was that some of you may have noticed that calendar appointments, email time stamps and many other things seem to be off by 1 hour starting yesterday. The reason is that unless you have all your updates and hot fixes from Microsoft, Windows 2000 and 2003 would believe that Daylight Savings Time changes occurred on Sunday, October 25th at 2am, and changed the clocks on any non-updated servers. If that’s an Exchange Server, the incorrect change will flow over into all Exchange functions as well, causing quite a few problems.

Normally, we here in the US change our clocks twice per year. The latter one used to happen on the last Sunday of October, when we all set the clocks back by one hour at 2am on that day. The problem is that the US Government changed the rules late last year, changing the dates that these one-hour shifts take place on. This year, it will be November 1st, but Windows wasn’t originally programmed to deal with that.

Most of us update Windows and Exchange regularly, so we got all the appropriate patches and ran the required updaters on the systems in question. You’ll know you did it right if the clock did not change Sunday, and do change on November 1 at 2am. You know you missed at least one if either your server time, or your email time stamps are all an hour off today.

Yet another reason to patch regularly, but everyone can miss one now and then, so visit this Microsoft Support site on DST changes if things are acting odd time-wise. If thing are acting odd in other ways, throw me an email, I might do a column on it =)

Friday Poll: Smartphones for Exchange Active Sync

2009-10-16T08:33:00.001-04:00

This week, let us know which device(s) you use to access your email, contacts and calendar items on an Exchange Server. Note, for the purposes of this poll, we’re just talking phones that are officially supporting Exchange Active Sync in some way.

Last week’s poll results:

It would seem that AD DNS and a combination of AD and 3rd-party DNS are neck and neck in terms of folks using them for Exchange Servers. Using only 3rd-Party was popular, but only about 1/2 has popular as either of the other 2 choices.

Power(Shell)full Stuff

2009-10-14T09:56:00.001-04:00

Windows PowerShell was introduced a few years back, but is still trying to find its way in the big, bright world of Windows even today. This command-line interface allows users of all versions of Windows from XP SP2 on up to navigate through day-to-day operations without walking through layers of GUI interaction to get there. While somewhat slow to take off in the mainstream Windows admin world, for Exchange Server (2007 and up) it has become an essential part of the Exchange Engineer’s toolkit.

With Exchange 2007, Microsoft removed a great deal of the control functionality from the Exchange Management Console (EMC) in favor of the extensions that Exchange makes to PowerShell, creating the Exchange Management Shell (EMS). At first blush, this seems to be taking one giant leap backwards in terms of command and control on a Windows Server (DOS, anyone?) but once you dive a little deeper, there are a lot of advantages to be found.

Let’s start with speed. EMC is slow, very slow. Waiting for each command to finish loading up in the GUI just to figure out the piece of information you need is painful, to say the least. The main reason for this is that the EMC doesn’t really do anything itself, it just displays the output of various PowerShell commands in a graphical format. So each time you ask the EMC to do anything at all, what you’re really doing is waiting for it to create the corresponding PowerShell commands, evoke and run them, and then take the results and spit them back out on the screen for you. For more complex tasks that are going to take some time anyway (like multi-mailbox move operations), this isn’t such a bad thing to deal with. The GUI components make that job easier, and don’t add a huge amount of time to the overall process. But for other operations, like getting a listing of all Storage Groups assigned to a particular server, the overhead in delays for getting the info and formatting it into the MMC3 GUI interface can mean the processes takes several times longer to perform in the EMC than it would at the command line.

Secondly, some techniques could never be performed inside of a GUI in any version of Exchange. Database consistency checking and error correction were always done from the command line, and therefore it was logical to build those routines into PowerShell and the EMS as the newer versions of Exchange evolved. By leveraging the way cmdlets (PowerShell code snippets) worked, much more complex database control and corrective action sequences could be piped through a single set of commands. This lets administrators do more with fewer keystrokes, and opens up a whole new world to 3rd-Party software platforms who found that batch files just couldn’t cut it for what they needed to do.

Finally, the same way that cmdlets can expand what can be done within the framework of a script for things that were always command-line based; they can also allow administrators to automated a lot of their day-to-day work as well. Prior to Exchange 2007, setting up users and mailboxes was a rather straight-forward process, but required that you interact with a series of GUI’s to get it done. This took up extra time, and also introduced another level of potential errors every time you opened up another GUI. Granted, this did not tend to lead to a lot of issues for experienced administrators, but even the most seasoned pro is going to slip up if they have to click in the same spot, over and over, several dozen times a week. PowerShell allows for the creation of complex scripts that can leverage cmdlets, VB and C# commands and other attributes bound into single executable files. This means that a set of operations can be crafted, tested and saved, then run over and over as required. Less moving parts means less chance for errors, and portability means that a more experienced administrator can craft scripts for folks who may need to run repetitive tasks but not have the skills to work with cmdlets yet. Entire online communities have sprung up to facilitate cooperative efforts on PowerShell scripts and to share what worked and what didn’t for various Exchange-related tasks.

Speed, efficiency and community interaction are just three components of what PowerShell can do to assist the average Exchange Engineer or Administrator. Since the trend toward leveraging PowerShell and the EMS continues into Exchange 2010 (scheduled for release later this year), getting on-board with PowerShell tools now will build a knowledge-base that will grow with you as you continue to leverage new and better Exchange platforms.

Friday Poll – DNS types.

2009-10-09T12:00:00.001-04:00

Why use AD DNS?

2009-10-06T12:03:00.001-04:00

My recent article on the need for (and use of) PTR Records in DNS have sparked quite a few questions on using DNS with Exchange Server in general. The biggest one I get is “Do I need to use Active Directory DNS in order for Exchange Server to work?” The answer to that one is a bit complicated, but in its simplest form, it boils down to, “No, but you really, truly should.”

Exchange Server 2000 and up required some form of DNS in order to function correctly. This is mainly because the Windows Internet Naming System (WINS) was “depreciated” starting with that version of Exchange. What that means is that MSFT officially asked the community to stop using it whenever possible, because it could be removed completely soon. As it turns out, WINS was phased out in Exchange 2007, though it may still be required for certain Outlook functions. That’s a topic for a whole different series of blog posts though.

As for DNS integration, it’s quite possible to install Exchange 2000-2007 without having Active Directory DNS configured in your domain, though it isn’t a best practice. As long as your DNS system can handle Server Name Records (SRV type records), you can successfully use a 3rd-party DNS for your Exchange environment. There are, however; some good reasons to go with the native Windows Active Directory Integrated DNS solutions:

1 – Exchange can natively talk to Active Directory DNS, and therefore can do some interesting tricks with that DNS platform that it can’t do with 3rd-party DNS. Things like AutoDiscovery when you move a user to different mailbox servers, or after a recovery operation with Database Portability just don’t work the same way if you’re not using Active Directory DNS.

2 – Many 3rd-Party tools leverage AD DNS to figure out where Exchange resources are. Note, I’m far from unbiased on this topic, so please see the disclaimer at the end of the blog. Since many Windows-based tools will natively use AD DNS API calls (like DNSCMD and the newer variants in PowerShell), you may need to make manual updates to your 3rd-Party DNS, or may have to give up functionality.

3 – Many other non-mailbox objects are stored in AD DNS, and must be mapped manually in other DNS systems in order for Exchange to work properly. You will have to track your Global Catalog servers, Domain Controllers and other resources in order for Exchange to function.

So, as you can see, there are some very good reasons to use Active Directory DNS if you plan on using Exchange Server. While you may have external DNS records hosted with an ISP or other provider; internally you will be better off with the native DNS solutions in Windows unless you are ready and willing to fine tune your DNS systems and stay on top of it.

If you are in doubt, you can use the Exchange Best Practices Analyzer to test your environment before you begin to install Exchange. This tool will test for many things that Exchange needs, including properly configured AD or 3rd-Party DNS systems.

FCC Legal BS

2009-10-06T11:28:00.001-04:00

I’ll get out ahead of the curve on this one, and publicly state what’s been down in the disclaimer at the bottom of the page since I started this blog over a year ago. I am an employee of Double-Take Software. I’m also a Microsoft ISV Alliance Ambassador (or whatever they end up calling us when the program gets finalized around PDC time). In other words, I AM BIASED. Those of you who read my blogs regularly know that fact, but just in case the US Government comes down on us bloggers like a ton of bricks, I figure I should be crystal clear.

Me. Biased. Done.

New Poll: Exchange Versions

2009-10-02T09:31:00.001-04:00

What is a PTR record and why should I care?

2009-09-29T14:08:00.001-04:00

True story, I heard this exact question from a client not too long ago. Through my trials and travails as an Exchange Engineer, DNS information is one of the very most confusing aspects of email systems that my clients have to deal with. Just figuring out how to use normal DNS records tends to lead to a strong desire to give up on the whole project, so attempting to discuss reverse records can cause many to throw up their hands and run screaming from the server room.

Alright, that only happened once, but wow was it fun to watch.

PTR, or reverse lookup, records are used to allow external servers and systems a way to find out what identity a server has based on its IP address. So, for example, we can look at the IP address information for Bing.com, Microsoft’s replacement for Live Search.

If I do an nslookup on bing.com, I get the following:

Name: bing.com
Address: 64.4.8.147

So it appears that 64.4.8.147 is the IP address for that URL. Now if I put the IP address into nslookup, my DNS server will attempt to backtrack to see what that server is identified as:

Name: origin.bay.ux.search.live.com
Address: 64.4.8.147

Not a perfect return, as I was looking for it to reply that the IP was assigned to a bing.com address, but knowing that Bing Search replaced Live Search, the results are clearly traceable.

You can read up on what PTR records do, and how to create them at this Wikipedia page.

Now that you have some idea of what PTR records are used for, we can discuss why you will want to make sure that all mail domains you have authority over are properly configured to use them.

These days, you can do a quick Bing (or Google) search and find dozens of software packages designed to allow you to send out email as if you were someone else. Sometimes there’s a legitimate reason to do this, such as if you manage email lists for multiple organizations through one mail domain. In many cases, these tools are used toward nefarious ends, allowing a hacker to send email that appears to be from a domain in order to scam or infect the recipient. Famous examples of this are phishing emails (see this Wikipedia page) where a scammer will send an email that appears to be from – say – a bank or other institution. Your end user receives the mail, and since it appears to be from a trusted source, they’ll click the link and possibly enter in private information, leaving your organization open to attack.

To combat this, many SMTP servers either natively support, or can be configured to support, PTR lookups before accepting email. This way, the header information can be examined to ensure that the email isn’t coming from a suspect source. The end users don’t see much difference, but email that is from unknown domains, or domains known to be fraudulent, can be rejected before ever getting to their mailboxes. Exchange 2003 and 2007 do not natively reject email based on a bad reverse DNS lookup, so left to their own devices; you don’t have to worry about blocking incoming mail by accident. This doesn’t mean you can ignore PTR records though. Since many other mail server systems can be configured to reject non-verifiable mail, and since there are a host of 3rd-party systems that work with Exchange Server that can do the same, failure to properly configure a PTR record can cause your outgoing email to get bounced because you cannot verify your identity. This means that you need to set up a PTR record for your Mail eXchanger (MX) records and your domain in general, or you risk having email returned as non-deliverable. Having no PTR record is just as bad as an incorrect configuration here, as a lack of a reverse DNS lookup will cause the same results as an incorrect reverse DNS lookup.

There is a great debate over if this is a good or bad thing. PTR responses could be forged, and so this is not a foolproof method of confirming identity. Also, if multiple organizations all use the same SMTP server (thing about that multi-list email server from before) then which one gets the PTR record assigned to it? If you have an email domain, then for now it is a good idea to ensure that PTR records are properly configured so you don’t run into the problem, but hopefully there will be better, more secure systems to rely on in future to confirm identity (such as the SMTP-AUTH proposed specification as part of E-SMTP).

To avoid blacklists, blocks and email black-holes, configure correct PTR records for your SMTP servers and domains. It is by no means a perfect system, but it is one that you will run into, so an ounce of prevention is definitely worth a pound of cure here.

Net Neutrality and EAS

2009-09-23T10:28:00.001-04:00

Mobile messaging and collaboration makes for a big, bright world in business today. What was once the domain of a single service provider (Research in Motion - RIM) has evolved into a robust set of platforms to convey email, appointments and contacts from one device to another. Blackberries, Windows Mobile devices, iPhones, Android phones and so many other systems can communicate either directly or through a proxy to a Microsoft Exchange platform. This unleashes the workforce and allows for your people to be where they need to be in order to work, instead of where they have to be just to talk to each other through the email system.

Net Neutrality is the idea that no matter what the network provider offers in terms of services and software, you should be able to use the devices of your choice and the platforms of your choice on those networks. It’s a great theory, but putting it into practice is causing some issues along the way. The FCC set forth a set of basic rules that they wanted carriers to follow, and in the greater sphere of comments, they were well received. They recently added in two more proposed rules that directly impact cellular networks (digital broadband) and the services that run across it – including Exchange Active Sync (EAS).

You can get a rundown of the entire proposed rule set in this article, but the two that directly impact EAS most are:

5. Broadband providers cannot block or degrade lawful traffic over their networks, favor certain content or applications over others and cannot "disfavor an Internet service just because it competes with a similar service offered by that broadband provider."

On the surface, this looks like a standard anti-competitive rule. In reality, however, many service providers in the cellular world are viciously blocking competing technologies, and their claim is that forcing neutrality will destroy their business. EAS is a great example of this phenomenon, as not that long ago many providers didn’t allow that traffic on their mobile networks. Mostly, this was due to the fact that they wanted to pus their own version of enterprise email synchronization (such as Sprint’s ill-fated attempt on the earlier Palm Treo devices). Eventually, the need to allow this traffic or lose business to other devices and networks overrode the desire to use and sell their own platform, but that took a great deal of time, and lead to quite a bit of bad press and back-end attempts to circumvent the blocks. By forcing mobile providers to allow all valid and legal traffic, the atmosphere for open communication standards will grow and more people will be able to take advantage of more technologies.

6.Broadband providers must be transparent about the service they are providing and how they are running their networks.

Proprietary networks are nothing new, but trying to create an EAS client for a phone on a network that actively blocks your ability to figure out how it sends and receives data makes this close to impossible. Some providers have blocked all traffic they do not wish to have on their networks by simply making it very difficult – or nearly impossible – to figure out how a 3rd-party tool can possibly communicate with it.

I’m of two minds on these proposed rules. On one side, EAS and other technologies require open, transparent communications platforms to work. Exchange can communicate with a whole world of different vendors’ mobile applications, but only if those apps can talk to the Exchange Server. On the other side, competition drives better software and platforms. If it wasn’t for all the things you can only do (or could only do) on an iPhone, RIM and Google would never have had the impetus to push their own platforms to new heights, and we’d still be staring at plain-text emails on black and white Blackberry devices.

It’s going to be a very loud fall season as the mobile providers and the FCC battle out these proposed rules. The end result will have a huge effect, either good or bad, on how flexible and feasible your mobile Exchange platform plans will be. Competition is a good thing, but it cannot be forced on the market at the expense of profits. There must be a way to balance these scales, and it will need to be found before Net Neutrality can be forged in the mobile marketplace.

Fold with me!

2009-09-18T17:07:00.001-04:00

Folding at home is a great way to help science expand to find brand new ways to help humanity. It’s a project of Stanford University, and been around since 2000. Long story short, you install a client software package on your PC that uses your unused CPU cycles to run protein folding equations. This lets hundreds of thousands of computers from around the world all work together to discover how diseases work, and how to beat them!

So, what does this have to do with Exchange? Two things.

1 – I have a team on Folding @Home. If you use team number 171744 after you install, you’ll be joining up on TalontedTweeple.

2 – For years now, virus attacks have leveraged Exchange Server to proliferate malicious software that creates a huge network of corrupted computers to act as a giant attack grid. It’s nice to be able to use the same theory (grid computing) to do something good for the world instead.

These guys have been running the program for nine years now, and you can see on their website all of the things the research projects that use Folding @Home have accomplished. This is a great way to let your PC work for the world when you’re not actively using it. The software can be tweaked to contain what it is allowed to do and not do, and is very well behaved.

Let’s face it, you’re using power every moment that your PC is running – even if you’re not using it – so why not let it do some work while you’re not around? Even if you don’t want to join my team, you can join teams for Google, IBM, or dozens of other companies and organizations. No matter what team you join (even no team at all), everyone is working toward the same goal.

Get back to where you once belonged (Failover Cluster version)

2009-09-15T12:11:00.001-04:00

In honor of the re-release of the Beatles stuff all over the world (games, CD’s, maybe iTunes at some point), I took the title of today’s post from their song “Get Back” on the album Let It Be (Remastered).

I am, of course, going to tie this to something in Exchange; specifically Exchange 2007 Standby Clustering. Standby clustering refers to the theory of using a replication engine (like the native CCR or a 3rd-party system like Double-Take Availability – see disclaimer below) to place a copy of the data for the Storage Groups of the production cluster onto a secondary cluster. Once the data is replicated, you can use the /RecoverCMS commands to recreate the production Exchange Cluster Mailbox Servers (CMS’s) on that secondary cluster.

The solution set for bringing up the Storage Groups and CMS’s on another physical cluster setup in the same or another location is fairly well established. If a single node fails on a production cluster, other nodes take over the failed Storage Groups and work resumes in a very automated fashion. If multiple nodes, or the entire cluster, fail you use /RecoverCMS and the associated protocols to manually get everything working on another system – so long as a copy of the data exists to work from.

The problem has traditionally been best expressed by the phrase, “And then what?”

If the original cluster failed completely, the answer was simple. Rebuild the systems with the same node names, but prepare the systems as though they would be a new /RecoverCMS target system. However, if you have not lost the production systems, and they’re stable enough to be used again, you would still have to reinstall them without some additional help. The most common reasons for this kind of outage are routine testing of the failover systems and extended power failures that generators and UPS systems can’t handle.

Microsoft does offer a command set to fix this particular problem, but it is not well known or publicized. As a matter of fact, during a recent client troubleshooting session, we had a couple or techs from Microsoft on the phone (Premier Support in this case) and they were not aware of this particular method for cluster restoration.

Once you have fixed whatever went wrong, if your production cluster is still viable (and is suitably stable for continued use), you can use a command set called /ClearLocalCMS to remove the original CMS entries from the original production cluster. Doing so is not without risks, and you should familiarize yourself with this KB article on the subject before you try it.

/ClearLocalCMS will remove the CMS components off the original production nodes, clean up AD, and disable the virtual computer object for the original cluster CMS. This ensures that Exchange doesn’t accidentally address the original cluster system, even after the restore process begins. Once the CMS is cleaned, you can go about restoration of the data using the same tools as you used to get it over to the standby cluster in the first place.

To get back to your original servers, use the /RecoverCMS command in the opposite direction (from DR back to production) and then use /ClearLocalCMS commands to re-prepare your DR cluster for use in the next emergency.

Jumping between clusters is not an automated or easy process, but it does work correctly if you follow all the steps in both directions. This set of command suites (/RecoverCMS and /ClearLocalCMS) can allow you to get back to where you once belonged, every time.

Back to Exchange stuff!

2009-09-14T08:50:00.001-04:00

For those who missed it, the Exchange Eco-System Protection (2003, 2007 and beyond) is available as an on-demand event now. Free with a quick registration form.

Click here to register and view the presentation.

More good stuff later this week.

Eight years out

2009-09-11T16:46:00.001-04:00

The online world has been a part of my life since I was a teenager. My father had been one of the gearheads who joined Compuserve before it even had a GUI, just lines of scrolling text. When I got out on my own, I wrote columns, learned new technologies and brought my words to the world.

On September 11th, 2001; I could do no different. So today, seven years later, as I think back about that moment in my life, I thought I’d share the words I had on that day. Unedited, typos and misinformation still right where they were, this was the Yahoo Groups post that I put together for my weekly column, Reality Checksum, when I finally made it back home that night. It is corny, flowery, and shows the inexperience of my writing not that long ago.

It is also my tribute.

I have gotten back to my life, walked away from a lot of what I saw, but I will never forget.

"The whole darn world is on fire, and my favorite TV show's not on."

A Special Edition of Reality Checksum

That line above is from a song by Billy Falcon called "Wonder
Years." He sings it as a quote from his young daughter as she
watched LA burn in the riots some years ago. She couldn't understand
why the streets were erupting in flame, why people had died, why –
just why.

Today, I felt that way.

I left my apartment today to go to a business meeting. It was a
great day, my first big deal with my new company, a sales colleague
from EMC was picking me up in Astoria to drive out to Jersey City to
the meeting. We were joking in the car and going over plans for the
meeting when I glanced back over my shoulder to see my world go up in
flames.

One of the Twin Towers was burning, smoke pouring from the upper
floors as I stared in disbelief. Shortly, as we listed to the news
radio with mouths dropped open, the other tower erupted in flame as
well. We listened as the radio told us that planes had caused the
damage, just ordinary planes – the same ones you and I would fly in
to get just about anywhere these days.

Then the shocking truth hit like a bulldozer, the planes had been
hijacked, the US was under terrorist attack, and it wasn't over. The
Pentagon was hit, Camp David, and another plane was taken down before
it could reach its intended target. We couldn't believe it as we
finally reached our destination directly across the river from ground
zero. We watched as the flames grew, consuming more of the buildings
every minute, but we weren't that concerned as these buildings were
supposed to survive such things (since the Empire State building was
hit by a bomber, the Twin Towers were supposed to be able to
withstand a similar accident).

We gave our apologies and condolences to the client we had come to
see – they had many clients in the Towers and cancelled the meeting.
And then we sat in the car and tried to figure out how to get back to
Queens when Manhattan was locked down. That's when we were struck
again.

I felt a rumble, as if a subway was running beneath the car, and
looked up to see one of the Towers fall from its heavenly perch down
to earth with a crashing roar.

For a full five minutes, two guys who are paid to talk for a living
couldn't say a word.

We began to move back toward the city, trying to just get home. Cell
phone services were out, too many transmitters had been in the Towers
and now didn't function. Luckily my wireless e-mail device was
working and I found out that my loved-ones and co-workers were safe.
Just as I was getting the last of my messages out, the second Tower
joined its sister and removed an epic landmark from the New York
Skyline forever.

We pulled over and tried to get to my company's offices in Hoboken,
NJ, but that office was evacuated. Finally, after much map
consultation, we found a route home and took the long ride back to
our abodes.

Now I'm watching television, every channel screams at me about events
I witnessed first-hand. By the grace of whatever higher-power you
subscribe to I was not at ground-zero, but the shockwaves of that
explosion racked me still.

Why? What did this gain whatever group is too cowardly to announce
itself? What could this group of cold-blooded murderers ever hope to
accomplish with these violent, senseless acts? This was not a
military target, this was not a governmental target, this was a
civilian building. Yes, it represents the financial might of the
world, and many would say that capitalism is bad, but does this give
anyone the right to kill tens of thousands of innocent people?
I hope we do not go out and bomb the crap out of some small country
in retribution – that would make us as bad as them. I hope we find
the masterminds, the people who figured out how to do this but didn't
want to get on the planes themselves. I hope we hunt down everyone
responsible for this travesty and haul each of them before the World
Court. I am a peaceful man, but not a pacifist, so if America needs
a death to satisfy our vengeance, then let them be executed by the
order of that court – but first let them be used to send a message to
the entire world.

Let the trial show the world that their plight was invalid, that
their fight was unjust. Let it show everyone that these animals are
nothing more than cold-blooded murderers with no higher purpose than
to kill as many people as they can to bring attention to
their "cause". Let each of them and their "causes" be discredited on
the Global Stage, never again to be given respect, to be allowed to
grow to this dangerous level, to flow into a grievous act like this.
And when all is said and done, let us show the world what we have
shown them time and time again. No matter what you do to us, how
many you kill, how much you destroy, how far you take your "cause" on
the Global Stage; you will never kill the indomitable spirit that
burns in the heart of every American. We have survived flood, fire,
disaster, war, corruption, and even a Civil War that tore our very
heart in two – but every time we came back, stronger than before,
ready to meet any challenge put to us again and again. You have not
won the day, you faceless, nameless cowards; you have done nothing
but rallied all of America to come crashing down upon you with all
the force of our Spirit. You will be found, you will be brought to
justice, and you will find out that no one tramples the American
Will – no matter how hard they try.

Now, let us begin to heal. Let us rebuild the Towers, the Pentagon,
our lives. Mourn those we have lost to this tragedy, respect their
memories by going on and living life to the fullest every day. Talk
to your children, explain what happened as best you can to their
young minds. We have to shape the future through them, and lead them
into a world of their own American Spirit, so that they may face the
challenges their world will put to them.

This morning, I saw firsthand my world crashing down – literally.
But brighter than the fires that burn in downtown Manhattan burns
another fire. It burns in my heart, and yours, and the hearts of
every free man and woman and child in the entire world. It is the
flame born of our outrage, our pain, our morning, our shock; but it
is beyond this. The flame that burns within our hearts will fire the
forges that will rebuild not just New York and Washington DC, but
will rebuild our world to heal this rift torn by violence.

My deepest condolences to all those who lost loved ones to this
tragedy. Let us morn their passing in the very greatest possible
way – live life, live on, and in our hearts, our mind, and our deeds,
let us remember them well.

And for those who have young children who cannot understand why they
were sent home or what is happening in their world, another song may
bring some solace to your troubled parental hearts:

"Little child,
dry your crying eyes,
how can I explain the fear you feel inside?
Cause you were born into this evil world,
where man is killing man and no one knows just why.
What we have become?
Just look what we have done.
All that we destroyed you must build again."
- White Lion, "When the Children Cry"

Let us begin to build again.

in necessariis unitas, in dubiis libertas, in omnibus caritas
Mike Talon

September 11, 2009

New York City

CCR clustering is still clustering, and so is DAG

2009-09-08T15:15:00.001-04:00

As more and more of my readers move to Exchange 2007 and 2010 from Exchange 2003 and earlier versions, I hear a lot about how using the new High Availability tools will finally free them from the yolk of clustering in Windows. While both CCR and DAG are definite improvements over traditional shared-disk clustering, neither is a departure from clustering entirely.

We’ll be talking about the new HA stuff in Exchange 2010 (along with much more of course) in the webinar Double-Take Software and Microsoft are presenting tomorrow. I’m the speaker for Double-Take, and Patrick Foley from Microsoft is going to be doing their portion. It’s September 9th at 11am, and you can still register for free by clicking here.

In the meantime, it is important to realize that both CCR (Continuous Cluster Replication) and DAG (Database Availability Groups) are offshoots of Windows Failover Clustering (WFC). They both change the way WFC works, and by quite a lot, so you may never touch the underlying cluster technology, but it is still there.

CCR – as its name implies – works by allowing you to create a cluster during the installation of Exchange 2007. This one is a bit easier to see as part of WFC, as you have to create a Failover Cluster first – specifically a Distributed Majority-Node File Share Witness Failover Cluster. After that, when you install Exchange Server you can specify which server(s) will be the Active node(s) and which will be passive. This creates the clustered Exchange resources for you, making the overall process of setting up clustering for Exchange a lot easier. As this one has Cluster in the name, it’s easier to see the WFC roots.

DAG will permit you to create the cluster itself from Exchange 2010 command sets, eliminating the need to pre-create the Failover Cluster prior to getting the Exchange installation rolling. While this makes the process even easier than in 2007, it still requires that you have two or more servers capable of running Distributed Failover Clustering. This means that not every version of Windows 2008 is going to be suitable for DAG, but also means that – under the hood – you still need to know how Distributed Failover Clustering works to properly manage the DAG systems.

In both cases, the required level of understanding of clustering is greatly diminished from what was needed in Exchange 2003 and earlier versions. Most of the guts of the cluster are controlled by Exchange itself, which is a double-edged sword. On one side you have the fact that folks who don’t have a lot of cluster know-how can now set up HA solutions for Exchange. On the other side, people who don’t have a lot of cluster know-how are facing troubleshooting clustered Exchange solutions they may not have realized were there.

Both solutions work great for Exchange. While they don’t eliminate the need for 3rd-party products to help with overall HA (and I’m biased on this one, see disclaimer below), they do make mailbox server protection much more complete. Just remember that you’re still running on a cluster, and arm yourself with the knowledge needed to keep it running smoothly.

Storage Groups, or, Keep Them Moving and Spread Them Out.

2009-08-31T13:57:00.001-04:00

In a recent conversation with a colleague (James from VA in this case), he mentioned that there were a lot of folks who simply jammed all their users into one Storage Group in Exchange, even when they had the option to use multiple groups, and really should have.

Storage Groups are databases in Exchange Server. They contain Information Stores and Log Files, and logically group together users and Public Folders that are related in some way. There are a lot of different ways that you can choose to use allocate users to Storage Groups, but here are some of the more common methods:

1) Geography – Many organizations are centralizing Exchange servers to one or two datacenters, instead of putting a server at each location. This saves money overall, allows for better message hygiene and, with the use of technologies like Outlook Anywhere, doesn’t alter the end-user experience to a any large degree. Creating a Storage Group for each physical location allows you to better administer the Exchange system as a whole. If a new policy or procedure impacts only one office, you won’t be stuck combing through all the mailboxes and folders trying to find the users who are impacted by that policy. Just apply it to the Storage Group for that office and move on.

2) Department/Employment Level – This is a very popular method for splitting up users into Storage Groups, especially where there are a relatively small number of locations or other physical defining factors. Many companies will define their Storage Groups by the departments that exist within the firm, mirroring their political structure into the messaging systems. Sales, Support, Administration, Management and other logical groups can be translated into their own Storage Groups. This has the dual benefit of not only allowing you to better control policies and procedures for each group, but also making it easy to put all managers into their own server which gets clustered, while the rest of the employees are on servers that will be restored from tape. That’s just one example of the benefits of this segregation system for Storage Groups from the real world, so please don’t send hate mail. Of course, you can use a tool like Double-Take to give you even more options, but see the disclaimer at the bottom of the blog, as I’m far from unbiased on that topic.

4) Alphabetical – Where there may be only one or two locations for the business, or where everyone’s email is equal, then using something as simple as the alphabet can help figure out where to split out your Storage Groups. A-M and N-Z or even 3 or 4 different breakouts can allow you to allocate your users across multiple Storage Groups without worrying about which users should go in which groups by other factors.

The reasons for splitting up Storage Groups go well beyond simple administrative tasks like policy and procedure enforcement. Storage groups can take an unmanageable situation, like 3000 users all in one gigantic glom, and make life easier to deal with by allowing you to manage smaller groups as required. Database maintenance on a 500 user, 50GB Storage Group is a lot easier than database maintenance on a 3000 user, 1.2TB set of Stores. It also means that the other 2500 users aren’t offline while you do that maintenance on the one Storage Group in question.

Physical limitations of Exchange could also force you to break things up into groups. Granted, the built-in limit of 16TB per Storage Group (in Exchange 2007) is one most folks won’t ever hit without already breaking things out into multiple Storage Groups, but there are other size limitations. Storage Groups must have their database files (.edb in 2003 and 2007, .stm in 2003 only) exist on a single logical volume. This means that if you have 1TB of disk space, your Storage Group can’t grow past that point. Multiple Storage Groups allows you to allocate your user data across multiple volumes, allowing easier growth and better storage management overall. This also leads to more spindles and read/write heads being used at once, which increases overall performance.

Even the Standard version of Exchange 2007 allows for up to 5 Storage Groups, so even smaller organizations can now split their users out across multiple Groups. Exchange 2003 and earlier only supported one Storage Group, so if you’re on those versions, you will have to keep everyone together. Otherwise, live by the simple mantra that more is better when it comes to the allocation of users to Storage Groups.

Getting Smart (Smarthosts that is)

2009-08-25T10:11:00.001-04:00

No matter what version of Exchange Server you’re using – or even if you don’t use Exchange at all – you need to perform message hygiene on all mail in your organization. Virus files, spam, phishing schemes and tons of other attacks are thrown at every email domain, every day. If you’re not ready to deal with them, you’re dead in the water. Smaller companies often just make due with hygiene software on the Exchange Server itself, but all sized firms need solution sets, and even smaller firms can take advantage of Smarthosts in a few different ways.

Smarthosts are servers or hosted solutions that are dedicated to performing message hygiene on all mail coming and going from your organization. They come in many flavors, but tend to center around three types:

1 – Fully hosted solutions. This method has no Smarthost hardware on-site, but instead contains everything at a hosting provider’s location. Lowest up front cost, but highest ongoing (monthly, quarterly, etc.) costs.

2 – Hybrid solutions. Here, you host a small appliance on-site to handle some of the workload, with the rest of the message hygiene functions handled by the service provider in their facility. This isn’t quite as popular as the other two solutions, as the costs can quickly outweigh the benefits.

3 – Fully owned solutions. Appliances and servers are in your datacenter, and totally controlled by you. Start up costs are high, but ongoing costs are very low, as you’re only paying for updates to the virus/spam filter engines.

For smaller organizations, hosted solutions allow you to assign your Mail eXchanger (MX) record to point to your Smarthost partner’s datacenter. There, all incoming mail will go through the filters and checkers before it ever reaches your internal server set. Most hosted providers allow you to update a list of “known good” recipients, so that any mail not destined for a valid employee is rejected immediately. Virus scans are performed, and optionally spam filtration happens as well. The remaining mail goes off to your internal mail servers for delivery to the end-users.

When mail leaves your organization, your internal servers are configured to send it first to the Smarthost provider, instead of directly to its destination SMTP servers. The service provider performs all the same message hygiene on those messages, then acts as the SMTP gateway for your domain out to the rest of the world.

Hybrid solutions do everything that the fully hosted solutions do, but typically place a small appliance on-site to do periodic scans of the mail server itself. They can also help speed up the whole process by making the “first hop” for email flow out of the organization be local instead of across the WAN. It’s rare to see a hybrid Smarthost system that only does email hygiene, as the fully hosted or fully owned methods are much better for this kind of single-task solution. Instead, the appliances on-site will typically handle all anti-malware processes including updating desktop protection and server scanning.

Fully owned solutions place appliances and/or other equipment at your production facility. They act the same as the hosted solution, but you own all of the hardware and pay only for periodic updates to virus definitions, malware profiles and spam allow/deny lists. This solution offers much more flexibility than a hosted solution, as you have complete and immediate control over any changes that might need to be put into effect. The drawback is that if the hardware needs to be upgraded, you’ll be responsible for buying the new boxes.

Smarthosts are available from a large number of vendors. Postini, Barracuda, and Microsoft Exchange Edge Services are just three that can be found with a Bing Search. Most perform the same tasks, but each has their own selling points. Your best bet is to talk with multiple vendors and see which one has the solution set closest to what you need. Ask about things like ease of administration, web or application interfaces, ability to create custom allow/deny lists, and integration with your own Domain services to get updates to users and allowed accounts without compromising security on your AD servers.

No matter which vendor you choose, or which solution, using a Smarthost removes the message hygiene load off the Exchange Servers, which is always a good thing to do. By dedicating either a service or server to handling message filtering and security, you can free up resources to provide a better end-user experience and a safer messaging environment.

Webinar coming up!

2009-08-20T16:06:00.001-04:00

Please feel free to register for the Double-Take and Microsoft Exchange Ecosystem Protection Webinar. It’s going to be on September 9th at 11am Eastern Time.

I’ll be presenting for Double-Take, and we’ll be joined by a (as yet not able to disclosed) Microsoft guest speaker as well.

You can register here to join the Webinar free of charge:

Exchange Ecosystem Protection from Double-Take and Microsoft

As for what we’re talking about, well, you can watch this video where I explain it:

Yep, that’s my ugly mug doing the teaser video =)

Hope to see you all there on September 9th!

Exchange 2003 only wins with WINS.

2009-08-19T13:34:00.001-04:00

Since Microsoft released the Release Candidate for Exchange 2010, I figured that a look back at some things in Exchange 2003 are well in order. After all, a lot of folks are currently on that platform, and waiting for 2010 to RTM before they upgrade.

So today, let’s take a look one of the components of Windows that Exchange 2003 needs to have in place, but that causes confusion and doubt every time it comes up in conversation.

The Windows Internet Naming Service (WINS) is a component of Windows Server NT4, 2000 and 2003 that – as its name implies – translates NetBIOS names into internet names and addresses. And to be absolutely clear on the subject, Microsoft *requires* the installation of WINS for full functionality of Exchange 2003. Here’s the proof.

The reasons for this insistence on having WINS present in Exchange 2003 are varied, but the controversy over the requirement has raged ever since Exchange 2003 was released. The confusion stems from the apparent dichotomy between the fact that 2003 is supposed to be totally DNS integrated, and the view that NetBIOS dependencies make it look as though it is not. Another reason for confusion is that even though Microsoft says that the installer will not run properly without WINS in place, many clients have managed to install Exchange 2003 without the WINS services running at all, or worse yet; with the WINS system improperly configured and malfunctioning.

Exchange 2003 leverages Active Directory (AD) DNS for nearly all name resolution functions, from finding other servers in the local environment to finding SMTP hosts for external mail destinations. For internal resolution, Exchange can leverage AD and Global Catalog servers to find things, as long as everything in the domain in question is using Windows 2003 or higher, and configured appropriately. MAPI systems in 2003 also can use DNS to find Exchange servers (Outlook 2003 and up) or to locate other resources. So if you are in a pure Windows/Exchange/Outlook 2003 or higher environment, and you have only one Active Directory site, then you’re all set without WINS.

That last sentence is key to figuring out where the requirements for WINS come from, and where most of the confusion stems from as well. Most environments that use Exchange 2003 still have mixed-mode domains, possibly even some Windows 2000 servers around. They’ve also brought legacy systems up to Windows 2003 over the years, meaning that older names and objects may still be preserved in AD. So if an Exchange 2003 server needs to find a resource that AD only has a “short name” (non-fully qualified domain name) for, the traditional method to find that resource would be WINS, not DNS.

This also comes into play if you have multiple AD sites across multiple physical locations. Since short names don’t translate properly from site to site, or domain to domain in the same Forest, WINS is necessary to translate the resources name into a location for the resource itself.

Finally, any legacy Outlook clients (XP and earlier) rely on WINS to find all resources, as the MAPI clients they contain don’t understand DNS lookups at all. So if you have any older Outlook clients running around, you’ll need to ensure WINS is configured properly. Similarly, ExMerge relies on WINS since it was a hold-over application from earlier Exchange versions, and therefore never designed to leverage DNS.

So, until your environment moves up to Exchange 2007 or 2010, and a Native 2003 or Native 2008 Domain architecture, you’re stuck with WINS. The good news is that WINS is just another component of Windows in 2003, and therefore not a bear to implement at all. Go to Add/Remove Programs and choose to install Windows Components. You’ll need your OS CD’s to finish the install, and as always; be sure to Service Pack after you are done and run Windows Update. There have been many changes and patches to WINS over the years, especially in light of recent attacks against it.

WINS is a legacy system that is – thankfully – going away as we move toward Exchange 2007 and 2010 native environments, and as legacy Outlook clients are phased out. Until then, make sure you keep up with WINS patches and ensure it is installed and configured. Not doing so can cause resolution problems for Exchange 2003, and installing it is a requirement from Microsoft, so take the time now to make sure your WINS systems are operating full steam.

Confirmed, No Server 2008 R2 for you!

2009-08-14T16:08:00.001-04:00

Sorry for the horrible delay in posting, my loyal readers! I’ve been trying to track down some official sources on this one, and of course Jeff Guillet from the EXPTA Blog beat me too the punch. However, he’s a good guy and a great author, so I don’t mind giving him the credit.

Much to the dismay of a large number of Exchange Admins and Engineers, MSFT will not be supporting the 2007 version of Exchange on Server 2008 R2. So, if you’re planning on upgrading from earlier versions of Exchange Server, you have only two choices:

1 – Use Server 2008 RTM, and be prepared to stay on that version of the OS for an extended period of time. This will let you use Exchange Server 2007 SP1 and take advantage of Distributed Failover clustering and other nifty Exchange 2007-specific tool sets that rely on the Server 2008 architecture.

2 – Alternately, you can wait on your upgrade until Exchange 2010 is released to market, and become an early adopter on Server 2008 *or* Server 2008 R2. Interestingly enough, Exchange 2010 will indeed by backwards-compatible to run on Server 2008 RTM, even though 2007 won’t make the leap forwards onto R2.

As many clients were in the process of either rolling out 2007 to replace other email platforms or were upgrading from Exchange 2003 and earlier, this is a dramatic policy announcement from Redmond. Current plans to continue toward Exchange 2007 on the latest OS (Server 2008 R2) will have to be altered or scrapped. If abandoned, new plans have to be set up for Exchange 2010. I can only believe this will lead to a slow adoption rate as Admins and Engineers try to figure out the combination of Exchange and Windows that will a) function and b) allow them to upgrade now and keep going for as long as possible. Since Exchange 2010 will have a lifecycle that goes beyond the end-of-life date for Exchange 2007, many clients are making hard decisions between moving forward with the Exchange 2007 rollout, or re-planning to use the newer version.

In the end, there are a lot of great reasons to move up to Exchange 2010, so from a purely technological perspective, moving up is a no-brainer. The problem is that many folks have been planning for over a year to implement Exchange 2007. Planning that started when the first Service Pack was released for both Windows 2008 and Exchange 2007 – traditionally signaling the point where most upgrades begin in earnest.

I fear that this will cause an additional hurdle to migration, both from other platforms and from Exchange 2003 and earlier. I can only hope that Microsoft has some trick up their sleeves when Exchange 2010 launches to make the jump easier or simply more compelling.

Exchange 2007 Installation – continued (finally)

2009-07-27T13:06:00.001-04:00

Some avid readers brought to my attention that I had promised an article on the minimum required for installation of Exchange 2007 in a default server config last week, and didn’t deliver. Sorry about that, and here we go!

Once you’ve stepped through the pre-requisites for Exchange 2007 (see two articles back), you’ll be ready to run the installer proper for the Exchange system. Today, we’ll focus on the setup for a single Exchange 2007 server holding all required roles.

Before you can install Exchange 2007, we’ll have to get AD ready to roll. Previous versions of the Exchange installer had the /forestprep and /domainprep switches that could be run by Domain Admins who didn’t have Exchange permissions and didn’t want to give those domain privileges to the Exchange Admin. Exchange 2007 doesn’t have those switches, but instead segments out the different tasks into a set of 5 switches, each doing a specific prep job. You have two choices here. First you can get Enterprise Admin rights and just run the setup wizard. Second, you can have someone with Enterprise Admin rights at the root domain and Domain Admin rights for each sub-domain to run the individual commands. They can be found, and are explained, in this TechNet article.

Once the domain and forest have been prepped, you can run the Exchange installer on the server where you want Exchange installed directly. While there are various command-line and silent install methods, I’m going to focus on the wizard-based installation.

After you step through the welcome screens, you’ll be asked a few critical questions. From here on out, we’re going under the assumption that you’re running as an Enterprise Admin and that you’re doing everything (domain prep and all) at once.

You’ll need to define the Organization Name. This is the Exchange Org, and not the company name or AD domain name. Though the three names (Domain, Company and Exchange Org) may be related, the Domain Name and Exchange Org Name can’t be identical. Choose something that makes sense, and doesn’t use any special characters – stick to numbers, letters and underscores.

You’ll also have to allow or deny permission for Microsoft to be informed about errors that Exchange sees, and you’ll tell Exchange if there are users on legacy Outlook clients (Outlook XP and 2003) and if there are 3rd-party MAPI clients (like Entourage) in the client-base. Be careful here, if there is any chance that you’ll have non-Outlook 2007/2010 clients, use the legacy setting. This creates a Public Folder hierarchy to handle administrative Public Folder tasks like the Offline Address Book distribution; even if you do not use Public Folders for anything else or you are setting up different Public-Folder Only servers. Without the administrative folders, Outlook before 2007 will not be able to function correctly.

You will also need to choose what Roles to install. The default is to create Mailbox (MBX), Hub/Transport (HT) and Client Access Services (CAS) roles, which are the three mandatory roles you must have in place for Exchange 2007 to run. While you do not have to have these all on one server, each site has to have at least one of each of these roles running somewhere. The default selection in the wizard will put these three roles onto the server you’re installing to, which is fine for smaller organizations. If you have heavy MAPI users or a lot of users, you will want to install the MBX role only and put CAS and HT on one or two independent servers. If that’s the case, select to install MBX role only here, and run the installer on the machine(s) that will host the HT and CAS roles and re-run the installer there, choosing the appropriate options as you go to install just the roles you need on each box.

The remainder of the installation is pretty much automated. You’ll be able to watch the progress of each installation task, and as Exchange moves forward you will see a status report (with green check, yellow bang or red stop sign) as each is completed. Hopefully, you’ll only see the green checks across the board.

While it is sometimes not required to reboot after the install, it’s not a bad idea to reboot anyway. The reboot should be quick, and will ensure that resources used by the installers are freed up, and that all the services start properly. Neither of those things is bad, and no one is yet using the server, so reboot, please.

For a default installation, that’s about it! Next week, we’ll start talking about what the individual roles do, so you can decide if you want them on independent servers (or at all, for the non-required roles). I’ll also endeavor to actually write up what I promise next week And finally, for my non-Exchange-2007 users, I promise to do some articles on Exchange 2003 again in the very near future!