Exchange Queue & A

Transitions and Migrations

Henrik Walther

 

T	ransitions and migrations seem to be on lots of folks' minds. In this installation, I address questions on the move from Exchange 2003 to Exchange 2007, as well as from either of these to Exchange 2010.

Q

Our enterprise uses Lotus Domino for messaging. However, we are planning to move to Exchange.Because Exchange 2010 is just around the corner, we're thinking about skipping Exchange 2007 and instead migrating directly to Exchange 2010. With this is mind, we have a question for you: Will Microsoft update the Microsoft Transporter Suite to support Exchange 2010 or will it provide another coexistence and migration tool?

A

The Exchange team will not add support for Exchange 2010 in the Microsoft Transporter Suite. Instead, it will rely on partner tools to deliver the feature set required for a Domino-to-Exchange migration. For example, it is helping partners with updates so their Domino-to-Exchange coexistence/migration tools work properly with Exchange 2010. In addition, the Exchange team will make sure the partners address functionality gaps. Note, however, that you can migrate without using partner tools that support Exchange 2010. To do this, you would deploy an Exchange 2007 server to use as a migration hop. That is, add an Exchange 2007 server to your infrastructure, then configure the Transporter Suite on it. Migrate data first from Domino to that server, and then from there to Exchange 2010 servers. Last, be aware that Microsoft will support Transporter Suite throughout the life of Exchange 2007, extended support for which ends in 2017. So, you still have a few years to perform your migration with the Transporter Suite.

Q

I know that Exchange 2007 release to manufacturing (RTM) and SP1 don't support Windows PowerShell version 2, but will Exchange 2007 SP2?I'm asking because we're planning to manage Exchange 2007 and 2010 servers with the equivalent Exchange management tools from the same server.

A

Yes, Exchange 2007 SP2 will support Windows PowerShell v2 for that exact purpose. Because Microsoft supports installation of Exchange 2007 and 2010 management tools on the same server (see Figure 1), and thereby makes managing Exchange 2007 and 2010 from the same server possible, supporting Windows PowerShell v2 in Exchange 2007 SP2 made sense. But do bear in mind that Exchange 2007 SP2 won't be able to leverage new features, such as Remote PowerShell, in Windows PowerShell v2. It simply means that you can install Windows PowerShell v2 instead of Windows PowerShell v1. The Windows PowerShell feature set of Exchange 2007 will stay the same.

Figure 1: A single Server can support Exchange 2007 SP2 and Exchange 2010 management tools.

Q

We are planning to transition from Exchange 2003 to Exchange 2007.Before we do, we want to upgrade our domain controllers to Windows Server 2008 aswell as switch the forest and domain functional levels from Windows 2003 toWindows 2008 native mode.In our research, we found documentation (technet.microsoft.com/library/bb232170.aspx) that tells us that Exchange 2003 server will no longer work as expected if we change the Active Directory environment to Windows Server 2008 native mode domain. Would you shed some light on why Microsoft doesn't support switching of the Active Directory environment to Windows Server 2008 native mode?

A

The article is correct, and here's why. First, Microsoft created Exchange 2003 (as well as its service packs) long before it developed the Windows Server 2008 and Windows 2008-based Active Directory environments. This, of course, means that the Exchange product group had no chance of coding or testing against a Windows Server 2008-based Active Directory environment while developing Exchange 2003. Given that Exchange 2003 support has ended (though extended support runs through mid-2014), devoting test resources to this scenario doesn't make any sense. The bottom line is that the Exchange team doesn't know if any Exchange 2003 functionality will break in a Windows Server 2008-based Active Directory environment. But this is certain: Should something break, the chances of Microsoft changing the Exchange 2003 code to fix it are slim to none.

Q

We've been informed that several schema changes in Exchange 2007 SP2 enable coexistence with Exchange 2010.Will we need to run Setup.com /PrepareSchema when upgrading to Exchange 2007 SP2 as well as when we are preparing the Active Directory environment for Exchange 2010? Also, we have the same question for Setup.com /PrepareAD and /PrepareDomain.

A

