First, a little background. For those of you who aren’t aware, when you access data via WebDAV on Exchange, calendar data is actually rendered as RFC 2445 iCalendar data. The iCalendar data has a lot of extra x-name stuff that is specific to Microsoft that allows it to support the additional MAPI information that’s needed for additional properties (that’s OK, RFC 2445 allows it). Anyway, Microsoft also provides a WebDAV-SQL dialect to query the data (not just for iCalendar stuff). This is great, because it lets you offload a lot of your effort for searching through the data on to the Exchange server.

Where things get a bit interested is when you are working with infinitely recurring appointments (recurring appointments without an end date). Internally, iCalendar is fine with this. The infinite pattern can be represented by a single iCalendar event, and everything is good. The twist is that when you search for events for a specific date range, Exchange will give you the parent event that actually represents the infinitely recurring pattern and a single event for each instance of your pattern that falls between your search date range. The single events list themselves as instances via a special property.

The reason for this behavior is most likely OWA. OWA is basically an early implementation of AJAX that has client side Javascript accessing a WebDAV back end. By instantiating all instances of the recurring pattern for you, much work is taken off of the front end for computing when instances of the recurring pattern should go. OWA just queries for a date range that’s either a day, week or month, and it’s given everything it needs. Exchange is even smart, in that once it has received a query for a certain date range, it caches the instance events on the back end and they become visible via WebDAV as separate entities.

The intelligent reader will notice an opportunity for problems here: if Exchange is instanciating and caching all these instances on the fly, a request with an open-ended date range search will never complete. Exchange would just keep instancing more an more instances. To avoid this problem, Microsoft implemented a system where you can only query a bounded date range of up to 2 years. Once you have queried for a specific date range and the results have been cached, open-ended range queries will return already cached instances, but for places where nothing was previously cached, nothing will be returned. Learned that gotcha the hard way.

The second problem with this caching strategy is that if unchecked, it would allow a client of intentionally or otherwise perform a DOS attack on Exchange. A client could continue to query 2 year date ranges forever, and force Exchange to cache more and more instances. To avoid this, Microsoft has implemented a cap as to how far into the future it will allow you to go. From what I can tell, this isn’t documented anywhere, but this is what I have determined experimentally on Exchange 2003:

1. Instances of infinite recurring appointments only seem to expand up until (approx) 10 year after the first date of the recurring meeting. This might actually not be time based, but rather # of occurrences based. I used an infinitely recurring appointment daily and it was about 10 or 11 years.
2. Instances of finite recurring appointment expand arbitrarily to the future, until the end of the prescribed recurrence patter (I only tested this with recurrence patters that have a specified number of recurrences, namely recurring monthly for 999 times, I did not test this with a set end date).
3. OWA suffers from the same limitation. If you try to view an appointment 30 years out for a daily infinite recurrence, it doesn’t show up.

The net result of this is that OWA will show an infinitely recurring appointment stopping sometime in the future, and your WebDAV queries might not return what you expect.

• UI jQuery Datepicker The standard datepicker available in the jQuery UI library. Pretty nice, though the visuals could use some work. The colors in the default control need some work.
• http://www.filamentgroup.com/examples/datepicker/ Based on the original codebase for the ui.datepicker jQuery control, this is a very impressive date range picker. Not completely in a reusable form at this point, but good nonetheless.
• Calendar This datepicker has a great visual appearance. It is build on top of the Mootools libary. This was actually my choice for a straight up datepicker until I realized that using jQuery and Mootools isn’t a walk in the park.

fsc --full-help

MSR F# Compiler, (c) Microsoft Corporation, All Rights Reserved
F# Version 1.9.2.9, compiling for .NET Framework Version v2.0.50727

Usage: fsc  [imported.dll … ] [file1.ml [file2.ml …] ]

