The information in this article applies to:
- Microsoft Mail for PC Networks, version 3.5
   
Below is a list of bugs fixed in version 3.5 of Microsoft Mail for PC
Networks.
 
For more information on the fix listed, query in the Microsoft Knowledge
Base on the article ID or the bug number.
 
 SUMMARY OF FILES UPGRADED FOR MAIL 3.5
 
All files have been upgraded with version 3.5 of Microsoft Mail for PC
Networks. A comprehensive list of all files upgraded due to fixes or
otherwise revised is as follows:
 
 Client (version 3.5.2000.4086)
 
    MSMAIL.EXE
   MAPI.DLL
   MSSFS.DLL
   SCHEDMSG.DLL
   Microsoft Mail (Macintosh workstation)
 Server (version 3.5 for .EXE)
 
    ADMIN.EXE
   EXTERNAL.EXE
   ASYNC.OVL
   X25ATLAN.OVL
   X25EICON.OVL
   IMPORT.EXE
   REBUILD.EXE
   SRVMAIN.EXE
  
SERVER BUGS FIXED IN MAIL 3.5
 
 
 PC Adm: Microsoft Mail ADMIN.EXE 3.2.17 Update
 
ARTICLE ID: Q107443
File Updated/Modified: ADMIN.EXE
 - With the earlier version of this file, a corrupt .MAI file could be
   created when you export the address list to a large number of
   postoffices. ADMIN.EXE has been modified so that the correct .MAI
   file is created when address lists are exported.
 - With the earlier version of this file, a corrupt SRVCONF.GLB file
   could be created when you add a directory synchronization (Dir-
   Sync) requestor on a computer that has an EtherExpress(TM) 16
   network card and is running the Ethernet_II protocol. ADMIN.EXE has
   been modified so that it uses a buffer size of 512 bytes instead of
   1K for its buffered I/O.
 - If a Mail Remote for Windows user forgets his or her password or if
   the password is changed while the remote driver is in use, the
   password can now be reset.
   NOTE: This password reset only applies to the server files. Local
   .MMF files will not be affected by this change.
 
   Notes:
   ------
 
   - To resolve this problem, two files must be updated: the
      ADMIN.EXE file (included in this update) and the MSRMTUI.DLL file
     (update included in MSRMTUI.EXE on the MSL).
   - To reset the password, you must ensure that the user's data
      disk was created using ADMIN.EXE version 3.2.12.
 
 - Local postoffice users added with the ADMIN.EXE utility will no
   longer be assigned an invalid identification number if the TID.GLB
   file is locked open. Also, batch creation of local postoffice users
   with the ADMIN.EXE utility while the TID.GLB file is locked open no
   longer results in the same invalid identification number being assigned
   to multiple users.
 - When you use ADMIN.EXE to change the routing type defined for a hub
   postoffice, the routing type definition for any downstream
   postoffice is also updated to match the routing type of the hub
   postoffice.
 - When you use ADMIN.EXE to remove users from a global group, access
   to group folders associated with that global group is also removed.
 - Correct figures are now reported when you use the Mail Administrator
   program to create reports that involve multiple postoffices with more
   than 32,768 users.
 - Groups with names 10 characters long can now be deleted successfully
   on other postoffices. With versions of ADMIN.EXE earlier than 3.2.12,
   if a group was deleted from a postoffice participating in Dir-Sync
   and its name was 10 characters long, other postoffices, including the
   Dir-Sync server, were unable to delete the group from their .USR files.
 - When the Admin account mailbox is greater than eight characters in
   length, the Keep Updates number will no longer change when you change
   the Administrator's Name in Config, DirSync, Server, Options.
   NOTE: To fix this problem, you need ADMIN.EXE version 3.2.13 or
   later (included in this update) and SRVMAIN.EXE version 3.2.13 or
   later, LISTDS.EXE version 3.2.1, and SCONFIX.EXE (updates included in
   SRVUPD.EXE on the MSL).
  - When you modify a remote client's account using Admin, Local Admin,
   Modify, the remote user's Custom View is no longer reset to the
   Default view.
 - ADMIN.EXE will now report an error writing to nnnnnnnn.XTN file,
   if locked open by another process.
    
