RTPIT
asked on
Win2k Server w/ Exchange 2k crashed Need to recover to 2k3
Ok so here's my hellish problem.
I have a Win2k Server which was running Exchange 2k. It was the PDC of the network and recently hit a point where it ran out of drive space, system started to fail on itself and that's when I was called in. Nothing runs on the 2k server and I'm grateful it even came up enough for me to get the data off. I got a flat copy of all of the exchange files. There is a pdc in the network, 2k box as well. And also a 2k3 server which was going to replace the Exchange/PDC server due to the fear of it failing, coincidence. So now I have the 2k3 server promoted and working as a DC in the network. Is there a way to take flat file backups of the 2k exchange server and get it running on the 2k3 server with exchange 2k3? I ask this because the 2k server with exchange 2k is old enough to where my client no longer has media or license information for either product and only has the new licensing for 2k3 server and exchange. As I sit typing this in a small server closet lit by one bulb, I'm hoping one of you out there has a solution for me. Thanks.
I have a Win2k Server which was running Exchange 2k. It was the PDC of the network and recently hit a point where it ran out of drive space, system started to fail on itself and that's when I was called in. Nothing runs on the 2k server and I'm grateful it even came up enough for me to get the data off. I got a flat copy of all of the exchange files. There is a pdc in the network, 2k box as well. And also a 2k3 server which was going to replace the Exchange/PDC server due to the fear of it failing, coincidence. So now I have the 2k3 server promoted and working as a DC in the network. Is there a way to take flat file backups of the 2k exchange server and get it running on the 2k3 server with exchange 2k3? I ask this because the 2k server with exchange 2k is old enough to where my client no longer has media or license information for either product and only has the new licensing for 2k3 server and exchange. As I sit typing this in a small server closet lit by one bulb, I'm hoping one of you out there has a solution for me. Thanks.
You cannot mount exch2k databases in exch2003.
Furthermore, the databases cannot be mounted on another server (=machine with different account in Active Diretory).
You must perform recovery on the same server; otherwise the relation between Exchange and AD is lost.
I hope for you you have a backup of the system state of the old server; you may be able to recover the server on another machine or in Virtual Server.... If not, you're in BIG trouble and you'd have to follow this procedure (from http://www.microsoft.com/technet/prodtechnol/exchange/2000/support/dbrecovr.mspx#EFGAC)
:"
Exchange 2000 Alternate Server Recovery
1.
Get names.
Before you begin to set up your recovery server, you need to create a list of all the following essential naming scheme elements in your original organization:
• The Exchange 2000 organization name.
• The name of the administrative group to which the database belongs.
• The name of the storage group to which the database belongs.
• The logical database name itself.
• The legacyExchangeDN value for the administrative group object that the database currently belongs to.
Except for the last item, you can easily obtain all of these names by using Exchange System Manager. You can view the legacyExchangeDN value by using various Lightweight Directory Access Protocol (LDAP) tools, such as the ADSI Edit, Ldp, or Ldifde tools. These tools enable you to view the raw attributes of Active Directory objects. ADSI Edit and Ldp are installed with the support tools on the Windows 2000 Setup CD. Ldifde is installed by default with Windows 2000 Server.
Ldifde is a bulk import and export utility for Active Directory. Ldifde uses the industry standard LDIF file format for import and export. For an Exchange 2000 administrator, Ldifde can be a very powerful tool for querying and managing the directory. The following procedure describes how to use Ldifde to obtain the legacyExchangeDN value:
1.
To use Ldifde effectively, the first thing you need to determine is the LDAP path to the objects of interest in the directory. It is very important that you become comfortable with constructing LDAP paths to objects in Active Directory.
Exchange Server 5.5 administrators are used to directory paths that look like the following:
/o=organization/ou=site/cn
The following is the preceding directory path reworked as an LDAP path:
CN=object,CN=container,CN=
An Exchange Server 5.5 directory path starts at the top of the tree, and works its way down, using slashes to delimit each component of the path. LDAP syntax starts at the bottom of the tree and works its way back up, using commas as delimiters.
In every Exchange 2000 organization, Exchange 2000 system objects are found in the same place, in the Configuration container in Active Directory. The Configuration container is always in the root domain for the forest. Child domains in a forest contain copies of the Configuration container, but child domains do not have a Configuration container of their own. The path to the Configuration container in every Active Directory forest is the following:
CN=Configuration, path_to_the_root_DNS_domai
If the Domain Name System (DNS) domain name for your root Windows 2000 Server domain is the following
corp.microsoft.com
you can translate this name into LDAP syntax as the following
DC=corp,DC=microsoft,DC=co
and the path to the Configuration container is therefore the following:
CN=Configuration,DC=corp,D
In the Configuration container, Exchange 2000 administrative groups are located under the following:
CN=Administrative Groups,CN=organization_nam
2.
After you determine the LDAP path, you are ready to construct an Ldifde command line that is similar to the following to display the legacyExchangeDN attribute for your administrative group:
ldifde -f con -d "CN=administrative_group_n
In the preceding example:
• The –ffilename parameter specifies the file name to which output is written. If you enter con, results are output to the screen.
• The –dbaseDN parameter defines the object and the LDAP path to the object.
• The –lLDAP_attribute_list parameter restricts the attribute output to the legacyExchangeDN value only and omits all other values. You can specify multiple attributes, separated by commas.
• The –pscope parameter defines the scope of the search. By default, all objects in the subtree under the specified path are returned. If you specify base, only the exact object that you specify is returned.
The following is the output from the preceding Ldif command:
dn: CN=administrative_group_na
changetype: add
legacyExchangeDN:
/O=organization_name/OU=or
The last line displays the legacyExchangeDN attribute stem for the administrative group.
3.
If you do not know and cannot find all of the names that you need, you can still restore the database successfully, but with some inconvenience. As you try to perform various steps of the recovery, you will receive various error messages. At each step, the error message indicates what is wrong with the current naming.
If you are restoring an online backup, the backup set itself contains the storage group and logical database names. Even if the other names are wrong, if you create a storage group and database on the recovery server with these names, you can restore, but not start, the database.
When you try to start a database that does not match the current legacyExchangeDN attribute naming, you receive an error message that is similar to the following:
Event Type: Error
Event Source: MSExchangeIS
Event Category: General
Event ID: 1088
Date: 8/25/2000
Time: 12:00:55 PM
User: N/A
Computer: RECOVERY1
Description:
The information store could not be loaded because the distinguished name (DN) /O=MICROSOFT/OU=55SITE1/CN
The database may have been restored to a computer that is in an organization or site different than the original database.
In the preceding error message, the legacyExchangeDN stem values are in bold type, and are red. The first path that is listed is the path that is actually inside the database. The second path is the path that is currently listed in Active Directory. To correct this problem, you must change the Active Directory path to match the path that is inside the database.
If the naming is wrong, you have the two following choices:
• Start over again.
• Use the methods that are described in Appendix A "Changing legacyExchangeDN Attribute Values" to change the names in the current installation to the correct names.
2.
Create a new forest.
In Microsoft Windows NT Server 4.0, you need to completely reinstall a server to turn the server into a domain controller. In Windows 2000, you simply run the Dcpromo utility to either promote or demote a server as a domain controller. Therefore, you can use a member server from your production forest temporarily as a recovery server. After you are done with the recovery, demote the server, and then rejoin the server to the previous domain.
The process to start a public information store database is the same as the process to start a mailbox database. Public information store data recovery in Exchange 2000 is very similar to the process that is used in Exchange Server 5.5.
The naming of the recovery forest is entirely at your discretion. This naming does not affect your ability to restore Exchange 2000 databases.
When you create the new forest, you may be prompted to install DNS. If you install DNS at this time, you can ignore the prompts that warn you to establish a static Internet Protocol (IP) address for the server. A Dynamic Host Configuration Protocol (DHCP) assigned IP address is sufficient for a recovery server that will not be left intact permanently.
3.
Install and configure DNS.
This step is necessary if your current DNS server does not allow you to dynamically register service location (SRV) records for your recovery server. In most cases, the DNS server that you use normally only allows secure updates, which means that you must be logged on with a trusted network account. The "rogue" domain that you just created probably does not have the permissions that are necessary to register records. Exchange 2000 cannot be installed in a forest unless SRV records for a domain controller in the forest can be found in DNS. Setup does not work, and error messages such as "Setup is unable to access the Windows 2000 Active Directory" or "Failed to look up the Windows 2000 Site to which this computer belongs" are displayed.
In Windows 2000 Server, installing DNS is a very simple process:
1.
If DNS has not already been installed on the recovery server, install DNS from the Windows 2000 Server installation CD.
Use the Windows Components Wizard in the Add/Remove Programs tool in Control Panel to install DNS. The DNS service is located in the Details folder under Networking Services.
Important: Do not install DHCP. Although an extra DNS server on your network does no harm (because only clients who deliberately point to the service's IP address use this service), DHCP advertises itself on the network, and clients are redirected from the normal DHCP system to your server. In most cases, this causes widespread logon problems on your network for many computers.
2.
At a command prompt, run the following command:
ipconfig /all
Write down your own primary IP address and the DNS servers' IP addresses.
3.
Open the Network and Dial-up Connections folder for your computer, and then open the properties for your primary network connection (usually listed as Local Area Connection).
Open the properties for Transmission Control Protocol/Internet Protocol (TCP/IP). If your computer has been configured by DHCP, the properties usually have automatic settings. Change the DNS setting to Use the following DNS server addresses, and then type your own IP address as the preferred DNS server.
Run the ipconfig /all command again to make sure that the setting is applied.
4.
Start the DNS Microsoft Management Console (MMC) snap-in (Dnsmgmt.msc). Right-click the server object, and then open the server properties. Click the Forwarders tab, and then add the IP address of your previous DNS server. When the local DNS database cannot resolve a name, your server queries your previous DNS server.
Note that if you configure your corporate DNS server as a secondary DNS server in the Internet Protocol properties, it does not have the same effect that configuring a forwarder does. The secondary DNS server is used only when the preferred one is unreachable, not when the preferred server is reachable but cannot resolve a name.
If Windows Internet Naming Service (WINS) name resolution is available on your network, you may not need to configure a forwarder to keep access to network resources. You may also need to specify the full DNS name of network resources (for example, server1.corp.microsoft.com
5.
Create a forward lookup zone. This zone should be a standard primary-type zone, and the zone name needs to match the DNS domain name that you created for your forest.
For example, if your recovery domain controller is server1.recovery.corp.micr
6.
After you create the zone, right-click the zone object, click Properties, and then set Allow Dynamic Updates to Yes.
This is a critical step. Until you do this, your server cannot register SRV records in your DNS.
Verify that SRV records for your recovery domain controller have been registered in the zone. The SRV records are displayed under the zone object as a series of folders with names that begin with underscores:
• _msdcs
• _sites
• _tcp
• _udp
It may take several minutes before these records are automatically registered. You can also stop and restart the Netlogon service, which causes the records to be displayed more quickly.
Important: If you are remotely connected to the server and lose your connection while the Netlogon service is stopped, you cannot reconnect. Click Re-start Service in Services to stop and start the service in a single operation, or use the following compound command:
net stop netlogon & net start netlogon
4.
Install Exchange 2000.
If the legacyExchangeDN value for your original administrative group includes /ou=First Administrative Group, you do not have to alter the legacyExchangeDN attributes on your recovery server. You can simply install Exchange 2000 by using the correct organization name.
However, if the legacyExchangeDN attribute is different, perform the following procedure:
1.
Run Exchange 2000 Setup with the /forestprep switch.
The /forestprep switch causes Setup to make any Active Directory schema and permissions changes that are necessary for Exchange 2000, but Setup does not actually install Exchange 2000.
2.
Run Exchange 2000 Setup again, and install only the system management tools. To do this, change the install Action next to Microsoft Exchange 2000 (the first selection) to Custom, and then click Install next to Microsoft Exchange System Management Tools.
Important: It is critical at this point that you do not install Microsoft Exchange Messaging and Collaboration Services.
3.
In Exchange System Manager, click Display Administrative Groups on the General tab in the properties of the organization object.
4.
Right-click the Administrative Groups object, click New, and then click Administrative Group. Type the name of the administrative group exactly as the name appears in the /ou= section of the original system's legacyExchangeDN attribute.
5.
Start Exchange 2000 Setup, and install Microsoft Exchange Messaging and Collaboration Services. Join the newly created administrative group when you are prompted to do so during Setup.
5.
Configure storage group and database names.
After Setup finishes, you must create storage group and database names on the server that match the database that you want to recover. If you want to, you can rename an existing storage group or database, or you can create a new storage group and database.
When you restore an online backup, the names of the database files (for example, Priv1.edb and Priv1.stm) do not have to match the names of the database files that are on tape. Only logical naming must be identical.
If you are restoring an offline backup, the situation is reversed; you must match the physical naming of the existing database files, but you do not need to match the logical naming of the storage group or database.
Note: An offline backup consists of the .edb and .stm files for a database, with no log files. If the database was shut down cleanly before these files were copied, you can start the files without the presence of the original log files, and these files generate new log files. If you are restoring an offline backup, delete all of the log and database files on the recovery server before you restore the .edb and .stm files.
An Exchange 2000 database records the names of the organization and administrative group to which the database belongs, but not the server, storage group, or logical database names. An Exchange 2000 database does not even "know" its own physical name. You can rename database files to match the file names that are already configured on the recovery server.
You must match storage group and database logical names only when you restore an online backup. This requirement is enforced by the restoration application programming interface (API) and is not an essential requirement in the databases themselves.
6.
Restore the databases.
Before you can restore a backup of a database that was created on one server to a different server, you must click This database can be overwritten by a restore in the properties of the database object. This is true for both online and offline backups.
Before you restore a database, use Exchange System Manager to dismount the database, but leave the information store service running.
If you are restoring a single online backup, do not forget to change the server name in the Restore To box, specify the temporary location for log and patch files in the appropriate box, and select the Last Backup Set check box. If you select this check box, hard recovery is run immediately after restoration finishes. Hard recovery replays the transaction logs and patch files that were also stored on tape into the database. Until hard recovery finishes, you cannot mount a database.
If you do not click to select the Last Backup Set check box, you can run hard recovery manually by using the Eseutil utility. In the temporary folder that you defined, there is a subfolder that is named according to the storage group. The Restore.env file is in this subfolder, along with log and patch files. The Restore.env file configures the hard recovery process. At a command prompt in the Restore.env location, run the following command:
d:\program files\exchsrvr\bin\eseutil
After hard recovery finishes, you can mount the database.
7.
Reconnect mailboxes to Active Directory accounts.
As described in the "Exchange 2000 Alternate Server Recovery Overview" section of this white paper, you can manually create an Active Directory user account, and then use the Reconnect function in Exchange System Manager to link an account to a mailbox.
Note: When you delete a mailbox by using the Active Directory Users and Computers MMC snap-in, the mailbox is not actually deleted. Instead, the Active Directory attributes that link the user account to the mailbox are removed. Periodically, the Mailbox Cleanup Agent scans the database to make sure that each mailbox is connected to an Active Directory account. Mailboxes that are not connected to an Active Directory account are flagged as disconnected, and then are deleted after 30 days in this state.
Therefore, after you delete a mailbox, you have 30 days to reconnect that mailbox to the same user or to a different user before the mailbox contents are lost forever.
If you are recovering more than a few mailboxes, it can be tedious to create accounts and reconnect those accounts one by one. The Mailbox Reconnect tool (Mbconn.exe) enables you to automate both account creation and mailbox reconnection tasks. The Mbconn tool is located in the Support folder of the Exchange 2000 installation CD.
The Mbconn tool works by running the Mailbox Cleanup Agent and then displaying all disconnected mailboxes in a list. The Actions menu in the Mbconn tool contains an Export Users command. This command scans the list of disconnected mailboxes and generates an LDIF file that contains user account import entries for each disconnected mailbox. Each entry defines properties that enable you to easily reconnect each mailbox to the appropriate user.
You can import the LDIF file into Active Directory, and then generate a matching user account for each mailbox by using the following command:
ldifde –i –f filename.ldf
After you generate Active Directory user accounts, the Preview feature in the Mbconn tool tries to match each disconnected mailbox with an Active Directory account. A green check mark is displayed next to all matched mailboxes. If more than one possible match is discovered, a double check mark is displayed. For these mailboxes, you must choose the account that you want the mailbox to reconnect to. You can also remove suggested matches, or match accounts one at a time.
If you click Save, the Mbconn tool performs the actual reconnections. It may take several minutes for the Recipient Update Service to finish the connection process that the Mbconn tool begins.
Also be aware that immediately after restoration, in the Mailboxes table in Exchange System Manager, the mailboxes in the database are displayed as connected. This is because when the mailboxes were backed up, the mailboxes were connected. The Mailbox Cleanup Agent on the recovery server probably has not run yet and marked all the mailboxes as disconnected. You can run the Mailbox Cleanup Agent manually by right-clicking the Mailboxes object. Until a mailbox is displayed as disconnected, the mailbox cannot be reconnected to any user by any means.
After you reconnect mailboxes, you can gain access to the data in those mailboxes by using several methods. You can log on to the mailbox by using an ordinary e-mail client and salvage data by using the e-mail client's user interface. You can also use the Exmerge utility to automatically export data from multiple mailboxes to individual .pst files for each mailbox.
You may encounter logon problems when you attach to mailboxes even though you have full Exchange and Windows administrative permissions. These logon problems are, paradoxically, probably because you have administrator permissions.
By default, when Exchange 2000 is installed, the installation account and members of the Domain Administrators and Enterprise Administrators groups are explicitly denied Send As and Receive As permissions for all mailboxes in the organization. These permissions are necessary to gain access to a mailbox as a client. Although you can override this denial, the override can be audited. Do not assign yourself such permissions, except on a laboratory server, unless doing so is in compliance with your company's security and privacy policies. For additional information about granting yourself extra permissions, see the following article in the Microsoft Knowledge Base:
262054 XADM: How to Get "Service Account" Access to All Mailboxes in Exchange 2000
The Exmerge utility is located in the Support folder on the Exchange 2000 installation CD. This utility attaches to each mailbox in turn as a MAPI client (similar to the method that Outlook uses to gain access to a mailbox), and copies or moves data from the mailbox to a personal folders database. You can then distribute these databases to individual users, or you can automatically merge the databases back into the users' actual mailboxes in the production system by using the .pst files only as an intermediary storage. The Exmerge utility has many other functions, which include the ability to filter messages by time, date, folder, or other attributes. Exmerge avoids putting duplicate messages back into the production system, but single instance storage is not preserved for messages that you restore by using Exmerge.
Refer to the Exmerge documentation for details about the functions and filters of the Exmerge utility.
Furthermore, the databases cannot be mounted on another server (=machine with different account in Active Diretory).
You must perform recovery on the same server; otherwise the relation between Exchange and AD is lost.
I hope for you you have a backup of the system state of the old server; you may be able to recover the server on another machine or in Virtual Server.... If not, you're in BIG trouble and you'd have to follow this procedure (from http://www.microsoft.com/technet/prodtechnol/exchange/2000/support/dbrecovr.mspx#EFGAC)
:"
Exchange 2000 Alternate Server Recovery
1.
Get names.
Before you begin to set up your recovery server, you need to create a list of all the following essential naming scheme elements in your original organization:
• The Exchange 2000 organization name.
• The name of the administrative group to which the database belongs.
• The name of the storage group to which the database belongs.
• The logical database name itself.
• The legacyExchangeDN value for the administrative group object that the database currently belongs to.
Except for the last item, you can easily obtain all of these names by using Exchange System Manager. You can view the legacyExchangeDN value by using various Lightweight Directory Access Protocol (LDAP) tools, such as the ADSI Edit, Ldp, or Ldifde tools. These tools enable you to view the raw attributes of Active Directory objects. ADSI Edit and Ldp are installed with the support tools on the Windows 2000 Setup CD. Ldifde is installed by default with Windows 2000 Server.
Ldifde is a bulk import and export utility for Active Directory. Ldifde uses the industry standard LDIF file format for import and export. For an Exchange 2000 administrator, Ldifde can be a very powerful tool for querying and managing the directory. The following procedure describes how to use Ldifde to obtain the legacyExchangeDN value:
1.
To use Ldifde effectively, the first thing you need to determine is the LDAP path to the objects of interest in the directory. It is very important that you become comfortable with constructing LDAP paths to objects in Active Directory.
Exchange Server 5.5 administrators are used to directory paths that look like the following:
/o=organization/ou=site/cn
The following is the preceding directory path reworked as an LDAP path:
CN=object,CN=container,CN=
An Exchange Server 5.5 directory path starts at the top of the tree, and works its way down, using slashes to delimit each component of the path. LDAP syntax starts at the bottom of the tree and works its way back up, using commas as delimiters.
In every Exchange 2000 organization, Exchange 2000 system objects are found in the same place, in the Configuration container in Active Directory. The Configuration container is always in the root domain for the forest. Child domains in a forest contain copies of the Configuration container, but child domains do not have a Configuration container of their own. The path to the Configuration container in every Active Directory forest is the following:
CN=Configuration, path_to_the_root_DNS_domai
If the Domain Name System (DNS) domain name for your root Windows 2000 Server domain is the following
corp.microsoft.com
you can translate this name into LDAP syntax as the following
DC=corp,DC=microsoft,DC=co
and the path to the Configuration container is therefore the following:
CN=Configuration,DC=corp,D
In the Configuration container, Exchange 2000 administrative groups are located under the following:
CN=Administrative Groups,CN=organization_nam
2.
After you determine the LDAP path, you are ready to construct an Ldifde command line that is similar to the following to display the legacyExchangeDN attribute for your administrative group:
ldifde -f con -d "CN=administrative_group_n
In the preceding example:
• The –ffilename parameter specifies the file name to which output is written. If you enter con, results are output to the screen.
• The –dbaseDN parameter defines the object and the LDAP path to the object.
• The –lLDAP_attribute_list parameter restricts the attribute output to the legacyExchangeDN value only and omits all other values. You can specify multiple attributes, separated by commas.
• The –pscope parameter defines the scope of the search. By default, all objects in the subtree under the specified path are returned. If you specify base, only the exact object that you specify is returned.
The following is the output from the preceding Ldif command:
dn: CN=administrative_group_na
changetype: add
legacyExchangeDN:
/O=organization_name/OU=or
The last line displays the legacyExchangeDN attribute stem for the administrative group.
3.
If you do not know and cannot find all of the names that you need, you can still restore the database successfully, but with some inconvenience. As you try to perform various steps of the recovery, you will receive various error messages. At each step, the error message indicates what is wrong with the current naming.
If you are restoring an online backup, the backup set itself contains the storage group and logical database names. Even if the other names are wrong, if you create a storage group and database on the recovery server with these names, you can restore, but not start, the database.
When you try to start a database that does not match the current legacyExchangeDN attribute naming, you receive an error message that is similar to the following:
Event Type: Error
Event Source: MSExchangeIS
Event Category: General
Event ID: 1088
Date: 8/25/2000
Time: 12:00:55 PM
User: N/A
Computer: RECOVERY1
Description:
The information store could not be loaded because the distinguished name (DN) /O=MICROSOFT/OU=55SITE1/CN
The database may have been restored to a computer that is in an organization or site different than the original database.
In the preceding error message, the legacyExchangeDN stem values are in bold type, and are red. The first path that is listed is the path that is actually inside the database. The second path is the path that is currently listed in Active Directory. To correct this problem, you must change the Active Directory path to match the path that is inside the database.
If the naming is wrong, you have the two following choices:
• Start over again.
• Use the methods that are described in Appendix A "Changing legacyExchangeDN Attribute Values" to change the names in the current installation to the correct names.
2.
Create a new forest.
In Microsoft Windows NT Server 4.0, you need to completely reinstall a server to turn the server into a domain controller. In Windows 2000, you simply run the Dcpromo utility to either promote or demote a server as a domain controller. Therefore, you can use a member server from your production forest temporarily as a recovery server. After you are done with the recovery, demote the server, and then rejoin the server to the previous domain.
The process to start a public information store database is the same as the process to start a mailbox database. Public information store data recovery in Exchange 2000 is very similar to the process that is used in Exchange Server 5.5.
The naming of the recovery forest is entirely at your discretion. This naming does not affect your ability to restore Exchange 2000 databases.
When you create the new forest, you may be prompted to install DNS. If you install DNS at this time, you can ignore the prompts that warn you to establish a static Internet Protocol (IP) address for the server. A Dynamic Host Configuration Protocol (DHCP) assigned IP address is sufficient for a recovery server that will not be left intact permanently.
3.
Install and configure DNS.
This step is necessary if your current DNS server does not allow you to dynamically register service location (SRV) records for your recovery server. In most cases, the DNS server that you use normally only allows secure updates, which means that you must be logged on with a trusted network account. The "rogue" domain that you just created probably does not have the permissions that are necessary to register records. Exchange 2000 cannot be installed in a forest unless SRV records for a domain controller in the forest can be found in DNS. Setup does not work, and error messages such as "Setup is unable to access the Windows 2000 Active Directory" or "Failed to look up the Windows 2000 Site to which this computer belongs" are displayed.
In Windows 2000 Server, installing DNS is a very simple process:
1.
If DNS has not already been installed on the recovery server, install DNS from the Windows 2000 Server installation CD.
Use the Windows Components Wizard in the Add/Remove Programs tool in Control Panel to install DNS. The DNS service is located in the Details folder under Networking Services.
Important: Do not install DHCP. Although an extra DNS server on your network does no harm (because only clients who deliberately point to the service's IP address use this service), DHCP advertises itself on the network, and clients are redirected from the normal DHCP system to your server. In most cases, this causes widespread logon problems on your network for many computers.
2.
At a command prompt, run the following command:
ipconfig /all
Write down your own primary IP address and the DNS servers' IP addresses.
3.
Open the Network and Dial-up Connections folder for your computer, and then open the properties for your primary network connection (usually listed as Local Area Connection).
Open the properties for Transmission Control Protocol/Internet Protocol (TCP/IP). If your computer has been configured by DHCP, the properties usually have automatic settings. Change the DNS setting to Use the following DNS server addresses, and then type your own IP address as the preferred DNS server.
Run the ipconfig /all command again to make sure that the setting is applied.
4.
Start the DNS Microsoft Management Console (MMC) snap-in (Dnsmgmt.msc). Right-click the server object, and then open the server properties. Click the Forwarders tab, and then add the IP address of your previous DNS server. When the local DNS database cannot resolve a name, your server queries your previous DNS server.
Note that if you configure your corporate DNS server as a secondary DNS server in the Internet Protocol properties, it does not have the same effect that configuring a forwarder does. The secondary DNS server is used only when the preferred one is unreachable, not when the preferred server is reachable but cannot resolve a name.
If Windows Internet Naming Service (WINS) name resolution is available on your network, you may not need to configure a forwarder to keep access to network resources. You may also need to specify the full DNS name of network resources (for example, server1.corp.microsoft.com
5.
Create a forward lookup zone. This zone should be a standard primary-type zone, and the zone name needs to match the DNS domain name that you created for your forest.
For example, if your recovery domain controller is server1.recovery.corp.micr
6.
After you create the zone, right-click the zone object, click Properties, and then set Allow Dynamic Updates to Yes.
This is a critical step. Until you do this, your server cannot register SRV records in your DNS.
Verify that SRV records for your recovery domain controller have been registered in the zone. The SRV records are displayed under the zone object as a series of folders with names that begin with underscores:
• _msdcs
• _sites
• _tcp
• _udp
It may take several minutes before these records are automatically registered. You can also stop and restart the Netlogon service, which causes the records to be displayed more quickly.
Important: If you are remotely connected to the server and lose your connection while the Netlogon service is stopped, you cannot reconnect. Click Re-start Service in Services to stop and start the service in a single operation, or use the following compound command:
net stop netlogon & net start netlogon
4.
Install Exchange 2000.
If the legacyExchangeDN value for your original administrative group includes /ou=First Administrative Group, you do not have to alter the legacyExchangeDN attributes on your recovery server. You can simply install Exchange 2000 by using the correct organization name.
However, if the legacyExchangeDN attribute is different, perform the following procedure:
1.
Run Exchange 2000 Setup with the /forestprep switch.
The /forestprep switch causes Setup to make any Active Directory schema and permissions changes that are necessary for Exchange 2000, but Setup does not actually install Exchange 2000.
2.
Run Exchange 2000 Setup again, and install only the system management tools. To do this, change the install Action next to Microsoft Exchange 2000 (the first selection) to Custom, and then click Install next to Microsoft Exchange System Management Tools.
Important: It is critical at this point that you do not install Microsoft Exchange Messaging and Collaboration Services.
3.
In Exchange System Manager, click Display Administrative Groups on the General tab in the properties of the organization object.
4.
Right-click the Administrative Groups object, click New, and then click Administrative Group. Type the name of the administrative group exactly as the name appears in the /ou= section of the original system's legacyExchangeDN attribute.
5.
Start Exchange 2000 Setup, and install Microsoft Exchange Messaging and Collaboration Services. Join the newly created administrative group when you are prompted to do so during Setup.
5.
Configure storage group and database names.
After Setup finishes, you must create storage group and database names on the server that match the database that you want to recover. If you want to, you can rename an existing storage group or database, or you can create a new storage group and database.
When you restore an online backup, the names of the database files (for example, Priv1.edb and Priv1.stm) do not have to match the names of the database files that are on tape. Only logical naming must be identical.
If you are restoring an offline backup, the situation is reversed; you must match the physical naming of the existing database files, but you do not need to match the logical naming of the storage group or database.
Note: An offline backup consists of the .edb and .stm files for a database, with no log files. If the database was shut down cleanly before these files were copied, you can start the files without the presence of the original log files, and these files generate new log files. If you are restoring an offline backup, delete all of the log and database files on the recovery server before you restore the .edb and .stm files.
An Exchange 2000 database records the names of the organization and administrative group to which the database belongs, but not the server, storage group, or logical database names. An Exchange 2000 database does not even "know" its own physical name. You can rename database files to match the file names that are already configured on the recovery server.
You must match storage group and database logical names only when you restore an online backup. This requirement is enforced by the restoration application programming interface (API) and is not an essential requirement in the databases themselves.
6.
Restore the databases.
Before you can restore a backup of a database that was created on one server to a different server, you must click This database can be overwritten by a restore in the properties of the database object. This is true for both online and offline backups.
Before you restore a database, use Exchange System Manager to dismount the database, but leave the information store service running.
If you are restoring a single online backup, do not forget to change the server name in the Restore To box, specify the temporary location for log and patch files in the appropriate box, and select the Last Backup Set check box. If you select this check box, hard recovery is run immediately after restoration finishes. Hard recovery replays the transaction logs and patch files that were also stored on tape into the database. Until hard recovery finishes, you cannot mount a database.
If you do not click to select the Last Backup Set check box, you can run hard recovery manually by using the Eseutil utility. In the temporary folder that you defined, there is a subfolder that is named according to the storage group. The Restore.env file is in this subfolder, along with log and patch files. The Restore.env file configures the hard recovery process. At a command prompt in the Restore.env location, run the following command:
d:\program files\exchsrvr\bin\eseutil
After hard recovery finishes, you can mount the database.
7.
Reconnect mailboxes to Active Directory accounts.
As described in the "Exchange 2000 Alternate Server Recovery Overview" section of this white paper, you can manually create an Active Directory user account, and then use the Reconnect function in Exchange System Manager to link an account to a mailbox.
Note: When you delete a mailbox by using the Active Directory Users and Computers MMC snap-in, the mailbox is not actually deleted. Instead, the Active Directory attributes that link the user account to the mailbox are removed. Periodically, the Mailbox Cleanup Agent scans the database to make sure that each mailbox is connected to an Active Directory account. Mailboxes that are not connected to an Active Directory account are flagged as disconnected, and then are deleted after 30 days in this state.
Therefore, after you delete a mailbox, you have 30 days to reconnect that mailbox to the same user or to a different user before the mailbox contents are lost forever.
If you are recovering more than a few mailboxes, it can be tedious to create accounts and reconnect those accounts one by one. The Mailbox Reconnect tool (Mbconn.exe) enables you to automate both account creation and mailbox reconnection tasks. The Mbconn tool is located in the Support folder of the Exchange 2000 installation CD.
The Mbconn tool works by running the Mailbox Cleanup Agent and then displaying all disconnected mailboxes in a list. The Actions menu in the Mbconn tool contains an Export Users command. This command scans the list of disconnected mailboxes and generates an LDIF file that contains user account import entries for each disconnected mailbox. Each entry defines properties that enable you to easily reconnect each mailbox to the appropriate user.
You can import the LDIF file into Active Directory, and then generate a matching user account for each mailbox by using the following command:
ldifde –i –f filename.ldf
After you generate Active Directory user accounts, the Preview feature in the Mbconn tool tries to match each disconnected mailbox with an Active Directory account. A green check mark is displayed next to all matched mailboxes. If more than one possible match is discovered, a double check mark is displayed. For these mailboxes, you must choose the account that you want the mailbox to reconnect to. You can also remove suggested matches, or match accounts one at a time.
If you click Save, the Mbconn tool performs the actual reconnections. It may take several minutes for the Recipient Update Service to finish the connection process that the Mbconn tool begins.
Also be aware that immediately after restoration, in the Mailboxes table in Exchange System Manager, the mailboxes in the database are displayed as connected. This is because when the mailboxes were backed up, the mailboxes were connected. The Mailbox Cleanup Agent on the recovery server probably has not run yet and marked all the mailboxes as disconnected. You can run the Mailbox Cleanup Agent manually by right-clicking the Mailboxes object. Until a mailbox is displayed as disconnected, the mailbox cannot be reconnected to any user by any means.
After you reconnect mailboxes, you can gain access to the data in those mailboxes by using several methods. You can log on to the mailbox by using an ordinary e-mail client and salvage data by using the e-mail client's user interface. You can also use the Exmerge utility to automatically export data from multiple mailboxes to individual .pst files for each mailbox.
You may encounter logon problems when you attach to mailboxes even though you have full Exchange and Windows administrative permissions. These logon problems are, paradoxically, probably because you have administrator permissions.
By default, when Exchange 2000 is installed, the installation account and members of the Domain Administrators and Enterprise Administrators groups are explicitly denied Send As and Receive As permissions for all mailboxes in the organization. These permissions are necessary to gain access to a mailbox as a client. Although you can override this denial, the override can be audited. Do not assign yourself such permissions, except on a laboratory server, unless doing so is in compliance with your company's security and privacy policies. For additional information about granting yourself extra permissions, see the following article in the Microsoft Knowledge Base:
262054 XADM: How to Get "Service Account" Access to All Mailboxes in Exchange 2000
The Exmerge utility is located in the Support folder on the Exchange 2000 installation CD. This utility attaches to each mailbox in turn as a MAPI client (similar to the method that Outlook uses to gain access to a mailbox), and copies or moves data from the mailbox to a personal folders database. You can then distribute these databases to individual users, or you can automatically merge the databases back into the users' actual mailboxes in the production system by using the .pst files only as an intermediary storage. The Exmerge utility has many other functions, which include the ability to filter messages by time, date, folder, or other attributes. Exmerge avoids putting duplicate messages back into the production system, but single instance storage is not preserved for messages that you restore by using Exmerge.
Refer to the Exmerge documentation for details about the functions and filters of the Exmerge utility.
ASKER
The old server no longer existed, I rebuilt the box, cleaned up the AD links to the old server, added back in the new server to the domain, performed a DCpromo, did a flat file copy from a hard backup into the new box, mounted the database, utilized the recovery wizard to relink the AD users to their corresponding mailboxes and all was well. I did not need to utilize a recovery storage group though if i was working with an online storage group and needed to bring certain parts of data without possible loss of current existing data that would have been the way to go. I do appreciate the effort on both responses but cannot award points since neither solution was utilized.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
here is an ms article on restore groups:
http://www.microsoft.com/technet/prodtechnol/exchange/2003/library/ue2k3rsg.mspx