What’s a Rollup?

Since the news a few days ago that Microsoft has released the Exchange 2010 Update Rollup 4 for download, I figured a couple of lines on what Rollups are would be a good thing. Many are confused as to why these Rollups exist, and when to use them.

An Update Rollup (UR) is a single-installer for many different hotfixes and patches to a single product that Microsoft produces. There have been such UR’s for everything from Windows to Office over the years, and they can make life easier if used correctly. For the most part, you don’t need them for day-to-day operations anymore, but you may use them when building up new systems.

For currently-installed Exchange 2007 and up servers, running Windows Update on a regular basis will get you the critical patches, fixes and updates you need. Just make sure you’ve authorized Windows Update to download software for other software running on Windows (it’s one of your settings in Windows Update) and you’ll find yourself downloading Exchange components as well. You still need to install Service Packs as they’re available, but the individual patches can be updated when you do your regular Windows Updates. There are a couple of cases, however, where this updating process doesn’t meet your needs.

If you’re building a new Exchange 2007 or 2010 system, for example. After installation and (where applicable) Service Pack updating, there may be a large number of individual fixes and patches to be applied. As these will be installed sequentially, and will require service or server restarts in many cases, the process can be time and labor consuming. The UR can apply all patches and fixes up to the date of UR release in one shot, making things faster, easier, and with fewer opportunities for errors.

Many companies prohibit auto-updates, and you may find yourself manually applying fixes and patches for Exchange. If you keep up with this process, then you have no problems, but if you do not; you can quickly find yourself knee-deep in required updates. The UR will make life easier by bringing you up to date quickly, so you can get back to regular patching.

Note that you should still check for updates *after* you go through the UR process. This is because there may be newer patches and fixes released after the UR is built, so while it is cumulative up to the release date, it is not current to today’s date.

Keeping up to date is the best way to avoid security pitfalls and software bugs.  When you’re starting from scratch or trying to catch up, Update Rollups can provide a way to quickly get close to “up-to-date” and help you do so without as many reboots, restarts and errors.

Why would you bring up an Exchange Server offline?

The Exchange Team Blog recently posted an article on how to help speed up the time certain Exchange Server services take to start when the server isn’t connected to the Internet.  You can read the article via this link. The question I’ve been hearing after this article showed up was “Why would I bring up an Exchange Server that isn’t net connected?  Isn’t the point of Exchange to send/receive mail?”  Valid question, but I can think of a few instances where this article can really help folks.

1 – You aren’t sure what’s broken

This is a pretty common one, believe it or not.  When troubleshooting Exchange, sometimes servers can appear to be connected to the Internet, but are not.  They may also require several reboots to properly correct whatever went wrong with the network connection once you figure out what broke.  In both cases, having a way to speed up the Exchange service startup can make troubleshooting faster and more efficient.

2 – You’re testing something out

Many times, administrators will want to see how certain changes impact Exchange Servers without allowing them to receive new mail (just in case they have to revert to a previous version of the database).  This is typically done by disconnecting the server from the network, as that will ensure no mail is transferred in any direction.  If a reboot is required for the testing, shortening service start times makes life easier.

3 – Secured environments

The article specifically mentions this one.  If Exchange Server is used for internal mail routing ONLY, and never expected to send/receive anything on the public Internet, then it may not be connected to the public Internet at all.  Under these specific circumstances, there’s no reason for things like public certificate updates to happen, since the Exchange Server will never use them.  Be very careful with this one, though. You’d be amazed how many times I have found so-called “isolated” Exchange Servers that are chattering away with the outside world.

As you can see, there are reasons why you would bring an Exchange Server up without a connection to the Internet.  In those circumstances, the guidance in the article can help speed up the process of getting your Exchange services started.  Just be careful to follow all the warnings in the articles, as a wrong move could either break Exchange or create a whopping security hole in your email architecture.

Exchange Server Deployment Assistant is a great tool!

Just a quick post today, as I’ve missed most of this week and didn’t want you readers to go into withdrawal =)

Microsoft apparently agrees with me that trying to figure out what steps to take in installation of Exchange 2010 can drive you batty.  In response, they’ve created the Exchange Server Deployment Assistant (ESDA) to help you know what to do when.

The tool is web based, and simple to use.  You tell the tool if you’re planning on upgrading from a previous version of Exchange or a net-new install of 2010.  You also tell it what components of the Exchange Server 2010 system you’ll be using – Disjointed namespaces, POP/IMAP, Unified Messaging, etc.