PC Adm: IMPORT.EXE 3.2.18 Update
 
ARTICLE-ID: Q111556
File Updated/Modified: IMPORT.EXE
 - The Import utility (with the -A option) no longer adds invalid DGN
   names to the Postoffice Address List (POL) when those names do not
   appear in the normal .USR files.
 - The Import utility no longer corrupts the MCI.NME file when
   importing MCI user names. This problem caused the Mail
   Administrator program to incorrectly display the MCI address
   information.
 - The Import utility no longer stops responding (hangs) when it
   processes RESYNC.GLB after doing heavy processing.
   NOTE: To resolve this problem, two .EXE files must be updated: the
   IMPORT.EXE file (update included in IMPORT.EXE version 3.2.9) and
   the SRVMAIN.EXE file (update included in SRVMAIN.EXE version 3.2.10).
  - The Import utility now updates FLAG.GLB when it runs, causing the
   External Mail program to update its address lists on the next cycle
   interval.
 - The Import utility no longer does 1-byte reads of the template
   files.
 - When it is importing modified SNADS template information, the
   Import utility no longer incorrectly sequences the information.
 - When you use the Import utility to modify a user's configuration
   (any option set with an "&") and that user has remote access, the
   user's remote access ability is no longer removed.
 - When you use the Modify transaction type to update a user in the
   POL but you do not make any changes to the user's alias, the user's
   record is no longer deleted.
 - When you use the -A command-line option to modify template
   information, the Import utility no longer increases the size of the
   associated .INF file on each pass. The Import utility now creates a
   new .INF file that incorporates the changes rather than appending
   the changes to the existing .INF file.
 - When you use the Import utility to change a user's mailbox name,
   Error 34--"Could not access log information file"--no longer occurs
   when you start the MS-DOS client.
 - Deleting a local user with Import no longer leaves the user's
   folder files (.IDX and .FLD) orphaned in the FOLDERS\LOC\0000????
   subdirectory of the Mail database.
 - A Microsoft Mail Connection 3.2 PROXYNET\PROXYPO postoffice address
   list is now propagated to a downstream requestor postoffice when
   the gateway postoffice is also the directory server postoffice. The
   Import utility now copies FFAPI postoffice address lists from the
   directory server to the GLB\RESYNC.GLB file to perform a directory
   synchronization manual import procedure.
   NOTE: To resolve this problem, two .EXE files must be updated: the
   IMPORT.EXE file (included in this update) and the SRVMAIN.EXE file
   (update included in SRVMAIN.EXE version 3.2.10).
  - Local postoffice users added with the Import utility will no longer
   be assigned an invalid identification number if the TID.GLB file is
   locked open. Also, batch creation of local postoffice users with
   the Import utility while the TID.GLB file is locked open no longer
   results in the same invalid identification number being assigned to
   multiple users.
 - Trap D errors or "An OS/2 program caused a protection violation"
   error no longer occurs under OS/2 or under the OS/2 subsystem of
   Windows NT when you use the Import utility with the -ST command-
   line option.
 - The Import utility now creates unique mailbag numbers when you add
   local postoffice users, even if the CONTROL.GLB file has been reset
   to zero.
 - When you use Import to add a new local user, the Import utility now
   adds that user's template information to the REQTRANS.GLB. Previously,
   even if the template information was included in the IMPORT.TXT file,
   it was not written to the REQTRANS.GLB.
 - When you use Import to create a new template for an external postoffice,
   the Macintosh client can now read the template information after the
   first user. Previously, the last field was not visible for any user, and
   the template information for the second and subsequent users would
   display incorrectly.
 - When you use Import version 3.2.14 or 3.2.16, and you add users via
   an Import batch file, these users can have their TID values reset.
   This will create problems sending mail, adding to groups, and deleting
   users.
    
PC Ext: Microsoft Mail EXTERNAL.EXE Version 3.2.18 Update
 
