How do I know when my system is ready for me to change my Exchange 2000 Server organization over to native mode?
The decision to move to native mode is tough because the switch from mixed to native mode is irreversible. In mixed mode, your Exchange 2000 organization can contain both Exchange 2000 and Exchange Server 5.5 servers, and the servers can interoperate freely, thanks to the Active Directory Connector (ADC) and Site Replication Services (SRS). In native mode, you can have only Exchange 2000 servers. To determine whether you're ready to move to native mode, first look at your server mix: If you have any Exchange Server 5.5 servers, you can't switch. Next, consider whether you need to switch. Native mode gives you one advantage: more flexibility in assigning servers to routing and administrative groups. One caveat is to make sure that you remove SRS before you switch over to native mode.
Recently, a malicious user began sending out unsolicited email with our domain as a return address, so now we get flooded with angry messages. How can I stop this problem?
Because the intruder is using your valid domain name as a return address, your server receives all the nastygrams from recipients and all the non-delivery reports (NDRs) from failed addresses. You might be able to take the intruder to court and sue for damages (depending on the law in your jurisdiction). More to the immediate point, your Exchange server can't tell the difference between messages sent to legitimate users and messages sent to a bogus address through your server. You could use server-side scripts or rules to filter out the messages. However, no method exists to keep the messages from transiting your connection to your Exchange server, short of putting an SMTP proxy in place and letting it filter the SMTP traffic before it reaches Exchange.
Does Exchange 2000 use any TCP or UDP ports that Exchange Server 5.5 doesn't?
Exchange 2000 and Exchange Server 5.5 have several ports in common:
- DNS on TCP port 53.
- IMAP4 on TCP port 143 (plain) and port 993 (with Secure Sockets Layer—SSL).
- POP3 on TCP port 110 (plain) and port 995 (with SSL).
- Network News Transfer Protocol (NNTP) on TCP port 119 (plain) and port 563 (with SSL).
- The ubiquitous HTTP on TCP port 80 (plain) and port 443 (with SSL).
- SMTP on TCP port 25 (plain) and port 465 (with SSL). Be aware that when two Exchange 2000 servers open a secure SMTP session, they use Transport Layer Security (TLS) instead of SSL, and they talk on port 25 instead of port 465.
- X.400 on TCP port 102. Users frequently change this port. The Microsoft article "XCON: Configuring MTA TCP/IP Port # for X.400 and RPC Listens" (http://support.microsoft.com/support/kb/articles/q161/9/31.asp) explains how to change this port.
- Remote procedure call (RPC) traffic on port 135. Users often change this port, too. The Microsoft article "XADM: Setting TCP/IP Port Numbers for Internet Firewalls" (http://support.microsoft.com/support/kb/articles/q148/7/32.asp) explains how to change this port.
- The Internet Relay Chat (IRC) protocol on TCP port 6667 (and sometimes TCP port 7000) or port 995 with SSL.
- Lightweight Directory Access Protocol (LDAP) usually appears on TCP port 389. However, because Win2K wants LDAP service to use port 389, the Exchange LDAP service must run on port 390 if you're running Exchange Server 5.5 on a Win2K domain controller (DC).
- Link-state routing updates on TCP port 691. It's important to let traffic that uses this port pass without restriction between all servers in a routing group.
- LDAP for Global Catalog (GC) lookups on TCP ports 3268 (plain) and 3269 (SSL).
- SRS using LDAP on port 379.
- Instant messaging (IM—using the rendezvous protocol—RVP) on TCP port 80. RVP sessions switch to a port numbered above 1024 when the IM session is established. This process means that you must be careful with firewalls because you don't generally want to open ports above 1024.
- Kerberos authentication on TCP and UDP port 88.
The following ports are specific to Exchange 2000 or Win2K. You usually don't need these ports on a Windows NT 4.0 server running Exchange Server 5.5.
If you're using Exchange 2000's conferencing service (or Microsoft NetMeeting), you need to keep several other ports in mind. The user locator service (for NetMeeting only) resides on TCP port 522, and audio and video conference setup use TCP ports 1731 and 1720, respectively.
Conferencing and IM are worth special mention because Exchange 2000 uses the ports I just listed to set up the connection. After the connection is established, the server picks a second, dynamically assigned UDP port (with a number above 1024), and the communications use that port. If you want to pass this traffic through a firewall, refer to the Microsoft article "How to Establish NetMeeting Connections Through a Firewall" (http://support.microsoft.com/support/kb/articles/q158/6/23.asp) for instructions.
I have a static IP from my ISP. I want to set up an Exchange server with the Internet Mail Service (IMS) for my experimentation and education. Do I need a registered domain name associated with the static IP for this arrangement to work?
You don't need a registered DNS name for your IP address if you just want to send outgoing mail. You can also send mail to the IP address, which is perfectly legal under Internet Engineering Task Force (IETF) Request for Comments (RFC) 822. However, because most people prefer DNS names to IP addresses, you might want to consider registering a DNS domain and setting up a DNS MX record. I use http://www.joker.com for domain registrations. That service charges about $15 a year for registrations, and the company's customer service seems to be much better than Network Solutions' customer service.
Outlook users are complaining that since we installed our firewall, they don't get new-mail notifications. What causes this problem?
Exchange and the Outlook client agree to use a randomly chosen UDP port for mail notifications. Exchange and Outlook negotiate this port number during the Messaging API (MAPI) session setup. The most likely problem is that your firewall isn't letting the outbound UDP packets reach clients. Unfortunately, unlike most of the other ports Exchange uses, you can't lock new mail notifications to a specific port, so you can't open a single port on your firewall to let these notifications pass.
We need to move about 70 X.400 connectors. Which tools can I use to back up and restore the configuration of Exchange Server 5.5 connectors and to automate moving connectors between servers?
As far as I know, no tools are available to help you. The API lets you talk to the Exchange Server 5.5 Directory Service (DS), where the connector information resides. Therefore, you can write your own tool, but it might take you longer to write a tool than to move the connectors by hand.
