You Had Me At EHLO... : Setup

Resolving MMC 3.0 errors when installing Exchange 12 CTP release

Exchange — Thu, 23 Mar 2006 17:41:00 GMT

As mentioned before - we now have CTP build of Exchange 12 those of you that have MSDN and TechNet subscriptions can install it.

One issue that seems to come up frequently for those of you that have tried installing this build is the following error at Setup:

"Exchange Server '12' requires Microsoft Management Console 3.0."

This happens even though the final (RTM), released version of MMC is installed on the system.

The problem here is that the CTP build of Exchange 12 setup actually needs a "RC1 refresh" build of MMC 3.0, and as this build is not found - the setup fails with the above error. E12 is looking for a registry key that is not there on the machine that has RTM version of MMC 3.0 installed. This issue is going to be fixed in later builds of Exchange 12 and will definitely not be there in final release version.

You can resolve this problem in 2 different ways:

1. Download and install the RC1 refresh MMC release, see Microsoft Management Console 3.0 Pre-Release (RC1 Refresh).

2. If you would like to run the RTM version instead (as you already installed it) create the following empty registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\MMC30Core

- Nino Bilic

x64 bit hardware will run Exchange 2003 on 32 bit Windows

Exchange — Fri, 18 Nov 2005 20:49:00 GMT

It seems we have some badly worded docs on some Microsoft sites that may lead you to believe that you cannot run Exchange 2003 on x64 bit systems. Also the release notes seem to be in error as well. Let me assure you that this information is incorrect and is being corrected.

You can run Exchange 2003 on x64 systems just fine. You do have to run Exchange 2003 on a 32 bit Windows version but they both run without issue on x64 systems.

I just wanted to post this blog entry so you are not confused and think that you are locked in. If you buy an x64 bit server now you can run Exchange 2003 now and be all the more ready for a E12 64 bit version when it arrives. In fact I would recommend if you are going to buy any systems in the near future that you buy x64 systems as they will not only run Exchange 2003 now, but they will also have a slight performance improvement vs. a 32 bit system and you will be ready (hardware wise) to go to the next version of Exchange that supports 64 bit without having to buy a new system.

Fact is your system maybe x64 bit now and you may not have notice! If you have a system that uses an Intel chip you can use this tool found at Intel’s web site that will tell you if your system is x64 bit capable http://support.intel.com/support/processors/tools/piu/sb/CS-014921.htm if your system has an AMD chip go to the AMD site and download their tool its call AMD CPUID http://www.amd.com/us-en/Processors/ComputingSolutions/0,,30_288_809_871^9706,00.html

Or you can just check by CPU type (not always clear however) you need to have one of these procs: AMD Athlon 64, AMD Opteron, Intel Xeon with Intel EM64T support, Intel Pentium 4 with Intel EM64T.

On the related subject - if you are wondering if Exchange 2003 can run on 64-bit version of Windows, please go here.

- David Espinoza

Permissions required to install the first Exchange 2003 Service Pack 2 (SP2) in the Org

Exchange — Fri, 02 Sep 2005 19:56:00 GMT

Because of the fact that the Community Technology Preview (CTP) build of Exchange 2003 SP2 is now available, we wanted to mention a permissions requirement for the FIRST SP2 installation into the organization.

With Exchange Server 2003 Service Pack 2, we have made a slight change in the way setup functions. As you may recall with Exchange Server 2003 Service Pack 1, you only needed the following rights to complete the installation:

· Exchange Administrator role on the administration group where the Exchange Server 2003 server exists.

· Member of the local Administrators group on the target Exchange Server 2003 server.

With Exchange Server 2003 Service Pack 2, we now include the Intelligent Message Filter; it is no longer a separate add-on to Exchange. As a result, we have to create an object within the Active Directory to store the IMF settings (if it does not already exist):

cn=UCE Content Filter,cn=Message Delivery,cn=Global Settings,cn=<ORG NAME>,cn=Microsoft Exchange,cn=Services,cn=configuration,dc=<Domain Name>

In order to be able to create and validate that object, the following right is needed:

- Exchange Administrator (or higher) on the Organization level

The first time you attempt to upgrade an Exchange Server 2003 RTM/SP1 server in your organization to Service Pack 2, setup will check permissions of currently logged on user and ensure that it has the necessary rights to create the above object. If the necessary rights are missing, the following warning will be displayed:

The part of the popup that applies to the permissions issue is:

