Why do you often tell people to contact Microsoft Product Support Services (PSS)? Contacting PSS is an expensive way to solve problems.
Using PSS isn't as expensive as you might think. When you call PSS, you're probably going to spend $195. If you're outside North America, you might spend more. If your organization has a support agreement with Microsoft, you might spend less.
The type of problem can help you determine whether calling PSS is worth the cost. Problems with Exchange servers (including tasks that you might need to perform but don't know how to accomplish) fall into three categories:
- Problems you know how to solve. You don't need to call PSS for these problems.
- Problems you have no idea how to solve. For these problems, a $195 call to PSS can be much cheaper than experimenting with your data and possibly losing some or all of it. The PSS team members have access to the Exchange source code and the Exchange development team, so they usually get to the bottom of any problem, no matter how obscure.
- Problems that fall between the two extremes of categories 1 and 2. For example, one of my clients recently had a problem with a server. He couldn't find any relevant information in Microsoft's online Knowledge Base. He didn't want to risk having the problem worsen to the point at which he lost data, so he called PSS. PSS knew about the problem and helped him fix it with no data loss.
If you attempt a task you're not entirely familiar with (e.g., disaster recovery), a call to PSS can save you a lot of hassle and aggravation. Always check the online Knowledge Base at http://support.microsoft.com first to see whether someone has already reported your problem. PSS's first step will be to check Microsoft's databases, so doing some legwork might help you fix your problem more quickly and less expensively.
In some cases, PSS doesn't charge you a fee. For example, if you report a problem that has an existing hotfix, PSS gives you the hotfix without charge. In other cases, Microsoft charges you a fee but then refunds your money. For example, if you report an incident that PSS identifies as a new, previously unreported bug, PSS gives you a refund.
If PSS can't help you solve your problem, it generally won't take your money. For example, if your Exchange Server Information Store (IS) is corrupt and you don't have a good backup, PSS probably won't be able to help you, so it won't charge you a fee.
At my company, we use the Collaboration Data Objects (CDO) libraries. I notice that we have two CDO versions: CDO 1.21 and Collaboration Data Objects for Windows NT Server (CDONTS). What's the difference between CDO 1.21 and CDONTS, and which one should I use?
CDO and CDONTS are confusingly similar. Three distinct versions exist:
- CDO 1.2. When you install Exchange Server 5.5 or Outlook Web Access (OWA), the installation program installs CDO 1.2 (better known as CDO 1.2 for Exchange).
- CDO 1.21. When you use the Corporate/Workgroup setting to install Outlook 98, the installation program installs CDO 1.21. You can also choose to install this version if you custom install Outlook 2000.
- CDONTS. When you install Exchange Server 5.5, Microsoft Internet Information Server (IIS) 4.0, or Microsoft Commercial Internet System (MCIS), the installation program installs CDONTS.
You can call all three versions from Active Server Pages (ASP), and all three versions offer similar capabilities. CDONTS uses SMTP to send mail. CDONTS can send HTML or MIME Encapsulation of Aggregate HTML Documents (MHTML) messages and doesn't require a Messaging API (MAPI) user profile. CDONTS is an early version of the CDO library Microsoft built into Windows 2000 (Win2K). CDO 1.2 requires a MAPI user profile, but as a result, you can use CDO 1.2 for such tasks as accessing personal calendar objects. The Microsoft article "INFO: What Is the Difference Between CDO 1.2 and CDONTS?" (http://support.microsoft.com/support/ kb/articles/q177/8/50.asp) explains the differences between the three versions in detail.
Many of my users use Internet Message Access Protocol 4 (IMAP4) over Secure Sockets Layer (SSL) connections to connect to the server. Occasionally, the Exchange Server IS stops accepting the IMAP4/SSL connections. When I check the event logs on the server, I see that the client has dropped the connections. Why do the connections drop?
The Exchange IS has a flaw. A particular combination of the IMAP4 fetch command makes the Exchange Server IS choke and drop its existing IMAP/SSL connections. The Exchange Server IS also stops accepting new connections. PSS offers a hotfix but won't tell you the exact combination of items in the IMAP4 fetch command because running the command against an unpatched server constitutes a Denial of Service (DoS) attack. To use the hotfix, you need build 5.5.2560 or later of store.exe, netif.dll, gapi32.dll, and mdbmsg.dll.
My company uses Lotus Notes but is migrating to Exchange. I've noticed that some items in Notes documents don't properly replicate to the Exchange server, resulting in nonprofessional-looking messages. Is this problem common?
Yes, this problem often occurs because Notes uses a customized Rich Text Format (RTF), which lets Notes users embed pop-up text messages, add radio buttons and check boxes, control justification and line spacing, and make other formatting changes. Unfortunately, the Notes application connector doesn't know how to handle these Notes-only attributes when converting Notes messages to Exchange public folder items, so the messages' formatting looks funny. Microsoft might fix this problem in the future; in the meantime, you have to endure substandard formatting.
My company expanded its Exchange organization by adding a new site with several new servers. Why did it take 2 days for the servers to show up in Exchange Administrator?
When you add a new server to a site, the server has to join the intrasite replication process. Two replication attributes advertise the presence of servers in a site: Reps-To and Reps-From. For all the servers in your site to see the new servers, the new servers must be in the Reps-To and Reps-From attributes for each existing server. If you add only one server, all the servers in the site receive the same update, so the new server appears quickly. However, if you add multiple servers to the site within a short period, not all the servers learn about the new servers simultaneously. The Knowledge Consistency Check (KCC) compares each server's Reps-To and Reps-From attributes, then adds or removes servers until each server's attributes are identical. However, the KCC doesn't run continuously. The KCC has to complete at least one replication cycle before all the servers in the site see the new servers.
I used the Migration Wizard to move many users from a legacy system to an Exchange system. Now the users can't open their .pst files with their logon credentials. What happened?
As the Microsoft article "XFOR: Migrated Users Assigned Random PST Password" (http://support.microsoft.com/support/kb/articles/q174/7/38.asp) explains, the Migration Wizard creates .pst files that contain the old system's mail. The wizard assigns random passwords for these .pst files. You can find a user's .pst password in the pst.password file, which appears in the same directory as the user's .pst file.
NT stores a fingerprint of your password rather than the password in the SAM database. NT follows this practice for a good reason. Because .pst files use a different password scheme, the only way you can assign a .pst password that matches the user's logon password is to have the system retrieve the logon password in an unencrypted form. But if the Migration Wizard can retrieve the logon password, so can an attacker. Because several utilities on the Internet can crack open protected files, don't put too much faith in a .pst password.
I used the Move Server Wizard (MSW) to move a server. Now, I no longer see the Offline Address Book (OAB) container in Exchange Administrator. Where did the OAB go?
The MSW doesn't automatically update OABs. To regenerate the OABs manually, follow these steps:
- Wait until the target site (i.e., the site you moved your server into) has completed a full replication cycle.
- Find the DS Site Configuration object, and open its Properties dialog box.
- Switch to the Offline Address Book tab.
- Select the server you want to generate OABs.
- Click Generate All.
This process completely regenerates the OAB, adds the OAB as a container object if it isn't present, and replicates the OAB throughout the organization.
I used the MSW to merge two single-server organizations. Consequently, one server flooded users with reminders and notifications for events that had already taken place. What happened?
One of the last tasks the MSW performs is to open each user's private store inside the Exchange Server IS and remove the user's Reminders folder. If this cleanup process fails or is interrupted, you'll see event ID 9502 in the event log, which tells you that MSW didn't remove a particular user's Reminders folder. When MSW doesn't remove this folder, numerous outdated reminders bombard the user the next time he or she logs on. Microsoft has a hotfix for this flaw; the fix is also in Exchange Server 5.5 Service Pack 3 (SP3), released in September.
I've protected my large distribution lists (DLs) by giving only administrators permission to use them. But how can I prevent users from sending mail to the entire Global Address List (GAL)?
You can't prevent users from sending a message to the entire GAL because they can always send a message to each GAL entry. However, you can limit the total number of addresses users can include in a message's To, Cc, and Bcc fields. To limit the number of addresses, add a new REG_DWORD value named "Max Recipients On Submit" to HKEY_LOCAL_MACHINE\ SYSTEM\CurrentControlSet\ Services\MSExchangeIS\ParametersSystem. Set the value to the maximum number of recipients that you want. As soon as you save the key, the Exchange Server IS will reject messages that have too many recipients. When users go beyond the limit, they receive a message telling them that the email couldn't be sent because it had too many recipients.
Before you set a limit, you need to keep in mind two important considerations. First, users can evade the limit by using server-based DLs. Thus, you need to make sure your DLs have the appropriate permissions.
Second, the limit applies to not only outgoing messages but also incoming messages that the Internet Mail Service (IMS) receives because the IMS submits incoming messages to the Exchange Server IS for processing. If an IMS-delivered message exceeds the maximum number of recipients, the Exchange Server IS logs event 4117 in the event log and saves the message in the IMS archive folder. You don't receive a nondelivery report (NDR).
When I send mail to some DLs in my organization, SMTP custom recipients often get multiple copies. I checked three Microsoft articles—"XADM: Multiple Messages Received by Exchange Client" (http://support. microsoft.com/support/ kb/articles/q143/3/75.asp), "XADM: Duplicate Messages are Received When Message Is Sent to Large DL and Recipient's Quotas Are Exceeded" (http://support.microsoft.com/ support/kb/articles/q232/3/91.asp), and "XCON: Distribution List (DL) Expansion" (http://support.microsoft.com/ support/kb/articles/ q185/1/94.asp)—but they didn't solve the problem. Do you have any idea what the problem might be?
This query baffled me. As Figure 1 shows, the problem involves nested DLs containing custom recipients. The DL on the left works fine and generates one message to the SMTP custom recipient. The DL on the right generates two messages.
The reader then talked with a PSS team member, who cited one of the referenced Microsoft articles and said that the reader's problem was a "feature." Luckily, the reader kept troubleshooting and found the solution. The problem arose because Microsoft followed an X.400 standard that specifies you must completely expand nested DLs, with no pruning of duplicates. This reader's solution was to remove all duplicates from his organization's nested DLs.
At my company, we run Exchange Server 5.5, SP2 on a Compaq ProLiant 3000 with 256MB of RAM and one 9.6GB hard disk. However, we're purchasing a ProLiant 3000 with RAID 5 capabilities, which we'll use as the Exchange server. How can I move all the information from the existing server to the new server?
The hard way would be to make a complete offline backup of your Exchange setup, reinstall Exchange, and treat the server move like a disaster recovery (i.e., move Exchange from the old server to the new one). Although this approach is a good way to practice your disaster-recovery skills, then Ed Crowley Server Move Method (http://www.swinc.com/resource/ exch_faq_appxa.htm) provides an easier way. This method takes advantage of the fact that you can easily add a new server to the site and start migrating mailboxes to it. Here's how the method works:
- Uncrate the new server, and install NT, then Exchange. When the Exchange setup program asks you whether you want to create a new site or join an existing site, join the existing site as a new server.
- Use the Tools, Move Mailbox command in Exchange Administrator to move mailboxes from the old server to the new one. You can move all the mailboxes at once or move the mailboxes in groups over several hours, days, or even weeks.
- If any public folders reside on the server you're decommissioning, create replicas of those folders on the new server. Wait for the folder contents to replicate, then delete the original folders.
- Create new connectors following the procedure I outlined in my July column.
- Follow the steps in the Microsoft article "XADM: How to Remove the First Exchange Server in a Site" (http://support.microsoft.com/ support/kb/articles/q152/9/59.asp) to move the system's Free/Busy folder and some other hidden folders over to the new machine.
You can leave the old server running as long as you like. When users attempt to log on to it, their MAPI clients automatically update their profiles to point to the new server. You need to tell your IMAP4, POP3, and OWA users about the new server. You also need to update your DNS and WINS servers to reflect the new server's name and IP address. If you want to replace a server but keep the same server name, check out the Microsoft article "XADM: How to Move Exchange to a New Computer with the Same Name" (http://support.microsoft.com/ support/kb/articles/q155/2/16.asp).
I grabbed some example CDO scripts from http://www.cdolive.com, but they fail with the error Cannot log on to system. What's wrong?
These scripts run with IIS, so they assume you've configured IIS correctly. Make sure the IUSR_server account has Log on Locally access. If the configuration is right, you might need to manually register the CDO DLL with the system; if you've never installed OWA on your server, the DLL might not be registered. To register the CDO DLL, open regsvr32.exe and enter
C:\winnt\system32\cdo.dll
Then stop and restart the Event Service on your Exchange server.
