Backing Up Transaction Log
The SQL configuration database for Migration Manager for Exchange projects uses the full recovery model. It causes transaction log file to eventually grow in size. To limit that growth, you need to periodically backup transaction log which also results in log file truncation. Prior to making a first log backup, you must perform at least one full database backup.
The recommended approach to backing up a transaction log is to configure an SQL Server Agent job which automatically performs scheduled log backup. It should use the following Transact-SQL query where database name and target paths are changed according to your environment:
BACKUP DATABASE [qmmexcfgdb]
TO DISK='C:\mydbbackups\qmmexcfgdb.bak'
GO
BACKUP LOG [qmmexcfgdb]
TO DISK='C:\mydbbackups\qmmexcfgdb.trn'
GO
|
|
Note: For more information on transaction log backup, refer to http://social.technet.microsoft.com/Search/en-US/sqlserver?query=BACKUP%20(Transact-SQL)%20log_Truncation&Refinement=30&ac=4. |
Configuring Statistics Portal
Statistics Portal is the Migration Manager component that provides online migration statistics and reporting. Once you have installed Statistics Portal on an IIS server in your network, you should configure it as described below.
Configure Statistics Portal—Select this option to make the Open Project Wizard connect to the portal and configure it to be used with the migration project. Type the URL to the portal in the URL field. In most cases (if the portal is installed in the same forest as the console), the wizard is able to retrieve the URL from the Active Directory. The URL might look like the following: http://IISSERVER:80/Migration.
Use these credentials for portal configuration—Specify the credentials that the wizard will use to configure the portal. The account should be a member of local Administrators group on the IIS server on which the portal is installed.
Credentials for Exchange statistics retrieval—Specify the SQL username and password that the portal will use to retrieve the Exchange migration data for the project from the SQL configuration database. The SQL login you specify to connect to the configuration database must at least have the db_datareader role on the database.
|
|
Note: If you need to enable SQL authentication after installation, use the Microsoft SQL Server Management tools (Enterprise Manager) or edit the registry as described in Microsoft Knowledge Base article 319930 at http://support.microsoft.com/kb/319930/. To learn about required Statistics Portal settings, refer to the System Requirements and Access Rights document. For security reasons, all network protocols may be disabled by default in SQL Server 2005 and SQL Server Express 2005 or later, which causes trouble with connecting to a project. For details on enabling the network protocols, refer to SQL Server documentation. |
Do not configure statistics portal—Select this option if you do not need reporting.
Analyzing the Environment
Before you start directory migration, you should analyze the existing directory environment. This includes identifying required hardware and software upgrades, possible naming conflicts in the case of directory merges, and for an inter-forest migration, comparing and unifying the source and target forest schemas. You can use Quest Reporter to obtain detailed information about the existing Active Directory configuration, hardware and software inventory, etc.
Prior to starting Exchange migration, you should analyze the existing Exchange organizations, checking whether the source and target objects and accounts involved in migration process meet the requirements stated by the System Requirements and Access Rights document. In particular, appropriate accounts must have sufficient rights to access servers and other objects involved in migration; the software required for agents' operation must be installed on those servers, and so on. You can use Migration Configuration Analyzer, which is shipped within Migration Manager for Exchange Resource Kit, to perform some of these checks automatically and to create a detailed report on check result. Note, however, that current version of this tool allows you to perform automatically the most operation-critical checks only (i.e., those listed in the Migration Configuration Analyzer section of the Migration Manager for Exchange Resource Kit User Guide); when the automatic check is successfully completed, the rest of requirements must be checked manually. For details, refer to the System Requirements and Access Rights document and the Migration Manager for Exchange Resource Kit User Guide.
Glossary
The following terms related to migration process are used throughout this document:
Migration: The common term used to describe the following types of migration activities:
- Account migration: When user accounts and other Active Directory objects such as groups, contacts, and computers in the source domain are created in the target domain. Account migration is usually performed in portions, by migration sessions. During a migration session you can specify to create an organizational unit (OU) structure on target similar to that on the source and place the migrated objects there. You also can delegate rights to perform account migration from certain organizational units to other administrators.
- Exchange data migration: When public folder and mailbox contents are transferred from the source to the target environment and synchronized during the co-existence period. Calendar and free/busy information is also synchronized to provide for transparent user collaboration.
Source servers: The domain controllers or Exchange servers from which the Active Directory objects or messaging system are migrated.
Target servers: The domain controllers or Exchange servers to which the Active Directory objects or messaging system are migrated.
Directory synchronization: The ongoing synchronization of objects’ properties (such as passwords and memberships) during the co-existence period of source and target environments. Directory synchronization is handled by the Directory Synchronization Agent. Although it is possible to make the Directory Synchronization Agent create accounts on the target, this option is normally used to populate the source and target Global Address Lists when two or more organizations are merged. In this case the Directory Synchronization Agent is configured to create disabled mailbox-enabled accounts on target and store them in the specified staging OUs, which are temporary. Migration sessions are later used to migrate source accounts, merge them with DSA-created accounts on the target, and move them from the staging OUs to the destination OUs.
Resources or distributed resources: User workstations and servers.
Resource update (resource processing): To ensure that resources will still be available to users when they start using their target accounts and after you have cleaned up SIDHistory, the permissions granted to source accounts for access to the resources must be re-assigned to the target accounts. This means that the ACLs of all the resources in the network need to be processed to refer to the new SIDs. Resource update (also referred to as resource processing) is the process of re-assigning rights and permissions from source to target accounts. Resource update is also referred to as translation or re-ACLing by the industry.
User switch: This is when a user starts authenticating in the target domain (logs on to the target domain). Usually, this happens right after the user's workstation is moved to the target domain.
Mailbox switch: Before a mailbox switch, all new mail is delivered to the source user mailbox and redirection is configured for the corresponding target mailbox. After the mailbox switch, all new mail is delivered to the target mailbox, redirection on target mailbox is disabled, and redirection is configured on the source mailbox using the Migration Manager redirection technology.
Cleanup: This is a post-migration activity. After you have successfully migrated Active Directory and Exchange data, switched users to log on to the target domain, and updated all resources for them, you can safely clean up legacy account permissions from resources and SIDHistory attributes of the migrated objects, disable source accounts, and decommission the source environment.