atom beingexchanged: July 2009

Monday, July 27, 2009

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!

Labels: , ,

Bookmark and Share
posted by Mike Talon at 0 Comments

Monday, July 20, 2009

Big Brother is Watc…[Recalled]

The big kerfuffle over Amazon’s Kindle Team removing several books without warning from users’ devices (story and link at the end of the blog) has lead me to think about the various time clients have used the Recall Message feature. Typically, they have found that it behaved just slightly better than opening their office door and screaming “NOBODY READ THAT!”

There are a lot of great reasons to use Recall Message in Outlook and Exchange.  Perhaps something was sent before it was finished, accidentally clicking Send without typing in that last bit of information.  Maybe you meant to add an attachment but did not – in which case may I suggest some of the great tools at Sperry Software.  You may also have accidentally hit Reply All instead of Reply, or added in a group email list via AutoComplete instead of the one person you wanted to send email to.  All of these are legitimate reasons to really want to get the email out of everyone’s Inbox.

Years ago, Microsoft attempted to build the functionality of yanking back an errant email on command.  It required (and still requires) that you be using Outlook in Exchange Mode, and a Microsoft Exchange Server as your email platform.  When first introduced, this worked great.  There was no such thing as a preview pane, you were always using an Exchange Server and MAPI for communication, and folks were probably online and connected since there was no Cached Mode.

The issues arise when you look at what is required for a Recall attempt to succeed:

  • The user must be online and connected to the Exchange Server
  • They must not be in Cached or Offline Modes
  • The message must be unread in the recipient’s Inbox (including unread by the Preview Pane)
  • The recipient cannot have moved the message to another folder (unread or otherwise)
  • They must be using MAPI. Even POP3 or IMAP on an Exchange Server won’t count.

So, as you can see, since the majority of email users these days do not meet one or many of these requirements, Recall Message will fail for the majority of your users.  What they will see is the original email (unchanged) and a notice saying you would like to recall the original email.  This can often be just as embarrassing as the original gaff, as it acts as a glaring exclamation point that someone made a goof.

One more note, Recall Message will not impact the copy of the information on a Blackberry or other 3rd-party Smartphones and mobile devices.  So even if the user’s desktop has all the requirements met, they’ll still have a copy of the message (and the recall request) sitting on their mobile device.

In the days of Exchange and Outlook with MAPI connections being the only conduit to email, Recall Message was a great way to manage errant information.  Today, with so many ways to connect to any mail system, including Exchange Server, this feature has lost its usefulness and created a false sense of security.  Remember, if there is a chance that someone’s using a non-Outlook client or not meeting all of the requirements above, you will not recall the mail.  An ounce of prevention is your only cure these days.

As for the Amazon gaff, for those who did not see the news:  Amazon recently pulled all the books by a major author and deleted them off all Kindle devices that held them.  This was due to someone posting the books on the Kindle store, without the publishing rights needed to earn money from them.  Once Amazon realized what was going on, they of course stopped selling all the books from that vendor.  Unfortunately they also removed all the digital copies that were stored on users’ Kindle devices without mentioning it to the Kindle owners.  They did refund everyone’s money, and they did send out an explanatory email, but not until several days later after the blogosphere detonated with Amazon hate postings.

Frankly, Amazon’s user agreement does say that they reserve the right to do exactly what they did.  I can’t fault them for heading off trouble (in the form of a copyright litigation) at the pass. However, it could have been handled a lot better, with more information supplied immediately to end users about what was going on and why.  Amazon has promised to make this process much more transparent so that next time there is no confusion.

The reason there was such an outcry about the process this time (as it has happened in the past, quietly and without fanfare or hate mail)?  The author in question was George Orwell, and the books were the likes of 1984 and Animal Farm.  Both of these books deal with subjects like retroactively removing information that didn’t meet the criteria of an overarching body of government or law.

From Dictionary.com:

Irony: an outcome of events contrary to what was, or might have been, expected.

Labels: , , , ,

Bookmark and Share
posted by Mike Talon at 0 Comments

Monday, July 13, 2009

Back to basics: Prepping a 2008 Server for Exchange 2007