ARTICLE-ID: Q111558
File Updated/Modified: EXTERNAL.EXE
 
 - NetBIOS notification does not work when the sender and receiver are
   on different postoffices and there are multiple External Mail
   programs running. The only time notification works is if the first
   External Mail program that was started up dispatches mail between
   the sender's and receiver's postoffices.
 - On Novell networks, the RNETWORK.GLB file is not updated at 4:00 A.M.
   on any drives that are dynamically attached.
 - In low-memory conditions, the External Mail program deletes mail
   from the outgoing mail queue without returning that mail to the
   sender. There are error messages in the SESSION.LOG and SYSTEM.LOG,
   but the mail file is still deleted. In most cases, the sender is
   not notified that the mail was not delivered. With the updated
   External Mail program, the mail message is not deleted but remains
   in the outgoing queue, and the External Mail program still attempts
   to deliver the mail. Because there is not enough memory to return
   the message to the sender, there is no entry in the SYSTEM.LOG. The
   administrator can return the mail from the queue.
 - When the EXTERNAL.INI parameter MinKDiskFull is not included in the
   EXTERNAL.INI file, the default value of 0 is used. This causes the
   External Mail program to attempt to deliver mail to a postoffice
   that has no disk space. The default value for MinKDiskFull has now
   been changed from 0 to 100K.
 - When the External Mail program marks a dynamic drive as being full
   (no disk space), it is not checked again until the External Mail
   program is restarted. The External Mail program now checks dynamic
   drives that are full on every cycle and changes their status if
   disk space becomes available.
 - Messages transferred asynchronously or through an X.25 connection
   do not get time stamped. Therefore, when you view the received
   message in Mail for Windows, the received date/time is actually the
   date/time it was composed, not the date/time it was received by
   External. The External Mail program now time stamps all messages.
 - The External Mail program sometimes hangs when CommType=X25EICON.
   The CommType setting can be specified in the .INI file or on the
   command line for External.
 - Versions 3.2.5 and 3.2.6 of the External Mail program mark a static
   drive as being full (no disk space) and the drive is not checked
   again until the External Mail program is restarted. The External
   Mail program now checks static drives that are full on every cycle
   and changes their status if disk space becomes available.
 - Mail sent to Remote Mail users would not be recorded in the
   SENT.LOG file if the LogSent option was specified in the
   EXTERNAL.INI file or if the -ms command-line option was included
   when the External Mail program was started. Version 3.2.9 of the
   External Mail program will correctly log mail sent to Remote Mail
   users in the SENT.LOG file.
 - When the Import utility is run with the autocreate function, and
   the External Mail program is also run against the same postoffice
   across a wide-area network (WAN) connection or in a high mail
   traffic situation, the Import utility may report "Fatal [59] Error
   autocreating postoffice: XXXXXXXXXX." This error occurs because of
   .XTN file contention between the External Mail program and the
   Import utility. Under normal circumstances, the External Mail
   program holds an .XTN file open for a very short interval and file
   contention is not an issue. Version 3.2.9 of the External Mail
   program now allows the Import utility to have write access to the
   .XTN file.
 - The External Mail program now determines and uses the appropriate
   international date format when the MS-DOS country command is used
   in the CONFIG.SYS file of the workstation running External.
 - The MinKDiskFull and MinKDiskNotFull parameters and their specified
   values are now recorded in the SESSION.LOG file and are displayed
   on screen in the External Mail program's LAN Postoffice Mail
   Activity display area when you use EXTERNAL.INI file entries and
   the undocumented -q1 command-line switch. Previously, logging of
   these parameters and their specified values would only occur when
   you used command-line parameters and the undocumented -q1 command-
   line switch.
 - The External Mail program fails to lock the queue when another
   instance of the External Mail program requests two-way asynchronous
   communication, including X.25. If a third instance of the External
   Mail program tries to service the same queue to deliver a message
   that was already deleted by the second instance, the following
   message may appear in the SYSTEM.LOG file:
       [16] Message was not sent due to missing message file.
 
 - The External Mail program may hang or create incorrect entries in the
   SYSTEM.LOG file if External encounters mailbag contention when it
   tries to deliver a single message to multiple users on a single
   postoffice. Under these conditions, the External Mail program may
   add the following entry to the SYSTEM.LOG file
       [008] Failure delivering mail due to mailbag contention.
      Mail item was not delivered to: <Friendly-Name>
   where <Friendly-Name> may list recipients who actually did receive
   the message, rather than listing only the recipient whose mailbag
   could not be accessed. It is also possible that no entries will be
   added to the SYSTEM.LOG file and External may stop responding.
   Under Windows NT, the External Mail program may return a general-
   protection fault (GP fault) and exit, or External may continue
   processing and add the following entry to the SYSTEM.LOG file on
   the destination postoffice:
 
       [012] This  corrupt message cannot be delivered. Contact your
      Administrator.
 - Multiple message attachments can now be sent successfully over an
   X.25 connection.
 - Two entries are now placed in the SENT.LOG file for each message that
   is transmitted asynchronously between postoffices.
 - The Echo command for modem scripts now works with EXTERNAL.EXE
   versions 3.2.x and Mail Remote for Windows.
   NOTE: The Echo command is restricted to the Send command and does
   not affect the Display command.
  - The System log now returns the name of the Invalid Address user after
   an error 002 (Unknown Address) occurs.
 - In some instances, External would call Mail Remote for MS-DOS or
   Mail Remote for Windows, make the connection, send mail, but not
   receive any queued mail for the user. The External Mail program now
   transmits any queued mail.
 - External was generating an extra P1 file when Mail Remote for Windows
   attempts to receive mail. These extra P1 files were not being deleted
   properly, and they were locked open until External was stopped.
   Although mail was still delivered, the P1 directory could have several
   stranded P1 files. The External Mail program now deletes the extra
   P1 files.
 - If a message is sent to another postoffice via asynchronous
   communication with the Useful Life of the message exceeded and no
   connection is made, two entries are added to the SYSTEM.LOG. One
   has valid information, and the other is a blank entry containing no
   message information.
 - External may report a "Circular route detected" error in the SYSTEM.LOG.
   This happens when the PO where mail is processed has a 9 character
   postoffice name that matches the first 9 characters of a 10 character PO
   name in the hoptrace.
 - External stops delivering mail after it receives a NetBIOS datagram
   (for a priority 5 mail message) from a user on a PO connected using
   the DrivesWAN option.
    
