We limit the size of our Exchange 2000 Server users' mailboxes, but sometimes an unusually long delay occurs before the limits take effect. What causes this delay, and what can we do about it?
The Store caches a table of mailbox limit data. Periodically, the Store has to refresh this cache, which it does by rereading the properties you set on the mailbox store and on individual user accounts. However, Exchange 2000 Service Pack 2 (SP2) and earlier contain a flaw that sometimes causes the Store to fail to notice changed limits. Exchange 2000 SP3 and later fix this problem by letting you specify the interval at which mailbox limits are reread. To control this interval, install Exchange 2000 SP3, then follow the instructions in the Microsoft article "XADM: Exchange 2000 Mailbox Size Limits Are Not Enforced in a Reasonable Period of Time; Fix Requires Exchange 2000 SP3" (Q327378, http://support.microsoft.com), which points to the Microsoft article "XADM: Exchange 2000 Mailbox Size Limits Are Not Enforced in a Reasonable Period of Time; Fix Requires Exchange 2000 SP2" (Q326252, http://support.microsoft.com), a similar fix that you can install on top of Exchange 2000 SP2 if you don't want to or can't move to Exchange 2000 SP3.
We're ready to migrate to Exchange 2000 Server, but our directory services group is nervous about the schema changes required for the Active Directory Connector (ADC) and Exchange 2000. Can we roll back these schema changes after they've been made?
Under typical circumstances, schema changes are irreversible; however, you do have some alternatives. For starters, you can perform an authoritative Active Directory (AD) restore to reverse any schema changes. Although this approach might sound scary, if you're careful and follow good backup practices, you can execute this action with minimal disruption. Another option is to disconnect the schema master from the network, make the schema changes directly on the schema master, and verify that everything works as you expect before you reconnect the schema master and let it replicate the changes. Of course, any other applications that need schema master access might not work properly during your testing phase. Perhaps the best solution I've seen is to create a new AD site and use the Microsoft Management Console (MMC) Active Directory Sites and Services snap-in to give the site a long replication interval. Transfer the schema master role to a server in the new site, then perform the schema updates directly on that server. If the updates succeed, you can force immediate replication to propagate the changes. If the changes fail, you can remove the fake schema master and seize that role for another server, which effectively wipes out the changes without requiring you to perform an authoritative AD restore.
We're ready to migrate.
End of Article
Prev. page
1
[2]
next page -->
