In the Google Calendar Connector framework, data flow from Exchange is provided by the Google Calendar Connector Web Service. Google Calendar connects to the Web Service to query Exchange servers for free/busy data and appointment data, which includes the name, place, and attendees of events. This document provides instructions for installing and configuring the Google Calendar Connector Web Service. Contents
- About This Document 1. Audience 1. For More Information
- Before You Install 1. Prerequisites 1. Google Calendar Account Setup 1. Dedicated Windows Service Accounts 1. Installation Checklist
- Installing the Google Calendar Connector Web Service 1. MSI Installation 1. Multiple Web Service Instances 1. File Permissions
- Configuring the Google Calendar Connector Web Service 1. Editing the Configuration File 1. Encrypting the Configuration File 1. HTTP Proxy Configuration Optional
- Installation Success 1. Verifying Communication
- Testing and Troubleshooting 1. Running Diagnostics Tests 1. Logging Configuration 1. HTTP Checking
- Known Issues
- Copyright Notices
This section describes the audience for this document, the organization of the material, and some additional sources of information.
The Google Calendar Connector Kit is a set of server-installed tools that require knowledgeable installation and configuration, tailored to the particulars of a customer's environment. These tools are only the technological part of the integration experience.
Before proceeding to install the Google Calendar Connector Web Service, please read and understand the important Security Considerations outlined in the Overview Guide.
This documentation is for systems administrators tasked with setting up and managing the Google Calendar Connector Web Service. Users of this documentation need to be familiar with the administration of Google Calendar, Microsoft Exchange Server, Active Directory, and Internet Information Services (IIS).
It is important to note that this tool only represents part of a solution for free/busy interoperability.
This document is part of the Google Calendar Connector document set, which includes the following related documents:
-
Overview Guide. Describes the components, process flow, and security considerations for the Google Calendar Connector Kit.
-
Sync Service Installation and Configuration Guide. Provides instructions for installing and configuring the Sync Service to provide free/busy data flow from Google Calendar to Exchange.
For background or general information on Google Apps, see the Google Apps for Administrators Help Center.
For background or general information on Windows administration, see Microsoft TechNet.
Before you install and configure the Google Calendar Connector Web Service, make sure your Windows environment meets the following prerequisites, and that Google Calendar and Exchange are prepared for sharing data.
- Google Apps Premier or Education Edition domain
To support the Web Service, your Windows environment must meet these prerequisites:
- Microsoft Windows Server 2003
- Internet Information Services (IIS) 6.0
- Microsoft Exchange Server 2003 SP2 or Microsoft Exchange Server 2007 SP1 or SP2
- ASP.NET 2.
To prepare Google Calendar for sharing free/busy data, you must perform these tasks:
- Login to your Google Apps Domain control panel. https://www.google.com/a/yourdomain.com
- Select Advanced Tools
- Scroll down to Free/Busy service
- Click on Set up Calendar to use your free/busy web service
- Select I am using a free/busy service at this URI:
- Enter the URI for the Calendar Connector Web Service
For example: https://mywebserver.acme.com/GCalExchangeLookup/Exchangequerier.aspx (Please review the project http://code.google.com/p/google-calendar-connectors/wiki/FAQ for more details and common questions)
The user name and password are required when you populate the GoogleApps.AdminUser.Login and Password parameters in the configuration process. NOTE: Before this account can be used with the connector you must login to Google Apps account and accept the standard terms of service agreement for the user account.
The Web Service requires dedicated Active Directory user accounts for performing LDAP queries and diagnostic tests with Exchange. Create these users as described in this section, and note the user names and passwords to provide when configuring the web service.
Create a dedicated user for performing Active Directory LDAP queries. The user name and password are required later when you populate the ActiveDirectory.DomainUser.Login and Password parameters in the configuration process. This account is also used by the Google Calendar Connector Sync Service if it is installed in the same environment.
Create a dedicated user for the connector web service to use for retrieving free/busy data. The user name and password are required later when you populate the Exchange.GCalQueryUser.Login and Password parameters in the configuration process.
NOTE: If you want to include appointment detail along with free/busy data, the Exchange Query User will need to be granted "Receive As" permission for all mailboxes. Refer to the Exchange Query User for details on how to delegate this permission.
Create a dedicated user for the connector web service to use for running diagnostic tests. The user name and password are required later when you populate Exchange.GCalQueryAdmin.Login and Password parameters in the configuration process. This account is also used by the Google Calendar Connector Sync Service if it is installed in the same environment.
The Exchange Query User user needs the extended "Receive As" permissions to be able to read appointment data for all Exchange users. Without setting this permission it gets the default Exchange permissions which typically only shows only free/busy data and no appointment detail.
To configure the permissions for the Recieve As:
Exchange 2003: 1. Start Registry Editor (regedit). 1. Navigate to the following key: HKEY_CURRENT_USER\Software\Microsoft\Exchange\ExAdmin 1. On the Edit menu, click Add Value, and then add the following registry value: 1. Value Name : ShowSecurityPage 1. Data Type : REG_DWORD 1. Value : 1 1. Close Registry Editor. 1. Start the Exchange System Manager. 1. Right Click on your Exchange Organization Name and select Properties 1. Select the Security Tab 1. Click the Advanced button 1. Click Add 1. In the Select Users, Computers, or Groups dialog enter the user name of the query admin user and click OK 1. Check the Allow box for the permission "Receive As" and click OK
Exchange 2007: 1. Allow "Receive As" permissions to Exchange Query User role account to read appointments details of a users' mailboxes.
Add-ADPermission -Identity _Mailbox folder_ -User Exchange.GCalQueryUser.Login -ExtendedRights Receive-As
Example: Add-ADPermission -Identity "Mailbox Database" -User syncuser -ExtendedRights Receive-As
The Exchange Information store caches permissions data. To flush the cache immediately after setting new permissions, dismount and remount the appropriate public folder store or restart the Information Store service. Otherwise the changes will not take effect until Exchange rebuilds the permissions cache.
To dismount and remount the public folder store:
- Open Exchange System Manager
- In tree view, expand Administrative Groups, {Your Administrative Group}, Servers,{Your local Exchange server}, and {Your Storage Group}.
- Right click on the Public Folder Store, select Dismount Store and click Yes to continue.
- Right click on the Public Folder Store, select Mount Store and click Yes at the success message dialog.
To restart the service Microsoft Exchange Information Store:
- Open the services.msc
- In right pane view, locate Microsoft Exchange Information Store, right click and select Restart
| Task | Completed? | Notes |
|---|---|---|
| Verify that Windows environment prerequisites are met | ||
| Provide Web Service URL to Google Apps Support | URL: | |
| Create dedicated Google Apps Web Service user | User name and password: | |
| Create dedicated Active Directory user | User name and password: | |
| Create dedicated Exchange Query user | User name and password: | |
| Create dedicated Exchange Admin user | User name and password: | |
| Set Exchange permissions for Query and Admin users |
The installer for the Web Service is provided as the file GoogleCalendarConnectorWebService.msi.
To install the Web Service:
- Locate and open the file GoogleCalendarConnectorWebService.msi.
- In the welcome dialog, click Next.
- Specify the desired virtual directory location, or accept the default value GCalExchangeLookup on the Default Web Site, and click Next.
- Click Next to begin the installation, and then Close when the dialog displays the message "Installation Complete".
- Open Internet Information Services (IIS) Manager and verify that the ASP.NET 2.0 Web Service Extension is "Allowed". * In the IIS Manager tree view, expand the local server. * Select Web Service Extensions. * From the list of web service extensions, select ASP.NET v2.0 and click Allowed.
- Using the IIS Management Console, update the Web Site to use v2.0 of the ASP.NET runtime.
- In the IIS Manager tree view, select the Web Site where the GCALExchangeLookup virtual web directory was created. . * Right click on the Web Site and select Properties. * Select the ASP.NET tab and set the ASP.NET version to 2.0. * Click OK to close the Properties dialog.
If you need to setup more than one domain with the Google Calendar Web Service you can use the following instructions for setting up multiple instances of the Google Calendar Web Service on a single server.
- Install the Google Calendar Web Service
- Copy the default install of the Web Service to a new folder, for example: C:\Inetpub\wwwroot\GCalExchangeLookup-domain.com
- Create new IIS Virtual Web Directory for the copy for domain.com on the default web site
cscript %WINDIR%\SYSTEM32\iisvdir.vbs /create w3svc/1/ROOT "GcalExchangeLookup-domain.com" "C:\Inetpub\wwwroot\GCalExchangeLookup-domain.com"
- Configure new logging paths: Edit the web.config and update the following log path values
<file value="C:\Google\logs\domain.com\WebService.log" />
initializeData="c:\google\logs\domain.com\WebNetTrace.log"
- Update the specific Google Apps Domain Values
<add key="GoogleApps.DomainName" value="domain.com" />
<add key="GoogleApps.AdminUser.Login" value="user" />
<add key="GoogleApps.AdminUser.Password" value="password" />
Special file system permissions must be set to allow the encryption of the web.config and the ability for the Web service to write files to the file system.
The local NETWORK SERVICE account requires modify access to the Web Service's virtual directory folder to perform encryption of the configuration file as well as modify access to the logging and data folders configured in the web.config file.
In Web.config\appSettings:
- NETWORK SERVICE must have "MODIFY" privileges to the GoogleApps.GCal.LogDirectory directory.
- NETWORK SERVICE must have "MODIFY" privileges to Web.config file.
In _Web.config\configuration\log4net\appender_:
- NETWORK SERVICE must have "MODIFY" privileges to configuration\log4net\appender\file.
To grant "Modify" access to a directory do the following:
- Open Windows Explorer.
- Navigate to the directory root folder (i.e. C:\Inetpub\wwwroot\GCalExchangeLookup).
- Right click on the folder and select Properties.
- Select the Security tab and click Add, type NETWORK SERVICE and click OK.
- With the NETWORK SERVICE user highlighted, check Allow for Modify privileges.
Configuration settings for the Web Service are stored in Web.config. You must edit this file to enter appropriate values for your setup. Additional configuration options for advanced users are available with in-line comments in Web.config. It is recommended you enable Configuration.EncryptOnNextRun when you have finished editing and tested the Web.config.
The "appSettings" section of web.config, located in the Web Service virtual directory, contains the following important configuration keys:
| Configuration Key | Description | Default Value |
|---|---|---|
| ActiveDirectory.DomainController | Specify the fully qualified domain name of a domain controller for your Windows Active Directory domain. This server is used for LDAP queries to retrieve user login and Exchange user attributes. For queries directly against a domain controller, prefix the machine name with LDAP://. For queries against the Global Catalog, prefix the machine name with GC://. For example: <add key="ActiveDirectory.DomainController" value="LDAP://HQAD1.corp.acme.com"/> |
|
| ActiveDirectory.DomainUser.Login | The userPrincipalName for the user account used by the web service to perform Active Directory lookups. See Dedicated Windows Service Accounts for more information on this user account. For example: <add key="ActiveDirectory.DomainUser.Login" value="[email protected]"/> |
|
| ActiveDirectory.DomainUser.Password | The password for the user account used by the web service to perform Active Directory lookups. | |
| Exchange.ServerName | The full qualified domain name of the target Exchange for the web service to communicate with. If this server does not host a copy of the Free/Busy Public Information store, you must specify the setting: Exchange.FreeBusyServerName. For example: <add key="Exchange.ServerName" value="HQEXCH1.corp.acme.com"/> |
|
| Exchange.GCalQueryUser.Login | The userPrincipalName of the user account used to query Exchange for free/busy data. See Dedicated Windows Service Accounts for more information on this user account. For example: <add key="Exchange.GCalQueryUser.Login" value="[email protected]"/> |
|
| Exchange.GCalQueryUser.Password | The password for the Active Directory user account used to query Exchange for free/busy data. Exchange. | |
| Exchange.GCalQueryAdmin.Login | The userPrincipalName of the user account used in running diagnostic tests for the web service. This must be an Active Directory user with rights to write data to the public folder free busy store. See Dedicated Windows Service Accounts for more information on this user account. For example: <add key="Exchange.GCalQueryAdmin.Login" value="[email protected]"/>. |
|
| Exchange.GCalQueryAdmin.Password | The password for the user account used in running diagnostic tests for the web service. | |
| Exchange.DefaultDomain | This setting prevents Exchange WebDav redirects to servers outside of the DNS domain defined. Enable this feature if the connector should not redirect Exchange server outside of this DNS domain. For example: <add key="Exchange.DefaultDomain" value=".corp.acme.com"/> |
DISABLED |
| Exchange.FreeBusyServerName | This setting allows the definition of a specific Exchange server to use when reading and writing free/busy data. By default the value Exchange.ServerName is used. Use this value if the default Exchange server does not host a replica of the Free/Busy Information Store. To enable this setting remove comments and define the fully qualified domain name of the server to use. For Example: <add key="Exchange.FreeBusyServerName" value="http://HQEXCH2.corp.acme.com"/> |
DISABLED |
| Exchange.EnableAppointmentLookup | This setting controls if the free/busy lookup should also retrieve and return appointment details. To enable appointment details to be returned set the value to True. For Example: <add key="Exchange.EnableAppointmentLookup" value="True"/> NOTE: See Dedicated Windows Service Accounts for more information on how to grant access to read appointment data for the service accounts. |
false |
| Exchange.LDAPQuery | This setting specifies the LDAP query that returns unique ActiveDirectory user object based on the identity passed in. In most cases, the passed in identity is a user's primary SMTP email address and therefore, the LDAP query string in most cases is "(mail={0})" (the {0} is replaced with the identity while querying LDAP). However, in the cases when users are identified by other primary fields, the value of this key should be set to appropriate LDAP query string. For example, to uniquely identify users by userPrincipalName, set the value to (userPrincipalName={0}) | (mail={0}) |
| Exchange.MaxConnections | This setting defines the maximum number of concurrent connections that can be made to configured Exchange server. To enable this setting remove comments and and define the max number of connections. For Example: <add key="Exchange.MaxConnections" value="50"/> |
|
| Exchange.ExchangeAPI | This setting determines which API is used by Web Service to query for free/busy data. There are two supported options "WebDAV" and "EWS". For Exchange 2003 environments, only "WebDAV" is supported. For Exchange 2007 environments "EWS" is the preferred method as this API provides real-time free/busy data from Google Apps along with appointment details. The "WebDAV" options is still fully supported for Exchange 2007 however, this API method only provides free/busy data and does not support appointment details. The free/busy data for the "WebDAV" API option is updated only periodically by the Sync Service. | WebDAV |
| Exchange.EWSURLPath | The URL path to Exchange Web Services on an Exchange Client Access Server. For example: <add key="Exchange.EWSURLPath" value="/EWS/Exchange.asmx"/> |
/EWS/Exchange.asmx |
| GoogleApps.DomainName | The domain name used by Google Apps. For example: <add key="GoogleApps.DomainName" value="acme.com" /> |
|
| GoogleApps.AdminUser.Login | The Google Apps user account name used for querying Google Calendar. This account must be a dedicated account in Google Apps setup for use with the Google Calendar Connector. For example: <add key="GoogleApps.AdminUser.Login" value="gcc_websvc" /> |
|
| GoogleApps.AdminUser.Password | The password for the Google Apps user account used for querying Google Calendar. | |
| GoogleApps.GCal.LogDirectory | This setting defines the directory to write debug output for the GDATA API feed for each user account queried from Google Apps. An individual file is written out per user request. The output contains the calendar feed data for the specific user. If no value is defined no output is written. For Example: <add key="GoogleApps.GCal.LogDirectory" value="C:\Google\logs"/> |
DISABLED |
| GoogleApps.GCal.DomainMapping | This setting allows the definition of SMTP domain name mappings. Use this setting if your Exchange Primary SMTP address is different from the Google Apps SMTP domain name. When enabled the connector maps the external Google Apps SMTP domain name to the internal Exchange SMTP domain name. This setting by default is commented out in the config file. To enable this setting remove comments and define the External and Internal SMTP domain names. For example: <add key="GoogleApps.GCal.DomainMapping" value="acme.com,exchange.acme.com"/> |
DISABLED |
| WebService.RequireLocalAccessforDiagnostics | This settings allows controlled access to the diagnostics.aspx page. By default the value is set to true which means you can only access the diagnostics.aspx from the local machine where its installed. NOTE: There is not authentication required to access this page and it can not be deleted. This page can query Active Directory for user accounts and Exchange user free/busy data. Opening access outside of localhost could leak sensitive user information. We recommend you always ensure this restriction is enforced. For example: <add key="WebService.RequireLocalAccessforDiagnostics" value="true"/> |
true |
| WebService.DefaultGoogleCalendarSSL | This setting allows you to override the default Google Calendar URL detection used by the web service. Some browsers might not properly set the referrer header. The referrer header is used to determine if you are using Google Calendar via HTTP or HTTPS. By default if no referrer header is found we use HTTPS as the default URL for Google Calendar. If your Google Apps Domain is configured to always use HTTP and the browser is not setting the referrer header data might not be posted back to Google Calendar properly. To work around this problem you can force the Web Service to always post to a HTTP Google Calendar URL. Add the following property to the web.config file: <add key="WebService.DefaultGoogleCalendarSSL" value="false"/>. **NOTE: We recommend you only set this value if you are experiencing this specific problem, and only if your Google Apps Calendar settings always force HTTP. |
NOT CONFIGURED** |
Because some configuration keys contain user names and passwords in plain text, it is recommended that you encrypt these configuration parameters. To enable encryption, Load the Diagnostics.aspx page. Click the "Encrypt Config Settings" button. This will rewrite the web.config with the configuration values encrypted. NOTE: "Network Service" must have modify privileges to the directory to rewrite the encrypted file.
This encryption method will encrypt the entire appSettings node of the configuration file, rendering it unreadable. Once encrypted, the settings are no longer in plain text on the file system. However, settings can still be changed through the IIS Manager.
The Web Service can optionally be configured to work with an HTTP proxy. This configuration may be required if all out-bound communication needs to be routed through a proxy. Configuring the HTTP proxy parameters in Web.config will instruct the Web Service to forward its communication through such a proxy.
Microsoft Support includes an overview of the same process and configuration in the following Knowledge Base article: http://support.microsoft.com/kb/307220.
The table below outlines the configuration parameters located under the <system.net.defaultProxy> node of Web.config:
| Configuration Key | Description | Default Value |
|---|---|---|
| bypasslist.address | Allows the Web Service to bypass the proxy for additional, non-local addresses. As per Microsoft's instructions, this field can contain a host name, or a regular expression. | |
| proxy.usesystemdefault | Instructs the .NET client to either use the default system profile for access, or to use a custom proxy defined in proxy.proxyaddress. To override the system default and configure a custom web proxy for the Web Service, this variable should be FALSE | True |
| proxy.proxyaddress | The URL:PORT pair for your proxy server. For example: http://proxyserver.corp.acme.com:3128 |
|
| proxy.bypassonlocal | Allows the Web Service to bypass the proxy for local addresses containing a ".". | True |
Important Note: Please carefully consider whether your Microsoft Exchange server communication should be sent through a custom proxy. Including Microsoft Exchange servers in a custom proxy scheme could result in decreased performance and certain types of Windows authentication may fail.
After completing the installation and configuration tasks, perform the following to verify that the Google Calendar can query free/busy data from Exchange.
To look up an Exchange user's free/busy information from Google Calendar:
- Choose an Exchange user with known free/busy times.
- Log on to Google Calendar.
- Click Create Event to open an event page.
- Click Check guest and resource availability to open the resource scheduler.
- Enter the e-mail address of the chosen Exchange user and click "Add".
- Click Refresh all
- Verify that the free/busy information displayed in the resource scheduler matches the known information.
If the Web Service does not work as expected, diagnostics should be run to identify any issues. If no data is return to Google Calendar, enable DEBUG logging to verify the web service is receiving the Google Calendar free/busy request. Refer to the "Logging" section for details. If unexpected issues persist, please refer to the sections entitled "Logging" and "HTTP Checking".
This section describes simple verification tests for the Web Service and provides some resources for troubleshooting common test failures. If the Web Service does not return free/busy data, use the following diagnostics tests, logging information, and troubleshooting checklist to identify and correct any issues.
Important Note: Please review Logging Configuration before beginning to test any of the functionality of the service.
The Web Service contains a diagnostics page that can help diagnose issues. Diagnostics.aspx, located in the root of the Web Service virtual directory, contains the following diagnostic tests for the web service:
- Verify users can be found in Active Directory
This test queries the Active Directory domain controller specified in ActiveDirectory.DomainController and returns all objects found in the result set. Specific LDAP queries can be tested using the text-area (cn=
*is the default). This test verifies that the Web Service can properly connect to an Active Directory server and retrieve user/contact information.
- Verify free / busy information can be found in Exchange (+/- 7 days)
This test verifies that the Web Service is correctly configured to talk to the Exchange server, and retrieve free/busy information for a user or contact. Please be aware that this test only returns free/busy information within 7 days of the current date.
- Diagnostics.aspx also contains other tests which are intended for test and troubleshooting the Sync Service.
The Google Calendar Connector includes a configuration node named
<log4net>
in Web.config which controls the logging behavior of the Web Service.
To use logging to troubleshoot Web Service issues:
- Verify Log Path:
<file value="C:\Google\logs\WebService.log" />
- Increase the logging level:
<level value="DEBUG" />
- Verify log file system permissions if the file is not created.
To change where the log file is stored, edit the node path configuration/log4net/appender/file and change the value attribute of the file node to the new location. Include the file name in the value attribute. NOTE: the NETWORK SERVICE account needs "Modify" access to the file system path. Increase the logging level
There are four logging levels, with DEBUG providing the most output and ERROR only logging severe events:
- DEBUG
- INFO
- WARN
- ERROR
The Web Service has many potential logging points for the DEBUG and ERROR levels. When logging is set to these levels, the size of the log file may grow very rapidly.
To set the Web Service logging to a certain level, edit the node path configuration/log4net/root/level and change the value attribute to one of the four levels listed. Lower severity levels are inclusive of higher levels. For example if the Web Service is set to INFO, it also logs WARN and ERROR but not DEBUG messages.
If log files are not being written verify that the following file permissions have been set up properly:
In Web.config\appSettings:
- NETWORK SERVICE must have "MODIFY" privileges to the GoogleApps.GCal.LogDirectory directory.
- NETWORK SERVICE must have "MODIFY" privileges to Web.config.
In Web.config\configuration\log4net\appender:
- NETWORK SERVICE must have "MODIFY" privileges to configuration\log4net\appender\file.
To grant "Modify" access to a directory do the following:
- Open Windows Explorer.
- Navigate to the directory root folder (i.e. C:\Inetpub\wwwroot\GCalExchangeLookup).
- Right click on the folder and select Properties.
- Select the Security tab and click Add, type NETWORK SERVICE and click OK.
- With the NETWORK SERVICE user highlighted, check Allow for Modify privileges.
In addition to diagnostic tests, HTTP analysis tools can be used to view the actual data that is being passed between Google Calendar and the Web Service. HTTP Analyzer (for Microsoft Internet Explorer) or Live HTTP Headers (for Firefox) are examples of HTTP analysis tools.
To troubleshoot the Web Service with an HTTP utility:
- Check whether a lookup request is sent from Google Calendar to the Web Service. The link for the request should match the Web Service URL provided to Google Apps.
- If Google Calendar is not making any requests, please contact Google Apps support to verify that the Google Calendar Connector interoperability is enabled for your domain and properly configured.
- Check the IIS log files for requests for the Web Service URL which was provided to Google Apps (ending in ExchangeQuerier.aspx) and verify that the result code is 200.
- Check the IIS log files on your Exchange server to verify the WebDAV requests the Web Service is making into Exchange.
- If a Google Calendar request is being made and the Web Service is responding, verify that the Web Service response is an HTML snippet with a POST action to the Google Calendar servers. If it is not, please send a copy of the response to Google Apps Support.
- If Google Calendar fails to add free/busy information from a valid Web Service response, there may be browser issues. Please contact Google Apps Support with your browser version and error information.
- Some versions of Firefox 3 Beta do not pass the referrer header to the Google Calendar Connector Web Service. When using SSL, this can result in the Google Calendar free-busy lookup requests causing a redirect to the login page. The referrer header is used to determine if the mailslot post url should be HTTP or HTTPS. To force SSL if the header is not being passed you can set the config setting: WebService.DefaultGoogleCalendarSSL=True
Library and license attributions are provided to conform with the Apache License, Version 2.0. A copy of the Apache License, Version 2.0 can be found here. The following licenses and libraries are used in the Google Calendar Connector Web Service:
- Google Data (GData) API .NET Client Library and its dependencies licensed under the Apache License, Version 2.0. (project, license)
- Apache log4net licensed under the Apache License, Version 2.0. (project, license)
- tz4net v3.0.2.0 licensed under the GNU LGPL V2. (project, license)
Portions Copyright (c) 2002 James W. Newkirk, Michael C. Two, Alexei A. Vorontsov or Copyright (c) 2000-2002 Philip A. Craig
Google, Google Calendar, Google Calendar Connector, Google Calendar Connector Web Service, Google Calendar Connector Sync Service are trademarks of Google, Inc.
All other company and product names may be trademarks of the respective companies with which they are associated.