Wiz/dumb : WebDAV

You Say Toemaytoe I Say Tahmahtah

Patrick Creehan — Wed, 16 Jul 2008 16:23:29 GMT

We’ve seen a bunch of folks asking recently if their Exchange 2007 CAS server can talk to their Exchange 2003 mailbox server. The answer is <gasp> it depends on what you mean.

It depends on what technology you are referring to and what you mean by “talk.” Are you referring to WebDAV calls? Then yes. Are you referring to OWA? Then sorta. Are you referring to Exchange Web Services (EWS), then no. There are really two things at play here: proxy and redirection. That is, can an Exchange 2007 CAS server serve as a proxy for calls to the backend mailbox server, or can it successfully redirect calls to the mailbox server where the call can be handled.

In Exchange 2003, HTTP calls were simply forwarded on from the front-end to the back-end. The back-end server would receive the HTTP request and handle it and then forward the response back up through the front-end. In Exchange 2007, however, the front-end CAS handles the HTTP request and speaks RPC to the back-end server.

When a request is received by a CAS server, it knows how to figure out who should handle the request – whether it needs proxied to a different CAS, or can be sent directly to an Exchange 2003 or 2007 back-end. For example, when a request is received for the /exchange virtual directory on a mailbox on an Exchange 2003 server, the HTTP request is forwarded to the appropriate server. So in this way, OWA still works from your 2007 CAS – even though the client will see the OWA 2003 interface. The same is true for activesync clients requesting the \Microsoft-Server-ActiveSync vdir.

If an Exchange Web Services call hits an Exchange 2007 CAS and the CAS is able to determine that the mailbox is on an Exchange 2003 back-end the call will fail since proxying cannot be performed.

Here’s more on the topic:

Overview of Exchange Server 2007 CAS Proxying and Redirection

Understanding Proxying and Redirection

How does E2k7's API Stack Stack up?

Patrick Creehan — Fri, 20 Jun 2008 22:21:02 GMT

Check this out:

Exchange Server 2007 Legacy API Property Mapping

This helps you compare WebDAV/CDOEX props to EWS properties. Also discussed are CDOEXM and WMI replacements and the look ahead.

ARGH: Large WebDAV PROPPATCH requests fail with 401/401.5

Patrick Creehan — Tue, 17 Jul 2007 19:09:00 GMT

I had a case recently where one of our products, Duet, was doing a large PROPPATCH against Exchange 2003 and it was failing with a HTTP 401 error. The customer noticed that small PROPPATCH requests succeeded, but large ones (bigger than say 25 KB) would fail. Well, we knew that it couldn't be a permission problem, because small ones succeeded, right?

After more digging around and more test scripts, we discovered that large PUT requests worked just fine and that the large PROPPATCH would work for Exchange Admins. The clues are starting to come together. I was immediately reminded of a known issue with CDOSys where large attachments are first cached to the TEMP directory before being sent via transport . If the user executing the code does not have permissions to the temp directory, they get an 80004005 Access Denied when they try to Send the message. Could we be doing something similar with WebDAV, writing the request to the disk first for large requests?

Sure enough, a FileMon indicated that we would receive an ACCESS DENIED when trying to create a file in the C:\WinNT\Temp directory called something like $ETn.tmp, where n is an integer that increments.

In my test environment, where I had previously been unable to reproduce the customer's problem, granted Authenticated Users the ability to Create Files, Write, and Read from this directory. By adding an explicit Deny ACE to this folder for my test user, I was finally able to reproduce his behavior exactly.

If your Exchange or IT Admins have locked down your server by modifying or removing this ACE, try giving your test user Modify permissions on the C:\WinNT\Temp directory and see if you don't get a better result.

HOWTO: Get Email Messages from Exchange to SharePoint

Patrick Creehan — Tue, 06 Feb 2007 19:15:00 GMT

Many people ask about how to do this, so I thought I'd write up a sample. This sample basically searches the inbox of a user and then does an HTTP GET against the DAV:href to get the EML file and then does an HTTP PUT to upload it to a SharePoint document library.