Exchange 2007 SP2 does indeed contain schema changes. As a matter of fact, this service pack includes all the schema changes required by Exchange 2010. Yes, you read correctly. If you've upgraded Exchange 2007 SP2, you don't need to run Setup.com /PrepareSchema when you're ready to prepare the Active Directory environment for Exchange 2010. The Exchange product group chose to include the Exchange 2010 schema changes in Exchange 2007 SP2 primarily so that customers only had to run Setup.com /PrepareSchema once. But even if you've upgraded to Exchange 2007 SP2, and therefore made schema changes necessary for Exchange 2010, you must still run Setup.com /PrepareAD and /PrepareDomain using the Exchange 2010 bits. This is because of the new universal security groups, the role-based access control permission model, cmdlets and what-not that will be available with Exchange 2010.

Q

What kind of Active Directory database (NTDS.DIT) growth should I expect after installing the schema objects included with Exchange 2010?

A

As a general rule, plan for 2KB of Directory Information Tree (DIT) growth per new class or attribute in the Active Directory schema. Because Exchange 2010 installs approximately 3,000 objects in the schema, you should expect the overall size of the NTDS.DIT file to increase around 6MB. As mentioned in my answer to the previous question, the same schema changes are included with Exchange 2007 SP2 and Exchange 2010. So you will see the same growth no matter if you run Setup.com /PrepareSchema using Exchange 2007 SP2 or Exchange 2010 bits.

Figure 2: the NTDS.DIT file can be sizable.

Q

Because we have a lot of Mac users, we have a lot of Entourage 2008 (and older) clients in our Exchange 2007-based messaging environment.Most of the Entourage clients connect to Exchange using Web-Based Distributed Authoring and Versioning (WebDAV), but a few connect via Post Office Protocol (POP) as well as Internet Message Access Protocol (IMAP). We've heard that Microsoft is discontinuing WebDAV as of Exchange 2010 and wonder if that will leave Entourage clients forced to connect to Exchange 2010 using legacy protocols such as POP or IMAP?

A

Yes, you're right, with Exchange 2010 Microsoft discontinues WebDAV. And, yes, this means that users of Entourage 2008 and older versions will only be able to connect to Exchange 2010 via POP or IMAP. But the Exchange team can't just ignore this mail client protocol because another Microsoft product group uses it. So, Microsoft is taking care of this problem with the new Entourage client (which, as of this writing, is in beta). The upcoming Entourage client will use Exchange Web Services (EWS) for connecting to Exchange. As a result, this version also will support many more features than did the previous, WebDAV-based versions. Now tasks, notes and categories can sync withExchange, and the new Entourage version will have full support for AutoDiscover (Entourage 2008 SP1 had only limited support for AutoDiscover). You can read more about the upcoming version of Entourage here: officeformac.com/blog/Entourage-for-Exchange-Web-Services-Beta-is-Live.

Q

We're a small business that wants to use the new database availability group (DAG) functionality once we upgrade from Exchange 2003 to Exchange 2010.We've read all DAG-related sections in the Exchange 2010 TechNet documentation, but cannot seem to find information on how many NICs DAG member servers need. The machines we're planning to dedicate as DAG member servers currently only have one NIC each. Is this sufficient?

A

Although DAGs will work fine with only one network interface, you really should have at least two NICs connected to separate subnets in each DAG member server. In fact, Microsoft doesn't support DAGs with only one network interface. You might wonder why this is a working scenario if Microsoft doesn't support it.

Figure 3: A database availability group member server should have at least two network interfaces, as shown here

Well, imagine the following: You have a DAG with two member servers each configured with two NIC -- a public network for Messaging Application Programming Interface (MAPI) connections and a private network for heartbeat and replication.

Now you lose the private network, which also serves the replication network. In this situation, the replication will continue via the public network (even if you haven't enabled replication for this network).

If you only had a single NIC in each DAG member server, replication would halt. Depending on the duration of the downtime, huge copy queues could result and you could lose data if the active database copy is corrupted and a failover to a database copy on another DAG member server was required.

 

Henrik Walther*, a Microsoft Certified Master: Exchange 2007 and Exchange MVP with more than 15 years of experience in the IT business. He works as a technology architect for Timengo (a Microsoft Gold Certified Partner in Denmark) and as a technical writer for Biblioso Corp. (a U.S.-based company that specializes in managed documentation and localization services).*