PURPOSE: Collect ETL trace from Exchange Server 2007 & 2010 to troubleshoot Exchange Web Services related issues.

Applies to: Microsoft® Exchange Server© 2007 & 2010

Steps

1) Go to CAS Server and fire up Extra.exe (%PROGRAMFILES%\Microsoft\Exchange Server\Bin\ExTRA.exe)
2) This will bring the following window, click on ‘Select a task’

3) Click on “Trace Control”

4) Configure the trace options, file location, maximum file size (100-200mb should be enough for normal scenarios)
5) Select sequential logging, and run traces for a time period in which you should be able to reproduce the issue. Usually 300 seconds are good enough to switch over and reproduce the error.
6) Click “Set components and tags for the type of tracing selected”
7) Type of tracing will be “6. OWA Tracing”

8) Under trace types, select all of them to get a verbose log
9) Under components, OWA will be selected by default – you might want to uncheck that as it will add logs for OWA traffic as well
10) Choose trace components according to your problem, in basic scenarios and EWS issues MSExchangeWebServices should be sufficient.
11) These are the providers which looks good to get a detailed log and uncovering the hidden issues somewhere in the communication.
                    a. ADProvider
                    b. ADRecipientCache
                    c. ADExpansion
                    d. AuthenticationProvider
                    e. Common
                    f. Diagnostics
                    g. MSExchangeWebServices
                    h. NetworkingLayer
12) Once done, hit Start tracing

13) It will run the trace for the specified duration, keep it running and reproduce the problem

14) Once done it will generate a binary file (.ETL) which contains all the proprietary & confidential debugging information related to the product.

15) Take instructions from the Microsoft Support Professional on how to send the file back to him/her.

DISCLAIMER: THE STEPS BELOW CAN IMPACT THE PERFORMANCE OF THE EXCHANGE SERVER AND MUST BE PERFORMED IN GUADIANCE OF MICROSOFT SUPPORT PROFESSIONAL. IN NO EVENT SHALL MICROSOFT, ITS AUTHORS, OR ANYONE ELSE INVOLVED IN THE CREATION, PRODUCTION, OR DELIVERY OF THE DOCUMENT BE LIABLE FOR ANY DAMAGES WHATSOEVER (INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS OF BUSINESS PROFITS, BUSINESS INTERRUPTION, LOSS OF BUSINESS INFORMATION, OR OTHER PECUNIARY LOSS) ARISING OUT OF THE USE OF OR INABILITY TO USE THE DOCUMENTATION, EVEN IF MICROSOFT HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

I got this customer, like all others complaining that they cannot set the contact’s Physical Address to a blank value. The same contact can be updated using EWS SOAP API but not with managed API… hmm… I knew the answer already

Error Message: The request failed schema validation: The element 'Updates' in namespace 'https://schemas.microsoft.com/exchange/services/2006/types' has incomplete content. List of possible elements expected: 'AppendToItemField, SetItemField, DeleteItemField' in namespace 'https://schemas.microsoft.com/exchange/services/2006/types'.

Here is the code which was causing the trouble

        static void UpdateContact(ExchangeService svc,ItemId id)

        {

            Contact myContact = Contact.Bind(svc, id);

            PhysicalAddressEntry paEntryHome = null;

            PhysicalAddressEntry paEntryBusiness = null;

            paEntryHome = new PhysicalAddressEntry();

            paEntryHome.Street = "";

            paEntryHome.City = "";

            paEntryHome.PostalCode = "";

            paEntryHome.State = "";

            paEntryHome.CountryOrRegion = "";

            paEntryBusiness = new PhysicalAddressEntry();

            paEntryBusiness.Street = "";

            paEntryBusiness.City = "";

            paEntryBusiness.PostalCode = "";

            paEntryBusiness.State = "";

            paEntryBusiness.CountryOrRegion = "";

            myContact.PhysicalAddresses[PhysicalAddressKey.Home] = paEntryHome;

            myContact.PhysicalAddresses[PhysicalAddressKey.Business] = paEntryBusiness;

            try

            {

                myContact.Update(ConflictResolutionMode.AlwaysOverwrite);

            }

            catch(Exception e)

            {

                Console.WriteLine(e.ToString());

            }

        }

So what was the trouble in the code, it look pretty neat.. huh? Not exactly. You are creating a new instance of PhysicalAddressEntry instead of using the existing object given by Managed API..