Once you give it this info, it walks you through all the steps required to properly install and configure the services you chose.  This includes pre-requisites for the OS and Features and Roles, and the installation and basic configuration of the Exchange software itself.  A great tool for those who want an idea of what needs to be done, start to finish.

You can find the ESDA tool here. Note, you’ll need Silverlight to use the tool, which is freely available from this link.

See you next week!

“I need an Exchange Server,” - it’s not quite that simple.

A partner called me today, distraught that he couldn’t get a simple answer to his client’s question.  What was the question?  “What do I have to buy to build an Exchange system for 200 users.” The frustration stemmed from the conversations that my vendor friend that had with the client about things like server class, storage, and about a dozen other criteria he wanted to be sure of before quoting out the hardware and software necessary to get the job done.  From the research the client had done on their own, they believed it should be as simple as buying “a server” and “some disk” and doing the Exchange install.

This particular vendor knows I work for Double-Take Software, and that I am one of their Exchange SME’s, and so reached out to me to see if I could come up with an answer on the failover/availability portion of the question, since that was also going to be a requirement for this environment.  He was less than thrilled with my answer, which fell somewhere between “are you insane,’ and, “I’m not touching this with a 40 foot pole.”

Eventually I settled down, and started walking through all the things that were wrong here, and trying to find some way to get the questions simplified enough so that the client didn’t feel like they were being asked to… well… architect a complete Exchange solution for their environment. It was quite the process, let me tell you.

In order to help those who have never worked with Exchange Server before, let me spell out a few of the things you will need to know before you move forward.  For those who work with it every day, I hope you can use this as a plain English explanation of what’s involved so that you can explain it to those who may need to sign the checks, but don’t know the tech – should you ever run into that problem.

First things first. “Exchange Server” isn’t a server.  It’s a platform of software tools that all work together to provide email, collaboration services and shared data services to end users.  That means that you can’t just buy “an Exchange Server,” and in most cases it’s not one server at all, but two or more acting in concert.  To say “I need an Exchange Server for 200 people” is like asking a car dealer for “a car that can go 10 miles each day.”  Do you want a car that can hold 2 people, or 4?  Are you planning on only moving people or do you have pets?  How about cargo space, are you planning on carrying groceries for those 10 miles, or hauling bricks?  Oh, and do you want a car that can go 5 days between trips to the gas station, or do you want an SUV that’s going to suck up the whole tank during each 10 mile trip?

To beat that analogy up even further, Exchange is only the engine, not the car.  Much like other types of engines, it works better in some car chassis than others.

So, what do you plan to do for your 200 users?  Do they use a lot of email all day long, or is it just light email a few times a week?  What do they email, just regular text emails, or are they shipping multimedia presentations back and forth to each other and outside the firm? Are they all in one office, or spread out across multiple offices all over the place?  If they are spread out (or if they access mail from home, etc.) what level of security do you need to provide?  Are they doctors (HIPPA) or officers of a public company (SOX)?

Now let’s talk about some other things that may go on in your environment.  Do you need to be able to schedule conference rooms, company vehicles or other shared resources?  How about generic email boxes, like for users to request information, open support tickets or contact a salesperson or media contact?  In other words, is it 200 users that need 300 mailboxes all told, or is it 200 mailboxes?

How big were you planning on letting these mailboxes get?  Left to their own devices, users can accumulate gigabyte after gigabyte of data.  I know some sales folks who routinely have about 6-8GB of data in their email boxes.  And speaking of all that email, how long do you plan on keeping it?  Do you need to archive older mail (which you should do) or do you need to permanently delete things over a certain again (which you may need to do)?

As you can see, things are quite a lot more complicated than “get me an Exchange Server for 200 people,” and we’re not done yet.

Let’s talk Exchange Ecosystems.  That’s Microsoft’s term for all the servers and services that surround the Exchange Server in most environments.  Don’t think you need that?  You may want to think again.

Anti-Spam, Anti-Virus and other message hygiene tasks could be done on the Exchange Mailbox server, but typically for systems over about 100 users, they’re done by independent servers well before the email reaches the mailbox.  That means either creating servers dedicated to those jobs, or – more likely at this size – leasing services from a 3rd-Party provider of message hygiene solutions.  If so, do you want to host an appliance at your site, or outsource everything?

Speaking of outsourcing, 200 users is still well within the range of Exchange Hosted Services or other forms of Exchange Server Hosting.  Then you can just outsource everything and tell the vendor what features you want.  Can you do that in your industry and with the regulations/company policies you’ve got in place?

