Exchange Admin Q and A: Often Misunderstood Subjects Part 1
Topic Last Modified: 2006-01-11
By Nino Bilic
The purpose of this article is to explain some often misunderstood subjects and provide additional documentation.
Is Hard Repaired Database (ESEUTIL /p) Okay To Run in Production?
How Many Times Do You Run ISINTEG -fix on Exchange Server?
Should You Enable Disabled Accounts Created by ADC?
Are Two One-way and One Two-way Recipient Connection Agreements the Same?
Does Exchange 2000 Server Offline Defragmentation Decrease the Size of the .stm File?
Can You Restore Databases from Exchange Standard Edition to Enterprise Edition or from Exchange Enterprise Edition to Standard Edition?
For More Information
Because running the /p switch on the database can remove database pages, and frequently does, this will have unpredictable results on the database operation.
The problems that can happen after running the /p switch on the database, and then running that database later can be:
The database stops accepting mail.
E-mail messages remain in the Outbox.
The Store.exe program runs with high CPU use with no load on the server.
The Store.exe program generates an access violation if there is a heavy load.
Users cannot open e-mail attachments or e-mail messages.
Running the hard repair on the database should be the last option. Preferably, you could restore from backup. However, if that is not an option, you should do the following after the database has been repaired:
Run ISINTEG on the store to get the best result possible.
After that, you should perform the following appropriate option:
If ISINTEG results in all zeros on fixes, warnings, and errors:
Perform an offline defragmentation of the repaired database, Eseutil /d, to create a new database.
- Perform an offline defragmentation of the repaired database, Eseutil /d, to create a new database.
If ISINTEG did not clean up the database on the mailbox database, and all zeros was not achieved:
Move all mailboxes to another server or store, remove the repaired database and create the new database on the original server, and then move mailboxes back if desired.
Run ExMerge to move all mailboxes out, remove the repaired database, create a new database, and then run ExMerge to move all data into this new database.
- Move all mailboxes to another server or store, remove the repaired database and create the new database on the original server, and then move mailboxes back if desired.
If ISINTEG did not clean up the database on the public folder database, and all zeros was not achieved:
Replicate all folders to another public folder server, remove the original database file, and then replicate folders back if desired.
Export all public folders through Microsoft® Outlook®, remove the repaired database file, and then create a new database. Import public folders into this new database.
- Replicate all folders to another public folder server, remove the original database file, and then replicate folders back if desired.
The previous is true for both Microsoft Exchange 2000 Server and earlier versions. In Exchange Server version 5.5, there is also a possibility that the directory database is hard repaired. In that case, you must rebuild the directory as soon as possible. A hard repaired directory is not for production use.
You run ISINTEG -fix until you get 0 fixes or the same numbers as a result more than twice in a row.
When ISINTEG gives you 0 fixes as a result, that means it cannot fix anything else. You should review the number of errors and warnings that you have. If they are both zero, which would make all three numbers zero, you know that ISINTEG was able to fix all logical errors in the database. Otherwise, consider rebuilding the database by using move mailbox and ExMerge, because it is probable that users will see some sort of problems in their mailboxes.
You run ISINTEG until you get the same result twice in a row to ensure that the logical problem is fixed if possible. For example, if ISINTEG returns seven fixes and three warnings, and does this twice in the row, you can assume that it cannot fix the logical problem in the database, and it is time for a database rebuild.
When disabled accounts are created by Active Directory Connector (ADC), you should not enable these accounts. This is not true for disabled accounts that were created by the ADMT utility.
If you enable these disabled accounts created by ADC, and then users use these accounts without additional modification to log on, issues will occur with public folders and delegation in Exchange.
Disabled account permissions are calculated by using the msExchMasterAccountSID value, instead of the actual security identifier (SID) value of the placeholder account. This is so that the user can continue to log on to the preexisting Microsoft Windows NT® Server 4.0 domain security context and still be granted rights to the user's Exchange 2000 Server objects.
Accounts that are created in the Active Directory® directory service do not have the msExchMasterAccountSid attribute. Such accounts rely on their own security context, objectSID or sIDHistory, to be granted permissions in Exchange store access control lists (ACLs).
For more information about how to properly enable these accounts, see the For More Information section.
Two one-way connection agreements are not supported.
Using two one-way connection agreements that have overlapping import and export containers to achieve two-way replication is not supported. For example, suppose you have a From Exchange to Windows connection agreement set up that is replicating the Site\Recipients container to a default import container of Domain\Users. You cannot set up another one-way From Windows to Exchange connection agreement that has Domain\Users as an export container. To achieve the two-way replication required for mixed sites, you must use a two-way connection agreement.
For more information, see the For More Information section.
Beta versions of Exchange 2000 Server had a feature where the .stm file size was reduced by the online defragmentation of the .stm file. This has been changed. To shrink the size of the .stm file in Exchange 2000 Server, offline defragmentation is needed. This is the same as for the .edb file.
This scenario works without any problems.
This will work without any problems as long as the databases are not over 16 gigabytes (GB) in size. The Standard Edition server cannot mount those databases because that are too big. Even though they can be restored, and brought consistent, they cannot be run on the Standard server.
Exchange Directory contains the information about the server being Standard Edition or Enterprise Edition. In Exchange 2000 Server, Active Directory is used.
In Exchange Server 5.5, if the Standard Edition directory and Information Store are restored to the Enterprise Edition installation of Exchange, you will still see the 16 GB limitation events at database startup. To resolve this issue, Exchange Enterprise Edition setup must be run to update the directory database, which will then remove the 16 GB limitation from the Information Store.
The same reasoning applies to Active Directory and Exchange 2000 Server.
If only the Information Store databases are restored, and the directory or Active Directory determines that this is an Enterprise Edition server, there will be no problem. It is not the Information Store databases that are marked as Standard or Enterprise, it is the directory in Exchange Server 5.5 or Active Directory in Exchange 2000 Server.
For more information, see Microsoft Knowledge Base article 240152, "How to determine which edition of Exchange Server is installed."
For more information, see the following Exchange Server resource and Microsoft Knowledge Base articles:
Exchange Admin Q&A: Often Misunderstood Subjects Part 2
259851, "Ramifications of Running the eseutil /p or edbutil /d /r command in Exchange"
316047, "XADM: Addressing Problems That Are Created When You Enable ADC-Generated Accounts"
303180, "Active Directory Connector Connection Agreement Requirements for Mixed Administrative Groups"