Got a basic Exchange 2003 or 2007 topic you’d like covered in this series?  Email MikeTalonNYC@gmail.com and you might see your topic covered here!

A lot of my clients have been asking me to write about some more basic topics dealing with Exchange Server 2007 here on the blog, and so this week I’d like to talk about pre-requisites for installation of Exchange Server 2007 on Windows Server 2008.  These will change as Server 2008 R2 goes live later this year, so stay tuned for updates.

To start, run through the basic install of a Windows Server 2008 x64 box in either Standard or Enterprise Edition.  For a stand-alone Exchange server, you can use either version of Windows.  If, however, you need to cluster your Exchange 2007 systems with SCC or CCR clusters, then you must install Windows 2008 Server Enterprise Edition.  This article focuses on a stand-alone Exchange server, and therefore which version you install depends more on cost versus performance.  Check out this article for the details on how many processor cores, how much RAM and other factors that change based on versions of Windows Server 2008:

Windows Server 2008 Editions on Microsoft.com

Note: Since Exchange requires .NET, right now you cannot install Exchange to a Server Core installation.

This is a good time to install any tools your organization uses which are not Exchange-specific.  Monitoring tools, storage management, etc.

Once you have the basic Windows Server installed, make sure you run Windows Update to get the latest Service Pack and all the assorted hotfixes and patches.  Some of these are required for Exchange, so do not skip this step.  The most critical of these (beyond the Service Pack) is the .NET platform.  While you must have at least .NET 2 installed, the current version is 3.5.1, so you may wish to install that version as well.  No doubt future tools in Exchange 2007 will need some of those components.  Since most of the .NET platform shows up as Optional, you may need to manually check the boxes for these downloads before they will be installed by Windows Update.

Next up, install PowerShell to the machine if you haven’t already.  This shows up in the Server Manager Wizard as a Feature, and is a wizard-driven installation, so you do not need to download anything from Microsoft to do the install anymore.  The default parameters are fine unless you have a preferred setup for PowerShell.  (for those who will inevitably email me on this, according to MSFT, it is spelled “PowerShell,” not “Powershell.” Go yell at them if you don’t like odd capitalization.)

Exchange 2007 also requires that the IIS system be present on the server.  You can install this by bringing up the Server Manager and adding the Web Services (IIS) Role to the box. When you select this role, you will be asked if you wish to also add dependency features/roles.  Select Yes here to automatically add in quite a few feature sets that both IIS and Exchange need. 

A couple of notes: Two items that are not selected by default or by auto-selection are Dynamic Compression and the IIS 6 Admin Tools.  You should select both of those manually, as Exchange will need them.   Also, you have the option of selecting different authentication types for the Web Services in this wizard as well.  Be sure to select any and all that your organization will use.  As with most things, you can go back and add them later, but since you’re doing the install anyway, might as well get them on the box now.  Aside from these items, you can safely use the defaults for this wizard and allow it to perform the installation.

After you run through the IIS Role setup, you’ll need to install the remote AD configuration tool kit on the server.  The easiest way to perform this step is to open a command prompt and run the following command:

ServerManagerCmd -i RSAT-ADDS

When you run that command, the system will appear to be doing not much of anything for quite a few minutes.  If your experience is like mine, it will appear to be stuck at 10% for most of that time.  In my lab, with virtual machines that were resource starved, it took about 10 minutes.  Wait until you are returned to the command prompt (C:\>) before you move forward or the tools will not be installed and the Exchange validation tool will error out.

Next week, I’ll walk you through a basic installation of the Exchange 2007 server will the 3 main roles on one box.  Until then, have fun getting prepped.

Labels: , ,

Bookmark and Share
posted by Mike Talon at 0 Comments

Monday, July 6, 2009

OAB – Oh Boy! Yet another annoying error conquered

Exasperation no more!  OAB 0x80190194 error solved - finally

As many of you already know, I do a lot of Exchange configuration in my day to day job (see disclaimer below).  From time to time, I run into errors that seem to occur over and over, regardless of the environment, until someone can finally figure it out.  Outlook attempting to download the Offline Address Book (OAB) has usually been one of those odd errors, especially when a server is first created.

