Exchange Queue & ASetup, Message Journaling, Storage Options, and More

KC Lemson and Nino Bilic

Q I'm running Exchange Server 2007 setup and I need to know if I can bypass the prerequisite check. I don't want to fix all the issues that prerequisite check told me to; I just want to run setup and be done with it!

A The short answer is no, you cannot. You really must fix any issues that the prerequisite check flags if these issues block setup from continuing, or your long-term Exchange experience will suffer.

Some admins have tried to edit the ExBPA.PreReqs.xml file (which is the file that contains the list of Exchange 2007 setup prerequisites) and remove the checks that are causing the setup block. This does not work, however, as the XML file is digitally signed, and any modification of its contents will make the signature invalid.

This is all to prevent you from creating an installation that will not work properly. We have tested Exchange 2007 in different environments and learned that some configurations and settings work better than others, and some can present real problems. Prerequisites are there to make sure that your setup has the best possible chance of succeeding, based on our experiences and testing.

If you find a genuine problem with Exchange 2007 prerequisite check, and it is blocking setup in your environment, you should open a case with Exchange support.

Q Where do I find the setup log? I can't find it in the root of the C: drive.

A All setup logs are now stored in the %SYSTEMDRIVE%\ExchangeSetupLogs directory, which in most installations means c:\ExchangeSetupLogs. You'll find multiple files in there, two of which are of primary interest:

ExchangeSetup.log This is the log that contains information about tasks and parameters that were used when setup was run. When server roles are being configured, the information about tasks that were run to configure the server is also recorded into this log. This is also the place where you will want to check for the majority of information pertaining to your server setup. Service pack setup will also append to the same file.

ExchangeSetup.msilog This file contains information about the unpacking phase of setup. When the Microsoft® Installer is copying files to their destinations from a temporary location, it logs into this file. So, if you have an issue that could be related to the ability to copy files or to accessing files during setup, this is the log that might be helpful.

Q I know that the prerequisite check is powered by the Exchange Server Best Practices Analyzer (BPA), so where can I find the report for the prerequisites?

A If you want to find a report that BPA created during the prerequisite check, look at the following folder:

%SYSTEMDRIVE%\Exchangesetuplogs\PreReqs

The file names have a standard format:

ExBPA.<dateandtime>.data.xml

If you are trying to figure out what a specific prerequisite check was looking for, find the XML file that contains the error message you saw and, just above the message, you will see the rule definition that was being tested.

Q How do I read setup logs? What options do I have?

A There are generally two ways to go about reading setup logs. You can run Get-SetupLog from the Exchange Management Shell, or you can just open the setup log file in Notepad or your favorite text editor.

If you use Get-SetupLog, here is an example of how you would pull up any warnings or errors:

Get-SetupLog c:\exchangesetuplogs\exchangesetup.log –error

If you want to make it pretty, you should get the Out-HTML.ps1 and Out-IE.ps1 scripts, which are available in the Exchange 2007 PowerShell Scriptacular demo pack. (Read more on our blog at msexchangeteam.com/archive/2006/12/27/431998.aspx.)

Once you get those scripts, place them into the Exchange scripts folder (by default c:\program files\microsoft\exchange server\scripts) and then run the following:

Get-SetupLog –tree:$false –error:$false | Where { $_.status –eq "Error" } | select datetime, depth, description, status | Out-HTML | Out-IE

This will open an easy-to-navigate browser window with an HTML view of errors that might have happened during setup (see Figure 1).

Figure 1** Out-HTML and Out-IE make the view of your setup logs easier to read **(Click the image for a larger view)

If, on the other hand, you opt to view the exchangesetup.log using Notepad, here are a few tips:

• To find a start of the setup run, search for: [0] Starting Microsoft Exchange 2007 Setup.
• To find an end of a setup run, search for: [0] End of Setup.
• Major setup tasks are separated by: [0] **************.
• To look for an account that ran setup, search for: [0] Logged on user.
• If you want to see which domain controller was used during setup, search for: [0] Setup will use the domain controller.

Generally speaking, when reviewing setup logs using Notepad, you should start at the end of the file and go back in time to see what the problem was. Errors are usually some of the very last pieces of information that are logged into the setup log.

Q Can I use Exchange 2007 Unified Messaging with my PBX?

A You probably can. Check out microsoft.com/technet/prodtechnol/exchange/telephony-advisor.mspx for a list of the supported VoIP gateways and PBXes. Any changes to the list of supported products will be added to this page.

Q I have a client running Small Business Server 2003 with Exchange, and the company policy requires that all mail be monitored. To perform the monitoring, I want to send a copy of all incoming and outgoing mail to the administrator's account. How can I make this happen?

