| Downloads |
|---|
| 5601.zip |
\[Editor's note: Email your Exchange Server and Outlook solutions (under 400 words) to R2R at [email protected]. Please include your phone number. We will edit submissions for style, grammar, and length. If we print your contribution, you'll get $100.\]
Recently, users in my company have experienced an intermittent problem when users update a delegate's calendar in Outlook 98. When User A updates User B's calendar, User A can see the update in User B's calendar, but User B can't see the item.
Microsoft hasn't officially declared that the problem is a bug, but the company offers a hotfix. The Microsoft article "XCLN: Outlook 8.5 Speed Enhancements for Calendar Folder Access" (http://support.microsoft.com/ support/kb/ articles/q189/3/10.asp) explains the Outlook 98 calendar caching feature and mentions an intermittent bug when you're caching to the .ost file and committing the change to the server. The hotfix for Windows 95, which I obtained from Microsoft Product Support Services (PSS), is available on the Exchange Administrator Web site (http://www.winntmag.com/newsletter/exchange). Contact PSS for hotfixes for other platforms. Here's the procedure for applying the hotfix:
- Shut down Outlook 98, and back up the old outllib.dll, emsmdb32.dll, emsui32.dll, emsabp32.dll, and mspst32.dll files.
- Delete from the system the .ost file that Outlook uses to keep a local copy of the calendar. You can find the .ost file at C:\windows\application data\microsoft\outlook.ost. Don't delete any other .ost files because you'll lose any slave replicas of other online folders.
- Run update.exe to apply the hotfix for outllib.dll. Update.exe retains the customer's process identifier (PID) information and prevents possible adverse cosmetic problems (e.g., in AutoSignature and any preferences users select in Tools, Options). Update.exe includes outllib.dll, so you don't have to copy outllib.dll to the system directory.
- Copy emsmdb32.dll, emsui32.dll, emsabp32.dll, and mspst32.dll to the system directory (C:\windows\system). You need these files because this hotfix exposes a bug in emsui32.dll.
- Add the Registry entry HKEY_CURRENT_USER\SOFTWARE\Microsoft\ Office\8.0\Outlook\Ost. Add a DWORD data type NoOST and the data value appropriate for your situation. Add the value to the Registry entry as a decimal value. You can choose from the following values:
- 0 (create OST and cache Calendar—this value is the default)
- 1 (cache only OST; disable offline use)
- 2 (no OST at all; users can't set up offline use)
- 3 (no caching, Outlook 97 mode; users can create OST)
- Restart Outlook.
If you've installed the hotfix correctly, you won't locate the deleted .ost file if you search for it. You can apply this hotfix safely to Outlook 98 installations that have installed the security patch (my company's 2800 PCs all have the security patch); however, I haven't tried installing the hotfix in conjunction with the archive patch.
GroupWise to Exchange Server Troubleshooting Guide
My company recently used the Exchange Migration Wizard to migrate from Novell GroupWise 4.1 to Exchange Server 5.5. Because I couldn't easily find published solutions for problems I encountered during the migration process, I created a troubleshooting guide for the migration team. Here are the most prevalent problems the team encountered, the reason behind the problem, and the solutions that the team developed.
8210 File I/O error
Problem: The 8210 File I/O error stops the Migration Wizard until you click OK and Cancel. If you get caught in a loop and can't return to the Migration Wizard to cancel, you might need to use the Task Manager to end the task.
Reason: The GroupWise database you're exporting has unresolved database problems or problems with the domain database.
Solution: Stop the Migration Wizard, restart the migration from the beginning, reanalyze and fix the database until it's clean.
Error writing to file 000000xx.sec—The process can't access the file because another process has locked a portion of the file.
Problem: This error stops the Migration Wizard.
Reason: When you run multiple instances of the Migration Wizard against the same post office, the other instance of the Migration Wizard is accessing one of the post office's message databases.
Solution: Press Retry to continue without any problems
Exported Message counter not increasing, Problem
Problem: The exported message counter isn't incrementing, and the GroupWise client on the server is flashing rapidly.
Reason: The Migration Wizard is having trouble reading the user's mail account.
Solution: Exit Migration Wizard. Note the account and the primary file that the wizard is creating. Restart the Migration Wizard. If you're performing a two-step process, select the users that follow the problem account in the list and modify the original packing list to import other users ahead of the problem user.
Exported Message counter not increasing, Problem 2
Problem: The exported message counter is not incrementing. When you check the Windows NT Task Manager, the GroupWise client isn't responding.
Reason: The GroupWise client is hung.
Solution: Use the NT Task Manager to end the GroupWise client task; the Migration Wizard will continue working.
Migration Wizard stops responding during import configuration
Problem: The Wizard stops responding when you're selecting the packing list (PKL) file for importing.
Reason: Although I don't know why this problem occurs, the solution lets you continue with the migration.
Solution: Abort the Migration Wizard from Task Manager, log out, and log back on. Restart the migration.
Virus Checkers Interfere with Exchange Server Performance
To improve our organization's safeguards against viruses, colleague Peter Harvey and I installed Symantec's Norton AntiVirus 5.0 on our Exchange server. Within a couple of days, users began to experience some performance anomalies; specifically, users couldn't use the Outlook client to send message replies (they received the Client operation failed message). We checked the NT Event Viewer Application Log on the server and found a large number—as many as 19 instances in 1 second—of ESE97 Performance and Database Page Cache errors linked to the MSExchangeIS process. Performance events displayed the Unexpected NT API error: 0xC000000D message, and Database Page Cache events stated Buffer I/O thread termination error -1022 occurred. According to related Microsoft Knowledge Base articles, ESE97 is the event source name for the JET database engine and -1022 errors are associated with JET_errDiskIO.
Searching the Knowledge Base for buffer I/O thread termination turned up no matches, but unexpected NT API error brought up a reference to the article "XADM: Err Msg: Unexpected NT API Error 0xC000000D" (http://support.microsoft.com/support/kb/articles/q174/7/46.asp). The article explains that several antivirus products install a file system filter that interferes with ESE97's ability to access the Exchange Server database files. The solution is to install the Windows NT 4.0 post-Service Pack 3 (SP3) hotfix rollup, which you can download from the Microsoft Web site (ftp://ftp.microsoft.com/bussys/winnt/winntpublic/ fixes/usa/ nt40/hotfixes-postSP3/roll-up).
However, the article links this problem to the Directory Service (DS—not the Information Store—IS—as our Event Viewer clearly stated) and to the Directory failing to start (whereas our Exchange Server services restarted successfully with each system reboot). We put two and two together and figured all the evidence we had pointed to the same solution. However, instead of applying the hotfixes, we installed the recently available NT 4.0 SP4. Sure enough, the service pack solved the problem, and the system has been running without incident.