Starting in Exchange Server 2003, the OAB was only generated for the first time when the server entered the first maintenance window after installation.  So if you built a brand new Exchange environment, you would need to wait until somewhere between 1 and 3 AM before you had an OAB.  This meant that Outlook clients would exhibit a strange error about "File Not Found" during every synchronization.  Outlook went to look for an OAB to download, there was none there, and the sync would abnormally end.

This was easy to fix, however.  You simply located the OAB in the Exchange Management tools and forced a rebuild, which immediately cleared up the problem.  In rare circumstances you followed the TechNet articles and removed the OAB and created a new one, then forced a rebuild.  All in all, not a very difficult fix, but one that eludes many Exchange Engineers and Administrators for hours and hours until they either figure out the fix from reading about it on forums; or the give up in frustration and see the miracle of the error going away the next day (since the OAB auto-rebuilt during the night).

When Exchange Server 2007 came along, I had hoped that this would be a thing of the past.  After all, the least that Microsoft could do would be to put a message in the installer about having to rebuild the OAB. The best would be to have it auto-generate immediately on install.  Alas, as most of us in the Exchange world figured out, neither is the case.  On a new Exchange build, you still have to manually force an update of the Offline Address Book.

It is a lot easier now, though.  One Powershell command does it all:

Update-OfflineAddressBook -id "Default Offline Address Book"

Since the first OAB is always "Default Offline Address Book", the command is universal and can just be done immediately on finalizing your installation of the Exchange software.

All was well until I started getting a stream of calls from colleagues across the country about a new error cropping up in Exchange 2007 and Outlook 2007.  These folks had already regenerated the OAB manually or waited until after the first maintenance window, and now - unlike the File not Found errors before - they were getting a very odd error indeed:

Task 'Microsoft Exchange' reported error (0x80190194) : 'The operation failed.'

Google searches turned up suggestions for Microsoft Update, the Windows Update Site, and a few other red herrings.  Further investigation led only to the usual recommendations to regenerate the OAB.  This was driving many people, including me, nuts!  Remarkably, for several months none of us found an answer, but in all cases the problem went away on its own. Sometimes in a few days, sometimes in a few weeks, but always resolved itself in time. 

Now, my readers know me, that's not quite good enough for my palate.  So when time finally permitted I did some deeper investigation.  I found several things out that had nothing really to do with the error, but are fun:

- Avira Antivirus considers Experts-Exchange.com a phishing site.

- People tended to suggest everything short of lighting candles, standing on your head and typing mysterious incantations into Powershell (though frankly some of the stuff was pretty close)

- Many folks just let it go away on its own and never though about it again - until they had to build a new Exchange system.

Finally, I tripped over the MSServerAdmin site and to this article:

http://www.msserveradmin.com/how-to-overcome-the-exchange-2007-oab-issues/

Which got me to look at the Microsoft Exchange File Distribution service on my Client Access Role server (which in my case was on the same box as the Mailbox Role).  Once I stopped and started that service, Outlook immediately began to download the OAB and all was well once again.  That's really all there is to it.  This only seems to happen on Server 2008, which explains why I wasn't seeing it back when most folks were installing Exchange 2007 to Windows 2003.  I do not have an answer as to why this problem is so common with Server 2008, but if any of the Microsoft folks who read this can tell me, I'll happily post an update.

So, why did it go away mysteriously by itself over time?  That was a little more of a quandry, but I got that answer too.  These days, it's not usual to have to reboot an Exchange 2007 server after installation is finalized.  So folks were not restarting services regularly by rebooting the boxes regularly.  However, eventually, Windows Update Services would download a critical OS patch, and - left to its own defaults - automatically reboot the box.  This might happen the next day, or might be several weeks away, but eventually we'd reach Patch Tuesday and the boxes would reboot - restarting the service and clearing the problem.

Good things come to those who wait - this time.  Hopefully the answer will always be as simple as "Just wait and it'll fix itself," but until then I shall keep searching for answers and reporting them here.

Labels: , ,

Bookmark and Share
posted by Mike Talon at 2 Comments