A What you need is message journaling, which allows you to keep a copy of all messages sent to or from a specific mailbox database in a separate journaling mailbox. There are a variety of options that let you configure how detailed the journaled copies should be (for example, do you want to capture BCC recipients?), and an additional tool you can download to get some advanced features, at go.microsoft.com/fwlink/?LinkId=93725. Journaling in Exchange 2003 is enabled on a per- database level, so every user in that database gets journaled. After you create the mailbox to hold the journaled messages, go to the properties of the mailbox store in Exchange System Manager and check the box to archive messages sent to or received by mailboxes on that store. Depending on your business policies, you may also want to enable the mailbox manager to automatically clean out old journal copies from the journal mailbox.

Exchange 2003 has another feature similar to journaling, called the archive sink. Unlike journaling, which saves copies of the messages to another mailbox in Exchange, the archive saves messages into a specified folder on the server hard drive. Why choose one method over the other? Journaling is generally intended for regulatory compliance scenarios, but the archive sink can be useful if you want to capture all messages coming in from or going out to the Internet, for example.

Exchange 2007 simplifies these scenarios significantly, and you can easily journal on a per-user or per-distribution-list (DL) basis. If you don't want users to know that their mail is being journaled, you can hide that DL from the Global Address List (note that this is not the same as hidden membership of a DL) or set up a custom attribute on the users and then create a Query-Based Distribution Group (also called Dynamic Distribution Lists or DDLs around here) to key off all users with that custom attribute. If you want to journal all mail in the entire organization to the same location, leave the recipient field blank when creating the journaling rule. Also note that if you want to use any journaling other than per- database in Exchange 2007, you'll need the Enterprise Client Access License (CAL) for those users. You'll find more information at microsoft.com/exchange/howtobuy/licensingFAQ.mspx. If you don't want that CAL or any of the other features, you can continue to use the per-database journaling feature from Exchange 2003. Finally, have a look at David Strome's article from the December 2006 issue of TechNet Magazine entitled "More Powerful Journaling in Exchange 2007," at technetmagazine.com/issues/2006/12/journaling.

Q All of my users run Microsoft Office 2003, and we have no plans to move to the 2007 Office system until a hardware refresh in 2008. From what I've read, though, I'm afraid they'll miss out on some features because of this. Will they be able to use Unified Messaging?

A Absolutely. In Office 2003, Unified Messaging-enabled users can receive voicemail messages and faxes in their mailboxes, as well as call in to access their mailbox via any phone. If you don't upgrade to Outlook 2007, the Unified Messaging feature you'll miss is the ability to configure voicemail settings through the Options tab in Outlook, as well as the special custom form that shows up on a voicemail message in Outlook and lets you play the message inline without having to launch a separate media player. In addition the feature that lets you write audio notes and save them with the voicemail message will not be available. But even without Outlook 2007, your Unified Messaging-enabled users can still use OWA 2007 to access the Unified Messaging settings (on the OWA options page) as well as use the custom form for voicemail in OWA.

Q My company already has a Storage Area Network (SAN) and I want to hook up Exchange 2007 to it. But I've heard a lot about direct attached storage (DAS) that makes me wonder whether I should choose that option. What do you think?

A There isn't a right or wrong answer to this question; it really depends on your company's policies and scenarios (especially if you already have a SAN). If you're thinking of buying a new SAN, adding another one, or otherwise considering an upgrade, we highly recommend you consider DAS. Here's some information to take into account: as of June 2007, Microsoft IT has deployed 17 Exchange 2007 mailbox servers for 40,000 mailboxes (with quotas ranging from 500MB to 10GB), all using Cluster Continuous Replication (CCR) with DAS. By September we plan to have 35 Exchange 2007 mailbox servers with 152,500 mailboxes all on DAS. So if you're wondering if DAS is appropriate and workable on an enterprise scale, it absolutely is. DAS has been key in allowing Microsoft IT to increase user quotas while decreasing overall storage costs. More information on this topology and deployment and the savings involved is at microsoft.com/technet/itshowcase/content/64bitexchange2007.mspx.

Although it may initially seem like a huge savings in storage to have all of your servers hooked up to the same SAN, it is not without risk. For example, one problem that commonly occurs is related to the different usage scenarios for the software hooked up to the SAN. If you have an HR application on the SAN that runs a batch process every evening at 5:00 PM, for example, that I/O spike could seriously affect your Exchange users. Lack of deterministic I/O is a common problem with shared SAN deployments.