Basic options:
  -I : Specify a directory for the include path.
  -r : Reference an F# or .NET assembly.
  -R : Reference an F# or .NET assembly and copy it locally.
  -o : Name the output file.
  -a: Produce a DLL.
  -g: Produce debug file. Disables optimizations if a -O flag is not given.
  –define : Define the given conditional compilation symbol.
  -i: Print the inferred interface of the assembly.
  -doc : Write the xmldoc of the assembly to the given file.
  -Ooff: Disable all optimizations, including JIT.
  -O0: Enable JIT optimizations.
  -O1: Enable JIT and local optimizations.
  -O: Same as -O2 (default unless -g)
  -O2: Same as -O1 but also enables cross module optimizations.
  -O3: Same as -O2 but with increased inlining and lambda lifting.
  –no-mllib:
        Do not implicitly reference mllib.dll or open
        Microsoft.FSharp.Compatibility.OCaml.Pervasives,
        useful if you wish to avoid dependencies on OCaml-compatibility library modules.
  –all-warnings: Print all warnings.
  –no-warnings: Do not print any warnings.
  –warn : Report the given specific warning.
  –no-warn : Do not report the given specific warning.
  –all-warnings-as-errors: Treat all warnings as errors.
  –warn-as-error : Treat the given specific warning as an error.
  –gnu-style-errors: Print line number errors in GNU style.
  –namespace :
        Define the default root namespace which will contain subsequent
        F# modules.
  –open :
        Open the given module as an initial definition for each source
        file, useful if you wish to use an alternative functional programming library.

  –fullpaths: Compiler generates fully qualified paths.
  –clr-root :
        Use to override where the compiler looks for mscorlib.dll and other framework
        components. Often needed when using –cli-version.
  –ml-compatibility: Treat F# keywords which are not OCaml keywords as identifiers.
        Also ignore OCaml-compatibility warnings.
  –copy-local : Locate the given file in the search paths and copy
        it locally (e.g. a PDB).
  –compiling-fslib: 
  –compiling-mllib: 
  -ifile : Print the inferred interface of the assembly to file.
  –target-exe: Produce an executable with a console
  –target-winexe: Produce an executable which does not have a
        stdin/stdout/stderr
  –target-dll: Produce a DLL
  –target-module: Produce a module that can be added to another assembly
  –auto-resolve: Automatically reference DLLs whose name matches a required
        F# module or namespace. Experimental.
  -c: Compile to a module (–target-module) and
        auto-resolve (–auto-resolve). Experimental.
  –standalone:
        Statically link the F# library and all transitively referenced DLLs
        that depend on the F# library into the assembly being generated.
        Disables the generation of the F# interface and optimization
        resources and renames all types beginning with Microsoft.FSharp,
        making them private to the target assembly. There must be no
        duplicate type names across any statically linked
        assemblies, no code may use reflection on any of the
        types in those assemblies, and no code may export F# library types
        as part of an API.
  –static-link :
        Statically the given assembly and all transitively referenced DLLs
        that depend on this assembly.  NOTE: use an assembly name e.g. mylib
        , not a DLL name, e.g. mylib.dll.
  –keyfile :
        Sign the assembly the given keypair file, as produced
        by the .NET Framework SDK ’sn.exe’ tool. This produces
        an assembly with a strong name. This is only relevant if producing
        an assembly to be shared amongst programs from different
        directories, e.g. to be installed in the Global Assembly Cache.
  –public-keyfile :
        Delay sign with the given public key file. The assembly can
        be fully signed later using ’sn.exe’ from the .NET Framework SDK.
  –retargetable : Specify that an assembly should be referenced in a
        retargetable fashion. Used to build binaries which are independent of
        the publisher of the referenced DLLs.
  –win32res : Specify a Win32 resource file (.res)
  –platform : Limit which platforms this code can run on:
                x86
                anycpu
        The default is anycpu. Other platform limitation specifications
        such as x64 and Itanium are not yet supported.
  –resource : Embed the specified managed resources (.resource).
        Produce .resource files from .resx files using resgen.exe or resxc.exe.
  –link-resource : Link the specified managed resource
        file (.resource). Produce .resource files from .resx files using resgen.exe
        or resxc.exe. Format may be [,[,public|private]].
  –base-address : Base address for the library to be built.
  –version-file :
  –version :
        Specify the version numbers for the generated .NET assembly
        (e.g. 1.2.0.1).
  –cli-version :
        Specify the CLI version to generate code for, regardless of the CLI you
        have installed at compile time.
        Valid values for this version of F# are:
                1.0
                1.1
                2.0
                build tags such as v2.0.x86chk
        You may have to add the right Framework directory to your include path, e.g.
                –clr-root \WINDOWS\Microsoft.NET\Framework\v1.1.4322
        You should also run the appropriate version of peverify on your
        binaries,e.g C:\Program Files\Microsoft Visual Studio .NET 2003\
        \SDK\v1.1\Bin\PEVerify.exe
        to ensure neither you nor any of the libraries you import
        have used features specific to other versions of the .NET Framework.
  –debug-file :
        Name the debug output file.
  –generate-debug-file:
  –no-debug-file:
        Control whether debug information is produced or not. Unlike -g
        this does not by default turn off optimizations.
  –no-debug-file:
        Control whether debug information is produced or not. Unlike -g
        this does not by default turn off optimizations.
  –generate-html:
        Generate HTML documentation.
  –html-output-directory :
        Output directory for HTML documentation.
  –html-css :
        Set the name of the Cascading Style Sheet for HTML docs.
  –html-namespace-file :
        Set the name of the master namespaces.html file
        assumed to be in the output directory.
  –html-namespace-file-append:
        Append to the master namespace file when generating HTML documentation.
  –no-optimization-data:
        Only add optimization information essential implementing ‘inline’
        constructs. Inhibitscross-module inlining but improves binary compatibility.
  –generate-optimization-data-file:
        Place optional information in a .optdata file associated with the
        generated assembly.
  –no-interface-data:
        Don’t add a resource to the generated assembly containing the
        interface data for use by other F# assemblies. The assembly can then
        only be accessed as a .NET assembly.
  –quotation-data:
        This flag is now obsolete. Use the ReflectedDefinition attribute instead.
  –generate-config-file:
        Generate a config file to ensure that a .exe runs on the
        version of the CLR specified by –cli-version.  The
        file will contain a ’supportedRuntime’ XML element.
  –jit-optimize:
  –no-jit-optimize:
  –local-optimize:
  –no-local-optimize:
  –cross-optimize:
  –no-cross-optimize:
        Fine grained control for JIT, local and cross-module optimizations.
  –fast-sublanguage-only:
        Restrict the F# langauge slightly to rule out constructs that are
        more difficult to compile efficiently, leading to more optimization
        opportunities for the compiler. This can significantly improve
        performance. Combines all the –no-ABC flags that follow.
  –no-inner-polymorphism:
        Do not permit inner bindings to be genuinely polymorphic.
  –permit-inner-polymorphism:
  –no-string-interning: Do not intern compiled string constants at runtime.
  –statistics: Show statistics of compiler.
  –progress: Show progress of compiler.
  –no-framework:
        Do not reference the .NET Framework assemblies by default.
  –sscli:
        Force the compiler to look use the installation
        of the SSCLI found on the path rather than an installed Microsoft CLI.
        Also produces debug information in the SSCLI format.
  –max-errors : 
  –generate-filter-blocks: Generate filter blocks to allow first-chance
        exception catching for non-matching exceptions
  –stamps: 
  –ranges: 
  –terms: 
  –termsfile: 
  –ilfiles: 
  –times: 
  –detuple : 
  –tlr : 
  –tlrlift : 
  –no-env: 
  –parse-only: 
  –typecheck-only: 
  –ast: 
  –tokenize: 
  –testInteractionParser: 
  –light: 
  –lightoff: 
  –inline-threshold : 
  –extra-optimization-loops : 
  –generics:
  –no-generics:
        Fine grained control over whether to produce code for a .NET CLR
        that supports generics.
  –all-tailcalls:
  –no-tailcalls:
        Fine grained control over whether to emit tailcall annotations.
  –closures-as-virtuals:
        Fine grained control over the implementaion of closures.
  –multi-entrypoint-closures:

