Skip navigation

The Exchange Server Troubleshooter - 01 Feb 1999

At the college where I work, students usually use Outlook Web Access (OWA), but I want them to use Outlook 98 instead of OWA in the dorms and in the labs. To do this, I need to create roaming profiles, so that students can run Outlook 98 from any PC without having to create a new profile. How do I create roaming profiles?

Thanks to reader Dan Schneider for submitting this question. Roaming profiles are often desirable, because they let you make machines interchangeable. With the proper use of profiles and system policies, you can set up hordes of interchangeable machines that users can log on to and have their desktop settings, mail, and files available, no matter where they work. However, profiles and policies address only user credentials and settings information, not mail profile information. The Outlook 97/98 client uses a separate profile, which doesn't necessarily have anything to do with the logged-on user's credentials and system profiles.

The solution might be profgen.exe, a tool from the Exchange Server Resource Kit. In brief, you use profgen.exe to dynamically create or change client profiles on a machine. By setting up the appropriate profgen.ini file and running profgen as part of the user's logon script, you can build the right profile when you need it.

Listing 1 shows an example profgen.ini file. The NEWPROF section keys tell profgen where to find the executable and default profile files; the DisplayUI and AutoExecute keys tell profgen to run silently in the background. The PROFGEN section tells profgen not to log what it's doing, not to change the displayed mailbox name, not to rename the profile file, and to use the user's logon credentials as the profile name.

