To complement my series on client-side calendar publishing, I’ve been looking for a way to push ICS files from Exchange. Why? A couple of local organizations with calendars I’d like to include in my calendar syndication project are running Exchange. It’s true that individuals within those organizations can use Outlook 2007 to publish calendars to the Internet. But companies like to manage these processes centrally. If the city wants its recreation center to publish summer activities, the city’s IT department should be able to do that whether or not the rec center’s desktop machine is alive.
Several folks suggested that the WebDAV interface to Exchange is the way to go, and after noodling on that for a while I’ve come up with a solution that seems to work. (I’ve tested it on a server here in my lab, and against my account on a production server.) I’m planning to release it as a CodePlex project, but as a Microsoft employee I have to cross a few t’s and dot a few i’s to get that done.
Meanwhile, since I’ve never administered Exchange, I have some questions for those who have. What I’ve got is a 100-line IronPython script that can be run on a scheduled basis. You give it a hostname and an account name, it reads events from that account’s calendar, and emits an ICS file.
First question: How does this fit in with your workflow? If you’re a town government, how would you like to manage your public calendar from Exchange? For example, would employees in various departments share one account that corresponds to that calendar? Would you rather divvy things up and then syndicate a set of calendars?
Second question: How will you want to publish the ICS file? My script only creates it. To publish the file to the Net, it could be copied to a directory on a webserver, or it could be uploaded to lots of places in lots of ways. It’s good to have choices, but it’s also good to have a sensible default, and I’m not sure what that should be.
Third question: Would you deploy this thing? I hope the small footprint will help. Being wary myself of solutions that haul in boatloads of requirements, I’ve whittled them down. You only need IronPython, plus of course the .NET Framework which it requires.
Originally, I was also using a few things from standard Python: command-line arguments, regular expressions. But it struck me that requiring all of standard Python for just those things was overkill, so I switched to their IronPython/.NET equivalents.
IronPython itself, resting as it does on the .NET foundation, is a tiny installation. Even so, it’ll be a new and unfamiliar thing to most people. Would an Exchange admin be willing to install IronPython on a production server and allow it to do the things this script does?