Q273478: XADM: How to Completely Remove Exchange 2000 from Active Directory
Q252335: XADM: How to Use Ldp.exe to View Entire Directory Tree and Locate the Microsoft Exchange Container
EXCHANGE IN THE DMZ (Unknown Article)
A lot of confusion exists about placing Microsoft Exchange servers in a network demilitarized zone (DMZ). Questions range from whether you should place Exchange servers in the DMZ to how you configure such servers. This week, I discuss the reasons you might locate Exchange servers in the DMZ and some protective measures you need to take if you do.
If you make any Exchange services available over the Internet, you need to set up an Exchange server in the DMZ. For example, if your Exchange server accepts inbound SMTP mail from the Internet, you must provide an SMTP connection to your Exchange server. Also, many companies place front-end Outlook Web Access (OWA) servers in the DMZ to let users access their mailboxes over a secure HTTP connection. If your organization requires news feeds (through Network News Transfer Protocol--NNTP), you might need an NNTP presence in your DMZ. Other services that might require an Exchange service in the DMZ include Instant Messaging (IM) services, conferencing services, and custom applications.
When you need to locate an Exchange server in the DMZ, you have several options for protecting the server. If you have a firewall in place, you might be able to locate the firewall proxy connections to your Exchange server inside the firewall so that the server isn't directly exposed to the Internet. This approach is common for services such as SMTP. When you don't have a proxy firewall, you need to set up some ACLs on the router that handles traffic to and from the Internet. Typically, the configuration on your Internet perimeter will have multiple zones that lead to a multitiered architecture. In such cases, you must limit inbound traffic to your Exchange servers to the specific services you want the servers to accept (e.g., SMTP, HTTP). Likewise, you must let only specified services travel to the Internet from your Exchange servers.
If you use standard management tools to administer and manage Exchange servers in the DMZ, you might need to implement special configurations. For example, when you locate OWA servers in the DMZ, you need to open TCP ports 80 (HTTP), 443 (Single Sockets Layer--SSL--port for HTTP), 389 (Lightweight Directory Access Protocol--LDAP), and 3268 (Global Catalog--GC) because OWA uses these ports to serve
clients. However, to manage the OWA server from inside the firewall, you also need to open certain remote procedure call (RPC) ports. Management tools such as Exchange System Manager (ESM) won't work unless you configure these ports and services to pass through the firewall.
Planning the connection and deployment of Exchange services in the DMZ can seem daunting. A good place to start is your Exchange Server documentation. Also, read the following Microsoft articles for more details about configuring Exchange services with firewalls.
XADM: How to Prevent the Replication of an Attribute from Exchange Server to Active Directory
XADM: Active Directory Connector Does Not Match to SID History After a User Has Been Cloned
XADM: Exchange Server 5.5 Mailbox Owner Rights Are Removed When You Change the ADC Connection Agreement from a One-Way Connection Agreement to a Two-Way Connection Agreement
XADM: Active Directory Connector Connection Agreement Requirements for Mixed Administrator Groups
XADM: ADC Connection Agreement for Exchange 5.5 on Windows 2000 DC Generates Error c1031b95
The following information is also can be very helpful and will explain why we might have a duplicate accounts and the way to solve the problem.
The ADC creates Disabled User accounts in the Active Directory even though all 5.5 mailboxes have a "Primary Windows NT Account" which points to an object in the Active Directory. In some cases, the duplicate accounts will be created with a "-1" appended to the display name. You may also find that the ADC creates custom recipients in the 5.5 directory whose Display Names and/or Proxy Addresses are identical to that of an existing 5.5 mailbox.
Prior to the initial replication of the Recipient Connection Agreement, the SMTP e-mail address of the Active Directory account was manually typed in. When the ADC replicates and attempts to match an existing 5.5 mailbox to it's Primary Windows NT Account in the Active Directory, it makes an attempt to mail-enable this Windows Account so that it is stamped with the same Proxy addresses as the 5.5 mailbox. If the Active Directory user account already has an e-mail address assigned to it, the ADC assumes that this Windows account is already mail-enabled which means one of 2 things:
1. It has been matched to another object in the 5.5 directory.
2. The Windows account has an Exchange 2000 mailbox.
If an Active Directory user account is already mail or mailbox-enabled, the ADC cannot match a 5.5 mailbox to this account. Since the 5.5 mailbox must have a representation of itself in the Active Directory, the ADC creates an additional user account (the default setting is a disabled user account) in the Active Directory. The new account will inherit the Display Name of the 5.5 mailbox. If the account is being created in the same Active Directory container where the Primary Windows NT Account for the 5.5 mailbox resides, the new account may be created with a "-1" appended to the display name. If the Connection Agreement is a 2-way CA, the ADC creates a custom recipient in the 5.5 directory whose proxy addresses match that of the 5.5 mailbox. This causes non-delivery reports to be generated when attempts are made to deliver mail to the 5.5 mailboxes which now have custom recipients with the same proxy addresses.
This is considered "By Design". You should never manually add an E-mail address to a Windows Account which is not currently mail-enabled.
1. Temporarily disable the ADC by stopping the service or setting the schedule of the Recipient Connection Agreement(s) to NEVER.
2. Remove the ADC-Global-Names attribute from all 5.5 recipients including the Custom Recipients which were created by the ADC. This can be achieved by editing the recipients in Raw Mode or by Directory Import/Export.
3. Delete the Custom Recipients, which were inadvertently created by the ADC, in the 5.5 directory. It's important to remove the ADC-Global-Names attribute from the Custom Recipients prior to deleting these objects since the tombstones of these objects have been known to cause problems if they still contain an ADC-Global-Names attribute.
4. Mail-disable all of the affected Windows Accounts including the Disabled Accounts. This can be automated by using the Killmail or Killmailuser utility. Contact Microsoft Product Support Services for this utility.
5. Delete the Disabled User Accounts created by the ADC.
6. Once you've completed this process, verify that the previously affected accounts no longer have an e-mail address. Re-enable the ADC and force replication. This time, the 5.5 mailboxes should be properly matched to the correct accounts in the Active Directory.
From Sami Atallah, MS Tech Support
Exchange 2000 in Six Steps