This service pack requires Exchange Administrator permissions at the organization level the first time it is applied in an Exchange organization. Subsequent installs of this service pack in the same organization require Exchange Administrator permissions at the administrative group level only.

After the first upgrade completes successfully, setup will check for the existence of the above AD object and allow customers to proceed with a more restricted permission set (i.e. Exchange Administrator role at the administrative group or higher, as per original permission requirements). So those elevated rights are needed only for the first Exchange 2003 SP2 installation in the Organization.

If the "UCE Content Filter" Active Directory object is not present in the AD, the IMF tab will not be visible in ESM Message Delivery properties.

- Ross Smith IV

Can Exchange 2003 be installed on 64-bit editions of Windows Server 2003?

Exchange — Mon, 11 Jul 2005 19:43:00 GMT

It seems like a question of compatibility / incompatibility of current versions of Exchange (mainly Exchange 2003) and Windows Server 2003 x64 editions is coming up more and more, so let’s address it.

In short – running current versions of Exchange, including Exchange 2003 on Windows Server 2003 x64 editions is not supported.

In fact, Exchange 2003 does not even install properly under WOW64. There are several reasons for this – some are related to Exchange 2003 IIS dependency but the biggest problem is that Exchange Setup installs the IFS (Installable File System) driver (exifs.sys) which is a 32 bit driver. On x64 editions of Windows, all of the Kernel mode components (which includes drivers) have to be native 64 bit components, while the User mode applications can be run under WOW64. This problem can not be addressed in future Exchange 2003 Service Packs either.

Now – the future is bright, we have plans, just not with current versions of Exchange. There is a list of applications that will run under Windows Server 2003 x64 in either 32 bit compatible or 64 bit native mode and you can find it here.

For more information on Exchange 2003 installation requirements, please go to this page.

- Nino Bilic

Exchange 2003 Memory Configuration change for Windows 2003 (PAE Support)

Exchange — Wed, 06 Jul 2005 02:29:00 GMT

Introduction

Exchange 2003 requires specific memory tuning to function optimally. This flash outlines Windows 2003 boot.ini configuration settings for Exchange 2003 and highlights recent changes. See the following KB articles for relevant background information on this topic:

· CPU and Memory Scalability for Exchange Server 2003 and for Exchange 2000 Server

· Use of the /3GB switch in Exchange Server 2003 on a Windows Server 2003-based system

· Using the /USERVA switch on Windows Server 2003-based computers that are running Exchange Server

This Flash covers only Exchange 2003/Windows 2003 topologies.

Deployment Guidelines

Exchange 2003 requires Windows 2003 Sp1 or Windows 2003 with security update MS04-032. Both of these versions contain the fix for a problem described in article 834628 which is necessary for Exchange 2003 to run reliably. The following table outlines the boot.ini configuration switches that must be added for the given Exchange 2003/Windows 2003 server role:

Boot.ini Configuration Matrix: Exchange 2003 RTM/SP1+ , Windows 2003 RTM/SP1+

*Exchange 2003 Server Role*	*Physical Memory Config*	*Additions made to Boot.ini*
Mailbox	> 1 GB**	/3GB /USERVA=3030

Public Folder	> 1 GB**	/3GB /USERVA=3030

Front End (FE)	> 1 GB**	None

SMTP Gateway/Bridgehead	> 1 GB**	None
SMTP Gateway/Bridgehead (Envelope Journaling*)	> 1 GB**	/3GB /USERVA=3030

MTA/X.400/3rd Party Connector Bridgehead*	> 1 GB**	/3GB /USERVA=3030

* Envelope Journaling or MTA/3rd Party Connectors send Gateway/Bridgehead email through the Store.exe process so the system benefits from /3GB.

** /3GB and /USERVA=3030 is not used on Exchange servers with less than 1GB RAM

***See KB 823440 for additional details on configuring Windows memory for Exchange 2003.

****Windows may add/require additional boot.ini configuration switches.

*****The above settings are applicable to all Exchange 2003 and Windows 2003 server SKU’s including Standard Editions.

Support Policy/Recommendation Change

There has been significant change to Exchange 2003’s recommended Boot.ini configuration settings. The following change has been made to Microsoft Exchange 2003 Support Policy.

It is recommended and supported to run Exchange 2003 with the PAE (Physical Address Extension) kernel on Windows 2003: Due to the issue (Hotfix in article 834628) found in Windows 2003 RTM running the PAE kernel, the fact that Exchange does not take advantage of more than 4GB of memory and the fact that Exchange running on PAE kernels was not initially tested; the Exchange Product group originally recommended running the /NOPAE switch in the boot.ini to prevent the PAE kernel from loading. This decision has been reversed for the following reasons:

a. Windows 2003 SP1 was released:

· Windows 2003 Sp1 contains the fix for 834628 so Exchange 2003 is stable running on the PAE kernel.

· Windows 2003 SP1 contains new security features (Data Execution Prevention (DEP)) which require the PAE kernel. Exchange 2003 needs to support PAE to take advantage of these new security features. Windows 2003 SP1 will automatically set DEP specific boot.ini settings to take advantage of DEP capable hardware.

b. New PCI-Express based server chipsets require PAE to take advantage of all the memory installed on a system (4GB):

Some of the physical address space on server systems is used to provide memory mapping of IO resources on the system chipset. This memory mapped IO (MMIO) space is typically provided below the 4GB address boundary. In a system with 4GB of physical memory this MMIO space pushes a section of physical memory above the 4GB address boundary. If the software running on the server supports only 32-bit physical addressing, it will not look for memory over the 4GB boundary. This results in the OS not providing access to all 4GB of physical memory. The amount of ‘hidden’ memory is equal to the address space taken up by the MMIO. PCI Express confounds this problem by providing extended PCI configuration space to support such features as Advanced Error Reporting (AER). This means the size of MMIO space required to map the chipset IO resources gets larger. Some early PCI Express chipsets confound the issue further by providing coarse granularity for this mapping which results in a range of 512MB being carved out for MMIO. This results in customers reporting hidden memory of 512MB to 768MB on servers using such chipsets.

c. The Exchange Product Group tested Exchange 2003 SP1/SP2 on Windows 2003 (/w 834628 ) with the PAE kernel and on Windows 2003 SP1 with PAE and DEP enabled:

· The Exchange Product Group did not find any issues relating to running on the PAE kernel nor running with DEP enabled (software and hardware enabled).

Additional Resources/Questions

How can the boot.ini configuration be validated in a running environment? Use the Exchange Best Practices Analyzer Tool The tool has been updated to include the support policy change outlined in this Flash.
How should Exchange 2003 memory based performance issues be troubleshooted? Use the Troubleshooting Exchange Server 2003 Performance whitepaper.
What is Microsoft’s stance on running Exchange on Windows 2000 with PAE? It is supported but not recommended. Hotfix 838647 is required for support. Windows 2000 does not have the security features that require PAE so the only benefit of running PAE on Windows 2000 for Exchange is to enable all memory access on newer PCI-Express based servers. It is not a well tested scenario so it is not recommended.
Does Exchange utilize more than 4GB of memory if the PAE kernel is loaded? Exchange will only utilize 4GB of memory regardless of whether the PAE kernel is loaded or not. The PAE kernel is beneficial (specifically for Exchange) to enable DEP and to see 100% of the physical memory on newer server chipsets. Memory above 4GB will not be utilized by Exchange.

- The Exchange Team

How to Create and Edit Exchange Server 2003 unattend Files?

Exchange — Fri, 22 Apr 2005 23:45:00 GMT

Alex MacLeod posted an excellent article on Exchange TechCenter that deals with creating and editing files needed for Exchange 2003 unattended setup. Really a great read if this is what you were wondering about!

Check it out here!

- Nino Bilic

The story of the MSDTC resource and Exchange 200x cluster servers

Exchange — Mon, 17 Jan 2005 18:13:00 GMT

As I already mentioned on my blog, here is some information on a somewhat confusing subject. I added two more questions about MSDTC that we hear often:

Over the years, the best practice recommendations on where to place the MS Distributed Transaction Coordinator (MSDTC) resource in Exchange cluster has bounced between two differing views. One camp thought it was unadvisable to place this resource in the cluster group occupied by the quorum resource, while others noted that Exchange doesn't really use DTC and its wasteful to dedicate a whole group (with IP and disk) to this resource.

Let's address this from the bottom up:

Why does Clustered Exchange 200x need a MSDTC resource anyways?
Exchange provides support for a workflow function, and this capability is installed on all Exchange 200x servers by the Exchange setup. This functionality is encapsulated in the CDOWFEVT.DLL binary. This workflow functionality requires various components to be registered with COM+ to function. COM+ requires DTC to be running. And on Clustered Windows, DTC won't initialize unless it's configured for the cluster -- ala MSDTC resource. Perhaps this domino-effect failure is familiar, particularly if you've run into the problem described in KB.312316!