PC DirSync: Microsoft Mail REBUILD.EXE 3.2.16 Update
 
ARTICLE-ID: Q111701
File Update/Modified: REBUILD.EXE
 - This replacement file corrects a problem that occurs on MS-DOS and
   Macintosh workstations when the GALNETPO.GLB file is regenerated
   while REBUILD.EXE is running.
 - In certain conditions, Rebuild would complete its process without
   failing or returning errors. However, the global address list (GAL)
   would not contain all the expected names.
 - If a network error occurred during the Rebuild process and Rebuild
   was unable to create or process a temporary file, an error would
   not be reported.
    
PC DirSync: Microsoft Mail SRVMAIN.EXE Version 3.2.14 Update
 
ARTICLE-ID: Q111703
File Update/Modified: SRVMAIN.EXE
 
IMPORTANT: When you update to SRVMAIN.EXE version 3.2.14, you need
to update ADMIN.EXE to version 3.2.13 or later (update included in
ADMUPD.EXE on the MSL) and LISTDS.EXE version 3.2.1 (included with this
update). You MUST also run SCONFIX.EXE (included with this update)
once. This is required for all users updating to SRVMAIN.EXE
version 3.2.14.
 - The Import utility no longer stops responding (hangs) when it
   processes RESYNC.GLB after doing heavy processing. This problem
   occurred because the heap became corrupted when it was under a
   heavy load.
   NOTE: To resolve this problem, two .EXE files must be updated: the
   SRVMAIN.EXE file (included in this update) and the IMPORT.EXE file
   (update included in IMPUPD.EXE on the MSL).
  - The SRVMAIN utility no longer does one-byte reads of the template
   files.
 - A Microsoft Mail Connection 3.2 PROXYNET\PROXYPO postoffice address
   list is now propagated to a downstream requestor postoffice when
   the gateway postoffice is also the directory server postoffice. The
   Import utility now copies FFAPI postoffice address lists from the
   directory server to the GLB\RESYNC.GLB file to perform a directory
   synchronization manual import procedure.
   NOTE: To resolve this problem, two .EXE files must be updated: the
   SRVMAIN.EXE file (included with this update) and the IMPORT.EXE file
   (update included in IMPUPD.EXE on the MSL).
  - The directory synchronization (Dir-Sync) server now continues to
   process updates when SRVMAIN.EXE encounters duplicate entries in the
   system mailbag. Previously, under these conditions SRVMAIN.EXE would
   quit without processing any additional updates in the system mailbag,
   and the following entries would be added to the DIRSYNC.LOG file:
       Error [115] Failure to read mail from NULL
 
       Warning [8] Error deleting file: <Network>/<Postoffice>/$SYSTEM.
 
 - Dir-Sync will no longer give error
       Error 156 Invalid Dirsync password from PCM:Network/Postoffice
 
   during the T2 cycle. Previously, even if the password for the
   Requestor postoffice was correct, the password of a requestor
   postoffice would be incorrectly compared against other requestor
   postoffices listed in the SRVCONF.GLB. Specifically, this occurred when
   postoffices were registered in a particular order, and the postoffice
   names were similar to or part of other requestor postoffice names.
  - If the DSSERVER.LOG on a requestor postoffice is corrupt for some
   reason, the SRVMAIN -r process during Dir-Sync will no longer cause
   a Trap D.
 - When the Admin account mailbox is greater than eight characters in
   length, the Keep Updates number will no longer change when you change
   the Administrator's name in Config, DirSync, Server, Options.
   IMPORTANT: This fix is specifically for users who have an
   Administrator's mailbox name greater than eight characters, and who
   want to receive Dir-Sync status messages.
 
   To add the new Administrator's name, you need ADMIN.EXE version 3.2.13
   or later. Run Admin, DirSync, Server, Options. Type in the desired
   mailbox name. If necessary, re-enter the Keep Updates field. This
   modified SRVMAIN requires a new LISTDS.EXE version 3.2.1 or later for
   checking the SRVCONF.GLB file.
  - If X.400 addresses are included in the very first Dir-Sync cycle,
   Dir-Sync will no longer fail with a protection violation during the T2
   cycle of the SRVMAIN process.
    
