Bruce Jackson's WebLog

Sample application and code showing how to connect and synchronize with Exchange Server over HTTP using WebDAV

2005-02-03T06:55:00Z

Recently, one my ISV partners told me that they wanted to create a bi-directional Exchange Server connector to keep calendars synchronized between their Exchange Mail Server and their application. To make this more challenging, they wanted to be able to deploy this in environments where RPC connectivity was turned off.

There were a couple of approaches we could take to solve the problem. The first was to enable RPC over HTTP in Windows 2003. The second was to use the WebDav interfaces into Exchange as OWA does. Once I verified that we didn’t require additional functionality than that provided by OWA, I decided to use the Dav interfaces.

I thought I’d also share the code (C#) and so feel free to download the documentation, code, and sample application from here. You can also view a short BlogCast here.

Here is a quick list of what is included:

¾ Remote Exchange Authentication over HTTP or HTTPS by way of either Basic Authentication or Forms-Based Authentication.

¾ Illustrates “Subscribe and Poll” for asynchronous notification of new or changed objects such as new or changed mail, appointments, tasks, etc.

¾ Illustrates “Subscribe and Notify” for synchronous notifications.

¾ How to Read and Send Exchange Mail using DAV.

¾ How to read, create, or modify appointments in Exchange using DAV.

In order to exercise these server-based classes, I have also included a sample client application that will send cell phone SMS messages alerting you of appointment reminders at the times specified in the Exchange based appointment.

Sample Code for IPSec Block Application

2004-08-23T22:47:00Z

As I pointed out in my previous post, I have written a couple of applications for my Exchange Server at home and I would post the code if anyone was interested. I’ve had a couple of requests and so I’ve created a web site where I’ll post links to the sample code. Disclaimer: I know the UI is terrible, but the more I try to make my web UI attractive, the worse it gets. So my motto is: “simple is better”.

The first is an SMTP Event Sink that handles my spam protection and I call SpamSinker. I need to clean up the code some and will post up the source when I get that done.

The other was a small application I wrote that I had planned to incorporate into SpamSinker, but is currently a small stand-alone application I call BlockIp. It uses the Dynamic Block of IPSec to prevent remote computers from connecting to my machine.

I wrote this because my analysis of the spam log files showed that spammers tend to use a range of IP addresses for a few days and then they move on. Instead of depending on the SpamSinker tool to catch them, I decided that once the number of inbound spam messages exceeded a certain threshold from an IP, then IPSec would block all future traffic from the IP. BlockIP was the first step in writing that code.

The following is a rough description of what the app does:

BlockIp checks for a list of IP Addresses to block when it first starts up. If the list doesn’t exist, it creates one. Although this file is in a .txt format, it actually is stored as xml so that the code can use the data classes generated by the MsDatasetGenerator I mentioned in my last post.

Next, it reads and lists in the UI all the IP Addresses you want to block. It also allows you to remove one or more from the existing list.

When you press the “Save” button, it will invoke the IPSec filter (using the NetSh command) which will remain in effect until you reboot the box; or until you press the “Disable Filters” in the UI.

It would be very easy to change these from dynamic to static. However, I chose dynamic filters since the objective was very specific: to only block IP Addresses temporarily when Spammers were using them and to release the blocks after a few days.

Feel free to download and modify the code for your use. It is a bit rough and was not written to be sample code but merely as a placeholder until I could move it into SpamSinker and so I apologize in advance for the bogus variable names and the lack of comments. Hopefully, when I have time to move it into SpamSinker, I’ll have time to polish it up and add a few comments.

Using XML Files as a Portable Application Database using MsDatasetGenerator

2004-08-21T01:16:00Z

Almost every application can benefit from persisting data into a local and portable data repository. For example, I worked for the tools group in Microsoft's IT department writing internal software tools when Microsoft first released Access. I would use Access to store user and error information for my applications while they were in beta. I remember one specific application that would "crash" the same time each day and by looking at the Access db, I found what the error was and more importantly, who had been using it when it crashed. It was a simple matter to call that individual and get a better understanding of what they had been doing and why so I could code around the mistake. I've also used this approach with external customers and simply asked them to email me the Access .mdb file so I could determine what the problems were.

Visual Studio contains a lightly documented tool called the MsDatasetGenerator (there is a similar but less robust tool in the .NET SDK called xsd.exe) that allows you to do similar things with xml files. Much like Access, these xml files are portable and can be used across several applications. Let me describe some of the ways I've used these and then provide a step-by-step to show you how to get started.

I run Exchange 2003 on my home network and since my daughters are in college, they use OWA to access their mail and so the cool Outlook 2003 Junk Email filter doesn't catch their spam. So, I decided to write my own Spam filter using .NET and the new SCL in Exchange. I won't go into details here of that application, but suffice it to say that I use rather resource-intensive Reverse DNS to determine if a message is from a spammer. If so, I add their IP to the xml "database". In that way, the application knows that the IP Address is from a probable spammer and in future requests (until the TTL expires), we don't do the DNS lookup again - just check the xml database. I have shared this application with Exchange hosting orgs and they found as I did, that the performance impact was negligible. This attests to the power and speed of these XML "databases" even when there are thousands of entries as I have in my spam xml database.

I later enhanced the application to tell me the reason (I have several methods I use to mark the SCL) for the detection as well as to increment the hit count from that IP. This allowed me to write another application that used the same xml file to evaluate the spam hits on the server. I found that over a short period of time, spammers will flood my server from several bogus domains but using the same rather small set of IP Addresses. So, I wrote a third application that would use IPSec to block the IPs at the network stack. This application would read the Exchange Spam XML file and organize the hits and display them. This third app would then let me mark which ones I wanted to block and it would store them in another xml database file for the IPSec filter. That way, the block list would load each time I ran the app or rebooted the server.

The point is, that these files are quick, easy, portable, and an easy way to share data between applications.

Oh, and if any of these apps sound useful, reply with a comment and I’ll write another Blog with a pointer to the code which you can download and use.

OK, so let’s look at some code.

1. Open Visual Studio and create a C# Console application.

2. Next, using the Solution Explorer, create a New Xml file and call it: testXml.xml

3. Put in the following content and save the file:

<root>

</root>

4. Next, in VS create the schema for the xml file (right-click over the .xml file and select Create Schema). You should now have a “testXml.xml” file and a “testXml.xsd” file.

Open the Properties dialog for the testXml.xsd file. In the Custom Tool box, key in: MSDatasetGenerator. Enable the “Show all Files” so you can see the newly generated testXml.cs file.

6. Open the testXml.cs file and notice that over 300 lines of C# code has been generated for this three line xml file. Review the code and you will see that this tool has created code to support collections, events, etc.

In the Main function (assuming a Console C# app), paste the following code:

// create an instance of the testxml dataset

testXml mytest = new testXml();

// you can load data from an existing xml file, this shows how easy it is to move data from

// one location or application to another.

// mytest.ReadXml(@"c:\myxmlfile.xml");

//or, you can simply populate the dataset and save it to disk

mytest.myData.AddmyDataRow("my first row data1", "my first row data 2");

mytest.myData.AddmyDataRow("my second row data1", "my second row data 2");

// can use the collections to interate through

foreach (testXml.myDataRow row in mytest.myData.Rows)

{

System.Diagnostics.Debug.WriteLine("Stuff 1: " + row.myDataStuff1);

System.Diagnostics.Debug.WriteLine("Stuff 2: " + row.myDataStuff2);

}

mytest.WriteXml(@"C:\myoutput.xml");

You’re done. With the tool generated code, you can easily add items, browse through collections, and move the dataset from one application to another, and you never have to use XPath or open the XML in your code!