Exchange of experiences / Erfahrungsaustausch / Get Help
You are not logged in.
|Der Kauf von iCal4OL ist vorübergehend wieder möglich, aber es gibt keinen Demo-Support.
Zur Konfiguration die FAQ lesen!
|The purchase of iCal4OL is temporarily possible again, but there is no support for the demo.|
For configuration read the FAQ!
iCal4OL Version 2.14.12 is now available. See Announcements / Ankündigungen
Sync Outlook with a Web Solution (Groupware) by CalDAV/GroupDAV/CardDAV
Use one of the Assistants on tab "Who" for initial CalDAV Setup!
GERMAN: Eine Beispielskonfiguration finden Sie hier!
ENGLISH: An example configuration you'll find here!
- iCal4OL is a Standalone Sync Solution - and not an "event driven" CalDAV Client-Addin for Outlook (OL).
This approach has some big advantages: Stable(!) and reliable, and working with every version of Outlook >= 2000.
(OL bugs - like forgetting to fire events when busy - make it nearly impossible, to program a real stable CalDAV Client for Outlook!)
(A few limitations for OL2010 64-bit apply, for the moment. See in German/English).
- The userinterface is odd... actually created before CalDAV was implemented.
As single person company, I just don't have the time (and money) to develop a new better interface.
Therefore I concentrate my efforts on the quality of the sync!
- The Sync is highly optimized and will take normally, from second sync on (=incremental), depending on configuration, just 1-5 minutes or even less.
- The Sync can be run e.g. every 10 minutes in the background => which is really fast enough for CalDAV.
There are special links under START - All Programs - iCal4OL ... to start iCal4OL directly in the background (tasktray).
- I did a lot of testing with Sunbird and ICAL 3.0 (Mac OS X Leopard) as CalDAV clients, which are working well together with iCal4OL.
- iCal4OL is a complex program. It's due to the different implementations/interpretations of the CalDAV/iCalendar "Standard", and due to wishes of my customers ;-)
- iCal4OL seems to be - for the moment - the only working CalDAV solution for Outlook on the market, but not easy to set up.
- iCal4OL will work on far eastern OS, like CHINESE, too. If you see wrong character handling, see http://ical.gutentag.ch/documentation.html#O16 about "Import UTF-8 decode".
JUST ASK, if something is not clear! iCal4OL comes with free, fast responding support!
Supported CalDAV enabled Websolutions and Stores: (sorted by name)
==> CardDAV Contact Sync is on tab "Contacts". See Homepage for supported server solutions (2). See http://ical.gutentag.ch/documentation.html#D14 for URL examples and flags.
- New implementation.. - see Help for your CalDAV Server Implementation and common mistakes..
- All Connected 4: UGO 2.0 (French)
- Atmail - Browserinterface - Settings - Calendar - CalDAV => use this URL in Assistant [Other] on tab "Who"!
- Baikal - will be/is supported from 2.13.5 on.
- Bedework - see http://ical.gutentag.ch/forum/viewtopic.php?id=132
- Chandler Cosmo
- Citadel >= 7.51 by GroupDAV (without exceptions of recurring events), see http://ical.gutentag.ch/forum/viewtopic.php?id=138
- CommuniGate Pro >= 5.2 - see http://ical.gutentag.ch/forum/viewtopic.php?id=160 for configuration - some special options are needed!
- Convergence 7 - actually not supported, but works. See http://ical.gutentag.ch/forum/Convergence7.pdf
- Darwin CalendarServer (iCalServer) and AddressbookServer
See here for latest improvements http://ical.gutentag.ch/forum/viewtopic.php?id=207 for Snow Leopard
Details for Darwin (like delegation/attendee handling) you'll find here: http://ical.gutentag.ch/forum/viewtopic.php?id=49
Darwin AdressBookServer SL is supported from 2.9.9 on!
- DAViCal 0.9.4.0 (or higher versions)
Note: 0.9.9.4 has a bug with <lastmodified>. Use "Carddav" in field "UserID:"! (Download newest version of iCal4OL, if 13 type mismatch error shows up.
- DavMail 3.9.6 Calendar and Contacts - Tasks can't work, due to missing field LAST-MODIFIED - circumvention see below (field UserID).
Important: Use [X] Select time period, with a rule like "from -31 to +365 days" ==> a rule WITH a TO-DATE!
It seems, LAST-MODIFIED is strangely handled by DAVMail (like events are added in the past..).
Open Bug: It looks like, uploading events to Exchange 2007 are always added in UTC-Time, instead in correct Timezone.
With DAVMail it becomes possible to sync Exchange hosted Calendars and Contacts over OWA with e.g. Google or another CalDAV Solution.
Configure on a second server a single Outlook profile with multiple calendar folders for each Exchange user/calendar.
You will need multiple configuration files (*.ini), but you can achieve nearly everything - if you set it up properly ;-)
Ask for support, describing exactly what you want to do.. by opening a new topic here in the forum.
eGroupware 1.4.004 by GroupDAV (no tasks) see http://ical.gutentag.ch/forum/viewtopic.php?id=68
eGroupware 1.6.001 and 1.6.002 by GroupDAV see http://ical.gutentag.ch/forum/viewtopic.php?id=68
eGroupware >= 1.6.003 and EPL 10.1 by CalDAV see http://ical.gutentag.ch/forum/viewtopic.php?id=221
- eGroupware >= 1.8.004 and EPL 11.1 by CalDAV - Older versions are not supported anymore! It's your own risk..
Latest improvements for Branch/Trunc Version and >=1.8.001: http://ical.gutentag.ch/forum/viewtopic.php?id=256
IMPORTANT: Every account in eGW MUST have a unique email address (which must correspond with the fields on tab "Who")
- Google Calendar by CalDAV (no tasks) - Important: CalDAV v1 over Assistant URL www.google.com works officially "not anymore", but does... See http://googleblog.blogspot.ch/2013/03/a … eaning.htm l
Google CalDAV v2 is out, using Assistant URL apidata.googleusercontent.com and OAuth 2.0
The integrated Google Calendar API v3 Sync is by far better = more options!
In CalDAV you must take care, not to upload attendees, or they are invited by email again, see flags "no_att" and "bodyatt"
- GroupOffice Prof by CalDAV
- Horde 5.1.3 by CalDAV
- ICEWARP >= 9.4.2 see http://ical.gutentag.ch/forum/viewtopic.php?id=127
- iCloud.com - See short introduction here (old): http://ical.gutentag.ch/forum/viewtopic.php?id=389
- Infomaniak - please ask for support http://www.infomaniak.com/ directly..
- Kerio Mailserver >= 6.7.0
Very helpful, if you need to filter events of existing Outlook Calendar Folders during Sync
Limitation: Tasks are always synced to the user main tasks folder of Kerio
For Kerio 7.x read http://ical.gutentag.ch/forum/viewtopic.php?id=291
- maXvis - please ask www.maxvis.de for support directly..
MobileMe Calendar at https://cal.me.com (Darwin based). Use the Darwin CalDAV AutoConfig Assistant for correct configuration
MyRoundCubeis NOT supported by iCal4OL and does not work! Events do not show up in the browser interface..
- OpenXChange (from 16.2.2013 on) see http://ical.gutentag.ch/forum/viewtopic.php?id=597
- Owncloud see http://ical.gutentag.ch/forum/viewtopic.php?id=452
- Posteo.de do not use the calendar browser interface = extremly buggy. Only access it by CalDAV/CardDAV clients. For CardDAV download (again) 2.12.24
- Radicale Assistant does not work, please see http://ical.gutentag.ch/forum/viewtopic … 2013#p2013 how to configure
- Scalix 11.4.6 see http://ical.gutentag.ch/forum/viewtopic … 1307#p1307
- SmarterMail (older version: no special characters upload possible (öéä), because UTF-8 is not understood by SmarterMail<10. CardDAV does work!)
- SOGo >= 1.0.4 CalDAV and CardDAV
- Synology Diskstation, see http://ical.gutentag.ch/forum/viewtopic … 1573#p1573
- Terminland.de - please ask for support http://www.terminland.de directly. Monthly and yearly recurring events are not supported by Terminland.de!
- Tine 2.0 - see http://ical.gutentag.ch/forum/viewtopic.php?id=459
- Tobit David.FX-Server 2011, see http://ical.gutentag.ch/forum/viewtopic.php?id=286
TribalOS see http://www.tribalos.com ... probably not working anymore
- Yahoo Calendar (based on Zimbra 6/7) see http://ical.gutentag.ch/forum/viewtopic.php?id=116
HTTP 503 Server Error - Upload of many events can cause it. Add "wait1s" or "wait2s" into field "UserID/Kennung" to slow down the upload.
- Zimbra 5 RC2 and 6 (with contacts) - see http://ical.gutentag.ch/forum/viewtopic.php?id=112
- A CalDAV-Server is integrated, too!
Connect Sunbird/ICAL/iOS Clients directly to an Outlook Calendar & Tasks (OL2010 64-bit is not supported)
Documentation see http://ical.gutentag.ch/forum/viewtopic.php?id=82
How to configure manually: ==> Better use the Autoconfiguration Assistants (Wizards) on tab "Who"!
Tab WHO: Fullname, Email address (must match the server account => enter User you want to sync with OL!) and your Timezone.
Tab WHAT: 2-Way Synchronization with Web Solutions (by CalDAV/GroupDAV + WebCalendar 1.05)
You will need multiple configuration files (*.ini) to sync multiple Outlook-(Sub-)Calendars with different Websolution-Calendars!
Use button [Save Configuration as..] to make a copy of a configuration file.
In the Default(.ini) configuration file activate those other configuration files on tab "Start" to run all together (=chaining).
A Right-Click on tab "Run" on a configuration file will show a Context Menu (Popup), for easier management of multiple configurations (*.ini)
(to modify a different configuration file, you may want to use tab "Configurations" and load them by e.g. double click...)
Tab HOW: The button [URL:] does show an older half-automatic assistant, which may help choosing the correct collection on the server.
URL examples for manual configuration - try first Assistants on tab "Who": (user=placeholder for account name)
Atmail..............: Login into browser interface. The URL for the Assistant (on tab "Who") is under [Settings] - Calendar - CalDAV
Chandler Cosmo: https://hub.chandlerproject.org/dav/collection/ba1060a0-c4f5-11dd-ab74-93de7c1bde9e/
Citadel 7.51......: http://localhost:2000/groupdav/Calendar/
(No support for moved or deleted occurrences of repeating events, see http://ical.gutentag.ch/forum/edit.php?id=401 for using WebDAV)
(It's necessary to mark (tab "Options-HTTP_DLL): [X] Use WinInet.dll instead of WinHttp.dll)
Convergence 7..: https://calendar.yourserver.com/dav/home/<userEmail>/<Calendarname>/
DavMail 3.9.x....: http://w3server:1080/users/Office@TEST.local/calendar/
by HTTPS.: https://www.example.com:8443/principals/users/ (update first to 2.14.0) Mavericks
Darwin Wiki 2.5.: http://ical.example.com:8008/calendars/__uids__/wiki-testwiki/calendar/
eGW 1.4.004 ....: https://www.example.com/egroupware/icalsrv/groupdav.php/calendar <== without trailing / eGW 1.6.00x ....: https://www.example.com/egroupware/groupdav.php/calendar/
EGroupware.... .: https://www.example.com/egroupware/groupdav.php/user/calendar/
This different URL will change the behavior for "denied" event-invitations and "finished tasks" - they are not in the feed!
EPL .................: https://www.example.com/egroupware/groupdav.php/user/calendar/
This different URL will change the behavior for "denied" event-invitations and "finished tasks" - they are not in the feed!
GOOGLE v1.......: https://www.google.com/calendar/dav/<calid>/events/ v1 API until 26. Sept. 2013
GOOGLE v2.......: https://apidata.googleusercontent.com/caldav/v2/<calid>/events/ v2 API with OAuth 2.0 from iCal4OL 2.13.8 on
GroupOffice Prof: https://office.xxxxx.fr/office-xxxxxx/modules/caldav/calendar.php/calendars/roland/roland-ics4ol-5/
Horde 5.1.3.......: http://demo.horde.org/rpc.php/calendars/demo/calendar:TqA5gU6arTLLlWFPFx7OPw5/
Kerio 6.7.0 ......: http://Server/caldav/domain.com/username/Calendar/
Kerio 7.x.x ......: http://Server/full-calendars/domain.com/username/Calendar/ (Tasks always sync with the main Kerio Task Folder!)
OpenXchange...: https://dav.openxchange-server.de/caldav/nn/ (nn=Number of Collection)
Owncloud 3.0....: http://Server/owncloud/apps/calendar/caldav.php/calendars/username/default%20calendar/
Owncloud 4.x....: http://demo.owncloud.org/dev/remote.php/caldav/calendars/username/default%20calendar/
Posteo.de.........: https://posteo.de:8443/calendars/username/default/ (example, use Assistant [Others])
Scalix 11.4.6....: http://example.com/api/dav/Calendars/Users/<user@domain>/<Calendar>/
SOGo 1.0.4.......: http://sogo-demo.inverse.ca/SOGo/dav/sogo1/Calendar/personal/
Note: text "sogo" must be part of the URL, so iCal4OL can recognize a SOGo Server
Synology..........: http://xxxx.example.com:5005/public/CaldavTest/Test/ or https://xxxx.example.com:5006/public/CaldavTest/Test/
DSM 4.2.x: Always with trailing slash!
Tine 2.0...........: http://my.example.com/tine/webdav/Calendar/personal/admin/Tine%202.0%20Admin%20Accounts%20pers%C3%B6nlicher%20Kalender/
Tobit David.......: http://example.com/caldav/
YAHOO.............: https://caldav.calendar.yahoo.com/dav/your_username/Calendar/your_calendar_name ("your_username" is lowercase)
It's necessary to mark (tab "Options-HTTP_DLL): [X] Use WinInet.dll (or LibCurl.dll) instead of WinHttp.dll.
There seems to be an issue with LOGON: If "Your_Username" is not working, try "email@example.com" in lowercase!
Login.............................: user (the calendar owner(!) login; Password field does not matter)
Button [Authentication]: user + password (same as above OR other user/password, which has full access to this calendar = ACL rights!)
UserID(Kennung)..........: caldav deleted remove ... ...and other flags, depending on your CalDAV-Solution!
The Assistants (Wizards) will fill the flags as needed - here for manual configuration:
Make sure, you installed the NEWEST version of iCal4OL.
Atmail Darwin.....: caldav deleted remove firstsimilar darwin 10 inbox status multiget no_auth limit
Atmail SabreDAV: caldav deleted remove firstsimilar organizer singleget href carddav singlecontacts (from version 2.12.3 on)
Baikal................: caldav deleted remove tasks firstsimilar organizer multiget carddav=11 singlecontacts (from version 2.13.5 on)
Bedework >=3.7: caldav deleted remove tasks firstsimilar organizer inbox status
Bedework 3.6....: caldav deleted remove tasks firstsimilar inbox status singleget <== there is a bug in Bedework<3.7
Chandler Cosmo: caldav deleted remove [tasks] firstsimilar organizer multiget (Not sure if tasks are supported...)
Citaldel 7.51......: caldav groupdav deleted remove tasks firstsimilar
Citaldel 7.84......: caldav groupdav deleted remove tasks firstsimilar notes dtstamp+1
Citaldel 8.0........: caldav groupdav deleted remove tasks firstsimilar notes
CommuniGate...: caldav deleted remove tasks=Tasksfoldername firstsimilar SingleExceptions <== Tasks=OtherTaskFolder, if not default "Tasks"
caldav deleted remove tasks=Tasksfoldername firstsimilar organizer <== newer versions, e.g. 5.3.14 !
Convergence 7..: caldav deleted remove organizer singleget older href ==> no tasks
Darwin 9 ..........: caldav deleted remove darwin inbox firstsimilar tasks (leopard)
Darwin 10 ........: caldav deleted remove darwin 10 inbox status firstsimilar multiget tasks (snow leopard / lion)
Darwin Wiki 2.5.: caldav deleted remove darwin 10 inbox status firstsimilar no_auth (Wiki may need extra flag ignoreLMT, but test it first without)
Mavericks.........: caldav deleted remove darwin 10 firstsimilar multiget older carddav singletasks
DAViCal ..........: caldav deleted remove tasks firstsimilar organizer inbox carddav
or: caldav deleted remove tasks firstsimilar organizer inbox carddav multiget (faster, needs FROM-Date)
or: caldav deleted remove tasks firstsimilar organizer inbox carddav singleget (does not need a FROM-Date)
or: caldav deleted remove tasks firstsimilar organizer carddav multiget older (only ETAG comparision)
DavMail 3.9.x...: caldav deleted remove firstsimilar organizer singleget older carddav singlecontacts
caldav deleted remove firstsimilar organizer singleget carddav singlecontacts [no_auth] singletasks older <= with tasks!
Important: Use [X] Select time period, with a rule like "from -31 to +365 days" ==> a rule WITH a TO-DATE! Incremental Sync may not work!
eGW 1.4.004.....: caldav groupdav deleted remove firstsimilar <== by GroupDAV => no tasks!
eGW 1.6.001.....: caldav groupdav deleted remove tasks firstsimilar <== by GroupDAV
eGW 1.6.002.....: caldav groupdav deleted remove tasks firstsimilar <== by GroupDAV
eGW 1.6.003.....: caldav deleted remove tasks firstsimilar
EGroupware 1.8: caldav deleted remove tasks firstsimilar organizer multiget
EPL >=11.1......: caldav deleted remove tasks firstsimilar organizer multiget <== Stylite AG
Google v1.........: caldav firstsimilar organizer multiget no_auth up asFeed no_Att BodyAtt for uploading a previous imported Remote Calendar, no tasks!
caldav deleted remove firstsimilar organizer multiget no_auth carddav singlecontacts no_Att BodyAtt for 2-Way-Sync, no tasks but CardDAV
CalDAV v1 API of Google Calendar will only work until 26. Sept. 2013!
Google v2.........: caldav deleted remove firstsimilar organizer multiget OAuth no_Att BodyAtt from 2.13.8 on, no tasks, no CardDAV (for now), different URL!
GroupOffice Prof: caldav deleted remove firstsimilar organizer singleget includetasks GO (you MUST use "singleget", and for tasks "includetasks") ("go" or "carddav=13 singlecontacts" for CardDAV..)
Fruux...............: caldav deleted remove tasks firstsimilar organizer multiget carddav singlecontacts no_auth
Horde 5.1.3......: caldav deleted remove firstsimilar organizer multiget older no_auth carddav singlecontacts horde newconn + e.g. tasks=ETE6z_46CbDG0IX-_c-wRQ6
ICEWARP>9.4.1: caldav deleted remove tasks firstsimilar organizer
Infomaniak.......: caldav deleted remove tasks firstsimilar organizer multiget older no_auth carddav singlecontacts href
iCloud..............: caldav deleted remove inbox tasks=<guid> firstsimilar multiget no_auth (other flags are default for iCoud, like "href older noinvite no_ctag organizer")
Kerio 6.x..........: caldav deleted remove tasks firstsimilar singleget href no_global (you MUST use singleget)
Kerio 7.x..........: caldav deleted remove tasks firstsimilar singleget href no_global older organizer inbox (you MUST use "singleget older")
Kerio 8.x..........: caldav deleted remove tasks firstsimilar multiget href no_global older organizer inbox client no_att body_att carddav singlecontacts no_dist ab 2.13.12 (neu downloaden!)
(Testen, ob ohne "no_att body_att" durch Kerio erneut Einladungen an Teilnehmer verschickt werden. Leider vermute ich, dass trotzdem..)
Mavericks........: caldav deleted remove firstsimilar darwin 10 multiget older [singletasks carddav]
OpenXchange...: caldav deleted remove firstsimilar organizer multiget carddav singlecontacts => no tasks!
OwnCloud 3.0...: caldav deleted remove firstsimilar organizer singleget older href no_auth carddav singlecontacts => no tasks!
OwnCloud 4.x...: caldav deleted remove firstsimilar organizer multiget older href no_auth carddav singlecontacts [singletasks] => tasks, if activated in 4.5.x
Posteo.de.........: caldav deleted remove firstsimilar organizer multiget older href carddav singlecontacts no_auth => no tasks!
Radicale...........: caldav deleted remove firstsimilar organizer singleget older href (don't know, if tasks are working with "includetasks"; "multiget" may work, too.)
Scalix...............: caldav deleted remove firstsimilar organizer => no tasks!
SOGO...............: caldav deleted remove includetasks firstsimilar organizer inbox client no_auth sync (Optimized sync by REPORT sync-collection + timestamps)
or: caldav deleted remove singletasks firstsimilar organizer multiget older client no_auth (without timestamps, only ETAG comparision)
SmarterMail =10: caldav deleted remove firstsimilar organizer multiget [older] no_auth carddav singlecontacts => no tasks! Will be supported from 2.12.24 on..
SmarterMail <10: caldav deleted remove firstsimilar => no tasks!
Synology...........: caldav deleted remove firstsimilar organizer singleget older [singletasks]
>=DSM 4.3.3810: caldav deleted remove firstsimilar organizer multiget older [singletasks] ("multiget" works only. if time period is not empty in server calendar)
Tine 2.0............: caldav deleted remove firstsimilar organizer singleget href no_global carddav singlecontacts tine2.0 no_dist => no tasks!
Tobit David fx ...: caldav deleted remove firstsimilar multiget (use always WITH "multiget" or "singleget"!)
TribalOS...........: caldav deleted remove firstsimilar (without "singleget" do NOT activate option "[X] Select time period", because it's not supported!)
YAHOO ............: caldav deleted remove tasks firstsimilar organizer wait1s
ZARAFA............: caldav deleted remove tasks firstsimilar organizer max50get (or tasks=Tasksfoldername, if not default "tasks")
Zimbra 5 RC2...: caldav deleted remove tasks firstsimilar (or tasks=Tasksfoldername, if not default "Tasks")
Zimbra 6.0.4....: caldav deleted remove tasks firstsimilar organizer inbox
Zimbra 7/8.......: caldav deleted remove tasks firstsimilar organizer multiget older carddav=1 singlecontacts only > 2.14.9, ask!
OTHER/NEW......: caldav deleted remove firstsimilar organizer singleget older href no_global for untested CalDAV-Implementations (about "older" see below!). Check out common server implementation mistakes here: http://ical.gutentag.ch/forum/viewtopic.php?id=449
... and activate:
[X] Select time period: with rule "from now (Incremental)" or "from -31 days (Incremental)"
These are the best options - past is gone....
Do not use a rule with a TO-Date, otherwise incremental Sync is not possible (logical problem) and will be deactivated!
Field Date/Time Last Run: [date] [time] .. will be updated automatically after a successful sync.
This is used for speeding up the next sync == Incremental Sync (only possible, if the TO-Date of the time period is empty = logical problem)!
Please read FAQ how "deleted items" are handled! You may want to use following feature, too:
[X] Activate enhanced options (tabs "1.x More") ... and on tab "2.1 More" mark:
[X] After Sync remove all events/tasks in "Deleted Items" folder => do not use this on first test run, or make a backup of Outlook.pst first!
If you sync more than one calendar with multiple configuration files *.ini, activate it only in the LAST chained configuration file.
LOGIN+PASSWORD: The [Authentication] Login+Password is actually used to access the feed - BASIC REALM or DIGEST AUTH is supported.
For CalDAV stores which are supporting both Authentications methods (BASIC+DIGEST) at the same time, you MUST activate
[X] Use WinInet.dll instead of WinHttp.dll (see tab "Options - HTTP_DLL")
==> If you run into server timeouts (due to a WinOS issue!), deactivate DIGEST AUTH on the server (and use BASIC REALM with HTTPS for security).
caldav - must be present/entered
==> Without up and down it's a 2-Way Sync!
up - do only an upload. With up asFeed modifications on the server are getting reset! Do not use deleted remove with up.
down - do only a download. With down asFeed modifications in Outlook are getting reset!
Note: With "down", already deleted items on server will not get automatically deleted in Outlook. This is (normally) done during the upload to the server.
Instead use down asFeed, OR activate on tab "Options" sub-tab "Import Feed" (if you want to keep OL modifications):
[X] eGW/WebDAV: Mark events not anymore in Import with <Deleted> during Export/Upload
[X] eGW/WebDAV: Remove events, which are marked with <Deleted> after Export/Upload
[X] Do it directly after Import
down asFeed - Subscribe as "read-only" feed.
Resets all modifications in Outlook, like re-adding already deleted items, resetting modifications and removing (if not anymore in the feed).
Already other existent OL items in this folder will not get touched! So this can be used with the option for adding a category (tab "1.1 More"), to see those events in a different color.
up asFeed - the opposite for uploading. DO NOT use "deleted remove" with it!
up asFeed no_cache singleget older - only needed to push up a previous imported feed to a CalDAV store, where singleget is needed, like for DAVMail with Exchange 2007.
deleted remove - In CalDAV the client program has to find out, which events have been deleted on the server (except for very new REPORT_sync-collection Specification). Those items are not in the XMLS feed anymore.
iCal4OL does the "Deletion" in two steps:
1) By deleted the subject is modified, e.g. from "Meeting" to "Meeting <Deleted>"
2) By remove the modified "xxxxxx <Deleted>" are actually deleted.
If it's a calendar folder in your personal mailbox, the deleted event is moved to the Outlook "Deleted Items" folder.
a) Please read FAQ, how iCal4OL handles the "Deleted Items" folder - there are options (for Exchange), to monitor deleted items differently.
b) It's a good idea to empty the "Deleted Items" Folder in Outlook from time to time. If it's filled, it will slow down the sync!
This two step approach has some advantages:
- you can distinguish deleted items, if they were deleted by iCal4OL or another program!
- you could move them back to the OL folder and run [Folder Sync Reset], if something went wrong.
- you could use deleted without remove, to still see those events in the calendar.
((On tab [Maintenance] you can later on delete those events permanently - see function in the middle:
Field: Delete all items from this import file, stated below: ==> Leave Empty
and mark "[x] Only delete with text <Deleted> in Subject"
and choose the correct Calendar folder.. ))
In a Scenario, where you NEVER delete events/tasks in the CalDAV-Websolution, do not use deleted remove. The upload will be faster, because not all Outlook items must be read for export, to find out if they have been deleted.. (You may still use manually modified subjects, like e.g. "meeting <deleted>". Items with text "deleted" in subject are treated as already deleted by iCal4OL)
PS1: If a CalDAV Store is emptied by a "caldav web interface" (hey, never a good idea!!), iCal4OL would mark events with text "<Deleted>" at next upload and move them to "deleted items". In this case, you have to move those items back to the calendar, clean THE CONNECTION INFO of the items, by using the button [Folder Sync Reset]!
(Manually: At least the Sync-Field Option on tab "Sync Fields" "[X] ImportWID" must be checked (and be done), and the "[X] Monitor deleted events" deactivated and the corresponding DB deleted, when asked for..)
PS2 (again): Exchange public folders do not move deleted items into the "Deleted Items" folder. To monitor deleted events here, you must activate the corresponding option on tab "Options" sub-tab [Exchange / *.pst]. This will generate/maintain a DB (*.mdb) during sync under
C:\documents and settings\<user profile>\Appdata\iCal4ol\<EntryID_of_folder>.MDB, which will be used at next import, to prevent adding those events again.. and delete those events on the server, too!
nosimilar - does not test for similar events (=identical Subject and Starttime), preventing 1-n relations (one Outlook event TO multiple similar server events.
Please be aware if you sync the first time, when on both sides events are present: Do not use this flag - events need to get "connected" again if they are "the same/similar"! Only if one side (Outlook or on Server) is empty, you can use it already for first sync. For this reason I implemented the flag..
firstsimilar - After a successful sync, this flag will automatically change to nosimilar!
tasks - for syncing tasks, too! Not supported for e.g. Google Tasks and EGroupware 1.4.004 (see above).
Zimbra & CommuniGate Pro: For using a different task folder than "Tasks", enter "tasks=TasksFolderName" (=<name of task folder>)
includetasks - a special flag, which works only together with singleget/multiget/sync, where the collection URL contains both: Events AND Tasks (E.g. SabreDAV, SOGo and DAViCal).
((singletasks is a test flag. Do not use it - for the moment only necessary for DavMail, if you need to sync tasks, too (still buggy in DavMail).
groupdav - Needed only, if you want to sync with EGroupware 1.4.004, 1.6.001, 1.6.002 or Citadel. Do NOT use it for EGroupware >= 1.6.003!
darwin - Needed(!), if you want to sync with Darwin Calendarserver
10 - For Snow Leopard or newer. This flag is "forcing" invitations (during upload of events) to the OUTBOX, even if no UID of attendees can get resolved. But mostly, iCal4OL will resolve all UID of users successfully (there are about 5 different methods implemented not to miss anything).
=> Note: "[X] Use Outlook Scheduling Tab for attendees" on tab "Options - Startup". Do not deactivate it!
From the OUTBOX, the server will distribute a copy of the event automatically to the INBOX of the attendees. External user may, or may not, get an invitation by mail (there seems to be some config problem in Darwin SL). Of course, you can send out invitations in Outlook directly, but be aware of duplication of invitations (attendee gets twice an invitation).
Use Noinvite to deactivate the Posting to the OUTBOX, completely!
inbox - only for Darwin Calendarserver, Bedework, DAViCAL, EGW 1.9, iCloud, SOGo, Scalix, Yahoo, Zimbra 6 and Kerio 7.1.x.
It will read the INBOX (scheduled events/tasks from other organizer) and control the upload of your own attendee status (limited modifications allowed). Always activate this for Darwin and Bedework >= 3.7!
The category Inbox and the "color label" Participation required are automatically added to those items!
If the event gets accepted in Darwin's WebCal or by ICAL, the category "Inbox" will get removed again. In Outloook 2007 use a color to highlight Inbox events!
==> Some important details for Darwin (like delegation/attendee handling) you'll find here: http://ical.gutentag.ch/forum/viewtopic.php?id=49
Because the invitations are synced from the server and not received by email, a special Category-Handling is implemented,
to change your own attendee status (accepted, tentative, denied).
You'll find special CalDAV-Scheduling related flags, like status (reading attendee stati) and reply (emptying the inbox), too.
Noinvite - For Darwin CalendarServer based solutions, e.g. Mobile Me wanted money to send email invitations over their server. So the CalDAV-Scheduling Spec (POST to Outbox METHOD:REQUEST) can't work. This will deactivate the function (Normally it's an option in Darwin which determines, if sending invitations is done automatically or not).
See flag RSVP further down, for setting RSVP=false (informing the server, no attendee responses are needed).
New Flag client will add SCHEDULE-AGENT=CLIENT to Attendee lines (see further down. Default for iCloud to prevent sending of invitations, which may be overridden with "schedule").
India - Version >=2.13.12 - Does upload in the timezone as set in a single Outlook event (e.g. invitation), if different from timezone on tab "Who".
Indian - Version >=2.13.12 - same as above, but also for download, if different from Outloook.TimeZones.Currenttimezone!
Note: For Google Calendar API v3 there are options available for testing the same functionality:
- Add in *.ini file, section [Export], line "iMeeting3=1" .... for download and upload.
- Mark on tab "Google" for only upload: "[X] Update Google Calendar in a different timezone"
There are different ways to retrieve events/tasks from a CalDAV collection
==> Check the section above about the "Basic 2-Way-Sync Configuration".
The Auto Configuration Button(s) on tab "Who" will configure iCal4OL for popular Groupwares, automatically!
singleget - this will activate the most common way to retrieve items from the server, but it's not the default of iCal4OL.
WITHOUT singleget, iCal4OL is performing a "REPORT calendar-query", which can retrieve a "time-range" including "calendar-data", which works perfectly together with the option "[X] Select time period" and a rule like "from -31 days (incremental)"!
In most cases, this is the BEST WAY TO SYNC, but not all CalDAV Implementations do support it!
WITH singleget, iCal4OL is performing first a "PROPFIND", then testing against HREF/ETAG of already existing (synced) events in OL, and using "REPORT multiget" to retrieve only the difference (the "calendar-data" of new or changed events).
This is compatible with most implementations, but not with all. iCal4OL is a Sync Solution and therefore NEEDS correctly set dates and times (or sequence). But some servers, do not provide the iCalendar fields like "LAST-MODIFIED:yyyyMMddThhmmssZ" correctly!
==> Important: Most servers do limit PROPFIND to a time-period like -30 to +365 days, because Sunbird/Ligthning gets very slow with more than 500 items to retrieve!
In e.g. EPL/EGroupware you may want to modify /calendar/inc/class.calendar_groupdav.inc.php (see function propfind) to change the limit.
==> Some Hosters are blocking HTTP REPORT Requests to EGroupware, resulting in HTTP 500 Internal Server Error.
In this case use singleget nomulti... this way only HTTP PROPFIND, GET and PUT are used for Syncing!
WITH multiget [tasks] iCal4OL is performing first a "REPORT calendar-query" WITHOUT "calendar-data", but WITH "time-range filter". This is about the same as above, but does only retrieve events from "[X] Select time period" with a FROM-Date, which is mandatory in this case or -31 days is used!
"includetasks" does not work here. You MUST use "tasks", because of the time-range filter (the spec of filters is limited.. so tasks can't get retrieved by the same request).
Compared to the above method, this is using less bandwidth, but nothing beats "REPORT sync-collection" below (Until now only in DAViCal and SOGo implemented..).
The MOST compatible way is to test only, if a Server or Outlook event has been changed/added, by using <href> and <getetag> for server items.
WITH singleget older: If an event was meanwhile modified on both sides, the Server version will win and be downloaded!
WITH multiget older: Same as above, but to HREF/ETAG will be retrieved by "REPORT calendar-query with time-range filter", instead with PROPFIND
Add flag etag to make iCal4OL ask, which way to sync, if item was modified on both sides.
xolder - is the same as older. The assistent will add this, if flag etag (Warning) is used.
Please note: The default behavior to check the collection tag is from version 2.12.7 deactivated (forced flag no_ctag)!
This may be overridden by flag getctag. This is the collection tag (e.g. calendar collection), which does tell, if something has changed on the server side.
In most CalDAV Servers it's implemented, and will change the behavior of iCal4OL Upload, if (now) getctag is used:
Only events modified after "Date and Time last run" will be checked, if they need to get uploaded - in this case those "few" events are read by normal Http GET command from the server. Since e.g. a sync is done every 10 minutes, and after an upload the <getctag> is different again, an event may be checked twice (=security).
While testing keep this in mind: If you sync more than once a minute, events may get tested again during upload, due to field "Date and time last run", which actually is set to -1 minute (for security) of last sync.
no_ctag: iCal4OL >= 2.12.7 it's now forced! Does NOT check the <getctag> (collection tag), to find out if something has been changed on the server. There may be an issue with perhaps mis-behavior of other CalDAV-Clients, changing HREF's (filename on server) of events..
The most advanced and modern way is only working for SOGo and DAViCAL (newest version) for now:
WITH sync [includetasks], iCal4OL is performing a "REPORT sync-collection" to retrieve ONLY modified, new or deleted items from the server collection from 2nd sync on.
If you want to sync with tasks, you MUST use here "includetasks" instead of "tasks"!
Older Text - with other words...:
singleget - may speed up the sync for "fat" calendars (many events already in the store) + better compatibility (see "singleget newer/older", too)!
WITHOUT singleget, all events are downloaded together from a certain date on => FROM-Date in option "[X] Select time period" e.g. with rule "from -31 days (Incremental)".
If "select time period" is not set or you are syncing with Zimbra (bug), all items from the CalDAV Store have to be read together!
This may take a long time, resulting in a timeout (waiting for the server response).
=> This may be "controlled" on tab "Options - HTTP_DLL" with:
"[X] WinHTTP: Do not show timeout popups, if sync is running in foreground" ==> only activate it, if you sync always in foreground!
- Syncing in background (tasktray) never shows pop-ups, but the sync may stop, if no server response is received.
- WinHTTP in asynchronous mode does use less CPU.
- Darwin and Zimbra do need WinInet.dll to work correctly. WinInet.dll never shows pop-ups (synchronous=waiting inside the dll).
But there is another way:
WITH singleget, iCal4OL will first read only the HREF (store references of the events) and ETAG (last modification stamp) of all events, but not the calendar-data itself (faster and smaller data size).
Then it will compare this info with already existing Outlook events, and just download those events, which are new or have changed (on either side). The Download is optimized, reading max. 200 events together (REPORT "calendar-multiget"), to circumvent timeout problems.
Syncs with "singleget" should be faster - at least from second sync on, if incremental sync is active (Do NOT use a TO-date in time period!).
Note: Do the first sync WITHOUT the option "[X] Select time period" - from second sync on use the rule "from -31 days (Incremental)"
(=> otherwise it will still read all older events before time period, if they are not in Outlook ... ask, it this is not clear!)
multiget [tasks] - does use REPORT instead of PROPFIND, together with FROM/TO-Date of option "Select time period".
PROPFIND does normally find ALL items in a collection, if not limited by the server itself (e.g. EGroupware does limit PROPFIND to -31 days).
singleget older - some new implementations of CalDAV do not set LAST-MODIFIED, DTSTAMP and SEQUENCE correctly!
==> This flag will make it possible to sync correctly only by checking ETAG of the server event, or if the event was modified in Outlook.
If an event was meanwhile modified on both sides, the Server version will win and be downloaded!
singleget newer - some new implementations of CalDAV do not set LAST-MODIFIED, DTSTAMP and SEQUENCE correctly!
==> Can't work correctly for already supported CalDAV implementation.. test it... or use "older"
This flag will make it possible to sync correctly only by checking ETAG of the server event, or if the event was modified in Outlook.
If an event was meanwhile modified on both sides, the Outlook version will win and be uploaded. Use flag "etag" to get a warning.
singleget sync [includetasks] - only for DAViCal and SOGo. This will use "REPORT sync-collection", a new CalDAV spec for speeding up syncs significantly.
If you want to sync with tasks, you MUST use "includetasks" instead of "tasks"!
getctag - can be used to optimize the sync (not downloading anything, if nothing change on server.
But if another CalDAV Client does change the HREF (filename on server), the event may get deleted in Outlook.
no_ctag - Does not check the "collection tag" on the server, if something has changed or not.
((Sometimes during testing and identical <getctag>, it takes a long time for one sync to check every item in Outlook during upload, because the filter for "LastModificationTime" still does include all newly downloaded events (field "Date and time last run"). Another (test) workaround would be, to wait at least 2 minutes, and then empty this field for next sync, and sync again.))
((singleget nomulti nocache - a test flag. It will use single HTTP GET's to retrieve events. It's sometimes the only way to find corrupted items on the server (HTTP 401 messages from EPL/eGW).))
etag - does check, if the same event (and contact) was modified on both sides (Server and Outlook), showing an inactive message box like:
This event was meanwhile modified on the server, too - Download anyway? If NO and newer(!), it will be uploaded
Does check for parallel modification of the same event/task/contact as a real CalDAV-Client software should - and ask what to do (with this flag, the newer event will NOT win automatically, but it's some kind of annoying to see those messages - the sync will stop and wait for your answer)
organizer - Will preserve the correct Organizer of an invitation, and does allow upload of "attendee status" changes by category names, like "accepted", "tentative" or "denied". See http://ical.gutentag.ch/forum/viewtopic … d=835#p835
==> This flag is necessary for EGroupware > 1.6.003, DAViCal, SOGo, Bedework, Zarafa and Kerio 7.1.x... and probably for other modern Groupwares, too!
Synced invitations (not by email received invitations) can't be added correctly to Outlook by a program (it's not possible). So iCal4OL has to keep track of the "real" organizer!
This flag is not supported for Darwin CalendarServer, because it's already done automatically (a little bit different, due to __uids__) by flag "darwin"!
BodyAtt (BodyAttendees) - from 2.13.3 on - will add the emails of invitees into the description during upload.
If you want to suppress ORGANIZER/ATTENDEE lines during upload, you must enable tab "1.2 More - Export" (on tab 1.HOW), and there mark the corresponding option, or from next version on:
no_Att (no_Attendees) - from 2.13.6 on - same as suppressing attendees during upload on tab "1.2 More - Export". Implemented because of the annoying Google Calendar CalDAV behavior, sending out email invitations again.
RSVP - will always set RSVP=false, to inform the server, that no response from attendees are needed. Depending on the server, this may help to prevent sending invitations by mail again. Note: iCal4OL does not send invitations, with one exception for older Darwin - use flag "noinvite" to deactivate it (newer Darwin will ignore it anyway, because they are sent automatically).
client - will add SCHEDULE-AGENT=CLIENT to Attendee lines. This is default for iCloud to prevent sending of invitations over server. But
with schedule you can override it for iCloud. DO NOT USE IT FOR FIRST SYNC, OR ALL YOUR INVITATIONS WILL INVITE ALL ATTENDEES AGAIN!
(With "schedule" you should never send invitations by email (just save them e.g. with CTRL-S), because iCloud will send an invitation, too)
href - from 2.11.12 on - HREF (server location of an item) and mostly UID (not OL invitations) will not be set to EntryID for new events, which may be too long for the CalDAV Server. Instead a GUID (Generated UID) is used. This is default for EPL/EGroupware and Synology CalDAV (Port 5005/5006), but can be forced for other stores with this flag.
no_global - from 2.11.13 on - UID's of invitations are set to PR_SEARCH_KEY instead of .GlobalAppointmentID, which is shorter an perhaps necessary for certain servers, where max. length of UID is 40 characters (.GlobalAppointmentID can be up to 232 characters long).
debug - will write all XMLS/iCalendar/VCARD stuff into the LOG.txt for support. This flag is valid for the Contact Sync, too. Add this flag, if something does not work as expected and email the LOG.txt. Please describe your issue exactly. See http://ical.gutentag.ch/support.html about "iCal4OL DEBUG", too.
no_auth - needed for Darwin Wiki Calendar, Mobile Me and iCloud. Those stores do not bring back HTTP 401 Not Authorized. So iCal4OL will manually add the authentication headers - for other stores, it may speed up the sync a little bit, because WinHttp.dll will always send a request first without credentials..
((iCal4OL will do the authentication itself, because there is an (invalid) header "Authenticate: negotiate" together with "Authenticate: Digest.." in the server response, which WinInet.dll and WinHttp.dll can't handle for a HTTP REPORT REQUEST => Bug "content gets lost"))
filter - from 2.13.5 on for option "select time period with from-to" for repeating events. Filters by occurrences start-end, and not by full pattern period. See http://ical.gutentag.ch/documentation.html#D61e
wait1s - does wait one second before HTTP PUT. Due to a bug in Yahoo (CalDAV/CardDAV implementation is very buggy), causing HTTP 503 Error. Use "wait2s" for waiting two seconds, if you still experience HTTP 503 Errors.
override - works from >= 2.14.9 on (download again!). There are load balancers out there like KEMP, which don't support WebDAV (and therefore CalDAV) commands like HTTP REPORT, like 1&1 Hosting. This may help, because it will use HTTP POST with override header "X-Http-Method-Override: REPORT".
max100get - only for singleget, multiget, sync (>=2.11.17). Limits REPORT-Multiget to max number items (Default=200). Number can be 10 to 200. May be needed for David.fx to prevent timeouts.
ignoreLMT - may be needed for older Darwin Wiki Calendar. LAST-MODIFIED was not supported, preventing the modified Wiki events from getting downloaded again. Add this flag ONLY, if you experience exactly this issue!
((With other words:The Wiki had LAST-MODIFIED implemented (and not just DTSTAMP as normal Darwin Calendars), but this field was not updated by the Wiki (Bug!). Flag ignoreLMT will ignore LAST-MODIFIED(-TIME) and will just use DTSTAMP, which is - in this case - correctly set))
setLMT - For unkown CalDAV implementations: LastModificationTime... the question is: Should it be the timestamp of HTTP PUT or the real last modification time? For known Implementation iCal4OL does handle it automatically. For unknown implementations without flag "older" the default is "real modification time". Using this flag will make sure to set it to HTTP PUT timestamp!
no_cache - for "singleget" and "multiget". It will retrieve/cache all server calendar-data, and not just the modifications. Actually only necessary for DAVMail 1-Way Uploading into OWA of Exchange 2007/2010. DAVMail has a bug with LAST-MODIFIED (missing), which iCal4OL can correct this way (will generate LAST-MODIFIED with ETAG info) => UserID: caldav up nosimilar organizer singleget debug no_ctag no_cache [asFeed]
caldav up asFeed singleget newer DelOld - Will delete all events in the CalDAV collection, which are NOT in Outlook! Modified events in the CalDAV collection (e.g. in Google SubCalendar) will get reset to OL version (by flag "asFeed"). With this "UserID:" the CalDAV collection will behave like a Subscribtion of an Outlook Calendar!
The Alternative would be to publish an OL Calendar as iCalendar Feed to a Webserver (by WebDAV or FTP), and then subscribing it in a Websolution.
DelOld will only work together with "singleget".
LastModified - only for DAViCal, to prevent uploading identical events again, where the LastModifiedTime gets changed by Exchange or an Outlook Search-Addin (If the event was uploaded before by iCal4OL, it will test if still identical (just DTSTAMP+LAST-MODIFIED are modified..), and in this case not upload it again). Note: "singleget", "multiget" and "sync" will always exclude unchanged events anyway.
limit (limit10-limit99) - for older Atmail (Darwin based) together with "multiget". Will retrieve events e.g. for 60 days together, to circumvent a bug with recurring events with (too) many occurrences.
Atmail - if by mod_rewrite server.php was "hidden", to sinc correctly new Atmail Servers, based on SabreDAV.
GO - only for GroupOffice Prof, if the path to an url collection does not contain "calendar.php/calendars/" (set by Assistants)
Notes - only for Citadel >= 7.84. Will download VNOTE's. Upload is not possible (bug in Citadel - they would never show up, but would get added to the DB).
allday2 - for Yahoo and perhaps older Zimbra, if you use allday events over several days (which Yahoo does not understand). It will tranform all allday events to start on hour 00:00:00 and end on 00:00:00 instead of allday.
allday2 - from 2.15.6 on, for Yahoo and perhaps older Zimbra. Single allday events are excluded from transforming..
newconn - for Horde 5.2.0, where only first request on a TCP connection is working = Bug in Horde!
Deprecated (but still working):
DTSTAMP+1 - only for Citadel 7.84. This version has a strange bug, not considering the daylight saving... sometimes times are off (DTSTAMP+2 aso ..)
direct - depricated, now default - does no harm!
To circumvent a rare FSO (File Scripting Object) bug on WinXP systems. Does no harm - you may want to use it for all CalDAV-Syncs.
(Only necessary, if iCal4OL stops responding, without importing events (the feed is saved in TEMP file and read twice: First for VTIMEZONE info, which could be at the end of file... Second for VEVENTS... Sometimes FSO blocks the second attempt on the same file?!)
nocache - ONLY FOR DAVICAL!! Normally all events of the caldav store will be read into memory at the beginning of a sync. In time critical environments with more than one real caldav client, this could result in a "ETAG precondition failed error" for those events, which where modified in Outlook "before this sync" AND MEANWHILE "during this sync" by a caldav client! Those events will get synced next time! No worries...
Also with flag nocache those events will correctly sync, due to newly read LAST-MODIFIED. So, there is no need to use this flag (just ignore precondition failed errors).
exchange - together with option "[X] Monitor deleted events in Exchange Calendars" (see tab "Options - Exchange")
will de-activate the deletion on the server = test flag.
Note: you MUST be the OWNER to Sync a public exchange calendar correctly (admin rights are not enough, because only the owner can add userdefined fields in the MAPI store). If you are not the Owner, you MUST activate on tab "Options - Exchange" the use of an external database for sync fields!
break1 - a test flag: after retrieving all events from the server, the program will stop and show, where a file was created with the server response (already modified; the file will be deleted by iCal4OL at the end of import)..
DAViCalOld - probably never needed. New iCal4OL Versions with very old DAViCal installations.
quote - probably never needed. If you get ALWAYS "HTTP 412 Precondition failed" during upload (see LOG.txt), you could try this. It was implemented for DAViCal newer versions - together with older versions of iCal4OL (from 0.9.9.0 on DAViCal needs ETAG quoting, which newer version of iCal4OL do provide)
cacheLMT - depricated. Will speed up the 2-way sync "just a little bit". But it should NEVER be used for the FIRST SYNC!
allday - only for old EGroupware 1.6.001 and .002 servers, residing in a different timezone than you: older versions of eGW did not support VTIMEZONE, and only a +/- hour difference could be configured. With this flag + "manual timezone difference" for down/up, a correct sync was possible. See this "older" German Topic: http://ical.gutentag.ch/forum/viewtopic.php?id=194
issue1 - only for older EGroupware. If iCal4OL detects an older version, it will read 6 month chunks of event, to prevent timeouts (repeating events did take very long to retrieve). With this flag, it will read everything in one chunk... which is done for never EGroupware versions, anyway.
split - together with "multiget" for older EGroupware 1.8.001. Will retrieve events by month (=36 requests for 3 years)
The field "UserID" can contain some flags for CardDAV (Contact-Sync), too: See http://ical.gutentag.ch/forum/viewtopic … 1056#p1056
Most important are probably:
CardDAV SingleContacts - will force newest CardDAV implementation. This is the default (anyway) for e.g. iCloud, EGroupware, SOGo, DAViCal,
but not for e.g. OwnCloud. (The Contact Sync was first implemented with GroupDAV - CardDAV was not existing at this time. If the contacts are working in iOS, this switch should be active. The Assistant on tab "Who" will add it, if really necessary, e.g. for OwnCloud)
AnsiContacts - only for "early" eGroupware 1.6.003 versions: Normally new contacts (tab Contacts) are uploaded in UTF-8 (VCARD 3.0). But some versions/servers have a strange bug, only accepting ANSI-Encoding (=VCARD 2.0) here. With this "Contact-related" flag, ANSI can be forced for CardDAV.
SimilarContacts - will optimize the download, never adding duplicated contacts. Use this only, if your contacts did get somehow duplicated on the server. You could download your contact DE-DUPLICATED e.g. in a empty, NEWLY added OL Contacts Folder!
no_dist - will definitly deactivate the sync of DistributionLists (even if supported by groupware)
add_dist - will activate DistributionLists Sync for solutions, which newly support them (e.g. Kerio 8.1.x).
see post at the bottom about CardDAV URL's...
- Does check the URL path (but can't detect, if your path is too short, e.g. it does only test if WebDAV possible).
If only servername:port (eg. "cal.me.com") is in the URL field, it will retrieve the full path. See http://ical.gutentag.ch/forum/viewtopic.php?id=278
- Does check the PC Clock against the Server time. Only on WinXP + Admin Rights, iCal4OL can adjust the PC Clock automatically.
Best configure NTP (Internet Time) on your PC, e.g. ntp.metas.ch is a reliable server.
Here at last... a screen shot of the configuration window:
Last edited by Roland (2013-11-06 21:59:19)
When syncing with iCal4OL - the newer version of an event "wins", if you did not enter "etag" in the field "UserID:" on tab "1. How"!
(the "etag precondition for a meanwhile changed event on the server" is not checked without this option).
Last edited by Roland (2011-06-24 20:50:25)
There is an inbuild CalDAV-Assistant for some CalDAV Stores on tab "Who" (and "How" to select the basic options).
It's working for DAViCal, Darwin CalendarServer, EPL/EGroupware, Zimbra, Yahoo, Kerio, Cosmo, Bedework, SOGo, CommuniGate Pro, Gaggle, Zarafa, Scalix, maXvis, Synology, Google Calendar by CalDAV, and for the inbuild CalDAV-iCal4OL-Server.
For Darwin CalendarServer and EPL/EGroupware there is even an additional [Enhanced Assistant] under [AutoConfig Assistant].
Last edited by Roland (2011-06-24 20:49:34)
CardDAV (Contact Sync on tab "Contacts")
Important: Under CONTROL PANEL - Phone and Modem Options - Location .. enter the correct area code, or even better choose "International Freephone Service"!
Otherwise the plus sign in front of a phone number may be ommitted during download sync = Outlook Issue; e.g. +41 893..
Just a few stores are capable of syncing the new VCARD VERSION:3.0 (AddressBookServer, Kerio, DAViCAL, Yahoo, iCloud, OwnCloud)
So the default in iCal4OL is VERSION:2.1 ... But some stores need the "text" VERSION:3.0 with content "from" VERSION:2.1 to function properly.. it's a mess with different tag names and a lot of bugs in most implementations. I do my best to support the most used web solutions ;-)
The default of iCal4OL is to use VERSION:2.1 for unknown solutions, which is a little bit oudated, because a lot of solutions are now supporting iOS 5!
Note: The field "UserID:" (Kennung:) here on tab "1. Who" can be used to influence the Contact Sync, too
CardDAV => will force VCARD VERSION:3.0, instead VERSION:2.1 This Flag and flag below are set by the assistants on tab WHO, if needed.
<LastModified> will be ignored (buggy for some stores!) and changed contacts are only detected by ETAG or Outlook modifications.
CardDAV=<nn> will force field labels for different web solutions during upload.
Normally this is done automatically. For Zimbra 7, with an exiting bug with label "REV:" you can use "CardDAV=1 singlecontacts" from version 2.14.10 on, or flag "gas"!
CardDAV=1 Zimbra 7 (from 2.14.10 on)
CardDAV=5 AdressbookServer, DaviCAL
CardDAV=8 Kerio, Infomaniak, (SabreDAV)
CardDAV=11 iCloud, DayLite
CardDAV=13 GroupOffice Prof
Normally "Carddav" is used together with "singlecontacts" and "no_dist"... see below.
singlecontacts => Forces PROPFIND, then REPORT MULTIGET of only modified/new contacts,
instead of PROPFIND with <D:prop><D:getetag/><D:getlastmodified/><C:address-data/> (all data at once)
Useful, if more than 1000 Contacts are in the collection, or if one contact is somehow "stuck"..
=> Some solutions like SOGo, IceWarp, Darwin, iCloud, MobileMe, EGroupware, EPL, Citadel are implemented with fixed "CardDAV singlecontacts" Flag!
(never use "carddav singlecontacts" for those...)
Those two options are set automatically by assistant (or even hidden and active) for many solutions = iOS support. Most CalDAV Solutions do not support anymore modification timestamps. Everything must be synced by ETAG (if something has changed or not).
Atmail => makes it work for this websolution, together with the above flags (..."CardDAV Singlecontacts Atmail")
Use this flag perhaps for non supported CalDAV Solutions, if not all contacts can get read from server.
tine2.0 => makes it work for this websolution, together with the above flags (..."CardDAV Singlecontacts tine2.0 no_dist")
Horde => makes it work for this websolution, together with the above flags (..."CardDAV Singlecontacts horde")
(other solutions may need one of those flags above, too. Kerio and OwnCloud not!)
Baikal => This flag name is misleading - implemented in 2.14.0 (..."CardDAV Singlecontacts baikal")
It's actually a new support flag for the CardDAV SOGo-Connector in Thunderbird 24.0 (..."CardDAV Singlecontacts baikal")
gas => Zimbra 7 has a severe bug (idiot programmers!) with label "REV:". Without flags "carddav=1 singlecontacts", this flag is needed! Works from 2.14.10 on.
(Without "singlecontacts" the timestamp of the lastmodificationtime does matter, which is wrongly shown as UTC, but is localtime ("Z" at the end means UTC).
fileas => Will use .FileAs instead of .Fullname for "FN" VCard label.
debug => will write more info into the LOG.txt (This flag is for CalDAV AND CardDAV).
no_dist => Distributionlists (Groups in iOS) are not synced. Will overturn the corresponding CardDAV option (may be nessary for non supported CardDAV solution).
WarnCDel => If more than 10 Contacts would get deleted on the server collection, iCal4OL will warn about it!
I had some strange report. After analyzing it, the server did not sent a full response (cut off). Seems to happen with e.g. OwnCloud
Cut off responses are now detected by iCal4OL.
Since 2.14.0 WarnCDel works, if more than 10 Contacts would get deleted in Outlook, too
similarcontact => If on the server all contacts are twice in the store (e.g. caused be a SmartPhone...),
this will just download one copy of them, trying to avoid duplicates!
(If you delete all contacts, remember to remove them from the folder "Deleted Items", too... and if you activated
[X] Monitor deleted Contacts (tab "Options-Exchange"), deactivate it (let delete the DB!) and
reactivate it again (D/E).... or use [Sync Folder Reset] for this Outlook Contact Folder!
ansicontact => only EGroupware. Older versions, or a misconfiguration of the server, will prevent the correct upload of UTF-8 encoded VCARD's.
If special characters like öčű do not show up, add this flag for e.g. 1.6.001
EPL => only EPL/EGroupware Upload: to avoid shortening/wrapping some fields for newest version 1.8
.JobTitle will normally get shortened to 64 characters, because older versions can't deal with too long fields sent by CardDAV
.BusinessAddressStreet will wrap after 64 characters
.HomeAddressStreet .. dito
.WebPage (URL;WORK) will get shortened to 128 char, to work with older versions...
.PersonalHomePage will get shortened to 128 char, to work with older versions...
fburl => Upload Outlook Contact Field FreeBusy (it's not CardDAV standard, but useful for OL to OL Sync over DAViCal)
BE AWARE: Most solutions do not support the character "semicolon (;)" in a contact field (in e.g. address fields or names).
Semicolons need proper encoding "\;", because simicolon is a separator for some VCARD fields, too. Most routines do decode it incorrectly, resulting in field shifts!
For quick review, here the CardDAV URL's for most supported stores:
(The Assistants on tab "Who" will correctly prefill the URL field for most solutions)
Replace the placeholder "<user>"...
(uids of user - see principal page, e.g. https://darwin-example.com:8843/princip … ;user>/)
https://p<NN>-contacts.icloud.com:443/<UserID>/carddavhome/card/ (Search for Collection Finder in this forum, if you're not using iCal4OL)
http://www.OwnCloud.de/owncloud/remote.php/carddav/addressbooks/<user>/contacts/ or https://myserver.de/owncloud/remote.php/carddav/addressbooks/<user>/kontakte/
http://zimbra5.example.com/home/<user>/Contacts.vcf (by SOAP)
http://zimbra6.example.com/dav/<usermailaddress>/Contacts/ (only newer 6.0.x)
Note: Yahoo CardDAV is buggy! Yahoo does not provide correct <addressbook-home-set> and can't deal with picture upload!
I therefore recommend, not to use it at all - or only to download contacts in an different Outlook Contact Folder than Default!
Last edited by Roland (2014-08-09 18:01:10)
Manipulation of Default.ini for CardDAV (some hidden options... add a line below the section [eGroupware]...)
=> Only for EGroupware: Will sync Outlook's MobileTelephoneNumber to "TEL;CELL;HOME" instead of "TEL;CELL;WORK". Other Cell will sync with .Home2TelephoneNumber
==> Will upload Outlook Categories as Nickname, so they become visible in iOS.
Best use it togehter with
==> Will not upload the OL field Nickname. Since it's used for Categories, it should not upload this field value, too ;-)