People rarely stand still for long.  I’m writing this blog posting on a train heading to Boston, but I have full access to my entire Exchange mailbox and other corporate resources through Outlook Web Access, Outlook Anywhere via my air card, and of course my Blackberry device.  Do your 200 users all need to be able to have that kind of access? If not, how many do and how many do not?  Do you need to configure Outlook Anywhere (the components of Exchange that enable many mobile devices like Windows Mobile and iPhones)?  Do your mobile folks like Blackberries instead?  If so, do you want to host your own Blackberry Enterprise Server, or outsource that too?

While we’re on the subject of people talking to each other, do your users need to share more than email?  Do they routinely cooperate on documents, lists, wikis and other things too?

At this point, you may be ready to throw your hands up, throw the idea of creating an Exchange Server out the window, and go home.  Don’t give up yet, because here’s where we tie it all together:

Exchange Server 2010 is the currently shipping version of the Exchange Server Messaging and Communications Platform.  It contains the ability to set up mailboxes, message hygiene and routing for email, communication with mobile devices and connections to other tools.  It’s available in two “flavors” – Standard and Enterprise.  With 200 users, you’re almost definitely looking at the Enterprise version, which is good, because it can help a lot with the high availability questions.  Most clients will also need additional availability solutions (see disclaimer below, I’m biased) and backup solutions as well.

Also, you’ll need Client Access Licenses for each user/mailbox.  There are two types, Standard and Enterprise.  Enterprise CAL’s allow you to do things like grant mobile access and get archiving and cross-mailbox search, so you will most likely need those for at least some of your users.

Next, what kind of hardware will you be needed?  Well, if the 200 users don’t do a lot of email work, you can get away with a lower-class machine than most.  You may even be able to squeeze everything on to one server, though putting the front-end systems (called Hub/Transport and Client Access Services) on their own server isn’t a bad idea.  You’re right on the edge of needing to split everything out anyway, and if you’re planning on growing (which hopefully you will) then you’re going to need to do it sooner rather than later.

As for what those servers will look like, there’s a lot of debate on that topic, so for this article I’ll use the official specs from Microsoft.  You can find them (and a lot more info) on the Microsoft TechNet site on Exchange Performance and Sizing.

Your front-end server should have between 4 and 12 cores, which you can get by using 1 to 3 quad-core processors, which are the standard these days.  The Mailbox server needs more horsepower, so you’re looking for from 4 to 24 cores there.  RAM-wise, front-end servers should be getting about 4GB-8GB each.  At this level you’ll probably only have one front-end server though.  Mailbox servers need 4GB to start, and then need 3MB/mailbox if your users are light email users.  If most of your users are heave emailers, with lots of attachments, huge contact lists and tons of calendar appointments, you should be looking more toward 30MB per user mailbox.

Disk space is another concern.  Microsoft has made Exchange 2010 much more efficient with disk than its predecessors, and so you can use a lot of different types of disk options.  You will need to be able to hold all the information not being archived or deleted, so think in terms of 200% of what you’re allowing your users.  So if each user can store up to 3GB of data in their mailbox, you should be allocating 1.2TB (3GB x 200 users x2) of storage space for them.  This will allow you to allocate space for Exchange’s transaction logs (internal log files used to track what Exchange is writing to the databases), the databases themselves, and the necessary queuing systems that shuttle mail back and forth, with a little room to grow.  These days you can get that with just internal disk, but many clients choose to go with external arrays so they can scale over time.  Definitely check the TechNet website for recommendations on what RAID to use and other disk settings; as this is just how much disk you need, not how you should create or allocate it.

Exchange 2010 also comes with native archiving and compliance search features built in.  This will, of course, require more hardware, so have a look at the overview of these tools on the TechNet site and plan accordingly.  Keep in mind that if you use native or 3rd-Party backup/availability tools, you’ll also need another server and appropriate disk space to hold the backup copies of the data.

External to the Exchange Server itself, but just as important, are the Ecosystem servers.  SharePoint Server allows your teams to share documents, calendars and projects easier than the native tools in Exchange Server could alone.  SharePoint is a whole other server platform, but one that you should look into if your users tend to share stuff on a daily basis.

