Provide Feedback on this Broadcast

Note This document is based on the original spoken Support WebCast transcript. It has been edited for clarity.

Vincent Yim: This presentation will assume that you might already have some prior knowledge of deploying Microsoft® Exchange 2000 Server with or without Exchange 5.5 interoperability.

In our agenda for today (slide 2), we will be discussing the new deployment changes, which include the deployment tools and the Active Directory® Connector (ADC) Tools. So the first two bullets there are new features in Microsoft Exchange Server 2003. We're also going to review some of the common migration paths when migrating from Exchange 5.5 or even from Exchange 2000.

Later on we'll be discussing some of the setup changes, such as the changes to the ADC Setup program, as well as the ADC service itself. Then we're going to discuss system and network configurations that will block the setup process from continuing. Finally, before the Q&A session, we're going to talk about the actual changes made to the Windows® system every time Exchange 2003 is installed on Windows.

Before I start talking about the deployment changes, let's first talk about what's not new. The Exchange 2003 Setup program is not much different from the Exchange 2000 version. If you ever ran the Exchange 2000 version of setup, you'd realize it's not exactly a simple task. Generally, our customers had quite a lot of trouble installing the Exchange 2000 version because our Setup program was pretty rigid in making sure that Windows was configured correctly.

The problem was even the most subtle Active Directory or Domain Name System (DNS) misconfigurations, or even misconfigurations on the local Windows system, caused a lot of roadblocks when customers' deployment deadlines were due. So the Exchange 2003 setup engine is not much different because it inherits all the strict prerequisite checking routines and then some more. We've added some more prerequisite checks.

Now we added a new feature called the Deployment Tools (slide 3), which are designed to ease the deployment process somewhat. The Deployment Tools are pretty much small programs that proactively scan for problems in Active Directory. If you're installing Exchange 2003 into an Exchange 5.5 environment, the tools will also query for errors against the Exchange 5.5 directory. Alongside the Deployment Tools is an integrated Deployment Tools Help file and the tools are run from that Help file, as you will see in the next slide.

Here's a quick screen shot of the Help Guide (slide 4). It's actually an HTML Web site that's compiled into a single file called the Deployment Tools Documentation. Whenever you start the Deployment Tools from the autorun — that is the splash screen when you insert the Exchange 2003 CD — you actually navigate through this very documentation that you see here. So although it might be tempting to skip the documentation, please follow it because it actually provides you with steps that you'll need to take in order to pass the rigid system checks to run the Exchange 2003 Setup program.

This documentation also has, as you can see here, embedded scripts and controls that scan for the health of certain Active Directory components or the Exchange 5.5 directory, if that is the deployment scenario that you choose. The scripts are the actual Deployment Tools themselves, and you run them by first filling in the server information on the Web page directly, and then clicking on the link to run each deployment tool, which then writes information into a log file. Typically, that log file is written in your system drive in the Exdeploy Logs folder.

The Help Guide won't run the same tools, nor will they prescribe the same installation steps for everyone. That's because each installer is in a different situation, and depending on what situation that is, whether or not you're joining 5.5, whether or not you're installing brand new, the Help file branches out into separate sets of instructions, depending on the feedback that you choose to enter in the Help file.

So if I was installing a fresh Exchange installation with no organization or interoperability, with 5.5, then I would not get the screen shot that you see here. Only those people, of course, integrating with Exchange 5.5 would get this screen when running through the Deployment Tools documentation.

I'm often asked if I can skip the Deployment Tools (slide 5). Typically, I say yes and no, depending on, of course, your situation. So to elaborate on where I would say no, I typically tell people that they should skip neither the Deployment Tools nor the ADC Tools if they're installing Exchange 2003 into a pure Exchange 5.5 site. Whenever I say pure, that typically means that there aren't any post-Exchange 5.5 servers in the Exchange site already.

Now you can skip the Deployment Tools if you're not joining Exchange 5.5. But we still recommend that you don't skip them, because the Help Guide still does a pretty good job in providing you with diagnostics logging, and helps you get past any future unforeseen setup problems. In fact, we recommend that you run the Deployment Tools days or possibly even weeks before you run the Exchange 2003 Setup program because you actually can better plan for scheduled downtimes that are required by setup.

For example, let's say that the Deployment Tools scan for the health of your Active Directory to make sure that it's suitable for an Exchange 2003 installation. Then it finds a domain controller that is at a service pack level that does not satisfy the Exchange 2003 installation. So rather than waiting until the deployment date to find that out, you can now find out well ahead of time, and then allocate a block of your time to prepare for that domain controller upgrade before you meet your Exchange 2003 deployment deadline.

Lastly, believe it or not, the Deployment Tools can run against Exchange 2000. I should rephrase that. You can use the Deployment Tools even if you are not deploying Exchange 2003. So if you're deploying Exchange 2000 in an Exchange 5.5 organization, you can download the Deployment Tools off of the Web if you just go to the Exchange 2003 Tools download site, and then grab and extract the Deployment Tools Help file. It's just a package that includes this compiled HTML Help file, as well as a few executables and DLLs. To run it you just click on the Help file, and then you pretty much run through the same steps as Exchange 2003 installers would. The only difference is that you won't be running through the ADC Tools, and we'll talk about the ADC Tools later on.

The Forestprep command (slide 6). There are several versions of the Forestprep command. You've got the Windows Server™ 2003 version, the Exchange 2000 version and, of course, we have to, unfortunately, rerun the Forestprep command again in Exchange 2003. So if you don't already know, it's a command that you typically used to type in by typing in setup /forestprep. So really it's not an executable all by itself; it's actually a switch that you provide to the Setup program.

It's run a little differently now. You have the option, if you completely use the Deployment Tools Help Guide, you won't need to ever drop down to the command prompt and type in the Forestprep command yourself. The Help file will actually fill in the /forestprep switch for you.

Anyway, Forestprep, as I said, is still required because we make some additional schema extensions, some that provide extensions for the mobility features of Exchange 2003. Also, we include a fix to the Exchange 2000 schema. Some of you might have already run across mangled attributes in your Active Directory, and that case typically happens if you run the ADPREP, which is the Windows 2003 Forestprep utility, to extend the schema for Windows 2003 after you've already extended the schema for Exchange 2000.

If you read Microsoft Knowledge Base article 314649 ("Windows Server 2003 ADPREP Command Causes Mangled Attributes in Windows 2000 Forests That Contain Exchange 2000 Servers"), you can get some more details on that. That article discusses an InetOrgPersonFix toolkit. You can bypass that toolkit by importing the schema or by extending the schema using Exchange 2003's version of Forestprep.

For new installations the Forestprep command pretty much looks the same, but "under the hood" (not visible) it's actually quite different from the Exchange 2000 case. Basically, the Forestprep operation for Exchange 2003 creates a placeholder globally unique identifier (GUID) object in Active Directory. This isn't a very user-friendly looking organization object, but it is the baseline for getting an organization created in Active Directory to support Exchange 2000 or Exchange 2003.

In the Exchange 2000 case, the Forestprep command required that the installer had to not only have the permissions to extend the schema, but also, if they were installing into a 5.5 organization, the installer also had to have permissions to the Exchange 5.5 directories. If those permissions weren't set, then they would not be able to complete Forestprep, except to create a brand new organization that would not interoperate with Exchange 5.5.

Now in Exchange 2003 we've kind of separated out those roles. The /forestprep switch only requires schema extension permissions. Later on, when you run the later phases of setup, then you are given the option to join an Exchange 5.5 organization or create a brand new one.

The ADC Tools (slide 7), as you can see here, is new to the Exchange 2003 setup process. Although we had the Active Directory Connector in Exchange 2000, and you also had an interface to create recipient connection agreements yourself, we now include another node in the ADC snap-in that's called the ADC Tools. This interface is meant to assist in creating your recipient connection agreements because quite often customers would inappropriately create their recipient connection agreements in such a way that it could cause corruption with their directories.

For instance, they might have accidentally converted mailboxes to custom recipients in 5.5. So to get a good consistent creation of all your recipient connection agreements, this ADC Tools interface runs through certain wizards. It scans for your Active Directory and for mail-enabled objects, or really for objects in the Exchange 5.5 directory, and performs a virtual match for a bunch of objects. We also made sure that there aren't any multiple resource mailboxes that haven't been designated as resource mailboxes in Exchange 5.5.