using System; 
using System.Web; 
using System.Xml; 
using System.Net; 
using System.Text; 
namespace UploadEmlToSharePoint 
{ 
    /// <summary> 
    /// Summary description for Class1. 
    /// </summary> 
    class Class1 
    { 
        static System.Net.CredentialCache MyCredentialCache; 
        /// <summary> 
        /// The main entry point for the application. 
        /// </summary> 
        [STAThread] 
        static void Main(string[] args) 
        { 
            System.Net.HttpWebRequest Request; 
            System.Net.WebResponse Response; 
            string strRootURI = "http://exchangeserver/exchange/User1/Inbox/"; 
            string strSPSRootURI = "http://wss/Shared%20Documents/"; 
            string strUserName = "User1"; 
            string strPassword = "Passw0rd"; 
            string strDomain = "DOMAIN"; 
            string strQuery =""; 
            byte[] bytes = null; 
            System.IO.Stream RequestStream = null; 
            System.IO.Stream ResponseStream = null; 
            XmlDocument ResponseXmlDoc = null; 
            XmlNodeList ResponseNodes = null; 
            XmlNamespaceManager xmlnsm = new XmlNamespaceManager(new NameTable()); 
            xmlnsm.AddNamespace("a","DAV:"); 
            try 
            { 
                // Build the SQL query. 
                strQuery = "<?xml version=\"1.0\"?><D:searchrequest xmlns:D = \"DAV:\" >" 
                    + "<D:sql>SELECT \"DAV:displayname\" FROM \"" + strRootURI + "\"" 
                    + "WHERE \"DAV:ishidden\" = false AND \"DAV:isfolder\" = false" 
                    + "</D:sql></D:searchrequest>"; 
                // Create a new CredentialCache object and fill it with the network 
                // credentials required to access the server. 
                MyCredentialCache = new System.Net.CredentialCache(); 
                    MyCredentialCache.Add( new System.Uri(strRootURI), 
                    "NTLM", 
                    new System.Net.NetworkCredential(strUserName, strPassword, strDomain) 
                ); 
                MyCredentialCache.Add(new System.Uri(strSPSRootURI), 
                    "NTLM", 
                    new System.Net.NetworkCredential(strUserName, strPassword, strDomain)); 
                // Create the HttpWebRequest object. 
                Request = (System.Net.HttpWebRequest)HttpWebRequest.Create(strRootURI); 
                // Add the network credentials to the request. 
                Request.Credentials = MyCredentialCache; 
                // Specify the method. 
                Request.Method = "SEARCH"; 
                // Encode the body using UTF-8. 
                bytes = Encoding.UTF8.GetBytes((string)strQuery); 
                // Set the content header length. This must be 
                // done before writing data to the request stream. 
                Request.ContentLength = bytes.Length; 
                //Set the translate header to false 
                Request.Headers.Add("Translate","f"); 
                // Get a reference to the request stream. 
                RequestStream = Request.GetRequestStream(); 
                // Write the SQL query to the request stream. 
                RequestStream.Write(bytes, 0, bytes.Length); 
                // Close the Stream object to release the connection 
                // for further use. 
                RequestStream.Close(); 
                // Set the content type header. 
                Request.ContentType = "text/xml"; 
                // Send the SEARCH method request and get the 
                // response from the server. 
                Response = (HttpWebResponse)Request.GetResponse(); 
                // Get the XML response stream. 
                ResponseStream = Response.GetResponseStream(); 
                // Create the XmlDocument object from the XML response stream. 
                ResponseXmlDoc = new XmlDocument(); 
                ResponseXmlDoc.Load(ResponseStream); 

                ResponseNodes = ResponseXmlDoc.GetElementsByTagName("a:response"); 
                if(ResponseNodes.Count > 0) 
                { 
                    Console.WriteLine("Non-folder item hrefs..."); 
                    // Loop through the display name nodes. 
                    for(int i=0; i<ResponseNodes.Count; i++) 
                    { 
                        // Display the non-folder item displayname. 
                        XmlNode responseNode = ResponseNodes[i]; 
                        XmlNode hrefNode = responseNode.SelectSingleNode("a:href",xmlnsm); 
                        XmlNode displayNameNode = responseNode.SelectSingleNode("a:propstat/a:prop/a:displayname",xmlnsm); 

                        //Downloads the EML file from the specified URL 
                        byte[] emlFile = GetBytesFrom(hrefNode.InnerText);

//Uploads the EML file to the SharePoint document library UploadToSPS(emlFile,strSPSRootURI + System.Web.HttpUtility.UrlPathEncode(displayNameNode.InnerText)); } } else { Console.WriteLine("No non-folder items found..."); } // Clean up. ResponseStream.Close(); Response.Close(); } catch(Exception ex) { // Catch any exceptions. Any error codes from the SEARCH // method request on the server will be caught here, also. Console.WriteLine(ex.Message); } Console.WriteLine("Done."); Console.Read(); } static byte[] GetBytesFrom(string DavURL) { Console.WriteLine(DavURL); byte[] buffer; System.Net.HttpWebRequest Request; System.Net.HttpWebResponse Response; System.IO.Stream ResponseStream; Request = (HttpWebRequest)HttpWebRequest.Create(DavURL); Request.Credentials = MyCredentialCache; Request.Headers.Add("Translate","f"); Response = (HttpWebResponse)Request.GetResponse(); ResponseStream = Response.GetResponseStream(); buffer = new byte[Response.ContentLength]; ResponseStream.Read(buffer,0,(int)Response.ContentLength); ResponseStream.Close(); Response.Close(); return buffer; } static void UploadToSPS(byte[] fileBytes, string URL) { Console.WriteLine("Uploading " + fileBytes.Length.ToString() + " bytes to " + URL); System.Net.HttpWebRequest Request; Request = (HttpWebRequest)HttpWebRequest.Create(URL); Request.Credentials = MyCredentialCache; Request.ContentLength = fileBytes.Length; Request.Method = "PUT"; System.IO.Stream str = Request.GetRequestStream(); str.Write(fileBytes,0,fileBytes.Length); str.Close(); Request.GetResponse(); } } }

What am I gonna do with 40 subscriptions to http://Vibe?

Patrick Creehan — Thu, 28 Sep 2006 21:37:00 GMT

So this is a scenario you could easily find yourself in as one of my larger customers did recently. The answer is also one of the less-obvious, more obvious of answers. So imagine the scenario: you have load balanced Exchange FE (front end) boxes serving a myriad of back ends. Or, in a slightly less dramatic scenario, you have a stand-alone box with a few mailbox stores on it....In either case, or several in between, the problem may surface. You are writing an application that uses the WebDAV subscription/call-back notification capabilities of Exchange to monitor for updates to certain folders in certain mailboxes. Your application has a list of paths to subscribe to (http://email.domain.com/Exchange/mailbox1/Calendar, http://email.domain.com/Exchange/mailbox2/Calendar, etc). As it rolls through the subscription list, you notice that the subscription-id header you are returned appears to be a duplicate!

Well this just won't do. How will your application be able to effectively know what folder issued the notification when the subscription-id now seems apparently ambiguous. The answer, my friend, is the OTHER header you are returned...subscribe-group. Subscribe-group is the base64-encoded GUID of your store. Subscriptions are managed per store which means if you have more than one store on a box, or more than one back end Exchange server, you have more than one subscription list being maintained. The only way to distinguish between them is to capture the subscribe-group header in addition to subscription-id. The NOTIFY on callback will provide you with both and so will the response to your SUBSCRIBE request, so you should be good to go. You will already implicitly know what store you are talking to when you POLL, so the subscribe-group does not need to be echoed to the server. Subscribe-group only helps the client application know which subscription it is receiving a call back for.