CLIENT BUGS FIXED IN MAIL 3.5
 
 
 Simple MAPI Version 3.2.0.4081 Update
 
ARTICLE-ID: Q95522
File Updated/Modified: MAPI.DLL
 - The sample Visual Basic Simple MAPI application has been modified
   to compile when you use Microsoft Visual Basic version 2.0.
 - Deleting a message in a shared folder does not function as
   expected; the message in the folder is deleted, but the header
   still appears. If you select the header to bring up the message,
   Mail for Windows returns a dialog box that says "The message cannot
   be accessed." Also, if you change a message in any way, the message
   becomes inaccessible.
 - Reply, Reply All, and Forward commands on customer messages in
   shared folders fail if these commands are called from Mail for
   Windows. This problem occurs because the client hands off the
   temporary message ID of the shared folder, instead of the permanent
   shared-folder message ID.
   NOTE: For this problem to be resolved, two files must be updated:
   the MAPI.DLL file (included in this update) and the MSMAIL.EXE file
   (update included in Application Note WA0889).
  - To correctly launch e-forms, Microsoft Electronic Forms Designer
   requires that the message type it gives to Simple MAPI be preserved
   in the delivered message. However, the message type is not encoded
   in WINMAIL.DAT by default, so it is lost across gateways.
   Therefore, the message is received and displayed as a note rather
   than as a Microsoft electronic form.
 - Custom forms that did not include their own textize maps
   could not use the provided default print/save functionality.
   NOTE: To fix this problem, MSSFS.DLL (update included in MSSFS.EXE
   on the MSL) version 3.2.4081 or later must be used in conjunction
   with the MAPI.DLL included in this update.
  - When you execute the MAPIAddress() function, an "Out of Memory"
   error can occur. Thi s problem occurs because a second MAPI session
   is being started and closed, and the MAPIAddress() function is then
   executed in the first session.
    
