PC WRmt: Not Designed to Support Extended InformationLast reviewed: June 4, 1996Article ID: Q117843 |
The information in this article applies to:
SYMPTOMSVersion 3.2 of Microsoft Mail Remote for Windows was not designed to support extended information (custom template information). When RNETWORK.GLB file is created, it packages all the TPL files. INF files do not get packaged in RNETWORK.GLB; therefore, extended information is not available for remote users. However, there is a problem with the way the remote client handles the extended information when it is present on the postoffice.
STATUSMicrosoft has confirmed this to be a problem in version 3.2 of Microsoft Mail Remote for Windows. This problem was corrected in MSRMTUI.DLL version 3.2.0.4008. If you do not have version 3.2.0.4008 (or later), you can find MSRMTUI.EXE, a self-extracting file, on the following services:
ARTICLE-ID: Q119591 TITLE : How to Obtain Microsoft Support Files from Online ServicesFor more information about how to obtain this Application Note, please see the following article in the Microsoft Knowledge Base:
ARTICLE-ID: Q103946 TITLE : Mail Remote MSRMTUI.DLL Update MORE INFORMATIONIf there is an 8DIGIT.TPL file associated with an external postoffice in the WINDOWS\MSMAIL\MSRMT\TPL subdirectory, when you get details by picking a user from the external PO list, the standard fields are displayed. But if you get details by picking a user from the GAL, in addition to the standard fields, the default template information is displayed (default information from 8DIGIT .TPL). Getting details on every user on that postoffice, results in the same template information because the information is being read from the 8DIGIT.TPL. The remote client does not read the INFs and so the template information should NOT be displayed when getting details. When RNETWORK.GLB is generated, all *.TPLs, (including 8DIGIT.TPLs for other postoffices) are included in the file. When the remote client is installed with this data disk, the TPLs are placed in the TPL subdirectory in WINDOWS\MSMAIL\MSRMT\TPL. On the remote client, the external postoffices have a hexid that do not correspond with the hexid on the postoffice. For example, if you have EXTNET/EXTPO defined on your PO, you may have 00000002.USR and 00000002.TPL and 00000002.INF on the PO whereas on the remote client, you may have 00000001.USR but the TPL is still is in 00000002.TPL. When you get details, you end up getting the information from the wrong TPL file. For example, on the postoffice, if you have 10 8DIGIT.TPL files associated with 10 different external POs. RNETWORK.GLB contains all these 10 8DIGIT.TPL files. The WINDOWS\MSMAIL\MSRMT\TPL directory contains these 10DIGIT.TPL files. When the information in the data disk is parsed out at the remote client, the external POs are associated with different hexids. When you get details on the user from the GAL, it looks at the wrong 8DIGIT.TPL file as the new hexid associations have not affected the TPLs. A similar problem existed with ADMIN.TPL and the problem was resolved by deleting the ADMIN.TPL file when you parse out RNETWORK.GLB. A similar mechanism is required to delete all the 8DIGIT.TPL files at the remote client.
|
Additional reference words: 3.20
© 1998 Microsoft Corporation. All rights reserved. Terms of Use. |