In the Exchange 2000 deployment case, we had a lot of customers not use the NTDSAtrb or NTDSNoMatch utilities. So if there were multiple mailboxes associated with the same primary Windows NT® account, the likelihood increases that ADC performs mismatches, and thereby renames objects that should not have been renamed, and then creates resource objects for the intended primary mailboxes. We'll get into some of the individual wizards in the ADC Tools later, but really quickly, let's go for a review on why we need to use the ADC Tools or, in fact, why we need the ADC service itself (slide 8).

As a quick review, if you have a mailbox that's on an Exchange 5.5 server, then when you log on with your client, typically Outlook®, sometimes Outlook with Access, then the global address list (GAL) that you're reading is actually stored in the Exchange 5.5 directory service. On the other hand, if you have a mailbox on Exchange 2000 or Exchange 2003, then anytime you log on with a client, you pull your global address list from Active Directory, specifically your global catalog servers.

Because there are two separate global address lists, there needs to be some mechanism to keep these directories in sync. Otherwise, you would have mail-flow problems; you would have routing problems because the GALs are not just meant to be able to allow the users to browse and pick and choose their intended recipients, but it also helps out in the routing as well.

This screen shot is about the Resource Mailbox Wizard (slide 9). This is actually one of the wizards within the ADC Tools snap-in. What it does is it helps you designate resource mailboxes. Specifically, in the Exchange 5.5 case, it was not uncommon for customers to configure multiple mailboxes with the same primary Windows NT account, and that didn't cause any problems with Exchange 5.5 by itself. But in Active Directory, because a mailbox is an attribute of a user object, there can only be a one-to-one association for every mailbox to a user object. However, in the Exchange 5.5 case you can have a many-to-one association, where many mailboxes could be assigned to a single NT 4.0 or Active Directory account.

If you don't run the NTDSATTRIB or NTDSNoMatch utilities, or if you skip the Resource Mailbox Wizard instead, you prematurely create and replicate your specific connection agreements. You can possibly encounter a situation where the ADC is going to perform a mismatch.

Let's take this, for example. Right here we have an Active Directory account, or it could be an NT 4.0 account for all we care, but let's say it's a security principal that is associated with three mailboxes here. Right here the Resource Mailbox Wizard has already chosen one particular mailbox to be the primary mailbox. So the distinction between primary and resource mailboxes is that there can only be one primary mailbox per Active Directory account or user account, but there can be multiple resource mailboxes. Resource mailboxes typically are secondary mailboxes that people don't primarily logon to to send and receive e-mail. These would be like conference room resources or mailboxes from old retired users that might have left your company.

In any event, when the ADC runs its matching, it typically reads the 5.5 mailboxes in the order in which they were created in the Exchange 5.5 directory. If your Active Directory account was the primary Windows NT account for the very first match, and if that first match read from 5.5 happened to be a resource mailbox, when the ADC replicates to Active Directory it uploads the 5.5 mailboxes mail-enabling attributes, but it also renames the CN value of your Active Directory account, and that can cause confusion. You would rather have the ADC service match up your primary mailbox with your Active Directory account rather than this resource mailbox.

So, in a nutshell, that pretty much summarizes the need for the Resource Mailbox Wizard, which replaces the NTDSATTRIB and NTDSNoMatch utilities that you might have seen discussed in Exchange 2000 deployment webcasts.

Moving on to the next slide (10), the last step of the ADC Tools is the Connection Agreement Wizard. Basically, you just run through this wizard. It takes all the XML files created from the previous tools run within the ADC Tools snap-in, and it uses the information that was collected from Exchange 5.5 and Active Directory in order to build recipient connection agreements that will perform all of the matching between Active Directory and the Exchange 5.5 GALs.

I am often asked if there are x number of sites, do I need x number of recipient connection agreements? It's much more involved than that, so the answer to that question requires more data. For each site, we must tally up all of the Active Directory domains whose accounts are associated with primary Windows NT accounts for that site's mailboxes, and each site may differ.

In the simplest case we need, really, one recipient connection agreement for each site, if all mailboxes in each site are associated with security identifiers from only one domain in a forest. Pretty often, though, that's not the case and it gets more complicated than that. Because Exchange 5.5 sites contain mailboxes associated with accounts from different domains, the connection agreement takes all that guesswork out of the picture and creates these recipient connection agreements for you. It creates the required number of connection agreements for you in order to have a synchronized global address list between what the 5.5 users see and what the Exchange 2000 and Exchange 2003 users see.

Another common question (slide 11) is, "Can we skip the ADC Tools?" Just like the Deployment Tools question, you cannot skip the ADC Tools if you are joining in a pure Exchange 5.5 site. So what happens if you try to skip the ADC Tools? Later on when you run the Setup program and your intention is to join an Exchange 5.5 site, the Exchange 2003 Setup program is going to block you, and that's because it checks for a completion marker in Active Directory. This completion marker is stamped by some of the Deployment Tools, as well as by the ADC Tools. So if you don't get far enough into the ADC Tools, then you won't be able to stamp this completion marker that the Exchange 2003 Setup program looks for.

Then the last bullet point: You will not be instructed to run the ADC Tools if you are creating a brand new Exchange 2003 organization in your Active Directory forest, but you will be told to run the ADC Tools if you are joining an organization that contains Exchange 5.5 directory services.

Throughout this presentation I've been talking about the different deployment paths. Right here (slide 12), this is a screen shot of the Exchange Deployment Tools Help file that illustrates the four types of deployment scenarios that you might fit. The first two scenarios require the ADC Tools because you are joining Exchange 2003 into an organization that contains Exchange 5.5 directory services.

Now the first option, which is Coexistence with Exchange 5.5, typically means that you don't have an Exchange organization object in Active Directory. So to back up a little bit, you would have an Exchange organization object in Active Directory if you tested an installation of Exchange 2000 or Exchange 2003 and you later tore down that server. Nevertheless, that installation would have left some remnants of that old organization in Active Directory. So if you had some rogue administrators that wanted to do some trials with Exchange 2000 or Exchange 2003, then you need to clean that up. Otherwise, you won't get this screen on the right-hand side when you run the Setup program.

The screen on the right-hand side is only presented if there is no organization object present in Active Directory. Here is where you can choose whether or not you want to join an existing Exchange 5.5 organization or create a brand new organization. Depending on the option you choose, as soon as you go down that path, it's not easy to backtrack and reset yourself. In other words, you can't switch deployment paths in the middle of your deployment process. You actually have to uninstall your servers and then redeploy so that you can get this Installation Type screen on the right-hand side.

The second and third deployment options presented by the Deployment Tools assume that you've already deployed Exchange 2000 into your Active Directory forest. Because Exchange 2000 is already present in your forest, you would not get the Installation Type screen on your right-hand side of this slide when you run Exchange 2003 setup.

The second option, Coexistence with Mixed Mode Exchange 2000 in Exchange 5.5, of course means that you've got a mixture of Exchange 2000 and Exchange 5.5 servers in your Exchange organization, and they are interoperating with each other. They all exist under the same organization. The second option would also apply, even if you no longer have Exchange 5.5 servers, but site replication services still reside on Exchange 2000 servers. Site replication services are basically Exchange 5.5 directory services. They're basically directory application bridgeheads for 5.5, but with their existence that still means that there is a 5.5 directory service in your organization.

The third option is actually quite simple. It's a lot more simplified because you're not dealing with Exchange 5.5 at all. If you choose the third option, then you get a list of steps to join or upgrade an Exchange 2003 server into your Exchange 2000 organization. The description of the link is a little bit misleading. You can choose the third option if you are not yet in native mode. So if you're running Exchange 2000 in mixed mode, but you don't have any Site Replication Services (SRSs), nor do you have any Exchange 5.5 directory services, then you can choose the third option.

The fourth option is the simplest of all. The fourth option simply creates an organization object in Active Directory, and you can install Exchange 2003 clean and fresh. There aren't as many prerequisite checks for the fourth option.

Some things to keep in mind when you are joining Exchange 2003 into an organization to create a mixed organization is that Exchange 2003 is going to join an Exchange 5.5 site (slide 13). In other words, they will be replication partners with each other. Exchange 5.5 will know about Exchange 2003 and vice versa. So you get all of the advantages and benefits of the intra-organizational messaging and collaboration features, such as sharing calendars with other users that reside on other 5.5 servers.

