beingexchanged

If I cannot bring you comfort, than at least I bring you hope…

2009-12-28T09:24:00.001-05:00

It’s the week between Christmas and New Year’s Day here in the US, and most of my compatriots are taking vacation days. As I work with a sales team (see disclaimer below the blog) I’m working, but I’m still in the spirit of the holiday season. So, instead of my usual Exchange-specific stuff, I’m going to give my annual Three Toasts blog entry this week.

Each year, at New Year’s Eve, I offer three toasts at whatever party I find myself attending. They sum up my feelings on the turning of the year pretty well, and so I’d like to share them with my blog readers as well.

First, a toast to everyone who’s stood with us this year. Friends and family who took the walk through our interesting times side by side with us, and who will walk again with us in 2010. May we celebrate together for many years to come.

Next, a toast to those who cannot be with us. Kept away by physical limits, or distances of the heart or spirit. Just know that you are missed, and that you will never be forgotten.

Finally, a toast to those who we will meet this year. May we learn from each other, and leave each other better than we were found.

Good luck, good health, and thanks for reading BeingExchanged for the last year. I’ll keep writing as long as you keep listening, so here’s to a great 2010!

For those interested in where the title came from, there is a truly beautiful song in (the otherwise horrible) movie Toys. I quote it in my blog posting each year around this time (whichever publication I’m writing for), and it’s worth a listen.

If I cannot bring you comfort,
then at least I bring you hope
For nothing is more precious than the time we have, and so
We all must learn from small misfortunes
Count the blessings that are real
Let the bells ring out for Christmas
At the closing of the year

- The Musical Cast of Toys Featuring Wendy and Lisa

Holiday M’s

2009-12-22T14:16:00.001-05:00

This is my last post for 2009 (barring any emergency stuff that is) and so I would like to impart my usual holiday wisdom to everyone who reads my blog. There are a lot of things we as admins and engineers do every day of every year, but around the holidays at the end of each year, it’s nice to take a step back and review a few things. I’ve got three M’s that each of us would do well to follow.

1 – Maintain: Maintenance is critical to a well-running technology plant. It doesn’t matter if you’re a 1-server SBS shop or have hundreds of servers in dozens of countries, you need to make sure things are kept up to date. This includes making sure you have the appropriate patches and fixes for applications, including your OS. Windows and Exchange 2003 and 2007 have both undergone significant upgrades this year with Service Packs and system roll-ups. Windows Update should cover you for Windows and Exchange 2007, but you’ll need to check the Exchange 2003 area of TechNET to get the updates for that platform.

Take the time to make sure you are up to date, the smooth running and security of your systems depend on it.

Also, now is the time to consider your offline maintenance runs, especially on Exchange 2000 and 2003. MSFT doesn’t really require these tools be run, but after a long year of employee shuffling and database reconfiguration, an offline defrag can definitely help keep the system running optimally. Exchange 2007 and 2010 do not generally require this, but it’s not a bad idea if you’ve removed or moved a large number of mailboxes around during the course of the year.

2 – Monitor: So many of my clients don’t have any form of proactive monitoring on their systems. There are inexpensive (and sometimes even free) tools that can keep an eye on your servers and systems, alerting you if things start to go south even before you start to see problems in the network itself. More advanced tools like System Center from Microsoft and Tivoli from IBM can help hunt down issues that have eluded you up until now. Monitoring should never be a “nice to have” item. You need it, and as soon as possible. At the very least, make a point of checking out the event logs on your Exchange servers once a week or so to see if there are any repetitive error messages cropping up. Knowing about errors now saves you from dealing with corruption or failures later.

3 – Make Merry! Let’s not forget that no matter what holiday you celebrate (Christmas, Solstice, Chanukah, Kwanza, something else, or nothing at all) this is typically a time of year when people take a break from the day-to-day activities of their lives. Try to take some time, get some rest, and clear your head. Every one of us deals with so many issues every day, that sometimes stepping back and looking at them with a new perspective is just the ticket. The servers will be there when you get back, and the monitoring systems (see above) can let you know if they need you in the meantime. Some of us don’t have the ability to take some time, but if you do, take it – you’ll be much more effective for it.

See you all in January, and thanks for reading along this year. I always welcome questions and comments to miketalonnyc@gmail.com – so fire away!

Bury the Berries? Not yet.

2009-12-14T14:19:00.001-05:00

Research in Motion (RIM) changed the game when they introduced their Blackberry devices to provide mobile email solutions for Exchange and other email platforms. Over the last few years, many other companies have stepped up to produce handheld messaging devices, mostly centered around mobile phones and carriers. There are so many good competitors these days, that some companies are considering if they want to ditch the Blackberry Enterprise Server (BES) platform in exchange for… well… Exchange.

Exchange 2003 and up allowed for Exchange Active Sync, a series of mobile technologies that allow Exchange servers to communicate directly with mobile devices using push synchronization to deliver email, contacts, calendar items and other information. Windows Mobile phones are natively equipped with the Active Sync technology; and the iPhone, PalmOS and WebOS, and various versions of software for Android phones have also licensed the Active Sync technology for those platforms. This means that these devices can communicate directly with an Exchange server and send/receive mail, sync contacts and tasks, and answer calendar requests without the need for an intervening server platform like BES.

