MOSS Calendar Syncing

What about http://msdn.microsoft.com/en-us/library/bb977430.aspx  check the Section titled: "The Forms Authentication Integration Update for Office 2007" also "http://blogs.msdn.com/sharepoint/archive/2009/05/13/update-on-sharepoint-forms-based-authentication-fba-and-office-client.aspx"  check the "Other Things To Know" section, Steve Peschka specifically states support for Outlook.  Any clues?

Interesting.  I was not aware of this hot fix and/or this section of the documentation. Thank you for pointing it out.

Do the other syncing features work?  For example, connecting a document library or a task list.

Sorry for responding so late... issues in IT Land over here.  Anyways, yes to my knowledge, however I didn't test all Client Integration Features just Document Opening from SharePoint.  You would be prompted with whatever form you have defined as your authentication page, from there the document  would open.  However I did get an error on server message before the doc opened.  Then I tested Outlook via FBA and that's when all began to unravel.

It appears to me that MS still has some work to do.

Yes.  I believe they have added better FBA support (which is great) but I am not convinced it will work with things like Calendar or Task list syncing within Outlook -- it is not specifically called out that I see though, so I could be wrong.

To me that was the purpose of the hotfix... better FBA support.  

This support comes down to an authorization cookie that can't be accessed by the Office Programs that was initially requested by the browser.  The only documented way to getting around this is setting a persistent cookie, however doing that'll open your attack surface BIG TIME for your application. I may be wrong, but I think that there's a protocol upgrade due here???

Perhaps you are right about the protocol upgrade.

MS has stated that they've made most, if not all of Client Integration Available Here:
http://msdn.microsoft.com/en-us/library/bb977430.aspx

OR READ BELOW EXCERPT  FROM PAFE BELOW
==============================================================
Some organizations might want to use forms authentication, but also require the same level of integration they get when using Windows authentication. There are a couple of possible workarounds in this scenario, but it is helpful to examine why this limitation exists.

When a user accesses a page on a site protected by forms authentication, the server looks for a valid authentication cookie. If no cookie is found, or if the cookie is not valid, the server redirects the browser to the logon page by using an HTTP 302 status code. At this page, the user is allowed to authenticate by using his or her credentials. After the credentials are validated, the server creates a valid authentication cookie and sends it back to the browser, with the originally requested page. The browser keeps the cookie in memory and sends it back to the server with every subsequent request to that Web server. With each request, the server checks the validity of the cookie to ensure that it is good (that it has not expired or been tampered with), and then processes the request.

Because the authentication cookie is in memory with the browser process, it introduces some limitations:

The cookie is retained only as long as the browser is open; when the browser is closed the cookie is destroyed with everything else in memory that the browser was using.

The cookie belongs to the browser's application process (such as the .exe file for the browser), and cannot be shared with other processes. Office system applications run in their own processes, for example, msword.exe for Microsoft Office Word. As such, a cookie that a user generated when logging into the site in the browser cannot be shared with Word.

The issues described in this article clarify why the Enable Client Integration option was developed: to help make the end-user experience more uniform and predictable in that environment; however, the user experience is somewhat different for users that are accustomed to SharePoint sites secured with Windows authentication. Even with those restrictions, there are still a few options that can be used to allow for using forms authentication and yet still provide many or all of the deep integration points with Office applications that are available when using Windows authentication.
==================================================================

Well I had to take this one to MS Support, there is a caveat after you've installed hotfix KB960499 on the client. If you're using the OOB login page for FBA, if you check "sign me in automatically" on the login page you'll be able to sync calendars with Outlook.  So the question is then what about if i use a custom login page... this is what I'm currently testing out, this and what seems to be a bug in the hotfix... I'll keep you all posted. Till then... MOSS IT UP.

Well I had to take this one to MS Support, there is a caveat after you've installed hotfix KB960499 on the client. If you're using the OOB login page for FBA, if you check "sign me in automatically" on the login page you'll be able to sync calendars with Outlook.  So the question is then what about if i use a custom login page... this is what I'm currently testing out, this and what seems to be a bug in the hotfix... I'll keep you all posted. Till then... MOSS IT UP.

SP2 just isn't working well with Calendar Syncing w/Outlook 2007, so, I had to downgrade to SP1, and using the default windows form if the FBA user checks "sign me in automatically"... syncing works all the time.

Also if you're using CKS:FBA codeplex solution for Extranet/Internet, on the login webpart, if you select "remember me next time" syncing w/ outlook calendar works well, also most other client integration features.  

Also I've found that I'm able to sync with Outlook 2003 Calendar w/o error, but all the other Client Integration Features don't work... but this was known by the MOSS Community because MS doesn't support this functionality w/ Office 2003 Products KB919042