On the other hand, if your installation option is to create a brand new Exchange organization (slide 14), then what happens is your Exchange 2003 server gets installed into its own organizational object and its own site. So even if you give the same organization names and the site names as the Exchange 5.5 server, they still will be separate. They won't know about each other; they won't be able to easily interoperate with each other. There are quite a few disadvantages to this scenario if your intention is to migrate from Exchange 5.5.

If you are looking at this next slide (15) when viewing the archived version of this WebCast, I must apologize in advance because you won't be able to see the animation in this slide. So if you are looking at the archived version of this WebCast, please download the PowerPoint® file so that you can see the diagram as well as the animations. In any event, I'm going to proceed here and discuss the specifics of this slide.

Basically, this is a diagram of all of the steps that the Deployment Tools Help file guides you through. So as soon as you insert your Exchange 2003 CD you get this splash screen, and the splash screen has a link to start running the Deployment Tools process, which then leads you into this Help file. Again, I apologize. The animation doesn't seem to be working on the slide. Eventually, when you run through the Help file, you get to the large decision-making point, where you get to choose which scenario you think applies to your situation. The most comprehensive and the most complex deployment path is the option for coexistence with Exchange 5.5.

In this scenario, we have you run tools that will check for the operating system versions, run a deployment tool called DSScopeScan, which scans for poorly service packed Exchange servers or Active Directory servers, and then we have you run NetDiag and DCDiag. Then we have you review the output of those support tools for any errors that could potentially cause unforeseen problems later on with the Exchange 2003 Setup program.

Eventually you complete the ADC Tools and run some more checks, and then when it comes time to run the full-blown Setup program, you get a screen, the Installation Type screen. If your intention is to join an Exchange 5.5 organization, but you end up clicking Next throughout the entire setup process, you can inadvertently choose a different option, which is to create a brand new Exchange organization. So this way, you won't be able to easily migrate from Exchange 5.5 if you choose the wrong option.

So please keep in mind to click the second option, which is the Join … an existing Exchange 5.5 Organization. Failure to do so would cause you to create a brand new Exchange server that is totally and completely separate from Exchange 5.5, and once you go down that path your deployment features are limited.

Let's just go through some quick review here (slide 16). Some properties of the mixed mode organization, when you choose to join an Exchange 5.5 organization, are that the Exchange 5.5 organization object gets grafted into Active Directory. Eventually, after you install what happens is that all the servers that are known to the Exchange 5.5 directory get written to Active Directory. So they share not only the same global address list, but the Exchange 2000 and Exchange 2003 servers know about the same servers. If you choose this deployment path, which is to join an Exchange 5.5 Organization, then you basically have the most amount of documentation here. You get the step-by-step walk-through that's provided by the Exchange Deployment Tools Help file.

Some more properties (slide 17) of the mixed mode organization are that you have built-in features that allow you to move mailboxes quite easily. Just like moving mailboxes from Exchange 5.5 to another Exchange 5.5 server, this is a true move mailbox from one Exchange server to an Exchange 2003 server. We also maintain single instance storage when you move mailboxes. Actually, you maintain some degree of single instance storage; it's not completely 100 percent, but you also retain rules and permissioning on your folders.

This mixed mode organization, as you might have seen in previous WebCasts, is also nicknamed the "standard deployment" method, and it's also called the "move mailbox" method. Again, another name for this scenario is the "coexistence with Exchange 5.5" scenario, which is what the Deployment Tools Help file calls it.

Another advantage of this deployment method is that your Outlook profiles are automatically updated. Let's take the case where you have a full-blown MAPI client that connects to an Exchange 5.5 server. In that client's registry, there is a pointer to that Exchange 5.5 server. If the administrator then moves that mailbox to another server, say Exchange 2003, then the next time the client logs on, his registry entry still points to the old Exchange 5.5 server. The 5.5 server, in turn, will redirect that Outlook client to the new home mailbox server of that user's mailbox. So then the registry on the Outlook client automatically gets updated. All this is seamless to the user, and that is because the Exchange 5.5 server knows about the new location of the moved mailbox.

PFMigrate is a script that is included in the Deployment Tools Directory on your Exchange 2003 CD. It is used to ease migration of public folder replicas. Also, another feature is that your public folder permissions are retained.

I am mentioning all these advantages because I'm going to also talk about the other deployment method later on, in which a lot of these features are not retained. Again, you have a shared global address list with this mixed mode organization-type deployment. You also have shared calendar and you can make use of delegates and such. So you can choose this deployment method if you want long-term coexistence between Exchange 5.5 and Exchange 2003. Lastly, global address list updates — I already reviewed this — but global address list updates are handled by the Active Directory Connector using intra-organizational recipient connection agreements.

On the other hand, if you chose to create a brand new organization (slide 18), even though your intention is to migrate from Exchange 5.5, then what you get is a completely separated server, and it knows nothing of your Exchange 5.5 organization. You can still migrate. This method is really meant for small- to medium-size organizations who want to do very quick migrations, and they don't want to spend any time coexisting with Exchange 2003 and Exchange 5.5. Of course, they would also use this deployment path if they were not migrating from any mail system at all.

Some properties (slide 19) of this new organization deployment are, of course, the Exchange 5.5 server has no knowledge of Exchange 2003, and Active Directory has no knowledge of Exchange 5.5. The global address lists are separated, so when you want to send a message to a user and you're on Exchange 2003 and you want to send a message to an Exchange 5.5 recipient, you won't be able to pick them out of the global address list, and there is no built-in replication mechanism.

Now in Active Directory, you can create contact mail-enabled contacts representing objects in the other organization. There are some third-party tools that can help populate your Active Directory with contacts, but these are not true mailboxes. Typically, they are just SMTP addresses that point to external e-mail domain names, representing 5.5 users in the other organization.

In addition, if you want a complete bi-directional replication, you have to create custom recipients in the Exchange 5.5 directory. So again, you would probably need to use scripts or third-party utilities, or identity integration services to automate the replication of the global address list. But in doing so, you introduce another level of complexity, and even if you get the directories in sync using these other utilities, you also have to manage who owns the SMTP domain names. So if you are migrating and you want the same SMTP domain name to be known between both Exchange organizations, it's a little difficult to get them to interoperate with each other because the two organizations will think that they are authoritative for that e-mail domain name. So you have to go through additional configurations in order to get these two separate organizations to work with each other.

Some other disadvantages of having two organizations in the midst of coexistence or migration is that there is no built-in public folder migration feature. So what you typically need to do is export your public folders to PSTs, and then attach that PST to a mailbox that is connected to the target Exchange 2003 organization, and then upload those public folders. This process is not only time-consuming, but you also don't retain any permissions on those public folders.

Since we don't have the built-in Move Mailbox feature, the mailbox migration tools of choice here are the Migration Wizard or the Exmerge utility. These are pretty straightforward tools. They don't do true migrations in that they don't perform true movements of mailboxes. They basically copy out data from one server and import it into the target server. In using these tools you lose single instance storage, and as soon as the user logs on to their brand new mailbox, they have to re-create their rules if they depended highly on those rules.

They also need to update their Outlook profiles manually. Because their old server knows nothing about the new server, which contains their moved mailbox, the old server will not redirect the Outlook client to the new server object. So the users need to manually configure their Outlook profiles themselves and enter the name of their new Exchange 2003 server. There are some things that you can do to work around that, though they're usually not as pretty. One common trick is to create a logon script that would edit the registry of all of these Outlook clients every time the users logged on.

Some other things to keep in mind (slide 20) with respect to Exchange organizations are that there can only be one Exchange organization object per Active Directory forest. An organization object contains all of the Exchange 2003, Exchange 2000, and Exchange 5.5 server information that is stored in Active Directory. You cannot have more than one organization per Active Directory forest.

Additionally, your Exchange organization cannot span multiple forests. What does this mean? You have a bunch of Exchange 5.5 sites that are connected via directory replication connectors that form a sort of chain, and then you deploy Exchange 2003 into different sites that are a part of that Exchange organization. It is possible for you to join an Exchange 2000 server or an Exchange 2003 server into those sites. But if the server you installed on resides in a different forest from the other Exchange 2003 servers, then you eventually have mail flow and replication problems. This is what is called backboning Exchange 2000 or Exchange 2003 servers across a 5.5 backbone.