PC Win: Mail for Windows MSSFS.DLL 3.2.0.4084 Update
 
ARTICLE-ID: Q96694
File Updated/Modified: MSSFS.DLL
 - When you send mail to an external postoffice group or gateway group
   that contains extended characters in the address, Mail for Windows
   does not convert from code page 850 to the ANSI code page when it
   reads the records from the NETPO.GLB file or any other gateway
   address file.
 - External postoffices, SNADS DGNs, and nodes for PROFS and
   OfficeVision are not displayed in alphabetic order because Mail
   for Windows reads them in one at a time and adds them to the
   hierarchy. With the updated version of MSSFS.DLL, Mail for Windows
   reads them in all at once, sorts them, and adds them to the
   hierarchy.
 - An "Unknown user" error may occur when you send a message. Mail for
   Windows caches only the first 8170 bytes of the NETWORK.GLB file
   and loses the rest. Postoffices and gateways that are defined past
   8170 bytes are ignored; therefore, you cannot send messages to the
   users on those postoffices or gateways.
 - The simple MAPI command MAPILogon() does a case-sensitive match on
   the user name and password; however, Microsoft Mail is not case
   sensitive. This problem occurs only if a MAPI session was already
   established when MAPILogon() is called.
 - Incorrect message dates are displayed. When parsing old A.M./P.M.
   style dates (generated from some gateways), Mail for Windows adds
   12 to the time if it is P.M. However, if the message was sent
   during the noon hour, the time is incorrectly read as 24:xx.
   Because this is an invalid time, the date is set to the
   programmer's birthday (12/16/68).
 - Mail for Windows may cause a general protection (GP) fault when it
   encounters a corrupt .XTN file in the database. It does not
   properly handle .XTN files that are an incorrect size.
 - Mail for Windows cannot view templates of SNADS or PROFS users when
   GALONLY=1 is set in the MSMAIL.INI file.
 - When you read a custom message from a shared folder, the wrong date
   is displayed.
 - In version 3.0b of Mail for Windows, the time stamp associated with
   resolved addresses is not saved correctly: if the Global Address
   List (GAL) was built twice in the same day, any mail addressed but
   not sent before the second rebuild could be misdirected. This
   problem was partially corrected in version 3.2 of Mail for Windows:
   the time stamp is saved correctly, thus reducing the time frame in
   which this problem could occur from one day to one clock hour.
   However, mail may still be misdirected at sites where GAL rebuilds
   are made within the same clock hour.
 - All users running Windows from a shared installation point must use
   the same postoffice when they use Advanced Security. This problem
   occurs because the MAIL.DAT file is saved to the Windows SYSTEM
   subdirectory, which is shared among all users running Windows from
   the same location. The client now checks both the WINDOWS (user's
   local directory) and WINDOWS\SYSTEM directories, in that order, for
   the MAIL.DAT file.
   NOTE: To resolve this problem when you are installing Mail for
   Windows, two files must be updated: the MSSFS.DLL file (included
   with this update) and the SETUP.EXE file (update included in
   SETUPD.EXE on the MSL).
  - Duplicate addresses are added to the Personal Address Book (PAB).
   NOTE: To resolve this problem, two .DLL files must be updated: the
   MSSFS.DLL file (included with this update) and the PABNSP.DLL file
   (update included in Application Note WA0887).
  - If users are running Mail for Windows from a shared installation
   point and the NETBIOS=1 flag is set in the MSMAIL.INI file, Mail
   checks the size, date, and time of the MSMAIL.INI file every 5
   seconds. Because the .INI file is on the network, frames are sent
   to the server to check the size of the file every 5 seconds, thus
   increasing traffic on the network. These checks no longer occur
   with this update.
 - When an urgent message is sent to an external user with NetBIOS
   notification in use, Mail for Windows does not send a NetBIOS
   datagram to the External Mail program. This process does work
   correctly when an urgent message is sent to a local user. When
   sending urgent messages, Mail for Windows now sends notifications
   to the External Mail program when NetBIOS notification is in use.
 - MACBinary II attachments are not recognized when originating from
   external Mail Systems.
 - When sending mail such that the number of recipients is greater
   than 200 (exact number depends on the specific address list), the
   body of the message will be missing.
 - When Add Recipients to Personal Address Book is selected, the
   GAL.NME file is locked open each time a global address list (GAL)
    name is added to a compose note.
 
 - In certain situations, viewing details of an external name from a
   group results in the error message:
       A GLB file on your server is corrupt.
 
 - If a message has more than 22 recipients selected from the GAL and
   that message is stored in a shared folder, the message appears to
   be corrupted. Attempting to open the message from the shared folder
   results in the error:
       Mail system error, Mail could not read the entire message from
      the Post Office. Some parts of the message may be missing.
      Ask the sender to resend the message.
 - Under certain conditions, a general protection (GP) fault can occur
   in MSSFS.DLL when the MAPILogon() function is used to begin a
   session with the messaging system.
 - The Check Names function fails to properly resolve partial friendly
   names and returns several selections when a unique resolution is
   possible. This behavior is most obvious when the GAL is selected as
   the default address list and the first and last name of the
   intended recipient begin with the same letter.
   NOTE: To resolve this problem, two .DLL files must be updated: the
   MSSFS.DLL file (this update) and the MAILMGR.DLL file (update included
   in Application Note WA1058).
  - The Windows client stops responding when it receives a message with an
   invalid time; that is, a time greater than 23 hours.
 - Templates that were created with extended characters will lose their
   extended characters when they are exported to other postoffices.
 - The Windows client cannot display a template field of zero length. These
   are display fields only and cannot be modified.
 - Custom forms that did not include their own textize maps could not
   use the provided default print/save functionality.
   NOTE: To fix this problem, MAPI.DLL version 3.2.4081 (available as
   MAPIUPD.EXE on the MSL) MUST be used with this MSSFS.DLL.
  - When you have more than one friendly name for the same PROFS userid,
   and you attempt to get details from the GAL in the Windows client,
   incorrect information is displayed.
 - When you add multiple users from the GAL with the same friendly name
   to the PAB or to Personal Groups, only the first entry gets added.
   No errors are reported.
    