So, does Exchange 200x workflow use MSDTC extensively?
Nope. Essentially just for the setup/upgrade steps, particularly if you've not actively implemented workflow applications.

OK, so – if that is the case – can we take the MSDTC resource offline and keep it that way on our clustered Exchange server?
If you are not using workflow applications on your clustered Exchange server – that is fine, the MSDTC resource can be kept offline. You do need to remember to bring the resource ONLINE though when running Setup of Exchange service packs or hotfixes.

What about deleting the MSDTC resource and then recreating it when having to run Setup?
This has not been tested and therefore we can not recommend it.

When, then, do some folks recommend to not put MSDTC into the default cluster group?
KB.168948 says pretty clearly not to put anything in the default cluster group that doesn't need to be there. This is a very important group, and anything placed in this group can contribute to lowered availability of the cluster.

But doesn't the old COMCLUST.EXE program put it there automatically?
Yes. Typically. Unless you follow the wacky steps in KB.290624. This is a big part of what leads to this confusion, because in Windows 2003 you don't use Comclust anymore, instead following the steps in KB.301600 so we see lots of variation with customers here based on which method they followed.

Ok, that makes sense... so why do others say DO put it in that group for Exchange 200x clusters?
Here's where it gets interesting. Consider the characteristics of a typical, real-world Exchange 200x cluster server: heavily-loaded, never enough disk spindles, etc. If you follow this path of recommendations, now all of a sudden you need to add AT LEAST one extra IP, one extra network name, and one extra physical disk. Just to support this MSDTC resource that 99% of Exchange clusters only need for setup/upgrade purposes. If you have to choose between allocating this extra disk spindle to an underutilized MSDTC resource or to an under provisioned database store LUN, most Exchange design architects will choose the second!

Microsoft has long advocated the first option (dedicated group/disk/etc for MSDTC) as a best practice, since it maintains the cluster group containing the quorum disk untouched. Pretty much all of the documentation and KBs currently state this position. However, after a bunch of internal discussion and debate, this recommendation is about to change and the KB/documentation will be updated shortly.

So, if you have long ignored older recommendation and placed the MSDTC resource in the cluster group containing the quorum... you're fine. Exchange so minimally utilizes DTC that the performance hit and impact to cluster availability are negligible and generally not worth allocating the additional resources. Put that extra disk toward your Exchange data storage instead (see previous postings here, here, and here for more). Additionally, it is recommended that you remove (uncheck) the option to "Affect the Group" from this MSDTC resource, so that if it does ever fail it will not impact the cluster group containing the quorum resource.

Note that this recommendation change does NOT apply if you are running SQL or some other application that utilizes MSDTC extensively. If your MSDTC is being utilized, you definitely still should keep this resource out of the cluster group containing the quorum to avoid any possible negative effect on cluster availability.

- Evan Dodds

The New Cluster “Clean Upgrade” Method

Exchange — Fri, 07 May 2004 16:47:00 GMT

Prior to releasing Exchange Server 2003 we didn’t test this scenario, and since we only support scenarios that we have tested and have confidence in this was considered unsupported. However, with so many customers interested in this method of upgrading we decided to test it and document the process. A KB article will be released describing the process, but for now here are the steps you need to know.

Summary:
In some cases it may be preferable to do a clean install of the operating system or Exchange Server rather than upgrading. On a cluster, your existing Exchange 2000 virtual server can be preserved and upgraded even if you need to clean install Windows 2003/Exchange 2003. Some custom configuration may be lost using this method, we recommend performing a standard upgrade if at all possible. Please read and understand all the steps and issues thoroughly before beginning this upgrade process.

This kb article covers clusters that meet the following requirements:

Windows 2000 SP3
Exchange 2000 SP3
Two nodes
Active/Passive configuration

Upgrading to:

Windows 2003
Exchange 2003

Steps:
For this example I’ll run the EVS on node2 while I upgrade node1, but it doesn’t matter which node is upgraded first.

1. Evict the passive node and rebuild

Make sure the EVS and all cluster resources are all running on node2 (active node).
Use cluster admin from node2 to stop the cluster service on node1 and then evict it from the cluster.
On node1, format the disk and clean install W2k3.
Rejoin node1 to the cluster (Important! This must happen before running Exchange setup)
On node1, clean install E2k3.

2. Configure services