In other words, we use the Exchange 5.5 directory application connectors and the 5.5 topology to get multiple forests to join an Exchange 5.5 organization, and that, unfortunately, is not going to work. You will have long-term problems if you try to migrate that route. In summary, make sure that all the Exchange 2000 or Exchange 2003 servers that are in a mixed mode organization come from the same Active Directory forest.

Now I'm going to move on to the setup of related changes (slide 21). In this slide, I talk about the need for your ADC services to be upgraded or removed when you install an Exchange 2003 server. That's because the Exchange 2003 setup process is going to search for any registered Active Directory Connector services that have been installed into your forest.

The reason for making this prerequisite check is that there have been previous versions of the Active Directory Connector. There was one that came with Windows, and then there was the release Exchange 2000 version, the ADC, and then subsequent service pack versions of the Active Directory Connector. The Exchange 2003 CD also comes with its version of the Active Directory Connector.

To control the version that you guys use, please install the Exchange 2003 version because there have been problems in the past with the old versions of the ADCs, specifically the Windows 2000 ADC. If you use it, it can cause corruption on public folders and older versions of the Exchange 2000 ADC service can cause problems with mailbox permissions being stripped or mailbox objects being converted into custom recipients.

Basically, to satisfy that setup requirement, find all the ADC services in your organization. Once you're on that machine, you can insert the Exchange 2003 CD, go to the ADC directory, run the Setup program, and the option that you would choose is to reinstall. The reinstall is actually a misnomer. It's actually doing an upgrade behind the scenes.

If you no longer need the Active Directory Connector, then you can go ahead and remove all of them from your organization. First of all, you need to decommission all the Exchange 5.5 directory services because if you still have 5.5 around then that means you still need the ADC service. If you don't have Exchange 5.5 around, the next thing you need to do is check to see if the version of the ADC that you've got installed is from the Exchange 2000 CD version or if it's a post-Exchange 2000 CD version.

If it's a post-Exchange 2000 CD version, and you can tell that by going into the properties of the ADC executable under Program Files\MSADC folder, if you go to the properties of that file and then click on the File Version tab you can actually get the build number. If that build number is greater than 4417, then you can run the Edsstub.exe that resides in the same directory as that ADC executable. The Edsstub utility is basically the ADC Setup program and you can remove it without any problem.

However, on the other hand, if the ADC build number is 4417, then that is the Exchange 2000 CD version. You don't want to uninstall using the Exchange 2000 CD because it not only removes ADC service, but it also removes a certain container from Active Directory that we'd prefer for you to keep in there. To work around that, find some service pack level of the Exchange 2000 server that includes the ADC folder, and then just run the ADC Setup program from that archive and then click the Remove option.

Another new feature of the Active Directory Connector (slide 22) is that the ADC service randomizes user logon names. Now don't worry; it doesn't affect your existing accounts. What happens is that any time the ADC looks at a 5.5 mailbox and looks at the primary Windows NT account, if that primary Windows NT account SID matches an object in Active Directory that contains the same object SID or SID history, the ADC will never randomize your samaccountname or your user logon name. It will basically just upload mailbox-enabling attributes to your existing account.

However, in the case where the ADC cannot perform a match, say for instance, your account in Active Directory is already associated with another mailbox, then what happens is the ADC needs to create a placeholder-disabled account in Active Directory. This placeholder-disabled account not only contains the mailbox attributes, but in the Exchange 2000 case, it inherits its user logon name from the Exchange 5.5's mailbox alias.

In the Exchange 2003 ADC case, we will randomize the same account name because you're not going to enable this account and use it for logon purposes. Basically, this placeholder-disabled account is meant to complete the global address list that is used by Exchange 2000 and Exchange 2003 users.

An example of a randomized user logon name created by the ADC service is listed here in the middle of this slide. The purpose of randomizing these account names is to prevent conflicts with future account migrations. Say, for instance, you run the ADC first, and then later on you go about running a migration tool, say from NetIQ, or if you use the Windows Active Directory migration tool to migrate user accounts from NT 4.0 to Active Directory. Then with this randomized logon name, you won't run into any user account conflicts. Whereas in the Exchange 2000 case, the same account name of that generated account would conflict with the Active Directory migration tool, so then ADNT is going to end up creating the user logon name with the dash one (-1) appended to the end.

A quick trivia question for you: How do new users memorize their new logon name, after the ADC creates the user accounts? That's actually a trick question. You should never ever enable these disabled accounts. Again, they're just placeholder accounts meant to fulfill the global address list in Active Directory, so that the Exchange 2000 and Exchange 2003 users will see a consistent global address list with the Exchange 5.5 users. The ADC is not meant as a user migration tool. It's just meant to synchronize the global address lists.

What's the upgrade order (slide 23) if you want to upgrade an Exchange 2000 organization to Exchange 2003? Because of that prerequisite check for the ADC services that I mentioned before, you need to first upgrade all of your ADC services in your forest, and then later on you need to upgrade your front-end servers. The reason you want to upgrade your front-end servers to Exchange 2003 before your back-end servers is because having an Exchange 2000 front-end accessing an Exchange 2003 back-end results in a really bad Outlook Web Access (OWA) interface, and that's not supported. The Setup program detects whether or not you're installing an Exchange 2003 server into an administrative group that contains Exchange 2000 front-end servers. Again, you'll hit a prerequisite check, so you'll want to make sure that you upgrade your front-end servers before your back-end servers.

Lastly, you can go about upgrading all of the workstation machines that happen to have the Exchange System Management components installed from Exchange 2000. You just insert the Exchange 2003 CD on those Windows 2000 or Windows XP machines, and then just run reinstall. That upgrades the Exchange System Management components, and it won't install the server components on those workstations.

Another common question is, can we have Exchange 2000 running on Windows 2003? The answer is no. Windows 2003 is going to actively disable Exchange 2000 store process or, actually, the IFS driver. So if you want to upgrade your operating system that runs Exchange 2000, you have to upgrade the Exchange version first. The first step, when you have Exchange 2000 on Windows 2000, you want to upgrade to Exchange 2003, and then for some period of time you have Exchange 2003 running on Windows 2000. You can keep it running this way — it's not a problem. Exchange 2003 works fine with Windows 2000.

I apologize for this slide here. The second part at the very bottom, where it says "Upgrade Windows," it should say Exchange 2003/Windows 2000 → Exchange 2003/Windows 2003. That would signify where you would upgrade the operating system after you've upgraded the Exchange version.

Note Slide 23 has been corrected.

Again, earlier I mentioned that the Setup program has a prerequisite check (slide 24) to make sure that there aren't any front-end servers that are running Exchange 2000. If there are, the Setup program is going to block you, but again, this check is only done within the local administrative group.

There is a workaround in that you can possibly install an Exchange 2003 server, if it's in a different administrative group, and still have your clients access the Exchange 2000 front-end server to get to their back-end Exchange 2003 servers. If you go that route, then it's unsupported and you get a pretty ugly OWA interface, as you see in the screen shot here.

We're often asked what if you upgrade your Exchange 2000 front-end servers to Exchange 2003, and then use that front-end to access Exchange 2000 back-end mailboxes? In that case, you still get the old interface. The only instance where you would get the new and improved OWA interface is if both the front-end and the back-end servers are upgraded to the Exchange 2003 version, or if the clients access the Exchange 2003 back-end server themselves, rather than going through the front-end.

Another new feature of Exchange 2003 is that now we allow the Standard Edition of the product to become a front-end server (slide 25). A well-known fact is in Exchange 2000 only Enterprise Editions can become front-end servers. However, this does not mean that you can upgrade an Exchange 2000 front-end server to become an Exchange 2003 Standard Edition front-end server. That's been a limitation of all previous versions of Exchange as well. You can't upgrade a more fully featured version of Exchange, such as the Enterprise Edition, to a less featured version of Exchange, such as the Standard Edition. So I documented that behavior in the bottom of the slide in this chart here. You can go from Standard to Standard, from Standard to Enterprise, and from Enterprise to Enterprise, but you cannot go from Enterprise to Standard.

We introduced some components into the Exchange 2000 version that have been discontinued in Exchange 2003 (slide 26). So when you run the Exchange 2003 Setup program, these will no longer exist in the component selection screen when you add and remove individual Exchange components to install.

