Shulou(Shulou.com)06/01 Report--

This article mainly introduces how to install Exchange 2003 in the Exchange 2010 environment, has a certain reference value, interested friends can refer to, I hope you can learn a lot after reading this article, the following let Xiaobian take you to understand.

Question: can I install Exchange 2003 or 2007 in a pure Exchange 2010 organization?

Answer: if the environment is a pure Exchange 2010 environment (an Exchange organization consisting only of Exchange 2010 servers and has never deployed a previous version of Exchange), it cannot. If you transition from Exchange 2007 to Exchange 2010 and the last Exchange 2007 server has been cancelled, you cannot because the organization is now considered a pure Exchange 2010 organization, and you will not be able to install Exchange 2007 in that organization thereafter.

If you plan to transition from Exchange 2003 to Exchange 2010 and have prepared the Active Directory forest using Exchange 2010 setup, you will still not be able to install the Exchange 2007 server in that organization. By the way, the first installation of Exchange 2010 in a pure Exchange 2003 organization will display a warning that it cannot be installed (see figure 1).

Figure 1 after you use the Exchange 2010 installer to prepare the environment, the installer warns you that you cannot install Exchange 2007 in that organization.

Therefore, if you sometimes need an Exchange 2007 server, you should keep an Exchange 2007 server in your organization after you transition from Exchange 2007 to Exchange 2010. Or, if you are transitioning from Exchange 2003 to Exchange 2010, you should deploy an Exchange 2007 server in the organization before using the Exchange 2010 installer to prepare the AD forest.

Problem: currently, we use Exchange 2007 as a messaging system in an enterprise environment. We just upgraded all client computers from Windows XP to Windows 7, but we encountered problems installing Exchange 2007 (SP2) management tools on the new Windows 7 client. Is there anything you should pay special attention to when installing Exchange 2007 management tools on Windows 7?

Answer: because Exchange Server 2007 was developed earlier than Windows 7, Windows 7 does not support Exchange 2007 management tools. The Exchange product group is focused on Exchange 2010, which of course supports Windows 7.

Unfortunately, software development is always constrained by budgets and resources. There are also a number of limitations when the Exchange product group must decide to install Exchange management tools on Windows 7 to provide support. Here is the fact that about 65% of all customers who use Exchange are still using Exchange 2003, and after Exchange 2010 is released and put into production, most customers will skip Exchange 2007 and use Exchange 2010 directly.

You can install Exchange 2007 Service Pack 3 on the Windows 7 client as a solution. Yes, you heard me correctly. Based on customer feedback, the Exchange product group has decided to release Exchange 2007 SP3 in the second half of 2010, which will add support for installing Exchange 2007 management tools on Windows 7 clients and Exchange 2007 on Windows Server 2008 R2 servers. For more information about the plan to release Exchange 2007 SP3, you can click on the following link: http://msexchangeteam.com/archive/2009/11/30/453327.aspx.

Question: I plan to migrate Exchange 2007 to Exchange 2010, and in preparing for this task, I set up a lab environment that contains two separate Active Directory forests. The source AD forest contains the Exchange 2007 organization, and the target AD forest contains the Exchange 2010 organization.

I remember that when performing a cross-forest migration from Exchange 2003 to Exchange 2007, the target organization did not require that the Active Directory user account had been migrated to the target AD forest.

After trying to move some Exchange 2007 mailboxes across forests to the Exchange 2010 organization, moving mailboxes across forests in Exchange 2010 seems to behave differently than in Exchange 2007.

Can you explain how to move mailboxes across forests when the target is an Exchange 2010 organization?

Answer: you are right that cross-forest mailbox mobility works differently in Exchange 2010 than in Exchange 2007.

As you said, Exchange 2007 Move-Mailbox cmdlet does not require AD accounts to be migrated to the target AD forest before moving related mailboxes. Exchange 2007 Move-Mailbox cmdlet looks for all AD accounts in the destination AD forest that match any proxy address (SMTP address), source ObjectSID (masterAccountSID, objectSID, and sidHistory), or legacyExchangeDN (x500 address marked on the user object). If a match is found, mail is enabled for the matching AD account in the target AD forest. If no match is found, Move-Mailbox cmdlet creates a disabled mailbox-enabled AD user account.

In Exchange 2010, the situation is different. First, Move-Mailbox cmdlet is no longer used. The cmdlet has been replaced by a brand new New-Move Request cmdlet, and by the way, the new cmdlet has been improved in several ways. In addition, when using New-Move Request cmdlet to perform a cross-forest mailbox move, Exchange 2010 wants to find a valid mail user and tries to use msExchMailboxGUID to match the source account with the destination account. Unlike Exchange 2007, it does not attempt to match the target account using the above attributes. This means that you need to provide mail users to the target AD forest before you can use Exchange 2010 to perform cross-forest movement.