Microsoft has some helpful instructions on how to accomplish all this for the .NET 2.0 framework. This article describes how to accomplish the configuration in .NET 2.0. The article also links to another article that describes how to create a service account for use with this type of authentication.

NOTE: All of this assumes that you want to use a single account for your web app and give that account access to the database. The application itself is responsible for authenticating users and making sure they have rights to perform all operations within your application. This is referred to as a trusted subsystem model. As such, the discussion below assumes that you are not using impersonation the users that are accessing your web app.

The same techniques can be applied to .NET 1.1 (and probably 1.0) ASP.NET apps. There are two ways to setup the Windows Authentication: using the Network Service account on your webserver (the easy way) and using a domain authenticated account specific for your application (the hard way).

Network Service Authentication

Starting with the Network Service account approach, you only need to do two things:

1. Give the account access to your database via SQL Server Management studio (assuming SQL Server 2005; with 2000 you would use Enterprise Manager)
2. Configure your connection string in your web.config file (or wherever you are storing it)

To configure SQL Server, create a new login with the login name:

Domain\WebServerName$

So my web server, Fozzie, on the Example domain would be Example\Fozzie$. Be sure to use Windows Authentication when you create the login, and be sure to map the login to the appropriate users on your desired database.

To configure your database connection string, use one of the equivalent options Trusted_Connection=Yes or Integrated_Security=SSPI. So your database connection strings would be of the form (stolen from Microsoft article):

Server=MyServer;Database=MyDb;Trusted_Connection=Yes;

or

Initial Catalog=MyDb;Data Source=MyServer;Integrated Security=SSPI;

The disadvantage of using the Network Service account to authenticate your application with SQL Server is that all web applications running on the same server will use the same account to authenticate, and thus will have access to each other’s databases. If this is not acceptable, the other option is to use a domain account for your web app.

Domain Account

Using a domain account to run your web application will give you more granular control of the application’s access to resources and will allow you to isolate different applications running on the same server. Configuring a web application to run as a domain account involves the following steps:

1. Create a domain account for use with the application
2. Give account access to database in SQL server
3. Give account needed rights to run ASP.NET application
4. Revoke right for account to log on locally to computers
5. Create app pool in IIS that uses the domain account as its process identity
6. Configure web application to use custom app pool
7. (optional)Create service principal names (SPNs) for the domain account