On node 1, run services.msc and set Distributed Transaction Service startup type to Manual
If you are using POP3 or IMAP set the start up type to manual on each service. (If you are not using these services consider deleting the resources and setting the services to disabled).
If you are using full text indexes please see the note below for special instructions.
On node2, take the Microsoft Exchange System Attendant resource offline (this will take all Exchange resources offline)

3. Upgrade the Exchange Virtual Server (EVS)

Move the offline EVS to rebuilt node (node1)
On node1, right click the System Attendant resource and select upgrade EVS
The upgraded EVS cannot be failed over to run on the older version node (node2). To prevent this from happening change the System Attendant resource possible owner list to include only the upgraded node.

Right click the System Attendant resource and select properties.
On the “general” tab next to “possible owners” click “modify”.
Under Possible owners select the name of the node that hasn’t been upgraded, and click the ? arrow button to remove it from the list.
Click ok.

Bring the EVS online

4. Repeat 1-2 (with node2 as the passive node)

Running Exchange setup on node2 should add it back to the possible owner list for the System Attendant resource
After both existing nodes are upgraded to Windows Server 2003 additional nodes can be added to the cluster.

Issues:

Full Text Indexes begin a Full Population after upgrading the Exchange Virtual Server

After the cluster node has been upgraded to Exchange 2003, the Exchange Virtual Server has been upgraded, and the cluster resources come on-line, a full population will begin on all full-text indexes and the indexes will be disabled for searching. To avoid having the full population begin automatically, manually start and then pause a full or incremental population on all the full-text indexes on the server prior to upgrading the Exchange Virtual Server. If the indexes are already paused when you upgrade, they will remain paused and the upgrade will finish normally. After you have finished upgrading, you can manually resume building the indexes when it is convenient to do so. Once the indexes have been built, you can enable searching on the newly built indexes.

One Way Upgrade

Once an EVS is upgraded it cannot be run on a node with older versions of Windows and/or Exchange.

Other Applications Must Be Installed Again After Upgrade

Workflows, virus scanning, event sinks, and any other application installed on your existing server will need to be reinstalled and configured. Make sure all applications you are planning to bring forward are compatible with the newer versions of Windows and Exchange.

Customized Registry Keys Lost

Any feature that is enabled by setting a registry key (such as journaling) will not be carried forward with this upgrade. Any customization, performance tuning, manually set or altered registry key will not be persisted using this upgrade method. These will need to be manually reset.

No Active/Active support

Using this method of upgrading Active/Active clusters is not supported.

Risk of Downtime Increased by time between upgrading first and second nodes

Once the Exchange Virtual Server has been upgraded it cannot be run on the older version node. If anything happens to the upgraded node during this time, it has no passive node to fail to. To reduce the risk of downtime, upgrade the second node soon as possible after upgrading the first. The risk of downtime is increased the longer the EVS has only one node available to run on.

- Carol Swales

What is the difference between Exchange 2003 and the Exchange 2003 installed with Small Business Server 2003?

Exchange — Wed, 05 May 2004 20:24:00 GMT

The version of Exchange that ships with SBS is 99% the same as Exchange 2003 Standard. The only difference is that the SBS version of Exchange can only be installed on an SBS server since there was a minor change added to look for the SBS product key instead of the Exchange product key.

- Gwen Zierdt

Tips on Troubleshooting Using the Exchange Server Setup Progress Log

Exchange — Thu, 08 Apr 2004 03:20:00 GMT

Here are some pretty useful tips straight from the Exchange Setup Test Team for using the Exchange Setup Log to troubleshoot Exchange Setup issues.

Tip #1: Most of the errors in the Setup Log are not really errors!

Yup, as silly as it sounds the vast majority of the "errors" in the log are actually expected return values from other Windows services that happen to come back to us in the form of an Exception, so it goes through Setup’s error handling processes. Most common is the "Error code 0XC0070424 (1060): The specified service does not exist as an installed service." This error shows up every time Setup tries to start, stop, or use a service that isn’t installed (surprisingly, Setup does this a lot for reasons I won’t go into here). For example, Setup will always try to stop the Exchange Information Store service, even if it isn’t installed yet. When Setup does that, the Service Control Manager returns an exception, Setup catches the exception, detects this is an expected exception, and from Setup’s point of view having no service installed is as good as stopping the service, the error is safely ignored.

Here's an example:

[13:43:33] Entering CAtomServices::ScStopAtomServices
[13:43:33] CService::ScGetStatus (f:\titanium\admin\src\libs\exsetup\service.cxx:722)
           Error code 0XC0070424 (1060): The specified service does not exist as an installed service.
[13:43:33] CService::ScIsStartedOrStopped (f:\titanium\admin\src\libs\exsetup\service.cxx:760)
           Error code 0XC0070424 (1060): The specified service does not exist as an installed service.
[13:43:33] === IGNORING PREVIOUS ERRORS === CServiceManager::ScStopService
(f:\titanium\admin\src\udog\setupbase\tools\svcmgr.cxx:537)
           The operation has completed successfully.

There are a number of other similar ignored error cases, such as trying to delete an Active Directory object right before creating it, or remove a file before we copy it. You get the idea.

There is one other "error" that I really want to mention because I constantly see postings in news groups with something to the effect of:

"My Exchange Setup failed! Here’s the error:
[09:42:28] CComBOIFacesFactory::QueryInterface (f:\titanium\admin\src\udog\bo\bofactory.cxx:54)
Error code 0X80004002 (16386): No interface."

All this "error" indicates is that the Setup UI has been exited. That’s it. It’s at the very end of every Setup Log, including all successful Setups and most of the failed ones too. It is in no way a real error or helpful in figuring out what the actual error is (if there is one) and can be safely ignored.

I know it’s dumb that we record an "error" when you correctly exit the UI, but it has to do with the Setup manager code (not written by Exchange) that the Setup processes plug into.

Tip #2: Know what strings to search on to find your way around the Setup Log:

Sections	Search string	What’s in there
Initialization	****** Beginning	This is at the start of the log for each instance of Exchange setup
Configuration summary	-- ID:62227 --	Lots of useful general information here: schema master DC identified, account running setup, install source directory, etc.
Pre-install on each component	is set to action	What action was set on each component, i.e. "install", "remove", "upgrade", etc
Beginning action on each major component	-- ID:62208 --	Prepare for file copy, build file queues, perform file copy, then configuration of the component (and its subcomponents, if any)
Skip to the bottom of file copy (server component)	Entering CAtomDW::ScSetup	This is where the real action starts to happen. If you’re looking for a failure, chances are it happens during configuration. Skip past the file copy with this string.
Completed action on each major component	-- ID:62209 --	If a component started (62208), but didn’t finish (62209), you can bet it contains a failure.
Post setup	Entering CCompRoot::ScPostSetup	Mostly service management again

Tip #3: Use the retry button!
If you have a problem during setup, hit retry and let setup try the operation again. Chances are if it failed the first time, it will fail again, but hitting retry will help highlight the failure in the log. Now when you open the log, you know exactly what section to look for the error in—every thing from the "***** RETRYING THE FAILED OPERATION *****" on down—and don’t have to wade through the rest of the log.

Tip #4: Installing on a cluster
If you’re setting up on a cluster and want to make sure setup recognizes it as a cluster, when you get to the component selection page, open the setup log and look for the line near the end of the setup log "We have detected that setup is running on a cluster"

Tip #5: Quickly find fatal errors
You can search a setup log for ">>>>>>>>>". This string is prefixed to all fatal errors.

Tip #6: Translate those Setup prereq messages for easy posting and faster help!
Running Setup of a localized build of Exchange and hitting a prereq message or error? Want to get help easier and faster in newsgroups and DLs?

Then try running Setup using an English version of Exchange. The messages will be captured in the Exchange Server Setup Progress log in English. Now you can copy and paste from the log into Google, newsgroups, or email, where it is often easier to get help if the messages are in English. Of course, you don’t have to translate into English, it works for any language that particular version of Exchange is localized into.

But wait, you don’t have other languages of Exchange available? Try using the free Eval version of Exchange downloadable from the net (just be sure not to actually install the Eval version!)

Note: This trick only works if you don’t have Exchange installed on that machine already. That’s because Exchange Setup requires you to run Setup using the same language as the Exchange that’s already there. You’ll get a prereq message telling you to use the same language if you try.

Tip #7: Why do we ignore error codes with regards to Device Update?

When we install Titanium, we see the following line w.r.t. Device Update:

[10:36:13] About to uninstall ASP.NET Device Update
[10:36:13] Process created ... waiting (-1)
[10:36:14] Ignoring exit code 0x000645

One might wonder why we ignore the exit code. Well, that’s because we try to uninstall it regardless if it is present or not. In the above case, it’s not present. We don’t want to fail setup because of a Device Update Installation/Un-installation Failure.