PC Mac: Macintosh Client Version 3.0.6 Update
 
ARTICLE ID: Q103945
File Updated/Modified: MACLIENT.HQX
 - With the earlier version of this file, the computer could stop
   responding when sending a message to a personal group under low
   memory conditions. The Macintosh client file has been modified to
   correct this problem.
 - Some network operating systems will not allow a file to be created
   in all uppercase letters. The Macintosh client file has been
   modified for these types of networks to allow the client to create
   filenames in lowercase letters if LOWRCASE.GLB exists in the GLB
   subdirectory of the Mail database.
 - With the earlier version of this file, when mail is sent to global
   groups that contain nonalphabetic characters in their names, the
   recipient field appears blank when the message is viewed by a Mail
   for Windows user. The Macintosh client file has been modified to
   correct this problem.
 - Extended template information that exceeds 64K is now correctly
   displayed when you choose the Info button in the Addressing dialog box
   of the Macintosh client.
 - The Macintosh client has been modified to enable you to address mail to
   an X.400 recipient when the address exceeds 52 characters. Attempting
   to do this with previous versions of the Macintosh client could produce
   the following error message:
       The application "unknown" has unexpectedly quit, because an error
      of type 1 occurred. OK?
 - If you attempt to forward a message in the Macintosh client, and
   you choose not to forward an attachment to that message, the following
   error message is generated:
       Low on Memory. Unable to complete the operation. Please close some
      windows.
   The Macintosh client has been modified to forward the message without
   generating the error.
  - On a Power Macintosh, if the check box Open "To" Address Selector
   (from the Compose menu, select Get Info) is selected, and you
   attempt to forward or reply to a message, the following error
   message is generated and can hang the machine:
       The system has closed the following application "Unknown"
      because of an error type 1".
   The Macintosh client has been modified to forward or reply to
   a message without generating the error or hanging the machine.
 
    