Only, few lines of code change and it started to work like charm.. here is the working code for the same.

        static void UpdateContact(ExchangeService svc,ItemId id)

        {

            Contact myContact = Contact.Bind(svc, id);

            PhysicalAddressEntry paEntryHome = null;

            PhysicalAddressEntry paEntryBusiness = null;

            paEntryHome = myContact.PhysicalAddresses[PhysicalAddressKey.Home];

            paEntryBusiness = myContact.PhysicalAddresses[PhysicalAddressKey.Business];

            paEntryHome.Street = "";

            paEntryHome.City = "";

            paEntryHome.PostalCode = "";

            paEntryHome.State = "";

            paEntryHome.CountryOrRegion = "";

            paEntryBusiness.Street = "";

            paEntryBusiness.City = "";

            paEntryBusiness.PostalCode = "";

            paEntryBusiness.State = "";

            paEntryBusiness.CountryOrRegion = "";

            try

            {

                myContact.Update(ConflictResolutionMode.AlwaysOverwrite);

            }

            catch(Exception e)

            {

                Console.WriteLine(e.ToString());

            }

        }

Hope this helps you all.

Happy coding / debugging!!!

First thought was registry, but that gets little messy.. you go to HKCR & then parse through it to find the location of Outlook.exe… I didn’t like that much, and that was not sure shot way… I could delete the Outlook.exe and it will still point me to the same path. You might ask why would someone delete the Outlook.exe and leaving other registry entries? My answer is because you can and then the registry solution will break.

So why not ask the Outlook itself where are you buddy? Nice, you would say, if only he can speak… yes he can!!! Here is how its done in C#

I am using Reflection to create an object to Outlook.Application. You can use this to create an object of any COM Object though. Whenever you create the object to a COM server inside EXE, its EXE is launched if not running already. So all you need to do is use System.Diagnostics.Process class to get its Process Path.

using System;
using System.Reflection;
using System.Diagnostics;

namespace OutlookLocationFinder
{
    class Program
    {
        static void Main(string[] args)
        {
            System.Type objType = null;
            object comObject = null;
            string version = string.Empty;
            Process[] p = null;

            try
            {

                // Create an object to Outlook.Application , replace with your COM Server's ProgID
                objType = System.Type.GetTypeFromProgID("Outlook.Application");

                // Activate the object
                comObject = System.Activator.CreateInstance(objType);

                // This is Outlook specific, I am calling the member property to get the version of Outlook
                version = (string)objType.InvokeMember("Version",
                               BindingFlags.InvokeMethod, null, comObject, null);
            }
            catch
            {
                Console.Write("Unable to create the object of type \"Outlook.Application\"");
            }

            // Whenever you create the object to a COM server inside EXE, its EXE is launched if not running already
            // Now, just get hold of the Process by its name
            p = Process.GetProcessesByName("Outlook");
            
            // Beware there could be multiple instances running of the same application, we just care about first one.
            if (null != p && p.Length > 0)
                Console.WriteLine("Outlook ({0}) is launched from: {1}", version, p[0].MainModule.FileName);
            else
                Console.WriteLine("Outlook does not seem to be installed properly on this machine, could not find process running on local machine");

            Console.Write("Press any key to exit.");
            Console.ReadKey(false);
        }
    }
}

Happy Coding / Debugging !!!