Blackberry and Good Technologies are two common tools that work side-by-side with the native Outlook Anywhere (formerly known as ActiveSync) systems in Exchange.  If you have Enterprise CAL’s, your users can access email via Outlook, Outlook Web Access, or a host of mobile devices like iPhones just by using Exchange Server.  If you want to add extra security and sync features, then you use Good.  If you want your users to have access to the popular Blackberry mobile devices – and centrally control and manage them, then you’ll need Blackberry Enterprise Server (BES).  Good can often by installed to the Exchange Mailbox Server, but it’s a better idea to give it its own server so it doesn’t bog down the mailboxes.  BES can either be provisioned on its own server at your site, or you can lease space on a hosted BES service provider’s server.  If you host your own, then of course you will need a server to put it on.

Summing up, we’ve gone from “I need an Exchange Server for 200 people,” to, “I need several servers of different sizes to host all the components of Exchange Server for my organization.”  If you have never touched Exchange Server before, this can be bewildering, frustrating and expensive – especailly seeing as you’ll probably goof up at least once (we all do).  The good news is that there are two options if you just can’t wrap your brain around all of this.

One is to get help.  There are a huge number of service providers who can assist you in planning, procuring and implementing all these moving parts.  Many can also train your team to maintain what they built, and to build out new stuff when needed.  If you plan on hosting everything yourself, this is the much better course of action to take, as going it alone quickly gets more expensive as you fix mix-ups than the consulting costs would have been.

Alternately, you can talk to Microsoft and their partners about having someone else host and administer your Exchange solution.  Hosted Exchange Services is the product offered directly by Microsoft, and many partners also host Exchange services on their own.  Take a look an article or two before this one in this blog for some details on that.  Up to 500 users/mailboxes, it is quite suitable to go the hosting route, and even up to 1000 users it can make a lot of sense.  It’s still Exchange Server, you still get Outlook, Outlook Web Access and Outlook Anywhere – and you may be able to get Good and BES too.  You’re trading management and hardware costs for a monthly cost per user and/or per amount of storage space they use.

So, what does it boil down to?  The short answer is that there is no valid short answer here.  You need to take a look at your users and your datacenter facility.  You need to know what they want to do with their messaging systems before you can even begin to install Exchange Server components.  Exchange Server is no longer something you can just buy “off the rack” and toss into your environment.  Plan, implement and manage it correctly, or it will be nothing but a nightmare until you eventually do the planning and rebuild it right – which always costs a lot more.

Offline Address Book Generation/Update

The OAB is used for Cached/Offline mode clients to perform lookups of contacts and other information. It is periodically updated from the Exchange Server to Outlook clients. A complete overview of how the OAB works in various versions of Exchange can be found on Microsoft TechNet by searching the sections for your specific version of Exchange.

In earlier versions of Exchange Server, a Public Folder was used to house the OAB data and distribute it. In 2007 and 2010, a web-based distribution system was put in place, with the ability to also maintain a Public Folder version in the event you have legacy Outlook (2003 SP1 or earlier) clients. While distribution of the OAB to any Outlook client is fairly automatic, the generation of the OAB for the first time may not fit into your time tables.

Usually, the OAB will update as part of the Online Maintenance Routines that occur by default every day from 1am to 3am server local time. This means that the OAB will not be generated at all until that first maintenance window, and will not be updated with new users until the first maintenance window after they are added to AD. There are several reasons why this may not work for you, but some common ones are:

- You’ve added a VIP to the AD system and management doesn’t want to wait 24 hours for the OAB to update.

- You have created a test system, and either don’t want to leave the system running overnight, or need to perform testing within the first 24 hours of the build.

- You add a large number of users to AD, and want to propagate the information to Outlook clients as quickly as possible.

In these, and other cases, you could force the Online Maintenance to occur, but that would take a significant amount of time, especially if all you want to do is update the OAB. In a production environment, performing maintenance routines during peak hours of operations can also have an impact on user experience, and so should be avoided.

To perform an immediate update of the just the OAB in Exchange Server 2007 or 2010, you can open a PowerShell command window and execute the following:

Update-OfflineAddressBook –id “Name of OAB” –verbose

Where “Name of OAB” is the name of the Offline Address Book you wish to update. Be sure to enclose it in quotes, especially if the name contains spaces. The default OAB for a new installation of Exchange is – oddly enough – “Default Offline Address Book” and you can use that name to perform the initial update on a brand new server.

If you maintain more than one OAB, or if you changed the default name, you must run the command for each OAB in your organization, replacing the name with the appropriate string each time.

The next time Outlook clients look for OAB information, they will see that the OAB has been updated, and download the appropriate changes to their local OAB copy.