However, there are two key reasons that I am (at least for now) sticking with my Blackberry device. First, there is battery life. Talk time is a pretty standard 4-6 hours no matter what OS runs on the phone you’re holding. But standby/messaging time is another story all together. With push email active, I have yet to see a Windows Mobile phone go more than 6-8 hours without needing a charge. If I turn off Bluetooth, push email and just about everything else that uses a transmitter, I can stretch that number to 12-14 hours, but then what’s the point of carrying the device? Blackberry devices routinely go 24-36 hours of messaging, even with Bluetooth active (but not transmitting). Android devices can go a bit longer than Windows Mobile, as do iPhones and WebOS systems. They typically run the middle-of-the-road between those two extremes.

Secondly, there is security. BES allows for a remote device to be wiped natively. Windows Mobile devices can also be remote-wiped if you’re on Exchange 2007 and up, but iPhone and other OS devices must use 3rd-party software to accomplish this goal. Remote-wiping is used to provide security if a device is lost or stolen. Once activated, all personal/corporate data on the phone is deleted, rendering it both useless and safe. Good Technologies has reinvented itself over the last few years as a great provider of remote-wipe and encryption systems for Android and iPhone platforms, but it is one more thing you have to manage in an environment that (based on who would use it) already has a BES server running.

Based on these two factors, I cannot envision organizations ditching BES in favor of an Active Sync solution set exclusively. Battery life makes these devices difficult for mobile personnel to use successfully, and the need for additional security systems only adds to that concern. For non-mobile users, battery life isn’t as much of an issue (as they’re going to be near a power outlet in many cases). Security, though, is still a huge concern. Unless they are on Windows Mobile devices exclusively (no iPhones, no Droids, etc), they’re going to need additional server solutions to be safe.

My prediction is that BES will stay in the Enterprise space for quite some time. We may see Windows Mobile, Android an WebOS take over more of the marketplace, but until these two issues are significantly improved, they will remain the minority for corporate mobile messaging.

Manage your migrations to minimize co-existence

2009-12-07T10:31:00.001-05:00

Exchange 2010 is beginning to get traction out in the real-world, which is by no means a bad thing. As folks begin to upgrade, though, there is a chance that you’ll end up with extended co-existence between different software versions and packages, and that can make life a living hell for technical staff. Multiple versions of multiple platforms can be difficult to manage at best, and if that management must continue for months (or longer) you could be setting yourself up to fail right from the start.

Co-existence of platforms is a necessary thing. Especially in larger organizations, the likelihood that you will be able to move all your users and systems from one software package to another in a weekend is slim at best. So, no matter if you are moving from a totally foreign system like Notes, or just upgrading between 2003 and 2010 on the Exchange platform, you will almost definitely need to have both systems running for a period of time as you move users and 3rd-Party tools. The key is to keep that time period as short as you can, and here’s why.

When multiple versions of a messaging platform (or multiple platforms) you must make sure you’re patching both independently, staying up to date on multiple security threats and dealing with end users who have to have changes made across both system sets. Since it is highly unlikely that you will have the benefit of extra staff during the migration, that means that the existing staff suddenly find themselves doing twice the work.

If the same number of people are forced to do twice the work, things fall through the cracks. Patches get applied incorrectly or not at all, threats are left unaddressed and shortcuts abound. It’s easier to open a hole in the firewall than try to deal with two sets of rules to manage connectivity. It’s easier to only focus on news and updates for the newer systems than to try to keep up with the influx of information for both platforms. The upshot of this is; that the longer you have both systems co-existing, the more opportunity you’ll find for something to break on one platform or the other. This endangers both systems, and possibly everything else in your environment.

So, when planning for your migrations, work as much as you can to ensure that you do not require extended periods of co-existence if they can be avoided. Sometimes you will need to have extended migration timelines – it’s unavoidable – but wherever you can do migrations quickly, you should.

Going cheap still has limits

2009-11-30T10:24:00.001-05:00

Over the Thanksgiving holiday here in the US, I finally got a chance to catch up on a lot of the information on Database Availability Groups (DAG) and other neat new features in Exchange 2010. I’ll get back to talking about earlier versions shortly, but one trend that got me thinking was that smaller organizations will be looking to use Ex2010 to get failover capability without clustering technologies and – therefore – at a lower cost. The problem is that while you can implement DAG much less expensively than a traditional or CCR cluster, there are some severe limits you need to be aware of.

Note: I will be attempting to keep everything very neutral in this article, but do keep in mind that I work for a High Availability/ Disaster Recovery solution provider (see notice below).

First, to spell out the Standard versus Enterprise versioning debate. Yes, you can get DAG capabilities in the Standard version of Exchange 2010. This means that you can create a DAG without the need for shelling out the extra cash for the Enterprise version of the Exchange Server software itself. However, since DAG requires some of the components from Microsoft Failover Clustering, if you want to use DAG you must be on Server 2008 RTM or R2 Enterprise Edition. So, in short, Exchange Standard is a yes, Windows Standard is a big no.