[View:https://www.youtube.com/watch?v=WyqkqVJ_6Ak]

Download the source code from below, feel free to use the code of this application for personal & educational purposes. Written permission is required prior to any commercial use of the code.

Have fun, happy coding!!!

QuickTimer_SourceCode_v1.0.zip

Cause: This is a known issue with Microsoft Product (Outlook 2010) and we have an internal fix available. The fix is expected to go public with the release of next Service Pack for the product.

Repro Code:

1. Setup a POP3 only profile
2. Make sure that there is at least one mail item in the Inbox.
3. Make the Inbox the current folder and run the following code:

Sub TestAddAttachment()
    Dim objItem As Outlook.MailItem
    Dim objAttachments As Outlook.Attachments
    Dim objItemAtt As Outlook.MailItem
   
    Set objItem = Application.CreateItem(olMailItem)
    objItem.Subject = "TestAddAttachment"
    Set objItemAtt = Application.ActiveExplorer.Selection.Item(1)
    Set objAttachments = objItem.Attachments
    objAttachments.Add objItemAtt, Outlook.olEmbeddeditem, 1, objItemAtt.Subject
    objItem.Display
End Sub

Actual Result:

objAttachments.Add raises an error:

Run-time error '-2147221233 (8004010f)':
The attempted operation failed. An object could not be found.

Expected Result: 

No error

Workaround:

There is a workaround by saving the embedded item to the file system, similar to the following:

Sub TestAddAttachmentWorkaround()
    Dim objItem As Outlook.MailItem
    Dim objAttachments As Outlook.Attachments
    Dim objItemAtt As Outlook.MailItem
    Dim strPath As String
   
    Set objItem = Application.CreateItem(olMailItem)
    objItem.Subject = "TestAddAttachment"
    Set objItemAtt = Application.ActiveExplorer.Selection.Item(1)
    strPath = Environ("TEMP") & "\testmsg.msg"
    objItemAtt.SaveAs strPath, olMSG
    Set objAttachments = objItem.Attachments
    objAttachments.Add strPath, Outlook.olEmbeddeditem, 1, objItemAtt.Subject
    objItem.Display
    Kill strPath
End Sub

Please contact Microsoft PSS if you are affected by this problem and cannot wait until next service pack release of Outlook 2010.

This was the configuration of the default Receive connector, pretty secured…huh??? Yeah!!!

Goal:  Send secured emails using CDOSYS over TLS using BASIC authentication

Challenges:  ‘80040213’ The transport failed to connect to the server.

I confirmed that the issue is not in connectivity and I could easily do a telnet to port 25 and get the banner and supported verbs lists. The problem was that I could not do STARTTLS… heck it was not listed in the verbs list. With my “Mr. Fix It” cap on I took an ETL trace and started debugging the issue.

I concluded that the certificates was the blocking issue, and I quickly turned back to the Event Viewer to see the following event log

Event Type:       Error

Event Source:    MSExchangeTransport

Event Category: TransportService

Event ID:          12014

Date:                7/23/2010

Time:                6:26:25 PM

User:                N/A

Computer:         MSGEX07

Description:

Microsoft Exchange couldn't find a certificate that contains the domain name msgex07.msglab.com in the personal store on the local computer. Therefore, it is unable to support the STARTTLS SMTP verb for the connector Default with a FQDN parameter of msgex07.msglab.com. If the connector's FQDN is not specified, the computer's FQDN is used. Verify the connector configuration and the installed certificates to make sure that there is a certificate with a domain name for that FQDN. If this certificate exists, run Enable-ExchangeCertificate -Services SMTP to make sure that the Microsoft Exchange Transport service has access to the certificate key.

For more information, see Help and Support Center at https://go.microsoft.com/fwlink/events.asp.

Once I have resolved the Certificate issues, I can see the STARTTLS verb supported by the Exchange server.

If you do not see STARTTLS and DO see the event log entry then you need to verify the following things

1) The FQDN of the server which is specified in the code, abc.xyz.com MUST match with the FQDN of the certificate

2) The FQDN of the Receive Connector MUST match the FQDN of the certificate

3) The Certificate in itself should be a valid one (not expired or with missing root CA)

You can verify these details with the help of your Exchange Admin and the following Powershell Cmdlet

Get-ExchangeCertificate | fl

Enable-ExchangeCertificate –Services SMTP

New-ExchangeCertificate

See the below link for more information

Reference: https://technet.microsoft.com/en-us/library/bb430748.aspx

You will notice the following error message displayed instead..

"This type of message isn't fully supported in Conversation mode. Click here to open the full version, which may show you more details or features."

This same form should work in Exchange 2007.

I have two news here, first there has been changes to Registry.xml and there has been couple of new clients support added. Make sure you have all of them listed in your Registry.xml when you run the test on Exchange 2010

    <Client Application="MSIE" MinimumVersion="7" Platform="Windows NT" />
    <Client Application="MSIE" MinimumVersion="7" Platform="Windows 2000" />
    <Client Application="MSIE" MinimumVersion="7" Platform="Windows 98; Win 9x 4.90" />
    <Client Application="Safari" MinimumVersion="3" Platform="Macintosh" />
    <Client Application="Firefox" MinimumVersion="3" Platform="Windows NT" />
    <Client Application="Firefox" MinimumVersion="3" Platform="Windows 2000" />
    <Client Application="Firefox" MinimumVersion="3" Platform="Windows 98; Win 9x 4.90" />
    <Client Application="Firefox" MinimumVersion="3" Platform="Macintosh" />
    <Client Application="Firefox" MinimumVersion="3" Platform="Linux" />
    <Client Application="Chrome" MinimumVersion="1" Platform="Windows NT" />