An advantage we've also realized with DAS is that it's simpler to manage because it doesn't require dedicated storage administrators or special equipment. It's incremental and easy to buy and expand later. And it's generally inexpensive enough that if you want to have spares lying around, it won't break the bank.

Q I have installed my first Exchange 2007 server. Now, when I try to connect to it using Outlook 2003, I get an error stating that the administrator has blocked my Outlook version. ("Your Exchange Server administrator has blocked the version of Outlook that you are using. Contact your administrator for assistance.") But I am the administrator and I never blocked it. What is going on?

A This behavior is not unexpected. When Exchange 2007 is being installed, the Setup wizard asks whether you are running any Outlook 2003 or earlier or Entourage clients in your organization (see Figure 2). If you answered no to this question, you may encounter this problem.

Figure 2** The Exchange 2007 Setup legacy client question **(Click the image for a larger view)

To resolve this issue after the fact (after setup has completed), you can simply create a public folder store using the Exchange Management Console or the Exchange Management Shell and restart the Information Store service. Restarting the Information Store service is mandatory in this case, and legacy clients (Outlook 2003 and earlier) will not be able to connect to the server until the service is restarted.

Additionally, if you are running the unattended setup of Exchange 2007, you can use the /EnableLegacyOutlook switch to specify how you want to answer the question about legacy clients.

Q Why would Exchange 2007 care if I connect to the server using older versions of Outlook? Why does creating the public folder store and restarting the Information Store service fix this problem?

A The answers to these questions revolve around the presence of the public folder store. If you recall, the public folder store in previous versions of Exchange is used to store the users' Free/Busy data, among other things. When a legacy Outlook user is connected to his Exchange server using MAPI or RPC over HTTP and publishes something to his calendar, the information about his Free/Busy status is also published to the server into a special public folder called the Schedule+ folder. This is the only way that legacy Outlook clients know of publishing users' Free/Busy data to the server and actually the only way a legacy Outlook knows how to read other users' Free/Busy information.

Exchange 2007 knows this. That's why if there is no public folder store, Exchange 2007 blocks earlier versions of clients. If Exchange 2007 allowed the legacy client connection, the client would encounter frequent errors as Outlook could not connect to the public folder store to publish Free/Busy data, and the client functionality would be limited as Free/Busy lookups that a user wants to do (when trying to schedule a meeting with someone else, for example) simply would not work. This is also why creating the public folder store resolves the issue, as Exchange 2007 server then knows that legacy clients can use the Free/Busy publishing functionality, so the mailbox logon is allowed.

From all this, there is one more thing you could have concluded: that Outlook 2007 clients do not require the public folder store to publish their Free/Busy information. This is true, but with a twist.

Without going into too much depth, let us just say that if a public folder store is present on an Exchange 2007 server, even an Outlook 2007 client will publish users Free/Busy data to it. The reason that this is done is so other clients, some of which are presumably legacy Outlook clients, can look up the Free/Busy information for an Outlook 2007 user; if the information is not in the public folder store, legacy clients would see no information for the Outlook 2007 user as nothing would ever populate the information into the public folder store. If the public folder store is not present, however, an Outlook 2007 client will not try to publish Free/Busy data. When there are no public stores and all clients are at least Outlook 2007, another mechanism of Free/Busy information lookup is used in which the calendar data is read directly out of the users' mailboxes, without creating a copy of this information anywhere else. If you want to read more about that, please look up information on the Availability Service in your server's help file or online Exchange documentation located at go.microsoft.com/fwlink/?LinkId=69434.

Q I just read Knowledge Base article 288894, which talks about blocking MAPI clients using a registry key (see support.microsoft.com/kb/288894). I checked my server's registry but this key was not set. How does the store execute this legacy client version block?

A A very good question! Indeed, Exchange 2007 Information Store does not use the "Disable MAPI Clients" registry value that is mentioned in that Knowledge Base article to block legacy clients. The reason for this is because there is a possibility that no public folder store exists and, therefore, no modification of that registry key can unblock those clients if no public folder store is present.

The behavior to block clients older than Outlook 2007 is simply hardcoded into Exchange 2007 Information Store. At service startup, the store checks for the presence of the public folder store, then decides whether only Outlook 2007 will be allowed to connect or if older versions will be able to connect to their mailboxes too. This check happens only at service startup. That's why you have to restart the Information Store service for the change to take effect after you create the public folder store.

KC Lemson is the User Experience Manager for Exchange Server. She is currently working toward a doctorate at a prestigious non-accredited university.

Nino Bilic is a Supportability Program Manager for Exchange Server. He is considering becoming a professional race car driver in Forza Motorsports 2.

© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.