Le Café Central de

                    ... Deva blogs!!

  • Le Café Central de DeVa

    TNEF & Winmail.dat


    Issue with TNEF:

    The use of TNEF is commonly affected by settings in Outlook that are referred to as "Microsoft Outlook Rich Text Format." Rich Text Format and TNEF are not exactly the same, but they are closely related.

    A TNEF-encoded message contains a plain text version of the message, and a binary attachment that "packages" various other parts of the original message. In most cases, the binary attachment will be named Winmail.dat, and may include:

    The formatted text version of the message (font information, colors, and such)

    OLE objects (embedded pictures, embedded Office documents, and such)

    Special Outlook features (custom forms, voting buttons, meeting requests, and such)

    Regular file attachments that were added to the original message

    In addition to the information listed above, the path to your personal folders file (PST) file and your logon name are embedded in the winmail.dat file. Although this data is not explicitly exposed to the recipient, if the recipient opens the winmail.dat file for editing in a binary or text editor, he can see the path and logon name. Note that no password information is revealed. To ensure that the path to your PST file or your logon name is not included in the winmail.dat attachment, use the steps in this article to send mail that does not include winmail.dat.

    Some Outlook features require TNEF encoding to be understood correctly by an Internet e-mail recipient who also uses Outlook. For example, when you send a message with voting buttons to a recipient over the Internet, if TNEF is not enabled for that recipient, the voting buttons will not be received. Alternatively, for sending messages with regular file attachments, TNEF is not needed. If you are sending e-mail with file attachments to a recipient who does not use Outlook or the Exchange Client, you should manually choose to use a mail format that does not require TNEF (such as plain text). By not sending TNEF messages, the recipient will be able to view and save the attachments as expected.

    Issues when Send & Receiving mails:

    When a message containing TNEF information is received by a mail client that does not understand TNEF, there are three common results:

    The plain text version of the message is received and it contains an attachment named Winmail.dat. The Winmail.dat attachment does not contain any useful information when opened since it is in the special TNEF format.

    The plain text version of the message is received and it contains an attachment with a generic name such as ATT00008.dat or ATT00005.eml. In this case the client is unable to recognize the TNEF part of the message, and is unable to recognize the Winmail.dat file name, so it creates a file name to hold the TNEF information.

    The plain text version of the message is received and the client ignores the Winmail.dat attachment. This is the behavior found in Microsoft Outlook Express. Outlook Express does not understand TNEF, but it does know to ignore TNEF information. The result is a plain text message.

    In addition to the receiving client, it is not uncommon for a mail server to strip out TNEF information from mail messages as it delivers them. If a server option to remove TNEF is turned on, clients will always receive a plain text version of the message. Microsoft Exchange Server is an example of a mail server application that has the option to remove TNEF from messages.

    Internet Standards - Message Encoding:

    The Internet standards for encoding messages such as Multipart Internet Mail Extensions (MIME) and UUENCODE are used independently of TNEF. TNEF can exist in a MIME-encoded message as a MIME body part of type "application/ms-tnef," or in a UUENCODED message as an attachment named Winmail.dat.

    When a TNEF message is sent using MIME, an entry similar to the following is added to the message:


    Alternatively, if a TNEF message is sent using UUENCODE, information similar to the following is added to the bottom of the message:

    begin 600 WINMAIL.DAT M>)\^(C<.`0:0" `$```````!``$``0>0!@`(````Y 0```````#H``$%@ ,` M#@```,L'" `$``<`)P`O``4`0 $!"8 !`"$````S,S5$,C,W,#%"0T-#13$ [. . .]

    In either case, the TNEF encoding is sent to the recipient and must be understood by the receiving client to correctly display the encapsulated information.


    For more information, please read this article

    TNEF & Winmail.dat 

    Exchange Server 2003 uses transport neutral encapsulation format (TNEF) to convert MAPI messages to RFC 822 format. TNEF appears on a message as a MIME attachment of type application/ms-tnef. The attachment is called Winmail.dat. It contains the full message content and any attached files. Only MAPI clients, such as Outlook, are able to decode the Winmail.dat attachment. Non-MAPI clients are unable to decode TNEF and might show Winmail.dat as a typical, but useless file.

    Note: Recipients with mailboxes on an Exchange server, who use Internet clients to access their messages, are not considered non-MAPI recipients. This is because the Exchange store that hosts the mailboxes can produce the necessary RFC 822 content in non-MAPI format when users download MAPI messages from their Inboxes using a POP3 or an IMAP4 client. There are several possible Exchange-to-Exchange transfer scenarios that require MAPI to RFC 822 conversion:

    • Recipient is on an Exchange server in the same routing group   Exchange Server 2003 renders MAPI messages into Summary-TNEF (S/TNEF) format, a special kind of transport-neutral encapsulation format (TNEF), which has no plain text part and is rendered in eight-bit binary format. S/TNEF messages consist only of Winmail.dat.

    Note: Within a routing group, Exchange Server 2003 always uses S/TNEF, because in all remote delivery cases, the message is guaranteed to take either an SMTP hop directly to a server running Exchange 2000 Server or Exchange Server 2003 or go to the Exchange MTA. Exchange 2000 Server and Exchange Server 2003 support binary MIME. On the other hand, if the message is passed to the Exchange MTA for delivery to a server running Exchange Server 5.5 through RPCs, message conversion is not required, because the RFC 822 format is not used.

    • Recipient is on an Exchange server in another routing group and the Exchange organization is operating in native mode   Exchange Server 2003 renders MAPI messages into Summary-TNEF (S/TNEF) format, because in native mode an Exchange organization can include only servers running Exchange 2000 Server and Exchange Server 2003 that support binary MIME.

    • Recipient is on an Exchange server in another routing group and the Exchange organization is operating in mixed mode   In mixed mode, it is possible to use the Internet Mail Service of Exchange Server 5.5 as an SMTP connector, but Internet Mail Service does not support binary MIME. Because the RFC 822 representation of S/TNEF that IMAIL generates is binary MIME, Internet Mail Service is unable to transfer S/TNEF messages. Because the Exchange categorizer cannot detect beforehand what route a message will take, the categorizer does not convert the message to S/TNEF for a recipient that is on a server outside the local routing group in mixed mode. To accommodate a potential Internet Mail Service instance in the transfer path, the Exchange categorizer converts the message to a plain text part and an attachment in legacy TNEF, which is seven-bit MIME that Internet Mail Service, can transfer.

    • Recipient is a MAPI recipient outside the local Exchange organization    Users and administrators can enable the transfer of TNEF across the boundaries of the local Exchange organization for recipients in external messaging environments who use Outlook. Because the recipient is not in the local Exchange organization, the Exchange categorizer cannot determine if all SMTP hosts involved in the message transfer support binary MIME. Correspondingly, the Exchange categorizer converts the message to a plain text part and an attachment in legacy TNEF.

    Note: Non-MAPI recipients typically prefer to receive a message in plain text or HTML without TNEF, because their clients cannot decode the Winmail.dat file that includes the message and all attachments. TNEF encapsulation prevents non-MAPI clients from accessing attachments. Non-Microsoft tools, such as EPOC WMDecode for Windows, might be able to extract attachments from Winmail.dat files.

    • MAPI messages sent to public folders   Messages sent to public folders are always relayed in legacy TNEF format.
    • MAPI messages sent to an expansion server over SMTP   If a message contains a distribution list with an explicit expansion server that is not the local server, the message is forwarded to the expansion server in legacy TNEF format (if SMTP is used for message transfer). In this case, a property is transmitted in the message transfer envelope through XEXCH50 that notifies the expansion server of the time the message was originally received through the Exchange store driver. After the categorizer on the expansion server expands the distribution list, it must apply the effective RFC 822 message formats to the individual recipients. The categorizer uses the Exchange store driver to copy the message to the Exchange store, where IMAIL reads the TNEF data to construct a MAPI message with the submit time of the original message. The SMTP transport subsystem can then read the MAPI message from the store in an RFC 822 format consistent with the recipients' formatting requirements.

    You can control the TNEF format behavior for sending messages by adding the following registry key. The number nn represents the virtual server instance for this machine.


    HKey_Local_Machine\Software\Microsoft\Exchange\StoreDriver\Exchange\ nn \EnableTnef





    Value Data



    A value of 0x0 disables TNEF, and messages are generated without using TNEF. A value of 0x1 will generate a message using legacy TNEF when S/TNEF would ordinarily be generated. A value of 0x2 has no effect, as that is the default behavior.


  • Le Café Central de DeVa

    Powershell &amp; cmdlet - In a Nutshell - Part 7 - Configure the Pickup directory using Set-TransportServer cmdlet


    Find the small article which talks about how to configure the pickup directory in Exchange Server 2007. 

    Exchange Server 2007 & configuring Pickup directory:

    Its' quite interesting to configure the pickup directory in Exchange Server 2007 environment. As we know that the Pickup directory is used by administrators for mail flow testing, or by applications that must create and submit their own messages. If we copy the correctly formatted e-mail message files to the Pickup directory are submitted for delivery.

    • If you've worked configuring with Exchange Server 2003, the same way it won't work "AS IS" in this environment. 
    • You cannot configure the Pickup directory by using the Exchange Management Console.
    • To configure the Pickup directory, you must use the Exchange Management Shell

    Some points to remember:

    • By default, the Pickup directory is located at C:\Program Files\Microsoft\Exchange Server\TransportRoles\Pickup. The directory must be local to the Exchange 2007 computer.

    • By default, the Pickup directory exists on every Exchange 2007 computer that has the Hub Transport server role or the Edge Transport server role installed. 

    • We must log on by using an account that is a member of the local Administrators group on that computer, where Edge Transport server role is installed.
    • By default, the Microsoft Exchange Transport service uses the security credentials of the Network Service user account to create the new Pickup directory and apply the correct permissions
    • Permissions required:
      • Administrator: Full Control
      • System: Full Control
      • Network Service: Read, Write, and Delete Subfolders and Files

    Set-TransportServer cmdlet: 

    To configure the Pickup directory location, we can make use of "Set-TransportServer" cmdlet. This cmdlet lets you configure any transport configuration parameter on a Microsoft Exchange Server 2007 Hub Transport or Edge transport server.

    The Set-TransportServer cmdlet manipulates the following groups of parameters:

    • Domain identity
    • Connection limiting
    • Failed message retry intervals and time-outs
    • Delivery status notification (DSN) messages, intervals, and time-outs
    • Domain Name System (DNS) sources
    • Protocol, undeliverable mail (badmail), and pickup storage location and file size
    • Message tracking location, age, and log size

    Note: The Set-TransportServer cmdlet does not require the Identity parameter to be specified when you run the command. When you use the Set-TransportServer command, you can set any number of parameters at the same time.

    Configuring the Pickup Directory Location:

    To set the Pickup directory to C:\Pickup Directory on an Exchange 2007 computer named Exchangesvr, run the following command:

    Set-TransportServer Exchangesvr -PickupDirectoryPath "C:\Pickup Directory"

    Note: Setting the value of the PickupDirectoryPath parameter to $null disables the Pickup directory. The directory that is specified by the PickupDirectoryPath parameter and the ReplayDirectoryPath parameter can't be the same.

    Still issues or not successful to configure Pickup directory location, you can create the new Pickup directory and apply the correct permissions to it before you use the PickupDirectoryPath parameter with the Set-TransportServer cmdlet.

  • Le Café Central de DeVa

    Creating MailBox Store programatically


    I have found this wonderful piece of code(Visual Basic 6.0), used to create mailbox store.

    '// Name:       CreateNewMailboxStoreDB
    '// Purpose:    To create a new Mailbox Store (MDB) with a given name
    '// Input:      strMDBName            = contains the name of the new MDB to be created
    '//             blnMount                    = True if the new MDB will be mounted after creation or False if the new MDB will not be mounted
    '//             strComputerName       = contains the name of the Exchange 2000 server
    '//             strSGName (Optional) = contains the name of the storage group to create the new MDB in; if it is empty then the new MDB will be created in the
    '//                                                  default Storage Group
    '//             strMDBUrl (Optional ByRef) = contains the URL to the new MDB created;

    Public Sub CreateNewMailboxStoreDB(ByVal strMDBName As String, ByVal strComputerName As String, Optional ByVal blnMount As Boolean, _
                                                              Optional ByVal strSGName As String, Optional ByRef strMDBUrl As String)

        Dim iServer         As New CDOEXM.ExchangeServer
        Dim iMDB            As New CDOEXM.MailboxStoreDB
        Dim arrStGroup()    As Variant
        Dim i               As Integer
        Dim strTemp         As String

        ' Set the name of the MailboxStoreDB
        iMDB.Name = strMDBName

        ' Bind to the Exchange Server
        iServer.DataSource.Open strComputerName

        ' Start to build the URL to the MailboxStoreDB - first part
        strTemp = "LDAP://" & iServer.DirectoryServer & "/" & "cn=" & strMDBName & ","

        ' Set variant array to the ExchangeServer.StorageGroups
        arrStGroup = iServer.StorageGroups

        ' Look in the StorageGroups array if the StorageGroup with strSGName exists
        If strSGName = "" Then
            ' Finish to build the URL to the MailboxStoreDB - add last part
            strMDBUrl = strTemp & iServer.StorageGroups(0)
            For i = 0 To UBound(arrStGroup)
                If InStr(1, UCase(arrStGroup(i)), UCase(strSGName)) <> 0 Then
                    strMDBUrl = arrStGroup(i)
                End If
            If strMDBUrl <> "" Then
                ' Finish to build the URL to the MailboxStoreDB - add last part
                strMDBUrl = strTemp & strMDBUrl
            End If
        End If

        ' Save the New MailboxStoreDB
        iMDB.DataSource.SaveTo strMDBUrl

        ' Mount the MailboxStoreDB if blnMount is True
        If blnMount = True Then
        End If

        ' Cleanup
        Set iServer = Nothing
        Set iMDB = Nothing

    End Sub

  • Le Café Central de DeVa

    Exchange Server 2003 SP2 - API Changes


    Microsoft have done changes in Exchange Server 2003 SP2. It includes new DLLs for several key APIs, and includes some key changes in behavior. While Exchange Server 2003 SP2 does not include any changes to the objects, classes, and interfaces, it does introduce key differences in how some of the APIs work.

    The following API libraries that ship with Exchange Server 2003 or with Microsoft Outlook 2003 have been updated in Exchange Server 2003 SP2:

    • Collaboration Data Objects for Exchange 2000 Server (CDOEX)   CDOEX ships as part of Exchange Server 2003, and must be run on the computer running Exchange Server 2003. The version of CDOEX.DLL that contains this change is 6.5.7638.2.
    • Collaboration Data Objects (CDO) version 1.2.1   CDO 1.2.1 is installed by Outlook 2003 and by Exchange Server 2003. CDO 1.2.1 is not redistributable, and must be run only on computers on which Outlook 2003 or Exchange Server 2003 is installed. The version of CDO.DLL that contains this change is 6.5.7638.2.
    • Exchange OLE DB (ExOLEDB) Provider   The ExOLEDB provider ships as part of Exchange Server 2003, and must be run on the computer running Exchange Server 2003. The version of the ExOLEDB provider DLL that contains this change is 6.5.7638.2.

    Important: These changes only affect the libraries that ship with Exchange Server 2003. The libraries that ship with Microsoft Windows XP, Microsoft Windows 2000 Server, Microsoft Windows Server 2003, and Microsoft Exchange 2000 Server are not affected by these changes.

    For more information, please find the detailed article available

  • Le Café Central de DeVa

    Powershell &amp; cmdlet - In a Nutshell - Part 8 - Configure deleted mailbox retention using Set-Mailboxdatabase cmdlet

    Now we'll discuss how to configure the deleted mailbox retention period in Exchange Server 2007

    Run the following command in Exchange Management shell,

    Set-MailboxDatabase dbName -MailboxRetention 32.00:00:00

    dbname - specifies database name,
    32.00:00:00 - specifies the retention period, i.e., the number of days, hours, minutes, and seconds required for it.

    By default, deleted mailboxes are retained for 30 days before they are purged from the mailbox database.
  • Le Café Central de DeVa

    MS Outlook 2007 PIA documentation available @ online


    Please find the Outlook 2007 PIA documentation available @ online

  • Le Café Central de DeVa

    Development related technology & feature changes: Exchange Server 2003 & Exchange server 2000


    Do you know?

    MS Exchange 2000 Server application development-related technologies and features were changed in MS Exchange Server 2003. Some technologies were enhanced, while others were removed, or are not supported in specific scenarios.

    • Exchange WMI Provider Changes
    • Active Directory Schema Changes
    • Managed Wrappers for SMTP Server Event Sinks
    • Anti-spam Infrastructure
    • CDO Component Names Did Not Change

    Exchange 2000 Technologies not Included with Exchange 2003:

    • M: Drive Mapping Removed
    • FrontPage Server Extensions Removed
    • Exchange Instant Messaging Removed
    • SQL Create Index Function Removed
    • Versioning Schema Properties Removed
    • MAPI Technology Changes
    • Visual Studio .NET Technology Support Policy
    • Anonymous Access to IIS Metabase Disabled
    • Public Folders Mail-Disabled by Default
    • savesentitems Field is ignored
    • Exchange 5.5 Event Agent Disabled by Default
    • MSDAIPP Cannot be Run on the Exchange Server

    More information is available at this following article, please click here

Page 1 of 1 (7 items)