Checking into it now. Feel free to contact me directly at jonu@microsoft.com.

Update: The script works as-is with IronPython 1.1, which was current when it was written. But not in IronPython 2.0.

If you change from this:

bytes = map(ord,list(query))
bytes = System.Array.CreateArray(System.Byte,bytes)

to this:

bytes = System.Text.Encoding.UTF8.GetBytes(query)

It works (for me, at least, on a VPN connection to my Exchange Server) in IronPython 2 as well.

Please let me know if this helps.

Meanwhile, having since learned a lot more iCalendar, and having used the DDay.iCal component for the elmcity project, I’m going to revisit this. I should probably use DDay.iCal to generate ICS more reliably than the ad-hoc way that script does it.

I installed Iron Python and downloaded your script, but I’m having some trouble getting it running. When I run:
ipy exchange2ical.py server user > user.ics
I get:
File “exchange2ical.py”, line 96 in exchange2ical.py. AttributeError: ‘type’ object has no attribute ‘CreateArray’

Am I missing something obvious? Thanks for your work on this!

As written, it uses your current Windows credentials. So if you run it from a logged-in PC, and your credentials are good for the Exchange server, it’ll work.

All that works well. You can access the script with some documentation etc at:
http://reminderfox.mozdev.org/utilities/PIM_escapeOL.zip

The trade-off of that solution: the HTA is threaded as SPAM with some Mail Services when sending it as an attachment.

So my Question:
Do you see another way to handle those JSCRIPTs and build a utility/standalone prog which doesn’t get problems with the Mail Servers?

Note: I don’t have any knowledge about Python :(

Right now I’m having trouble getting Codeplex to let me browse the source code, it keeps sending me to the license agreement page then back to the source code index (it did that yesterday, too, but it worked once).

My memory, though, is that you aren’t backslash escaping text in your SUMMARY, which is required for TEXT. Most calendar clients will tolerate the lack of escaping, but not all. Lone commas, for instance, may cause a parser to ignore everything after it.

http://severinghaus.org/projects/icv/

while very convenient, does not catch some iCalendar validation errors that the current version of Ben Fortuna’s iCal4j library for Java, on which this validator is purportedly based, routinely identifies.

Hmm. Yeah, that whole subject is deeply scary to me.

There’s surely more that can be done with the SQL / WebDAV, so far I’ve only cribbed from examples I could find. I’m hoping this will attract folks who know more about it and who can chime in.

> It tolerates some illegal things some
> calendar clients won’t, like the
> absence of
> a UID in VEVENTs, for instance.

Thanks for the tip. Is there a stricter validator?

While I’ve got you, do you have an opinion on punting the line folding?

As the author of a Python iCalendar library I suppose I ought to want you to use one, but I think Simplest Thing That Could Work is a better plan. It’s nice not to have to deal with Python dependencies.

I will note that since all your times are UTC, RRULEs aren’t going to work around DST transitions. But I’m not sure if Exchange gives you any reasonable timezone information, so fixing that problem would definitely be a pain.

Note that the “iCalendar validator” doesn’t actually do any validation, it just makes sure your file parses in iCal4J. The two are closely connected, but not quite the same thing. It tolerates some illegal things some calendar clients won’t, like the absence of a UID in VEVENTs, for instance.