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?
June 6, 2008 at 9:58 am
If i ever meet you, I’m going to give you a big kiss, and I don’t make a habit of kissing men. Let us know when it’s published – I’ve been looking for a way to do this.
June 8, 2008 at 5:21 pm
I think I’ve mentioned this before, but for one purpose we have (publicizing public hearings), we need to select a set of events, and when they get published, we would ideally have:
One .ics file for each event
One .ics file for all events in the selected set
HTML (or XML from which we could derive it) for those files – each event would have an icon/button to open its .ics file; the re would be an icon/button to open the file with all of the events.
Optionally a way to download those files, so others could “pass the word” although there are risks involved and it might be better just to pass the link.
An individual person or company may only be interested in one hearing, and would add just that one to their calendar. A “citizen’s watchdog”-type group might want to track all of them.
June 11, 2008 at 11:52 am
[...] Posted by Jon Udell under Uncategorized The Exchange-to-iCalendar script that I mentioned here is now published to CodePlex. It’s intended for organizations that run Exchange and would [...]
June 16, 2008 at 12:41 pm
Hi. I’ve run Exchange servers before and expect to run them again (currently I’m outsourcing Exchange). I’ve been reading your blogs and articles off an on for a decade, you seem like a smart guy, but I wouldn’t run your script on my (somewhat theoretical) production Exchange server. I would consider running it in a test environment, on a non-Exchange server, connecting to a test Exchange server, to see how it works. If I had a good test environment which mimicked load and task patterns on a production Exchange server, I might develop sufficient comfort to deploy your code. Even then, I’d be uncomfortable running it directly on the Exchange server. Who has the budget for such a test environment for corporate email? And the time to maintain it properly? Nobody I’ve ever met ;]
Exchange is too huge, fussy, and essential to mess with (I assume) lightly-tested code. This is the problem with commercial software. Only Microsoft can really, really fix Exchange when it really blows up. Only Microsoft can validate 3rd-party add-ons to Exchange. Who will validate your light-weight, useful, easily deployed application? The Exchange dev/qa team? A 3rd-party Exchange-app lab? Most sysadmin teams have insufficient budgets and/or staff, and enormous responsibility for uptime, data integrity, data security, etc. This makes them (us) highly risk-averse.
June 16, 2008 at 3:49 pm
> I wouldn’t run your script on my
> (somewhat theoretical) production
> Exchange server.
Note that the script needn’t run on the Exchange server, it only needs to run on some server that can contact the Exchange server and make HTTP requests of it, in the same way that OWA (Outlook Web Access) makes requests of it.
That said, I understand and well appreciate your point about aversion to risk. So, it’s good that there’s also the option to publish from Outlook 2007.