By the way, unlike Exchange 2007, you can now perform cross-forest mailbox movements using the Exchange 2010 Exchange management console (see figure 2). You just need to add the Exchange organization from the target forest AD to EMC first.

Figure 2 Exchange 2010 New remote Mobility request window

You can create mail users in the target Exchange 2010 organization by using the PrepareMoveRequest.ps1 script described in this section of Microsoft TechNet, or by using Identity Lifecycle Management (ILM) 2007 FP1 (with the latest patch to enable Exchange 2010 to provide ILM 2007 FP1) or by using Forefront Identity Management (FIM 2010), which is currently available in candidate release 1 and will be RTM in the first quarter of 2010.

Problem: Exchange 2007 is currently deployed in our organization. We have a high availability solution that consists of four Exchange 2007 servers, two of which have Hub Transport and client access server roles installed, and two servers that act as mailbox server cluster nodes in a continuous replication cluster (CCR) cluster. To achieve load balancing and provide automatic failover for incoming clients and SMTP connections, an Exchange 2007 server with HT and CAS server roles installed in Windows NLB is configured. This solution works, but with the release of Exchange 2010, we want to use this latest version of the Exchange server. In this release, not only can we take advantage of several new features, but it is said that we can reduce the number of Exchange servers to two without losing the HA functionality that we now have.

Is there anything you should pay special attention to before moving to the Exchange 2010 HA solution, which consists of only two servers?

Answer: yes. To build a high-availability Exchange 2007 messaging solution with automatic failover and no single point of failure at the hardware or storage level, you need a total of four servers: two servers installed with the Exchange 2007 client access and Hub Transport server roles, and two servers acting as cluster nodes in a cluster based continuous replication cluster (CCR).

Hub transport has built-in load balancing and failover capabilities for intra-site communication, and you can use the DNS loop mechanism to make it redundant. However, because the CAS role does not include any load balancing features, you must also typically configure these two servers as nodes in the Windows Network load balancing (WNLB) cluster to provide load balancing and automatic failover for incoming connections from clients and servers on Internet and other external networks.

The two servers that are clustered nodes in the CCR cluster install the active and passive mailbox server roles, respectively, so that the clustered mailbox server (CMS) can switch over or fail over to either of the two nodes. Finally, you use one of the front-end servers in the CCR cluster exclusively as a file sharing witness (third vote).

As you may already know, CCR (and SCC, LCR, and SCR with the same functionality) has been removed from Exchange 2010. However, Exchange 2010 introduces a new feature called Database availability grouping (DAG). This feature uses the same synchronization technology as the combination of CCR and SCR, but also provides a lot of new features, and many of its features are greatly improved compared to CCR and SCR. It is worth noting that Exchange 2010 supports the installation of other Exchange 2010 roles (Hub Transport, client access, and even Unified messaging) on the same server that contains the Mailbox server roles that have been added to DAG. This means that you no longer need to dedicate two servers to configure the Hub Transport and client access server roles of the front-end servers. Simply install all the necessary Exchange 2010 roles on these two servers and you have a fully redundant messaging solution based on Exchange 2010. Something like that. Yes, it sounds incredible, doesn't it?

You know that since DAG makes some use of Windows failover clustering (WFC) components (mainly detection signals and clustered databases), you cannot configure these two servers as nodes in Windows NLB because WFC and WNLB are not supported on the same server. It has not been supported since Windows NT version 4.0 because of potential hardware sharing conflicts between the cluster service and WNLB. For more information, read the knowledge base article: http://support.microsoft.com/default.aspx?kbid=235305.

This means that you must use an external load balancing / failover device, such as a hardware-based load balancer. Also note that this balancer should be redundant, so you need at least two devices.

Although you are still using WFC, and although DAG is an Enterprise Edition feature, you can actually use DAG without the help of Exchange 2010 Enterprise Edition. Unlike Exchange 2007 CCR, DAG is also included in the standard edition of Exchange 2010. Keep in mind, however, that in this case, you can only use a maximum of 5 databases (including active and passive database replicas).

Because the CAS and HT roles are installed on the same server where the Mailbox server role is installed, and the server is a DAG member server, you can save two servers and two Windows 2008 and Exchange 2010 Standard Edition licenses. If you do not have an external load balancer installed in your environment, you can use a virtual load balancer device or purchase a hardware-based load balancer. Of course, you also need a server to act as a witness, although this is the recommended best practice for using an Exchange server, but it is not required. It can be any Windows 2003 Compact 2008 file server in the environment.

Thank you for reading this article carefully. I hope the article "how to install Exchange 2003 in Exchange 2010" shared by the editor will be helpful to you. At the same time, I hope you will support us and pay attention to the industry information channel. More related knowledge is waiting for you to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.