Got an Exchange-related question that Mike can try to get you an answer for? Follow Mike Talon on Twitter (@TalonNYC) and send an @ mention with your question.

What the {Censored} Do I Install for Exchange 2010??!!

This is a complaint I have heard over and over again from clients going to install Exchange 2010l and even earlier versions.  The level of profanity depends a lot on the individual, but I have heard some rather prim and proper folks resort to very short words when it comes to Exchange pre-requisites. Come to think of it, they've resorted to some long words as well, but none fit for publication in family-friendly venues.

Exchange prerequisites have typically been confusing and difficult to master.  Starting with Exchange 2000 and 2003, the pre-flight checks built into the setup protocols became intelligent enough to figure out what was missing for the most part.  However, the installer didn’t tell you what those things were unless you started playing with the install options and suddenly got a popup which detailed what wasn’t there.  Exchange 2007 and now 2010 both have extensive pre-flight checks that occur before you do any form of installation, just after you tell the installer which components you’d like to put on the box.  They check for everything from your .NET versioning to Active Directory connectivity, but once they tell you all the different things that are not present, how do you figure out what to install in order to make those things present?

Thankfully, Microsoft has had TechNet pages that detail prerequisites for Exchange installations, starting back in Exchange 2000.  Up until 2007, it was up to you to install each of the components listed, but with the advent of newer server management tools in Server 2008, the process can be automated.

For example, to pre-stage Server 2008 R2 for Exchange 2010, you can invoke a series of PowerShell commands to set up nearly all the prerequisites in one shot.  First run:

Import-Module ServerManager

inside a PowerShell window in order to load the correct command modules into the session.  Then, use the correct sequence of commands in the same PowerShell window to load the prerequisites for the roles you need to run on this particular server.  For example, if you wanted to run Hub/Transport, Client Access Services and Mailbox Services; you would execute the following block of commands:

Add-WindowsFeature NET-Framework,RSAT-ADDS,Web-Server,Web-Basic-Auth,Web-Windows-Auth,Web-Metabase,Web-Net-Ext,Web-Lgcy-Mgmt-Console,WAS-Process-Model,RSAT-Web-Server,Web-ISAPI-Ext,Web-Digest-Auth,Web-Dyn-Compression,NET-HTTP-Activation,RPC-Over-HTTP-Proxy –Restart

The specific commands (and the tool to call them) will change based on three things:

1. The version of Exchange (2007, 2010, etc)
2. The version of Windows (2003, 2008, 2008 R2)
3. The Roles you intend to install (Hub/Transport, Client Access, Mailbox, Unified Messaging, etc.)

Some things, like installing the 2007 Office System Converter Filter Pack; still have to be done manually, but most of the basic pre-installations can easily be automated using these combinations of command window and PowerShell scripts.

Microsoft has put up all the commands and processes for all the Server OS’s that Exchange 2010 can run on in this TechNet article.  Similar articles exist for previous versions of Exchange too, so you can get your prerequisites onto the server before you even start the Exchange 2010 installation executable.

Outlook Mail stuck? It may not be your profile.

During a recent Exchange 2010 training, our instructor went through a couple of things that could be causing mail to not leave an Outlook or OWA client during normal operations.  When I did a few searches on this topic, I was alarmed to see that many people suggest that the problem is the Outlook offline storage file or PST.  While that does sometimes cause these issues (especially if you’re on Exchange 2003 or earlier), there are a couple of quick checks you should make against the server first.

On Exchange 2007 and 2010, if mail is getting stuck in users’ Outboxes on various clients, check two things:

1 – Is there less than 4GB of disk space available on any volume on the servers that contains Exchange data and/or queues? If there is less than 4GB, Backpressure protocols kick in, and Transport Services won’t move mail anywhere, leaving new messages stuck in users’ Outboxes. This is fixed by freeing up drive space or moving the database and/or queues to another volume with more room.

2 – If the disk space is ok, check to see if the Transport Services (which vary depending on your Exchange version) are running.  Any service that isn’t started can cause mail routing to fail, and messages to stay on the client software.  Obviously, to fix this you either need to get the services up or bring another Hub/Transport system online to handle mail flow.

Additionally, if you are using Exchange 2010, mail may get stuck in the Drafts folder.  That is to say, it leaves the Outbox and immediately appears in the Drafts folder in Outlook.  If you see this behavior, check to ensure that the Mail Submission service is running on your CAS server.  If it isn’t, mail can’t be properly picked up from the Outlook client, and the resulting error shoves the email into the Drafts folder.

