No posting this week, check out Double-Take Cloud instead =)

Hello loyal readers!

This week, I’m giving the news cycle to Double-Take Software, who both pay me and keep this site running.  They have just launched the Double-Take Cloud product, which allows for backup and recovery of your servers into the EC2 Cloud from Amazon.

Of course, I wouldn’t post it here unless it could also be used for Microsoft Exchange servers!

Go ahead and have a look: http://www.doubletake.com/cloud

See you next week.

Mike Talon

Don’t uninstall to fix Exchange!

Exchange Server does, occasionally, act oddly.  Alright, it can do that a lot, but hopefully you won’t run into the phenomenon.  If you should see strange behavior from your Exchange Server, the first thing to remember is that it is not a truly stand-alone application, and can’t be treated as such.  When problems happen with many software packages, the default fix-it is to uninstall the applications, reboot and reinstall.  While that may work with many apps on the Windows Server platform, doing that for Exchange Server will lead to rather disastrous results.

When Exchange Server installs, one of the first things it does is start building structures in Active Directory.  If you have no Exchange Servers at all, this includes extending the Schema and creating an Organization for Exchange and the related security constructs in both the Forest Root domain and the domain you’re installing into.  The thing many folks don’t realize until it is too late, is that much of this mucking about in Active Directory is undone when you uninstall an Exchange Server, which could be a problem if you plan on just fixing something and moving on.

When you uninstall Exchange Server, the uninstallation protocol will remove all objects in AD that were assigned to that server, which could lead to unexpected end results for users, Public Folders and other objects that don’t exist elsewhere in your organization.  This means that an attempt to uninstall to fix a somewhat minor issue could result in an absolute disaster for your Exchange environment overall that cannot be fixed by simply failing over.  The Organization and Forest Root updates will remain, but most of what you did in terms of configuration for the specific Exchange Server will be wiped out.

So, what to do in order to avoid this?  First, hit http://technet.microsoft.com and http://support.doubletake.com to see if there are articles on how to fix the problem you’re seeing.  These documents generally detail much easier fixes for common Exchange problems, and not-so-common ones as well.  Correcting the issues with Exchange still in place is the best route to take when it’s available.

If you do have to reinstall Exchange, your best bet is to shut down the malfunctioning server, build a new one with the same name, and use the disasterrecovery or recoverCMS switches with the Exchange Server installer tools.  This will transfer the settings over to the new machine, instead of removing everything permanently from AD.  Nearly all configuration for Exchange is stored in AD, so using these switches during the installation will allow you to get back up and running quickly, ready to restore the mailbox and folder data from an independent backup.  More information on these switches, the exact syntax for each version of Exchange Server and guidelines for use can be found in various places. http://support.microsoft.com, http://www.msexchange.org and http://technet.microsoft.com are three great resources.

As with most other topics, Exchange acts differently from most other applications when it comes to reinstallation. Always check the support sites before you take any drastic measures, and remember that Exchange is a totally AD-integrated application, so you’re never working on “just the Exchange Server itself.”

Fixing Blackberry Exchange Server Calendar Sync

I’m unashamedly a Blackberry addict. I think most folks who read this column know that, as I’m quite honest about my issues with the Windows Mobile platform, and quite looking forward to seeing if Windows Mobile 7 fixes them.  That being said, occasionally the Blackberry platform will have issues synchronizing non-email information from the Exchange Server through a Blackberry Enterprise Server.  Email and Contacts tend to sync correctly. If they don’t, the issue usually resides with the BES server itself. 

Calendar info, on the other hand, seems to stop syncing for some folks much more frequently. This can happen for many different reasons, and will usually happen if you do a device switch and something happens during the switch itself.  Luckily, if your calendar is not syncing correctly, there are a couple of things that will typically fix the problem for you.

1 – Try removing and replacing the CICAL record on the Blackberry device.  You do this by going to Options – Advanced Options – Service Book. Once there, look for a record for Desktop [CICAL] and highlight it.  Click the Menu Button and then Delete. 

*IMPORTANT* don’t close the Advanced Options panel yet.

Wait for about 10 seconds, then click the Menu Button again and choose Undelete.

If all went well, you should see a ton of send/receive activity going on, and your calendar will suddenly start syncing up again.

2 – If that method didn’t work, you can try to re-activate your Blackberry.  This will involve your BES system admin, so it’s not something you can do alone.  Have your admin get you a password for an Enterprise Activation.  They’ll supply you with that password, which will be valid for a limited amount of time (usually 12 hours), but more than enough time for this activity to happen.