Also, keep in mind that each Exchange 2010 Server Standard may have no more than 5 databases on it. There seems to be a good deal of confusion around that, but as has been quoted in Jim McBee's blog and other places, that doesn’t mean each Standard server can host 5 live databases. It means that the total of both live and passive copies of databases housed on that server many not be more than 5. So, if you want 1 live database on each of 4 servers, you can get away with Exchange 2010 Standard. However, if you have 3 live databases on 2 servers, the Standard version is not enough to allow you to perform DAG on all databases, as that would make 3 live and 3 passive on each box, for a total of 6 per server.

One thing that is not limited is your ability to use any Client Access License (CAL) on any Exchange Server version you’d like. Enterprise CAL’s run just fine on Exchange Standard, and vice-versa. This means that end-users running on Standard can get nifty features without requiring you to upgrade to Exchange Enterprise.

So, smaller organizations may very well be able to use the Standard version of Exchange 2010 (but not Windows) in order to get DAG functionality for their databases and other higher-end feature sets. Just keep in mind that there are still limitations on the Standard version, and avoid hitting those limits if you’re staying on Standard.

Vacation this week!

2009-11-23T15:40:00.001-05:00

Hi folks, I’m not taking the entire week for Thanksgiving off (I only wish), but I am going to be swamped during the days I’m in the office. So, no new post this week, but I promise to be back next Monday with a great article for you all.

In the meantime, Jeff Guillet (@expta on Twitter) has finally got his Exchange 2010 Unleashed book released in Kindle form! It has been out of a few weeks in hardcopy, but I was waiting for the digital edition. You can grab a copy At Amazon.com via this link. Since Kindle now runs on PC’s and iPhones, you don’t need to buy a Kindle device anymore. Of course you could buy the dead-tree version, but it is a HUGE book (owing in no small part to Jeff’s knowledge).

See you next week, and to all my readers in the USA, happy Thanksgiving to one and all.

Look before you leap

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

There’s a great deal of talk these days about migrating directly to Exchange 2010 instead of jumping first to the 2007 version of the platform. The arguments for and against this got more complicated when Microsoft did a reversal for support and announced that 2007 would be able to run (at some future point) on Server 2008 R2. This effectively extended the support cycle of 2007, which means that a slightly older, and more thoroughly tested and widely installed, version is a legitimate option going forward. That being said, many clients are opting to just go to Exchange 2010 from whatever they’re on now, skipping 2007 if it isn’t already in place.

I’m going to avoid discussing the pros and cons of going to Exchange 2010 directly in this particular post (that’s fodder for quite a few additional posts though). Let’s just say that you’re jumping from an earlier version directly to 2010 and go on from there. While most of the process isn’t too bad overall, there are a couple of sticking points that you’ll need to have sorted out before you make the move. In smaller organizations, these are pretty easy issues to take care of, but on large-scale roll-outs, they can be a problem.

First, make sure your domains are at least at Server 2003 native functional domain levels. Most of you are already there, but just in case you had a few NT servers hanging around, be ready for this one. As long as all your servers are 2003 and up, making this change doesn’t have a lot of impact on your domain. You can find out about the impact of raising Domain Functional Levels in this TechNET article. So, what if you DO still have Exchange 2000/Windows 2000 servers in your environment? You need to upgrade to Exchange 2007 as an interim step to 2010. Since the Exchange 2000 life-cycle is definitely over (and has been for a while), Microsoft offers no method of co-existence between Exchange 2000 and Exchange 2010 – migration or otherwise.

Once your domain is prepped to 2003 or 2008 native mode, you then must plan to keep your old Exchange infrastructure long enough for the migration to occur. That’s because the Mailbox systems for one version of Exchange can’t talk to any other in most cases. So a 2003 Mailbox Server can’t talk directly to a 2010 Mailbox Server without some assistance.That assistance is in the form of Bridgehead servers (2003) or Hub/Transport and Client Access Servers (2007). You will need to have at least one of each for each Site you have set up in Exchange/AD. One note, this has nothing to do with the migration itself, this is all about the period of co-existence you’ll need to go through until everyone is on the 2010 architecture.

After you have upgraded your Domain Functional Level and set up your front-end server systems, you can begin the process of installing the first of your Exchange 2010 server systems. Start with the Hub/Transport and Client Access roles (unless you are installing them on the Mailbox Role server itself) to allow for message routing to get set up. This lets mail flow between the 2010 and legacy front-end servers, so when you start moving mailboxes, you don’t lose mail connectivity.

Finally, once you’re sure mail is flowing correctly and that no one is about to get lost in the shuffle, take one more backup of the legacy systems (just to be safe) and start your migration.

You can find a guide to preparing for and deploying Exchange 2010 at this TechNET site. Along with other blogs and Microsoft sites, this should be required reading before you even download the software and play with it in a lab. With a migration that includes a period of co-existence with earlier versions of Exchange; careful, proper planning is not a nice-to-have thing. It is a solid requirement that must not be overlooked or under-appreciated.

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