If you want to use profgen, you can learn more about it in two Microsoft articles: "XCLN: How to Set Up Windows 95 Roving Users with Profgen.exe" (http://support.microsoft.com/support/kb/articles/q182/0/35 .asp) and "XADM: Troubleshooting Profgen.exe Problems" (http://support.microsoft.com/support/kb/articles/q159/9/78.asp). Sue Mosher also maintains a useful list of roaming-related material at http://www.slipstick.com/exchange/olroam.htm.

You might find some alternatives to profgen more palatable. Haaverson's OProfile (http://www.haav.com/products/oprofile/default.htm) and Automated Profile Management's Profile Maker (http://www.autoprof.com/profmkr.htm) let you automatically generate profiles with a great deal more flexibility than profgen does. Another advantage of these commercial products is that Haaverson and Automated Profile Management support their products; Microsoft doesn't officially support profgen.

I've created calendar objects for my resources under a public folder named Resources. Everyone has permission to view those objects, but only the admin staff can administer them. The setup works, but I read at http://www.msexchange.org that you can schedule resources only with mailboxes. Is this statement true?

Sort of. As you've discovered, you can use a public folder to schedule resources just fine. What you might not have noticed is that you're missing some useful features that are available when you put resources in a mailbox.

Keeping calendar data in a public folder means that all users have to manually manage that resource. Manually scheduling commonly used resources not only is a nuisance but also negates the advantage of having the resource accept appointments. Further, if you're not careful, you can create schedule conflicts, because calendar objects in public folders don't publish free/busy information.

When you create a mailbox for a resource and set it up as a delegate in Outlook, the mailbox can automatically manage the resource schedule. When a user schedules an event for a resource that has a mailbox, the mailbox (or, more properly, its client) automatically handles updating the schedule, publishing when the resource is available, and so on. No one has to do anything except invite the resource to take part in the meeting. Try using a mailbox instead of a public folder; you'll like the extra features.

After I installed Service Pack 1 (SP1) on an Exchange Server 5.5 test machine, most of the Exchange Performance Monitor counters disappeared. What happened?

This problem usually occurs because you had a link monitor, server monitor, or Performance Monitor session open when you installed SP1. When any of these monitors are active, the SP1 installer can't replace the DLLs that provide the monitoring. As a result, SP1 removes the entire set of counters but doesn't replace them with the new ones. The easiest way to restore the original counters to their pre-SP1 state is to make sure you've closed all your link, server, and Performance Monitor sessions and reinstall the service pack.

When I tried to run isinteg ­fix using the ­t switch, isinteg gave me the JET_errDiskFull error message, but I have plenty of disk space. Why did I get an error?

Although isinteg doesn't use as much disk space as some modes of edbutil/eseutil use, isinteg uses some space as it builds temporary files and uses these files to verify and fix the database. The isinteg documentation says isinteg automatically places these temporary files in the same directory as the database you're trying to fix, but that information isn't true. Isinteg builds its temporary files in the directory specified by the TEMP environment variable. Try using the ­t directoryName switch to force isinteg to put its temporary files someplace else that has plenty of free space.

I want to add an alternate recipient address to all the mailboxes in our company. Adding the addresses manually is tedious and time-consuming, but I can't get the process to work properly with the directory import tool. What can I do?

When you use the File, Directory Import command in Exchange Administrator, you have to supply a file that contains the data you want to import. The first line of this file is the header. The header specifies which directory fields, or attributes, each subsequent record in the file contains. The rest of the file contains directory data, with one record per line; these records contain the attributes specified in the header.

Listing 2 gives a short example of a directory import file. The first line is the header; it specifies which attributes the second line contains. The key to making directory import work is to make sure that the attribute name you've specified matches the Exchange Server directory name for that attribute. In your case, the correct attribute is Alternate Recipient, and Exchange Administrator expects to see a complete distinguished name, in the format /o=Org/ou=Site/cn=RecipContainer/ cn=DirectoryName.

One way to find the right attribute name is to use Exchange Administrator's raw mode, which lets you see the attribute names of any object in the directory. By starting admin.exe with the /r switch and opening the Properties sheet for an item, you can see a list of all the attributes available for that object. Screen 1 shows a mailbox Properties sheet in raw mode; the List attributes of type drop-down menu controls which attributes appear in the Object attributes list. To find the correct name for an attribute, browse through the list until you see the item you're looking for. You also have to find the correct format for the attribute field. If you don't already know what the correct format is, you can use the File, Directory Export command to export a record that includes the attribute of interest, and then check the exported file's header to see the proper name.

I recently had to reinstall Exchange Server on a failed server. The installation seemed to go OK, but the services wouldn't start and I received error 0xc002041d. What could be causing the problem?

When you're troubleshooting a service start failure, the first thing to check is whether you've correctly specified the site service account. Double-click the service in Control Panel, Services, and make sure you've selected This Account and correctly filled in the site service account name and password.

If the site service account name is correct, you can check two other possible causes that Microsoft discusses in the article "XADM: Exchange Server Setup Fails With 0xc002041d" (http://support.microsoft.com/support/ kb/articles/q182/5/13.asp). First, you might have set your system clock to a date later than the year 2038. However, because most sites don't have a reason to date their mail 40 years into the future, a more likely cause is that you installed an antivirus package before you installed Exchange Server.

Microsoft's recommended fix for the first problem is to make sure you've set the clock to the correct time and date. For the second problem, Microsoft suggests uninstalling the antivirus software, running the Exchange Setup application to reinstall Exchange, and reinstalling the antivirus software.

I have an Exchange Server organization with about 550 mailboxes. I've acquired another Exchange server with a separate organization and site, with about 200 mailboxes in it. How do I move mailboxes from the smaller organization into my current organization? I think the Move Mailbox option within Exchange Administrator lets you move mailboxes only between servers within a site.

Reader Simon Hynes sent in this juicy question. For a long time, the only possible answer was, "You can't." As Simon noted, Exchange Administrator's Move Mailbox command lets you move mailboxes only between servers in a site. You still can't use Exchange Administrator to automatically move mailboxes between sites; however, you can use two manual methods.

The first way works best with small numbers of mailboxes. Use the Exchange client or Outlook to log on to the mailbox and export all its contents to a .pst file. Create the mailbox on the destination server, log on to it, and import the .pst file. This process is tedious; using it for 200 mailboxes would definitely be drudgery.

The second method isn't nearly as tedious, because you let the Move Server Wizard do the work for you. Shortly after the release of Exchange Server 5.5 SP1, Microsoft publicly released the Move Server Wizard, the tool formerly known as Pilgrim. The Move Server Wizard does what its name implies: It lets you move servers from one site to another. You can move a server between two existing sites and organizations, or you can move a server to create a new site or organization. You can even merge two existing sites and organizations. This tool is perfect for solving Simon's problem—all he has to do is move the smaller server into the larger organization, and all the mailboxes and their contents will also move. Tony Redmond explained the Move Server Wizard in detail in "How to Rebuild Your Exchange Organization," Windows NT Magazine, January 1999.

What does the Move Server Wizard do?

On the surface, moving a server between sites doesn't seem difficult, but it is. Every object in the server's directory has a complete distinguished name attached to it, and updating every directory object to reflect the new site's changed name isn't a task you can do halfheartedly—you need to examine and rename every object in the directory. Exchange offered no way to even attempt the job manually, because Exchange Administrator didn't expose many objects whose names needed to change.

The upgrade process is fairly easy to describe, but I suspect it wasn't easy to code. Here's what the Move Server Wizard does:

  1. Updates all directory objects to mirror the new site and organization information. Each object gets a new distinguished name and possibly a new email address. The wizard preserves email addresses so that people still can send mail to the object after it moves.
  2. Updates the private Information Store (IS) on the server so that all stored messages have the new correct address for any item you modified in step 1.
  3. Checks for, and warns you about, any duplicate distribution lists, mailboxes, or custom recipients.
  4. Removes the server from the original site.
  5. Inserts the server into the new organization and site.
  6. Cleans up several temporary items and changes made during the preceding steps.

The Move Server Wizard isn't a fully automated solution; you still have to do some work after the wizard finishes. For example, you have to restart the Message Transfer Agent (MTA) on the moved server, clean up any public folder replicas and permissions that the wizard didn't translate properly, and fix any administrative permissions that the move affected. Each mailbox client has to do a few tasks, too. The Move Server Wizard documentation (which comes with the wizard) explains all these tasks.

To obtain the Move Server Wizard, go to http://backoffice.microsoft.com/downtrial/moreinfo/ ex55sp1wizard.asp. The wizard also is part of Exchange Server 5.0 SP2, which Microsoft released in December 1998. Versions are available for Intel and Alpha CPUs, but you can run the wizard only on servers that are already running Exchange Server 5.5 SP1.

What do I need to watch out for in the Move Server Wizard?

The Move Server Wizard works quite well, and moving a server between sites when the need dictates is a wonderful capability. The wizard is a huge improvement over the old days of having servers stuck in their original sites. You need to be wary of a few quirks, however.

  1. If you try to run the Move Server Wizard on more than one server at a time, you'll make a huge mess. Don't even think about it.
  2. The Move Server Wizard will let you move all the private ISs out of a site without warning you that doing so will strand mailboxes. Let's say you have a site with two servers, one for mailboxes and one for public folders. If you move the mailbox server to another site, you can still create mailboxes in the site, but the server that can host them is no longer there—so the mailboxes will be stuck forever! A workaround for this problem is to use Exchange Administrator's File, New Other, Information Store command to create a new private store on a server in the site. Then, you can use the formerly stranded mailboxes as usual.
  3. If you move a server that you've specified as the expansion server for any distribution list in the directory, you must use Exchange Administrator to update the expansion server for the distribution list, or you can't change the server's membership.
  4. If you move a server that hosts public folders and you tell the Move Server Wizard to put the server into an existing site, the wizard might not move the server's public IS. See the Microsoft article "XADM: Server Missing Public IS After Move Server Wizard" (http://support.microsoft.com/support/kb/articles/q194/8/14.asp) for more details.

The best recommendation I can make is that you carefully read the Move Server Wizard documentation (particularly the troubleshooting sections, which tell you how to recover from a failure during the move process) before you try moving anything.

After my server has been up for a while, the MTA stops. When I check the event log, I see error messages with event ID 9156. What's going on?

This problem is a known bug in Exchange Server 5.0, 5.5, and 5.5 SP1. (The problem doesn't occur in Exchange Server 4.0 because Microsoft rewrote—and greatly improved—the MTA in Exchange Server 5.0.) If the MTA is using an X.400 connector to send mail and the underlying connection fails (or seems to fail), the MTA might not free the connection block object it's using. This leak means that eventually Exchange marks all the connection blocks as in use. Because the MTA can't open any more connections, it logs event ID 9156 and sits there like a lump until you restart it.

You can fix the problem by stopping and restarting the MTA every so often. However, a better method is to contact Microsoft Product Support and ask for the hotfix mentioned in the article "XCON: MTA Stops Processing Messages and Generates 9156 Events" (http://support.microsoft.com/support/kb/articles/q193/8/94.asp). This fix is part of Exchange Server 5.5 SP2. You can also make two other adjustments that might help reduce, or even eliminate, the problem.

  1. Change the X.400 connector parameters to be more tolerant of slow links and link errors. The connection block leak happens only when the MTA gives up on a connection. By raising the value of the Transfer interval (sec) field on the Messaging Defaults tab of the MTA Site Configuration property sheet, you can force the MTA to wait a bit longer before it decides the connection has failed. However, beware that adjusting this value can reduce your MTA throughput.
  2. Adjust the number of connection blocks that Exchange allocates to the connection. By default, Exchange assigns 10 connection blocks to each connector. If you have more than two TCP/IP X.400 connectors, allocating more connection control blocks can delay the onset of the problem. To adjust the number of connection blocks, you need to change two Registry values in the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeMTA\Parameters subkey:
    • The TCP/IP Control blocks value specifies the number of control blocks to allocate for TCP/IP connections. The default is 10; you can raise it as high as 2000, though a more practical setting is 15 or 20 per connection.
    • The TP4 Control blocks value specifies the same value for TP4 connectors. Set it to the same value you use for the TCP/IP value.

Any time you run the Performance Optimizer, you need to reapply these changes, because the Performance Optimizer resets these two values to their defaults. Instead of editing the Registry directly, you can also run the Performance Optimizer with its ­v switch, then change the # of TCP/IP control blocks and # of TP4 control blocks parameters when they appear in the Performance Optimizer wizard.

Hide comments

Comments

  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Publish