Secondly, This issue is “by design” that the custom forms will not work in Conversation Mode for now.

This issue seems like something obvious that the product group will want to fix in the next major version.   It is currently not under consideration for a service pack or rollup for Exchange 2010, but may be considered at some point based on customer feedback.

If this issue is causing troubles for you then I would request you to contact PSS.

The SmtpClient class only supports the SMTP Service Extension for Secure SMTP over Transport Layer Security as defined in RFC 3207. In this mode, the SMTP session begins on an unencrypted channel, then a STARTTLS command is issued by the client to the server to switch to secure communication using SSL. See RFC 3207 published by the Internet Engineering Task Force (IETF) for more information.

An alternate connection method is where an SSL session is established up front before any protocol commands are sent. This connection method is sometimes called SMTP/SSL, SMTP over SSL, or SMTPS and by default uses port 465. This alternate connection method using SSL is not currently supported.

This is the limitation of SmtpClient and publically documented here but often missed

https://msdn.microsoft.com/en-us/library/system.net.mail.smtpclient.enablessl.aspx

You may also ask your service provider to see if they can support STARTTLS sessions, which is fairly secure and not too complex to implement.

You have an option to use either CDOSYS / System.Web.Mail from .Net 1.1 which internally uses CDOSYS to send out email. CDOSYS had this support but then the support was dropped in System.Net.Mail. Some may argue that why this downgrade, when CDOSYS had this support why System.Net.Mail drop this support – well this is not really a downgrade but a design decision that they made to support only one of the two optional ways to implement SSL while the SMTPS is used less commonly when compared to TLS.

Here is the sample code that can do the job for you, please do not forget to add a reference to System.Web.dll into your project for this to work. I have compiled it on VS2008 and found it working.

Please do proper testing before using this code in production and treat this piece of code just for the sake of educational purpose.

using System;
using System.Collections.Generic;
using System.Text;
using System.Web.Mail;
 
namespace ConsoleApplication2
{
    class Program
    {
        static void Main(string[] args)
        {
 
            MailMessage msg = new MailMessage();
            msg.To = "to@server.com";
            msg.From = "from@server.com";
            msg.Subject = "This is a test email using System.Web.Mail";
            msg.Body = "Hello There!!!";
            msg.BodyFormat = MailFormat.Text;
 
            // SMTP Server to use
            msg.Fields.Add("https://schemas.microsoft.com/cdo/configuration/smtpserver", "smtp.server.com");   
 
            // SMTP Port to use
            msg.Fields.Add("https://schemas.microsoft.com/cdo/configuration/smtpserverport", "465");                 
            
            // Send using Value, leave it to 2 for sending via SMTP Port specified
            msg.Fields.Add("https://schemas.microsoft.com/cdo/configuration/sendusing", "2");                        
            
            // Use SSL : 0 = False, 1 = True
            msg.Fields.Add("https://schemas.microsoft.com/cdo/configuration/smtpusessl", "1");                       
 
 
            // Authentication mode: 
            //  0 - Anonymous
            //  1 - Basic
            //  2 - NTLM
            msg.Fields.Add("https://schemas.microsoft.com/cdo/configuration/smtpauthenticate", "1");
 
 
            // Username and password to connect to the SMTP Server
            msg.Fields.Add("https://schemas.microsoft.com/cdo/configuration/sendusername", "USERNAME_HERE");
            msg.Fields.Add("https://schemas.microsoft.com/cdo/configuration/sendpassword", "PASSWORD_HERE");
 
            SmtpMail.Send(msg);            
 
        }
    }
}

We have an official release for the issue and if you are facing this problem then I would recommend you contacting PSS and refer to this blog

https://blogs.msdn.com/b/vikas/archive/2010/04/05/bug-net-4-0-system-net-mail-unable-to-send-emails-with-large-attachments-more-than-3mb.aspx

I am expected it to be released in a public KB in some time but for the time being you can request for the hotfix by contacting PSS

UPDATE - 7/21/2010

If you prefer not to contact PSS, you can download the hotfix by yourself from the following link.

https://connect.microsoft.com/VisualStudio/Downloads/DownloadDetails.aspx?DownloadID=30226

Although if the same application is executed outside Service Control Manager then it work and is able to create the profile just fine.

In both cases we found out that the older versions of OLMAPI32 had this problem and you MUST upgrade to the latest version 12.0.6514.5000 or above

Publically available latest version is “October 2009 security update” - https://support.microsoft.com/kb/972363