PC Win: Mail for Windows MSMAIL.EXE 3.20.4085 Update
 
ARTICLE-ID: Q111557
File Updated/Modified: MSMAIL.EXE
 - When an open custom message is deleted from a shared folder, the
   message header still appears in the folder. Trying to open the
   message again results in the error
       The message cannot be accessed.
 
 - You cannot do a Reply, Reply All, or Forward on a custom message
   that is located in a shared folder.
   NOTE: For this problem to be resolved, two files must be updated:
   the MSMAIL.EXE file (included in this update) and the MAPI.DLL file
   (update included in MAPIUPD.EXE on the MSL).
  - An error is now generated when the ACCESS.GLB file is locked open
   and a user attempts to change his or her password.
    
PC Adm: Microsoft Mail MMFCLEAN.EXE Utility
 
ARTICLE-ID: Q117693
File Updated/Modified: MMFCLEAN.EXE
 
Currently, there is no way for an administrator to monitor or manage
space consumed by a Windows or OS/2 Mail user on a version 3.0 or
later Microsoft Mail postoffice (PO). In versions of Microsoft Mail
earlier than version 3.0, the administrator could purge mail messages
for all users on the PO. When the mail message file (MMF) architecture
of versions 3.0 and later of Microsoft Mail for Windows was introduced,
the administrator lost the ability to purge mail messages stored in the
MMFs.
 
The MMFCLEAN utility included in this Application Note is a Windows(TM)
based application to be used on Microsoft Mail 3.0 and later
postoffices to purge mail from MMFs. MMFs usually exist on the PO and
contain the users' private mail messages and folders. There is one MMF
per Windows user on the PO. By default, the Windows user will have his
or her MMF file stored on the PO, but the user can choose to store the
MMF file on his or her local machine. The MMFCLEAN utility matches the
capability of the Mail Administrator program. The administrator should
run it from a Windows 3.0 or 3.1, or Windows for Workgroups 3.1 or 3.11
local area network (LAN) client connected to the PO over the network.
 
You can use the MMFCLEAN utility to clean the MMF according to the
following criteria:
 - Message Age days
 - All messages with size greater than XXX
 - Message priority
  
 Things to Note Before Running MMFCLEAN
 
    WARNING: Before you use the MMFCLEAN utility to clean the database,
   make an additional backup copy of your Microsoft Mail postoffice. If
   an error occurs during a fix, you can restore the backup made
   immediately before you used the MMFCLEAN utility. In all other
   circumstances, you should restore the database from your most recent
   regularly scheduled backup.
 Available disk space should be three times the size of the largest
   MMF.
Do not use an active PO; all users should be logged off and the PO
   should be backed up.
File Scan is required for Novell networks.
MMFs not stored on the PO will not be included; any MMFs stored on a
   user's local drive or on another server will not be cleaned.
No other Mail application should be running on the workstation when
   you start the MMFCLEAN utility.
The Just Compress check box in the Criteria dialog box overrides all
   other criteria. Remember that when a cleaning is done, a compress is
   also automatically done.
   Important: When MMFCLEAN does comparisons on the aging date, the
   creation date of the message is used instead of the date the user
   received the message. This means that if a user was on vacation for
   a week and then came in and downloaded his new messages to his MMF,
   the user's message could get deleted right after it is read if the
   criteria for MMFCLEAN is Read Mail Greater Than 7 Days. We are
   currently investigating how to change this limitation.
 
 
 PC Win: Mail SCHEDMSG.DLL Version 3.2.4086 Update
 
ARTICLE-ID: Q129997
File Updated/Modified: SCHEDMSG.DLL
 
	
	 |