Granted, if these issues are not the cause of your issue, or if it only seems to be happening to one user, then rebuilding the OST or PST might be in order.  However before you disrupt clients day-to-day activities, a quick check of the server might uncover a correctable error that can be quickly contained.  In the case of lack of disk space, it can even expose a growing problem that must be dealt with in the near future to avoid much more wide-spread downtime.

Two for tea, and tea for 2007?

Those following my twitter feed (http://www.twitter.com/talonnyc) already know I’m in an Exchange 2010 training this week at New Horizons here in NYC.  During the class, someone had asked if you could run both the Exchange 2007 and 2010 admin tools on the same system, and our trainer (though extremely well versed on just about any other topic we threw at him) wasn’t sure on that one.  Luckily, the twitterverse came to the rescue and Henrik Walther the Editor of MSExchange.org sent over an article that went through the details on this, and many other topics on Exchange 2010 management.  The article found here is definitely worth the read, but since it covers several other topics, here’s the skinny on multiple client tools installs:

2003 Tools: Cannot be installed on the same system as 2007 or 2010.

2007: x86 tools can’t be installed with the 2010 tools, but the 64-bit versions can co-exist

2010: Only available in 64-bit versions, and can co-exist with the x64 versions of the 2007 tools

To use both the 2007 and 2010 tools, install all pre-requisites for the 2010 versions.  This includes PowerShell 2 and the .NET 3.5 (go with 3.5.1) Framework package, along with others.  Consult the install guides at MSExchange.org for more in-depth details on what you need to have on your workstation ahead of time.  The Exchange 2007 tools are compatible with these upgraded pre-requisites, and so can either be left in place (if already installed) or installed first.  Then install your Exchange 2010 tools and you are on your way.

Always remember to use the Exchange 2010 tools whenever possible.  Certain configuration specific to Exchange 2010 (Like Moderation rules) will be ignored by the earlier tool kit, even though it will let you do many operations with either version.  This could lead to you accidentally ignoring a vital configuration or management step along the way.

Thanks to Mr.. Walther for the excellent information!

Public Folders continue to be whittled away

With each new release of Exchange Server, Microsoft de-emphasizes available Public Folder functionality and restricts Public Folders from participating in the newer technologies of the current release. Of course, they also announce that they make no promises as to Public Folders even being included in the next release down the line.  Exchange Server 2010 is no exception to these rules, and while Public Folder technologies are still in the release, they are restricted and downplayed overall.

With the RTM version of Exchange 2007, you needed to use Outlook or other tools to manage folders, but the backlash from end-users was so fierce that Microsoft put the tools back into Exchange with the SP1 release. Still stinging from that set of events, the Exchange Team seems to have built at least basic Public Folder functions into the shipping release of 2010, but with some limits.  A few of these were limited in 2007, some are new.

As with 2007, Outlook and Outlook Web Access are about the only remaining methods to connect to Public Folder trees.  Gone are the days of NNTP and IMAP access to folders, and apparently gone to stay.  Since most users who need Public Folder access use Outlook anyway, this wasn’t a huge issue, but it did hamper 3rd-Party Public Folder integration unless the vendor was - or is - using MAPI connectivity.

The new clustering solution set that was introduced in Exchange 2010 (Database Availability Groups, or DAG) doesn’t support Public Folder databases either.  You can, however, host Public Folder databases on MBX servers that are using DAG for their Mailbox Stores.  You simply have to use some other replication system to protect the data (either Public Folder Replication or a 3rd-Party system – see disclaimer at the end of this blog).  More info on this can be found on TechNet.

So, while Public Folders are still not dead yet, they are systematically becoming a very difficult feature-set to continue using.  Microsoft has been actively encouraging Exchange users to leverage the functionality of a SharePoint Server to replace what was once stored in Public Folders, and for the most part you can do much more with SharePoint overall.  There are several 3rd-Party tools available to move your Public Folders to SharePoint, and once there you have a great deal more control over content, accessibility and general functionality.

If your organization uses a great deal of Public Folders, and you intend to move to Exchange 2010, consider migration of the folder information and functions to SharePoint.  Doing so as part of an overall migration strategy is a lot better than trying to rush the job after you find out that Public Folder functions in Exchange 2010 may no longer do what you need.

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

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.

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

What is a PTR record and why should I care?

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.

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

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.

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

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)

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.

Exchange 2003 only wins with WINS.

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.

Exchange 2007 Installation – continued (finally)

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!