The Instant Messaging component has been decommissioned, as has the KMS service. Also, we no longer include the Chat components. If you want to retain these features, then you need to keep an Exchange 2000 server running in your Exchange 2003 organization, and it will not have any problems coexisting. These features of these components are now available in the Office Live Communications Server product. KMS is also replaced by the features of the Windows 2003 Certificate Services.

One other thing to note that's not included on this slide is if you are in-place upgrading an Exchange 2000 server that has these decommissioned components, then the Setup program is going to block you until you uninstall these components. That's because the Exchange 2003 setup process doesn't know how to handle upgrading these components.

Now we're going to discuss changes made to the local system when you install Exchange 2003 (slide 27). The old version, Exchange 2000, automatically configured IIS to include a new virtual directory called Exchange, and having this /Exchange virtual directory allowed you access OWA. The OWA interface has quite a lot of features. In Exchange 2003, we now create a new virtual directory called OMA for mobile devices and handhelds to be able to access a scaled-down version of OWA. If you want to get some more information about the features of Outlook Mobile Access (OMA), refer to another WebCast, 819270.

Some other changes (slide 28) made to the system are that the M drive has now been hidden. In Exchange 2000, the M drive was available and it represented the Web storage system. You could actually, if you wanted to, use Explorer to browse through the M drive and access some folders, such as public folders, and if you had mailbox permissions, you could go to other people's mailboxes.

However, this was not a very good idea because what happens is we had a lot of customers accidentally changing NTFS permissions through the Explorer interface, and that corrupted the way Exchange stored its ACLs on these mailbox resources. Additionally, some other corruption that was caused by antivirus software that was file-based. If you have file-based antivirus software that scans the M drive, or if you have backup programs that back up the M drive, then you have some more item-level corruption happening in your store. So in Exchange 2003, to avoid all of that corruption we now hide the M drive.

We also changed the maximum hop count on brand new installations. The hop count is a threshold that tells servers how long a message can bounce between servers. This is used to determine whether or not a message might have been looping. Nowadays, with the proliferation with gateway-level antivirus scanners or spam filters, we have a lot more servers touching messages as they traverse across the Internet. The maximum hop count in Exchange 2000 was 15, so even legitimately routed messages could have been returned as non-delivery reports, just because it went through too many scanning servers. So we increased the maximum hop count to 30.

Another change that's security related is that the authenticated users group is unable to log on locally. Also, we removed their ability to log on through terminal services. If you ever tried to log on to a domain controller using a regular domain user account, then you typically would get denied. That's because domain controllers are supposed to be more secure than regular member servers. In Exchange 2003 we're trying to make the mail servers a little more secure, as domain controllers are.

In Exchange 2000, we had no message size limits. So, potentially, if you had lots of messages coming in from the Internet, a malicious user could possibly send tons of messages with huge attachments and fill up space on your Exchange server and no one would be the wiser until the store stopped because it ran out of disk space. Now we set a default message size limit on inbound SMTP messages to, I believe, 10 megabytes (MB).

Also, by default, we disable the Internet protocols NNTP, POP3, and IMAP4. Now you can very easily enable them again. Just go into your services snap-in and change the service state from disabled to automatic or manual, if you desire. We changed this because we realized that not as many users were using these Internet protocols connecting to Exchange 2000 servers using Outlook Express. More and more users were using the full-blown Outlook that uses the MAPI interface. Also, with the disabling of these Internet protocols, we have less surface area of denial of service attacks for Exchange 2003 servers.

Another change that we made that's somewhat security related is that we remove the ability for just any plain old user to create top-level public folders. If you've ever administered Exchange 5.5 or Exchange 2000 and allowed your users to run amok in creating top-level public folders, it became quite difficult to administer all those public folders. So they are no longer allowed to create top-level public folders in your hierarchy.

Lastly, message tracking logs; the Message Tracking Log share is more secure. You typically use this if you enable message tracking, and you want to check to see what path the message took when it was received or sent from your Exchange server. In Exchange 2000, anybody could access that share. In Exchange 2003, we automatically lock it down now.

I've listed some miscellaneous items here (slide 29) that didn't seem to fit in the other slides. The /chooseDC switch is a new switch, similar to /forestprep. You can add to the end of the Setup program when you run the setup from the command line. The /chooseDC switch is typically used if you are deploying Exchange 2003 into a branch office scenario, and suppose that branch office had a local domain controller. When you run Exchange 2003 without any switches, the install process would pick any domain controller arbitrarily and you had no choice there. In Exchange 2003, if you specify a particular domain controller using the /chooseDC switch, you can specify a local domain controller as opposed to a remote one that the Exchange Setup program would automatically choose for you, and that can save quite a bit of bandwidth and will get your Exchange 2003 server installed a little faster.

In Windows 2000, Exchange 2003 also automatically installs ASP.NET in the .NET Framework. In Windows 2003, ASP.NET is available through Add and Remove Programs. That's actually a prerequisite and you need to add ASP.NET to Windows 2003 before you install Exchange 2003, but in Windows 2000, the Exchange setup process adds that for you.

I mentioned earlier about the PFMigrate utility. I can go into a little more detail here. PFMigrate is a script file. You use it to specify a source server and a target server, and all it does is it modifies replicas. You can use it to automate adding replicas to a new server that you've recently deployed, and that would be, of course, your target server. So the PFMigrate script consists of a source server and a target server, and it compares all the folder replicas that exist on a source server and the target servers, and those that aren't in common can get added to the target server. Again, these are changes to replicas. So, after the replicas have been added, you need to wait for the background public folder replication process to complete before decommissioning the replicas from your source server.

This slide here is just for your reference (slide 30). In Exchange 2003, we have some slight modifications to the permissions framework, in that you don't need to require as many permissions now when you run certain setup actions. You can refer to this table, which will eventually be written into a Knowledge Base article regarding the individual setup actions that require certain permissions. If you don't meet those permissions, then you will get blocked from running setup.

That pretty much concludes the presentation portion of our WebCast for today. I'm going to hand this back to Marilyn, who's going to read some questions that have submitted to us.

Marilyn Loftus: Thanks for the presentation, Vincent. Before we move into the Q&A portion of the Support WebCast, I'd like to share a couple of quick program notes with our listeners. If any of the details of the PowerPoint slides were difficult to view in your browser today, or you would simply like to have a copy of the slides, they are available to download now from the Web site, which is http://support.microsoft.com/webcasts/. Also, if you would like to review the content again, this is where you'll be able to find the on-demand streaming media.

The Q&A portion of the Support WebCast is intended to encourage further discussion of today's Support WebCast topic. In addition, one-on-one product support issues are outside the scope of this Support WebCast. If you do find that you need some more complex technical assistance, please feel free to submit an incident on the Web, or call Microsoft Product Support Services directly and speak to a Support Professional. So on to the questions.

The first question is: Will introducing Exchange 2003 preserve custom permissions that we set in our native Exchange 2000 configurations?

Vincent: Most of the time, yes. The Exchange installation process is going to change some global settings, such as the hop count and, I guess, the message size limits to 10 MB. Most other permissions, such as permissioning on public folders and such, they won't get modified at all.

Marilyn: The next question: What about NoMatch on aliases?

Vincent: I'm confused about the terminology. You would use NTDSNoMatch when there are multiple mailboxes assigned. You can also use it with custom recipients because you can assign a primary Windows NT account to a custom recipient. So if multiple 5.5 objects are associated with an Active Directory or an NT 4.0 account, then you would want to designate the NTDSNoMatch value on Custom Attribute 10 of pretty much all of those 5.5 objects minus one, and that minus one would indicate the primary mailbox for that user.

Marilyn: The next question: If you have an Exchange 5.5 server and installed an ADC, can it be removed after you're in your native mode for Exchange 2003?

Vincent: It depends on what you did. If you actually installed Exchange 2000 or Exchange 2003 into its own Exchange organization, then really there is no need for your Active Directory Connector. If, however, you did join Exchange 2000 or Exchange 2003 into a 5.5 organization and then you went about decommissioning 5.5, then you can uninstall your ADC, but you cannot uninstall your ADC until after the very last Exchange 5.5 directory service has been removed from your Exchange organization.

Marilyn: Then next question: What and where are the completion markers discussed in the "Can I Skip ADC Tools" slide?

