Friday Poll: Public Folder support

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?

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

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

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.

Why use AD DNS?

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

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