When we install Exchange 2003 SP1, we see the following lines w.r.t. Device Update:

[11:14:03] About to uninstall ASP.NET Device Update 2
[11:14:03] Process created ... waiting (-1)
[11:14:06] Ignoring exit code 00000000
[11:14:06] About to uninstall ASP.NET Device Update 3
[11:14:07] Process created ... waiting (-1)
[11:14:07] Ignoring exit code 0x000645
[11:14:07] About to install ASP.NET Device Update
[11:14:07] Process created ... waiting (-1)
[11:14:11] Ignoring exit code 00000000
[11:14:11] ASP.NET Device Update was installed

Here, we first try to uninstall Device Update 2, then uninstall Device Update 3 and then install Device Update 4. In the above case, there was no problem installing DU4 (see the bold italicized line).

However, in the case that Device Update 4 was installed already, we would ignore an error code and continue with setup. The MSIInstaller would throw an error saying it was already installed and we’d also see an Error in the Application Event Viewer, with Source of MsiInstaller whose description is:

Product: Microsoft .NET Framework 1.1 -- Device Update 4.0 -- This Device Update has already been installed.

- The Exchange Setup Test Team (Berg, Batwoo, Alex, Ted and others who we hope will keep participating on this blog!)

The first rule for secure deployment

Exchange — Thu, 18 Mar 2004 16:55:00 GMT

Disable services, features and components that you are not using.

Exchange is a complex product that provides many features. Many of the features are not used by every Exchange customer. In Exchange 2003 we changed the install to only enable by default features used by the majority of our customers. The reason for this is that it presents a smaller surface area for the product. If all of the users of an Exchange server are using Outlook or OWA to read their email, then why should the Exchange server be listening on POP3, IMAP4, or NNTP interfaces. Disabling unused components and services increases the security of the server by reducing the surface area Exchange is listening on. Having an unused feature enabled and running could also place extra load on the server and reduce the performance and throughput of that server.

After disabling a component always ensure that the system still provides the required functionality. There may be internal dependancies between components that are not imediately obvious. Microsoft has just released the Exchange Server 2003 Security Hardening Guide at http://www.microsoft.com/downloads/details.aspx?FamilyId=6A80711F-E5C9-4AEF-9A44-504DB09B9065&displaylang=en. If you are an Exchange administator I recommend that you read though this guide and implement the policies that apply to your Exchange deployment. Even if you have not deployed Exchange 2003 you will be able to put into practice many of the ideas this guide presents.

Michael Nelte

What is DomainPrep and Why DomainPrep the Root Domain?

Exchange — Fri, 27 Feb 2004 17:45:00 GMT

What is DomainPrep? Why does Exchange recommend running DomainPrep on the Root Domain if there are no Exchange servers or users in that domain?

I have been asked these questions so frequently I thought I’d do a post on it. I know DomainPrep is a little mysterious to many people so let me quickly explain what DomainPrep is and does.

DomainPrep does all the tasks for Exchange Setup which require Domain Admin rights to accomplish. These tasks are:

Create two groups; The Exchange Enterprise Servers group (EES) and the Exchange Domain Servers group (EDS)
Create the Microsoft Exchange System Objects container (also known as the Domain Proxy Container) in the Active Directory
Add permissions (mainly for the EES and EDS) to the Domain, AdminSDHolder, and MS Exchange System Objects containers
Add permissions to the EES, EDS, and the Pre-Windows 2000 Compatible Access Group
Add the EES to the local security policy “Manage auditing and security log” on every Domain Controller in the domain

Note: The Recipient Update Service (RUS) will keep these permissions up to date when Exchange is installed in new domains and when new Exchange Full Administrators are delegated.

Thus running DomainPrep requires an account that has Domain Admin level permissions, but does NOT require any Exchange Admin permissions. This way you don’t have to give your email administrator Domain Admin permissions in order to install the first Exchange in a given domain.

That’s it. 2 groups, an object, and some permissions for the groups. That’s all DomainPrep is. It doesn’t create any directories, install any binaries, or add any regkeys. It’s actually very lightweight and runs in seconds.

So then why do I need to run DomainPrep is my Root (or Parent) Domain if I’m not going to have any Exchange servers or users with Exchange mailboxes in that domain? The short answer is "Because that’s usually where the GC is".