Vincent: I'm not advocating that anybody should go about in stamping those objects manually. But if you really want to know, if you open up ADSIEdit or LDP, or whatever LDAP editor you prefer, navigate down to the Configuration container, and then navigate underneath Configuration Services, and then there is a Microsoft Exchange container. So that Active Directory object container, that Microsoft Exchange container, if you go to the properties of that there is a description field. It's that description field that's multivalued, so all of the completion markers get stamped there. Again, I would strongly recommend that you do not mess with that description container attribute yourself.

Marilyn: The next question is: I remember in the beta that there were two attributes in Exchange 2000 that had to be manually changed for some reason; one was secretary. Is that still the case?

Vincent: I believe this question involves the mangled attributes discussion. You no longer need to manipulate these, if that's what you were asking about. That's because the Exchange 2003 schema already includes the InetOrgPersonFix.ldf attributes. If, however, you did run adprep /forestprep from the Windows 2003 CD, then you will need to do some level of fixing up. Refer to that Knowledge Base article in the presentation for more details about which ordering of steps that you've done, how to search on those mangled attributes, and learn exactly what you need to do to fix them.

Marilyn: The next question is: If the servers are on the same site, is the redirection of the client setting or has that changed?

Vincent: If two servers are in the same site, then after you Move Mailbox the redirection happens, I believe, only once. So when the Outlook client contacts the old mailbox server, the old mailbox server knows about the new mailbox server and is going to redirect just that one time, and then that registry change is made at the client computer permanently. So any subsequent Outlook connections will go directly to the target, the new mailbox server, and not the old mailbox server.

Marilyn: When an Exchange migration is done between two organizations, and a new organization is created inside the old one, why is it preferred to completely re-create user Outlook profiles instead of just changing the server name? What are the resources that might have problems if profiles are not re-created?

Vincent: That's a little more detailed and probably needs to be addressed by an Outlook expert. To my knowledge, you don't need to re-create the whole entire profile. I believe you can simply change the server name yourself. But that question can probably be more fully answered by an Outlook expert.

Marilyn: What is the most current build version of Exchange 2003?

Vincent: The release version was 6944.4, and we don't yet have a service pack for Exchange 2003. If you've ever seen 6940, and if you look into your Exchange System Manager and look at your Service container, if you see the old 6940, then that means that you've got Release Candidate 1 installed.

Marilyn: The next question is: How do you upgrade a trial version of Exchange 2003 Enterprise to the retail version? Do you simply reinstall it?

Vincent: It depends. If you bought the retail version and it happens to be the Enterprise Edition, then you can go ahead and insert the Exchange 2003 CD, and when you run setup you won't get an option for upgrade, but you will get an option to reinstall. That will reinstall the retail versions of all those files for you. However, if you purchased a Standard Edition of Exchange 2003 and you want to reinstall, even though you've got the Enterprise Evaluation version of Exchange 2003 on your system, then you need to uninstall first and then install brand new.

Marilyn: The next question: What if you don't want to upgrade your front-end server? Say you want to install a fresh install of Windows Server 2003 and Exchange Server 2003. Is there a supported workaround?

Vincent: One workaround that you can do that will bypass the Setup program is to temporarily uncheck (click to clear) the check box on your Exchange 2000 front-end servers, and then when the Exchange 2003 Setup program runs it won't detect that you've got front-end servers. Then after the setup completes, you can then check (click to select) the front-end check box again for the Exchange 2000 Server.

That's not recommended, and if you do that you will encounter an unsupported scenario if the clients try to access the Exchange 2003 back-end server through the front-end.

Marilyn: What is the preferred installation order in Exchange 2003 migration from Exchange 5.5? Is it to first run setup, Forestprep then setup, DomainPrep, and only after this install the ADC?

Vincent: If you're talking about integrating with Exchange 5.5, then you really need to run the Forestprep and the ADC Setup, but it doesn't really matter which order that you run them in. You just need to run both of those before running the full-blown Setup program. Typically, we would have customers run the ADC Setup program first, and then Forestprep, and then the DomainPrep, and then the full-blown Setup, which installs all of the server binaries.

Now in Exchange 2000, if you ran just plain old Setup, it would automatically set Forestprep and DomainPrep to automatically install for you. So potentially, if you have a very small organization, just running Setup would run all of those switches under the hood. But in Exchange 2003, we now have you explicitly run those setup commands separately.

Marilyn: I'm upgrading Exchange 2000 native mode to Exchange 2003. I chose the upgrade option from the Setup program. What is the difference between the Reinstall and the Upgrade option?

Vincent: If you chose Upgrade, then that means that the server binaries that are installed on your system already are older than the DLLs on the CD to which you're upgrading. If you chose Reinstall, then that means that the media that you're installing with matches, or is lower than, the version of the binary files installed on your Windows system.

Marilyn: If I have a mixed Exchange 2000 and Exchange 2003 environment, and I've updated my OWA front-end servers to Exchange 2003, will the Exchange 2003 users see the new OWA interface?

Vincent: Again, refer to one of those slides that I showed you before. If your front-ends and your back-ends are Exchange 2003, then the users will be able to see the new OWA interface. If the front-end is Exchange 2003, but the back-end server where the mailbox resides is still Exchange 2000, then you still get the old Exchange 2000 interface.

Marilyn: The next question is: The cluster installation documentation for Exchange 2003 starts with the clustering of MSDTC Comclust. What is the MSDTC required for in Exchange 2003? This wasn't performed in Exchange 2000 cluster installation.

Vincent: We actually have a clustering WebCast; that was our last Exchange WebCast. If you want some more details on MSDTC, I do know that you don't need to run Comclust to create the MSDTC resource on Windows 2003. However, you do it to create it on Windows 2000. In some cases, the Exchange 2000 clustering Setup program won't complete unless you've manually created the MSDTC resource yourself. I don't think I've narrowed it down to which configurations require the MSDTC resource and which don't, but in Exchange 2000 it never hurts to have the MSDTC resource. If I'm not mistaken, it's used to register some COM components during the setup process.

Marilyn: The next question is: I am using the PFMigrate script to migrate the public folders. When I run the "/R" it shows two public folders, but when I run the PFMigrate with a "/A" it just brings up the Help for PFMigrate and nothing populates in the log file.

Vincent: We can probably go into more of a discussion on this, but just right off the bat, at least from a high-level perspective, when you run the Add or Delete commands or the Report command, which is /R, you need to specify a target and a source server. Failure to specify all those parameters will not allow you to complete the task. The /R, again, is just a report. If I'm not mistaken, it tells you the differences in the public folder replicas between the target and the source servers. The /A switch requires that you give it a /N switch, which tells the PFMigrate utility the maximum number of public folder replicas, to modify on the target server. So if you use the /A switch and it's not working, then either you're missing the /N switch or the target or the source server in the command line.

Marilyn: The next question is: Approximately how long does the install take, assuming you are migrating into a pure 5.5 organization?

Vincent: If you're talking about all of the steps, including running the ADC Tools and everything, it really varies. If you were joining into a 5.5 organization and your Exchange 5.5 directory is very large, then when you run your ADC Tools it needs to traverse through your entire Exchange 5.5 directory. If your 5.5 sites that the ADC Tools are connecting to are remote, then this, in fact, can take a few hours to run through just the data collection steps itself. But if all of these servers are local and we don't need to talk to anything remotely, then ADC Tools can run very quickly, and the actual Setup program itself, when it installs the binaries and everything, can take between 12 and 30 minutes, in my experience, based on your level of hardware.

Marilyn: The next question is: Are updates from Exchange 2003 Beta 2 and RC1 supported in RTM?

Vincent: No. You can't upgrade directly from Beta 2 or RC1 to the RTM version of Exchange 2003. You have to pretty much uninstall that server and reinstall. You can in-place upgrade from RC1 to the RTM version, the release version of Exchange 2003, just by inserting the CD and choosing Reinstall. But if the installation is prior to RC1, then you cannot upgrade to the release version.

Marilyn: Can the pre-Deployment Tools be run to check things before Exchange 2003 Forestprep is done? Also, why does one of the checks require write access to AD?

Vincent: Yes. The Deployment Tools can be run prior to running Forestprep or any other setup steps. What was the second part of this question?

Marilyn: Why does one of the checks require write access to AD?

Vincent: That's a good question, and I neglected to mention it during the presentation. It depends on which check that you're talking about. If you are talking about DSScopeScan, it's basically read-only from AD and 5.5. In fact, most of the deployment tools are read-only. Some of them, however, do make write operations. I mentioned it's a good question because I wanted to talk a little bit about the PubFoldCheck deployment tool.