On your device, go to Options – Advanced Options – Enterprise Activation.  The system will ask for your registered Exchange Email address and the password your admin created for you.  On some OS’s it may also ask for routing information to your BES server, which your admin can supply to you.

After entering this information, the device will begin an Enterprise Activation, which pulls down all of the settings and configuration from your corporate BES server and Exchange Server.  This could take up to an hour to complete, but you’ll see a new icon on your device for Enterprise Activation that will let you keep an eye on the progress of the process. If you have very large (1500+ entry) contact lists, you might see one or more databases failing to sync during Activation. This has happened to me often, and generally the issues are corrected via the normal contact list sync over the next couple of hours after Activation is complete.

Once you have re-activated the device, the calendar should be synching again.

As you would guess, re-activation is a process that will take much longer than the CICAL delete/undelete method, but sometimes it is the only way to get the Exchange Server sending you your calendar information again.

Note that on OS 4 and higher, most of your personal settings are stored via BES, so you won’t lose signatures or most personalization during the re-activation.

Hopefully, this will be helpful for those who have been having trouble with Exchange BES sync components. Calendars not syncing is an odd problem, as with all the Blackberry devices I’ve had since remote calendar sync started it has worked without a hitch in nearly every case.  But keeping this info handy could quickly correct for minor hiccups with Over The Air calendar syncing, I know it certainly saved my bacon more than once.

The Move is ON!

I’ve recently moved the digital location of this blog, but don’t update your bookmarks.  I intend to keep the BeingExchanged.com domain alive and well for quite a while, and the home page will always re-direct/link to the blog.  I just wanted to let everyone know that they were not hijacked, I have a re-direct system set up to get you here =)

For those wondering why the shake-up with the landing pages, Blogger (part of Google) recently announced that they would be ending FTP publishing for hosted blogs.  I use Blogger for my blog, and therefore had to stop using FTP publishing.  This isn’t a big deal, it just means I needed to re-direct to the BeingExchanged.blogspot.com URL in the background.

You can read about the FTP shut-down at the BlogSpot FTP Depreciation Site.

So, now we get to have the Great Bug-Hunt!  Check stuff out, try links, and let me know if anything looks weird.  You can find my contact information on the right-hand panel of this page.

Thanks, and looking forward to a full 2010 of Exchange-focused blogging for all of my readers!

- Mike Talon

Take Care With Exchange 2010 Throttling Policies

Many of my clients are currently evaluating Exchange 2010 for their production environments. While they probably won’t be implementing for a little time yet (average target dates are in Q4 for most clients I talk to), they are beginning to see different switches and settings that need to be tweaked from their defaults.  One of those settings is the native Throttling Policies that Exchange 2010 puts into effect to limit how much of various Exchange resources other applications are permitted to use.

Brian Desmond wrote a great article (you can read it here) that goes into detail about one potential problem that these limits impose.  Since the Throttling Policies are designed to stop individual client applications (among other things) from using up all the resources of an Exchange Server, they can impact 3rd-Party tools just as much as POP, IMAP and other mail client software.  In Brian’s article, he brings up the difficulties that Blackberry Enterprise Server (BES) runs into with the default policies, as they would normally hamstring BES’s ability to use a single account to ferry messages back and forth between Blackberry devices and the Exchange Server itself. 

In this case, what applies to the BES server can also impact other 3rd-Party applications that need to access an Exchange database via a client connection.  For example, archiving systems not using the new native tools may be working via a Journaling Mailbox or other single-account connection system. This means that the policies, as set up by default, would severely hamper the ability of the archiving system to get the data from the Exchange Server and into the archive solution.  Using the native archiving and compliance tools will help fix this, but many clients have invested a huge amount of time and money in setting up existing solutions. This means they face the choice between paying and implementing for an upgrade to the 3rd-Party system, versus completely re-engineering their archiving and compliance systems to switch to the native tools. 

Also, consider periodic mass-connectivity.  Anti-virus and other scanning tools may periodically connect to the exchange system using client connectivity, as would some 3-rd Party search and indexing systems.  Both of these will most likely not be hit by the policy limits, but could be if they do a mass-crawl. Careful evaluation of all systems that use client connections is necessary to eliminate any issues before they start generating client complaints.

Luckily, it is not difficult to change the Throttling Polices in Exchange 2010.  Brian’s article offers a great explanation of it, and of course Microsoft TechNET has a full set of details.  Once you determine which applications may need extended client access to the Exchange Server, you can set up custom policies for those applications and the accounts they use.