Solutions to fix your messaging problems
We recently finished migrating one of the sites in our mixed-mode Exchange Server organization so that the site no longer contains any Exchange Server 5.5 servers. Can we safely remove that site's Site Replication Service (SRS) instance?
The Exchange 2000 Server SRS exchanges site topology information with Exchange 5.5 sites. Each Exchange 5.5 site has an instance of the Knowledge Consistency Checker (KCC), which maintains the internal tables that track how that site communicates with other sites. The KCC map includes information about which site members are bridgeheads, which connectors exist, and what address spaces they cover. To share information, the KCCs use the Exchange 5.5 Directory Services API, which Exchange 2000 doesn't support. Instead of reinventing the wheel, the Exchange 2000 directory team created the SRS, which can request data from an Exchange 5.5 KCC and translate it into an appropriate format and structure for the Exchange 2000 routing engine.
If you have even one Exchange 5.5 server in your organization, you need the SRS. This requirement is simple enough if you have a small number of sites; where people sometimes get in trouble is when they have large organizations with multiple administrative groups. Just because you've removed all the Exchange 5.5 servers from a mixed-mode administrative group doesn't mean you can remove the SRS. Before you remove the SRS, you must ensure that it's no longer needed. The safest way to do this is to make sure that the site has a directory replication connector that points to another site's SRS. Be sure you read and understand the recommendations in the Microsoft article "XADM: Preparing a Mixed Mode Organization for Conversion to Native Mode" (Q272314, http://support.microsoft.com) before removing any SRS instances to ensure that you don't have directory replication problems between Exchange 2000 and your remaining Exchange 5.5 servers.
How can I force a user to view a Web page before using Outlook Web Access (OWA)? We want users to view and agree to a set of terms and conditions before they can use OWA services.
As long as your Web page can redirect users to the correct location, you can use any kind of Web page you want. For example, you can construct a Web page that requires users to click a button (or take some other action to show that they agree to the terms of use), then automatically redirects the user to whatever location you specify.
How many subfolders can a public folder contain?
The Exchange Server Information Store (IS) doesn't impose a fixed limit on the number of subfolders you can create in a public folder. I've seen sites with thousands of subfolders, and you could probably jam several tens of thousands of folders into one container before the system stopped working. However, long before you reached the breaking point, you'd probably observe three major problems. First, if you replicate the folders, you'll experience increased overhead because the system will be busy replicating all the folder contents. If you don't replicate the folder contents, Exchange will still replicate the hierarchy, and you'll be vulnerable to losing data if a server fails. Second, users will have a hard time completing their work if they have to search through 20,000 folders to find the documents they need. Third, you will have to address document management. Keep in mind that Microsoft SharePoint Portal Server is a much better document management solution than Exchange's public folder system.
As we migrate users from Exchange Server 5.5 to Exchange 2000 Server, we want to give Exchange 2000 users access to the Exchange 2000 version of Outlook Web Access (OWA). What's the best way to accomplish this?
You have a couple of choices for granting Exchange 2000 users full access to an Exchange 2000 OWA server. You can make the Exchange 2000 OWA box visible on the Internet so that users can connect to the appropriate server. Of course, this approach requires that users know which server houses their mailbox—an assumption you can't always make. An alternative is to replace the default.asp page on the Exchange 5.5 OWA server with a page that accepts the user's credentials, looks up the name of the user's home server in the directory, then redirects the user to the appropriate OWA page: either the existing Exchange 5.5 OWA page for users homed on an Exchange 5.5 server or the Exchange 2000 OWA page for those users you've already migrated.
Do limits exist for how many user accounts I can list in an Exchange 2000 Server distribution group?
Microsoft recommends that you limit a distribution group list to no more than 5000 objects. Remember, Active Directory (AD) replicates attributes, so when you add a new member to a distribution group, AD replicates that membership attribute. As a result, having 5000 or so members in one distribution group list really chokes replication traffic. If you need to use large distribution groups, however, don't despair. You can create a top-level distribution group and add other distribution groups to it. When the membership of a nested distribution group increases or decreases, AD must replicate those changes but only has to replicate the top-level distribution group if you add or remove nested groups.
How can I let all users use Exchange Instant Messaging (IM) internally but let only some users send IM traffic to outside contacts?
Although the Exchange IM service and client don't provide this feature, you can use a firewall or proxy server to let only users you specify send traffic to the outside world. By controlling who can use the proxy, you can control who sends IM traffic. Microsoft Internet Security and Acceleration (ISA) Server 2000 provides a terrific tool for restricting access that lets you configure a rule set to easily block traffic to MSN (or other messaging systems).
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.