That runs a DS/IS Consistency adjustment against the 5.5 public folder stores or public information store for any zombie permissions. (Zombie users are user accounts that are not represented in Active Directory.) So if you've ever deployed Exchange 2000 into an Exchange 5.5 environment, you might have noticed some performance problems when accessing public folders, or maybe your users have been denied access altogether to public folders, where only the owners were able to access public folders. That's because these zombie permissions, permissions that still exist on these public folders that represent user objects or mailboxes that have since been deleted are causing the store to have calculation problems. So the PubFoldCheck deployment tool cleans up all those zombie permissions from the stores.

Some other tools do write to Active Directory. For instance, the ADCUserCheck tool and the ADC Tools, they need to write those completion markers into Active Directory. Otherwise, there is no enforcement, and any rogue administrator who simply runs setup could potentially get away with installing Exchange 2003 in the wrong scenario without doing any research. So to create those completion markers in Active Directory, we need to have write access to Active Directory.

Marilyn: The next question is: If I use PFMigrate to add replicas to a source Exchange 2003 server, how do I know when the content has completed replicating before removing the source replica?

Vincent: That is also a good question. Whenever you complete the PFMigrate command, basically it returns right away at the command prompt. So if you open up Task Manager, because the PFMigrate is a Windows script file, look for a task or a process called WScript.exe. If it no longer exists in Task Manager, then you can pretty much assume that the PFMigrate script has already completed adding the replicas, and then you just have to wait for the contents of those public folders to backfill into the target server.

Marilyn: The next question: Would I be able to move a user from one domain to another domain within the organization?

Vincent: That's basically a Windows question, but I do know a little bit about the MoveTree utility. That utility can be used to move objects, in fact, entire containers from one Active Directory domain to another that reside in the same forest. If you're moving from one domain to another and the source domain happens to be an NT 4.0 domain or an entirely different Active Directory forest, then you can use a utility, such as the Active Directory Migration Tool to migrate the user object, and you can migrate their SID history as well.

Marilyn: The next question: Would you recommend removing an Exchange 2000 server that is not being used to Exchange 2003 or just perform an upgrade?

Vincent: If you're not using that Exchange 2000 server and you are unsure of its stability or you think you've configured it incorrectly, then by all means, please go ahead and remove it using the Exchange 2000 uninstall process. What you'd be looking for within that uninstall process is a little textbox that says that the Setup program is going to remove the organization object from Active Directory. If you don't see that textbox, then that old Exchange 2000 org object is still going to reside in Active Directory, and potentially can cause problems with your new Exchange 2003 installation.

In this case, you might want to make use of the /removeorg switch. If you just go to our Support Knowledge Base and type removeorg and exchange, then you can get usage for the /removeorg switch. That cleans up that old rogue organization object that you used to have, to pave the way for a brand new fresh and clean Exchange 2000 organization object.

Marilyn: The next question: Is there a benefit to upgrading the AD 2000 native mode domain to 2003 before Exchange 5.5 2003 upgrade? Is there a benefit to upgrading this domain afterwards?

Vincent: You're talking about upgrading the domain functional levels, and from memory I don't foresee any major advantages. Now if you upgrade to the Windows 2003 functional level for your forest, then you gain the ability to create mailbox-enabled InetOrgPerson objects. The InetOrgPerson objects are very similar to user objects, except these objects of this class don't login to your domain locally. Instead, they're usually just Internet-facing type user objects. Typically, only hosters would create objects of class InetOrgPerson. That's basically the only advantage there.

There is a disadvantage. If you're only using Exchange 2000 and you upgrade your forest to Windows 2003 functional level, then what happens is you enable the Linked Value Replication feature. So when linked values get replicated between domain controllers, only the changes replicate rather than the whole entire attributes themselves.

One example is like a distribution list. If you change the membership of a distribution group or a security group and it happens to have 5,000 users, in the old behavior, with Windows 2000 AD, is that it would replicate the whole entire membership list again, and that can cause some saturation on the over-the-wire bandwidth. In Windows 2003 functional level, only the changes replicate between domain controllers.

Now the problem comes if an Exchange 2000 version of the ADC service still exists that knows nothing about linked values. So what happens is the Exchange 2000 version of the ADC service can potentially not replicate group membership to distribution lists. So your distribution lists in 5.5 might have a different list from the corresponding group in Active Directory. So bottom is if you still have Exchange 2000 and you're using the Exchange 2000 version of the ADC, make sure that you upgrade your Active Directory Connector to the Exchange 2003 version prior to upgrading your forest to Windows 2003 functional level.

Marilyn: The next question is: Is there an Exchange 5.5 server prior to this?

Vincent: Is there an Exchange 5.5 server prior to this presentation? If you're talking about the versions, yes, there were some older Exchange versions. We had 5.0; we had 4.0, but at this time they are no longer supported.

Marilyn: The next question: Is there a need for at least one DC to be upgraded to Windows 2003 before Exchange is upgraded to 2003?

Vincent: No. Exchange 2003 only requires that it has access to a global catalog server that is at least Windows 2000 SP3 or Windows 2003. So you can still keep all of your DCs at the Windows 2000 level, as long as they are running Service Pack 3 or later.

Marilyn: When you tune an Exchange Server 2003, you need to add the /3GB/USERVA=3030, when you have more than 1 gigabyte (GB) of RAM. Do you also need to change the ESE log buffers as well?

Vincent: I'm going to defer to someone who's more an expert on this question.

Nino Bilic: No, you do not have to increase the buffer size. You could potentially do that for performance reasons, but you do not have to do it. The 3-GB memory tuning that is done in Boot.ini file is a separate thing from buffers that you can set in Exchange after Windows is started up. So the short answer is that you do not have to change the buffers, no.

Marilyn: The next question is: Is there a way to synchronize and share Free/Busy information between trusted but separate forests?

Vincent: There is a way. If you go to the Microsoft.com/exchange site, on the left-hand side there is a Download link, and as soon as you click it you go to another page where you will see the "Tools and Updates for Exchange 2003" link on the Exchange 2003 tab. On that page there is a utility called the InterOrg sync (Inter-Organization Replication) tool. It's also nicknamed Exchsync, and it is used to replicate between different Exchange organizations, not only public folders, but also Free/Busy information.

I mention this only because you said that you have two different forests, and that means you must have two Exchange organizations in those two forests. So because you have two different Exchange organizations, you need to establish some level of directory replication. So if you've already created contacts in one forest that represent mailboxes in another forest and vice versa, then you can go ahead and deploy the InterOrg Free/Busy sync tool to replicate Free/Busy information. The reason I said you need that base level of directory replication with contacts is because the Free/Busy sync tool keys off of external SMTP addresses, in order to match up for those Free/Busy queries.

Marilyn: The next question: In the slide discussing Connection Agreement Wizard (slide 10), it appears that the ADC Tools builds a mesh of recommended ADC connection agreements. If you're already in Exchange 5.5 Exchange 2000 mixed mode and have a number of agreements in place, will the tools recognize them and leave things alone or will it try to modify or replace them?

Vincent: That's a very good question. It will, in fact, try to modify your existing connection agreements. So if you have a very large topology with many recipient connection agreements already created, and you really believe that you have a valid and correct configuration of all your recipient connection agreements, then you do not need to run the Connection Agreement (CA) Wizard.

The CA Wizard, if it detects any custom-made connection agreements, will go ahead and delete them. So to get past the Connection Agreement Wizard, you go ahead and get to that point, but don't run the wizard. Instead, hit the Verify button in step 4, which will verify the validity of your existing recipient connection agreements. If the verify tool determines that you still have some objects that have not yet been replicated, then refer to the XML files and the ADC Tools .log file that are logged into the logging path listed in step 1 of the ADC Tools.

Marilyn: The next question: When DL owners are set now, will the owner permissions happen automatically as they did in 5.5?

Vincent: That's a good question. I'm not sure if I can answer that. We can defer it. We can answer it offline.

Marilyn: The next question: We have an ADC connecting our Exchange 5.5 organization to our Active Directory, but no Exchange 2000 server is installed yet. Can we use the Exchange 2003 Deployment Tools and upgrade the ADC, or do we need to remove the Exchange organization information from Active Directory first and then run the Deployment Tools?