The main issue has to do with DSAccess. DSAccess is what Exchange services use to access information in the Active Directory. In order for it to find the correct information, DSAccess needs to talk to Global Catalog servers, even if those servers are not in a domain where Exchange is installed. DSAccess will only talk to GCs that it has rights to. It will check to see if it has rights to that GC by checking if it has privileges to the Security Access Control List (SACL) on the GC. These rights are only propagated by the Recipient Update Service (RUS) and you can only create a RUS for domains that have been DomainPrepped.

If you follow this chain, you’ll see that it comes down to "DSAccess needs to be able to talk to a GC", and in order to do that the GC has to be in a domain which has been DomainPrep’d and has a RUS pointed at it.

So if you have a parent-child domain configuration, with Exchange only in the child domain, and GCs in the parent domain, you will have to run DomainPrep in the parent domain AND create a new RUS on an Exchange server in the child domain and point that RUS at the parent domain.

Now I know you’re all asking the question "What if you don’t have a GC, or Exchange servers, or users getting Exchange mailboxes in the parent domain?" The answer is: "Then you don’t need to DomainPrep the parent domain."

So if all your GCs are in the child domain, and none are in the parent domain, and there are never going to be any Exchange resources in the in the parent domain, then you don’t need to DomainPrep it or create a RUS for it. But that configuration doesn’t happen very often and the consequences for not DomainPreping the parent are bad enough (like the Exchange Information Store service won’t start) that we tell everyone to always domainprep the parent domain.

- “Berg”

Failure extending the schema in the Active Directory?

Exchange — Wed, 11 Feb 2004 17:54:00 GMT

It is possible while installing the Active Directory Connector (ADC), or while running an Exchange setup forestprep action, to be greeted with this incredibly generic error message: “Extending the schema in the Active Directory failed. Please consult the error log LDIF.ERR in your TEMP directory.” When presented with this error message, you might dutifully go off to find yourr LDIF.ERR log, as directed, and find nothing of the sort present in your temp directory. So now what?

Well, one possible explanation is that you’ve got spaces in your temp dir path. I know, I know – what up? Here’s the scoop: Exchange setup and ADC setup both need to import a bunch of schema into the AD on initial installation. To do this, they call on a little Windows utility called ldifde.exe. Ldifde.exe takes as one of its parameters a directory path for the location of its log file. Our setups pass as this parameter the path to the current user’s TEMP directory. The code calls a Win32 API (GetTempDir()), which returns the value of the TMP/TEMP variables, and appends a trailing backslash to the string (presumably so a filename can be just tacked on the end). If our code gets back the temp dir string and finds a space anywhere in it, we’ll enclose the whole string in quotation marks (perfectly reasonable string handling practice). However, when we pass a quoted string to ldifde.exe, it barfs. In fact, in barfs so early that it isn’t even able to write an LDIF.ERR log to the TEMP dir.

Why does ldifde.exe panic when it gets our string? That’s where the bug is – I’m guessing ldifde.exe reads the trailing backslash and quotation mark at the end of the string (\”)as an escape sequence, and so doesn’t think the string is actually formatted correctly. The owners of ldifde are currently investigating this.

How is it that you’ve got a space in your temp dir path? Well, by default the temp dir path is something like D:\Documents and Settings\Alex\Local Settings\Temp. “But wait,” you say, “there are spaces all over the place in that path.” Right you are. However, by happy accident your temp dir variable actually gets constructed by default using 8.3 short file names. So the path becomes D:\DOCUME~1\Alex\LOCALS~1\Temp…no spaces there, which is why most users don’t experience this problem. A user would have to manually change their temp dir path to get spaces in it…or would they?

Another (this time not-so-happy) accident: you can disable 8.3 file name creation. There is, in fact, a registry key that will allow you to do this (intuitively named NtfsDisable8dot3NameCreation, found in HKLM\System\CurrentControlSet\Control\FileSystem). Set this value to 1, and 8.3 filename creation will be disabled. If a user logs on to a box where this setting is in effect, the userprofile for that user will include TMP/TEMP variables that look like this: D:\DOCUME~1\Alex\Local Settings\Temp. Uh-oh…forestprep and ADC install fail. This registry setting is actually specified in many of the security templates found up on TechNet.

The workaround is to remove the spaces in your temp dir path variables (SET TEMP=D:\SOMETHING\WITHOUT\SPACES; SET TMP=D:\SOMETHING\WITHOUT\SPACES), then run forestprep or ADC install, then set your variables back the way you had them. We'll have a KB article about this created in the next few weeks.

- Alex MacLeod