Vincent: You said you don't have an Exchange 2000 installation yet, but you mentioned that you already have an organization for Exchange 2000 in Active Directory. This probably means you've already run the forestprep command from the Exchange 2000 CD. In this case, if you want to move on to Exchange 2003, you don't need to undo anything that you've already done. You can go ahead and run the Exchange 2000 Setup program — of course, make sure that you upgrade your ADC first — and you can keep your existing recipient connection agreements.

Marilyn: The next question: We noticed the response of OWA was slow after the upgrade to Exchange 2003. What is the reason?

Vincent: For that, we would need a lot more details than that. That might be best handled if you opened up a support incident, and one of our Exchange connectivity specialists can assist you with that.

Marilyn: In addition to that question: Only front-end servers are Exchange 2003 with Windows 2003, and back-end servers are Exchange 2000 with Windows 2000. Users complain that the response is slow. Is this the information they need to give to the Support Professional?

Vincent: Yes and the Support Professional will probably start off with some other troubleshooting to narrow it down to see whether or not it is the new Exchange 2003 front-end server. One thing you can do is access OWA directly to the back-end server while you're connected locally, and see if performance is improved. If not, then it's not due to the new Exchange 2003 installation.

Marilyn: The next question: What is the upgrade path to upgrade an Exchange 2000 cluster to an Exchange 2003 cluster?

Vincent: That has been discussed in the previous WebCast. So if you want more details on that, refer to Evan Dodds's and Allen Mock's "Clustering Microsoft Exchange Server 2003" WebCast. If you want a quick answer, you need to make sure that you upgrade the binary files. In other words, upgrade the Exchange files on the passive node first, then you fail over the group to the passive node, and then you upgrade the virtual server group. This upgrade process is actually new in the Cluster Administrator, as soon as you get the binaries installed on that node. Now that your old active node is now a passive node, then you go about upgrading the binary files on that just by inserting the CD and choosing Reinstall.

Marilyn: The next question: Will PFMigrate /R switch return all replicas, even if they are in different 5.5 sites or admin groups?

Vincent: No. PFMigrate just compares the replicas between a target server and a source server. It does not give you any information about public folders that have replicas on other servers in other admin groups or sites.

Marilyn: The next question: Are there some best practices available to rehome public folders in Exchange 2003?

Vincent: It's basically the same as in Exchange 2000. I think we can provide some Knowledge Base articles and possibly some white papers offline.

For information about migrating public folders, see following Knowledge Base (KB) article:
288150 "XADM: How to Rehome Public Folders in Exchange 2000"

If you have thousands of public folders, it might be easier to use the PFMigrate tool to perform the public folder migration. For more information, see the following KB article:
822895 "Overview of the Public Folder Migration Tool"

For information about how to migrate system folders, see steps 1 through 10 in the following KB article:
822450 "How to Remove the Last Exchange Server 5.5 Computer from an Exchange Server 2003 Administrative Group"

Marilyn: Why is there no more Exchange Home Server for public folders with Exchange 2003 server? How can I be sure the public folders are correctly replicated on each site? Is PFInfo tool compatible with Exchange 2003?

Vincent: That we'll probably have to follow up offline as well.

Follow-up information: Unlike in Exchange Server 5.5, you do not have to set a home server for a public folder in Exchange Server 2003. Any replica acts as the primary replica of the data that it holds, and any public folder server can be removed from the replica list. You can refer to Knowledge Base article 822895 "Overview of the Public Folder Migration Tool."

Marilyn: When will the Exchange 2003 Resource Kit be available?

Vincent: That, unfortunately, I do not know the answer to. So again, we'll have to follow up offline.

Marilyn: We have a Mobile Information Server installation with the auxiliary topology. Is there any migration path from this setup to the built-in mobile features of Exchange 2003?

Vincent: That's a good question. This is another prerequisite check that the Exchange 2003 server makes. If Mobile Information Server (MIS) or any of its components is installed on the local machine, the Exchange 2003 setup process is going to halt you. They cannot exist on the same machine. However, Mobile Information Server and Exchange 2003 can indeed coexist in the same forest. So you can have two servers, as long as they're running side by side, running both Exchange 2003 and Mobile Information Server, but you can have no overlapping components.

Marilyn: We've had a couple more questions come in. Since mailbox attributes are part of an AD user object, what happens with public folders that have mailboxes, i.e., SMTP addresses, associated with it?

Vincent: That's handled by your public folder Connection Agreements. In 5.5 the public folders that had e-mail addresses are replicated to your Microsoft Exchange System Objects container. So that's what's handled by the public folder connection agreements. So you can still e-mail to them when you're on Exchange 2003 and the public folders have had their replicas moved to Exchange 2003.

Marilyn: The next question is: Can the pre-Deployment Tools be run before the Forestprep? We already answered that.

Vincent: Absolutely. Again, I'm going to reiterate that we recommend you run the Deployment Tools well ahead of your Exchange 2003 installation, just so you can get a basic idea of what might be misconfigured in your Active Directory, or what in your Active Directory is not suitable for the Exchange 2003 installation.

Marilyn: The next question: If I use PFMigrate to add replicas to a destination Exchange 2003 server, how do I know when the content has completed replicating before removing the source MSX 5.5 replica.

Vincent: You trust the replication status view in Exchange System Manager for the public folder on that target server, and compare what its item count in Exchange System Manager compared with the 5.5 server. From past experience, I can't say that the Exchange 5.5 representation is entirely accurate. The best way to tell is, if you can log on to a mailbox whose mailbox store points to each public folder store respectively and then compare the item count yourself when logged on.

Also, you don't need to wait in order to remove the replica from 5.5. Within a few minutes of each other, you can add the replica to the Exchange 2003 server, and then remove the replica from 5.5. Again, that just removes the replica information. It does not change the content immediately. In the background, the content is still going to replicate from 5.5 to the target Exchange 2003 server.

Marilyn: The next question might be a lifecycle question, but I'm going to throw it out just in case you can answer it. Is the support for Exchange 5.5 going to end after the Exchange 2003 release?

Vincent: Authoritatively I can't speak on this. I do know what is public information, and that is the 5.5 support lifecycle has been extended a few more months, I believe 12 more months. By that time, I don't believe we'll have a new version of Exchange by then. That's as much as I can say, unfortunately.

Marilyn: You can actually get that information at http://support.microsoft.com/lifecycle/. One more question that we have: Is there any new functionality added to Exchange 2003 to support Exchange forest topology?

Vincent: I'm not sure if that question quite makes sense, but if you're talking about the multi-forest topology, there aren't very many changes. We do now have a new attribute called ms-Exch-Originating-Forest. Typically, that gets used when you're running Identity Integration services in conjunction with multiple Exchange installations in different forests.

Marilyn: The next question is: After you have moved to native mode Windows 2003 and Exchange 2003, how do you clean up AD and all the additional information that was populated for coexistence.

Vincent: There's not very much that you need to clean up. Once you've moved down that path, pretty much just decommission your Active Directory Connector services, and the Uninstall program will go ahead and remove those corresponding Active Directory objects that were created by those installations. Other than that, there's not much that you would need to clean up, once you upgrade to Windows 2003 and Exchange 2003.

Marilyn: Let me ask the question that I have still outstanding. We have a Mobile Information Server Carrier Edition running. What should we do to have these servers support the Always Up-To-Date notifications? I know that Exchange 2003 does not support SMS notifications.

Vincent: I believe we actually do. Unfortunately, I can't go very deep into that, but I would strongly recommend that you refer to that Flexible Mobility WebCast. I believe that might mention something about our Always Up-To-Date feature in Exchange 2003.

Marilyn: The next question: Is there a good resource for setting up the new HTTP functionality of Outlook 2003 in Exchange 2003?

Vincent: If you're talking about the Cache mode feature, and even using the RPC over HTTP Proxy service, then I believe either the "What's New" or the "Getting Started Guide" on TechNet under the planning resources is good for you.

Marilyn: It appears that we've answered all the questions that were submitted so that is going to wrap up our session. I want to thank all of you for joining us, and hope the information was useful to you. I want to thank our presenters for coming in today and giving us some great information.

If you have any suggestions for future Support WebCast topics, general comments about today's session, or the WebCast program as a whole, please feel free to use the following link, http://support.microsoft.com/servicedesks/webcasts/feedback.asp.

We hope you have the opportunity to tune in again in the near future. Thanks, and have a great day.