Connect. Communicate. Collaborate. Securely.

Home » Kerio User Forums » Kerio Connect » GAL vs Public Folders Contacts - advantage?
  •  
silver02suby

Messages: 35

Karma: 1
Send a private message to this user
Our company uses a Public Folders item for all of our Company Contacts, which is a listing of clients, vendors, etc, plus the employees within the company. It's available right in Outlook for the Windows users, it stays nicely synced into Address Book for the Mac users, and ActiveSync allows the iPhone users to search those contacts OTA so they don't have to have all 5500 contacts sitting in their iPhones.

Is there an advantage to going the GAL route? I'm not sure what I would gain for my company, if anything.

I know iPhone OS 3.0 will support CalDAV subscriptions, which solves the "I can't see the company calendar(s)" issue for iPhones, which is outstanding. Am I being as efficient as possible for my employees?

-Bill

Mac OS X Server 10.4.11, KMS 6.7.0 P1
  •  
Pavel Dobry (Kerio)

Messages: 5245
Karma: 251
Send a private message to this user
silver02suby wrote on Wed, 17 June 2009 04:56


I know iPhone OS 3.0 will support CalDAV subscriptions, which solves the "I can't see the company calendar(s)" issue for iPhones, which is outstanding. Am I being as efficient as possible for my employees?



Actually, it seems that calendar client on the iPhone is not ready to display calendars that come from Kerio MailServer or any other source than Apple iCal server. I'm afraid we will have to wait for some 3.x update ;-(
  •  
My IT Indy

Messages: 1262
Karma: 40
Send a private message to this user
Kerio_pdobry wrote on Wed, 17 June 2009 04:47

silver02suby wrote on Wed, 17 June 2009 04:56


I know iPhone OS 3.0 will support CalDAV subscriptions, which solves the "I can't see the company calendar(s)" issue for iPhones, which is outstanding. Am I being as efficient as possible for my employees?



Actually, it seems that calendar client on the iPhone is not ready to display calendars that come from Kerio MailServer or any other source than Apple iCal server. I'm afraid we will have to wait for some 3.x update ;-(



Can you explain your statement? I'm not sure what you mean.

-
My IT Indy
Kerio Certified Reseller and Hosted Provider
http://www.myitindy.com
  •  
Pavel Dobry (Kerio)

Messages: 5245
Karma: 251
Send a private message to this user
HoosierMac wrote on Wed, 17 June 2009 15:40

Kerio_pdobry wrote on Wed, 17 June 2009 04:47


Actually, it seems that calendar client on the iPhone is not ready to display calendars that come from Kerio MailServer or any other source than Apple iCal server. I'm afraid we will have to wait for some 3.x update ;-(

Can you explain your statement? I'm not sure what you mean.


Since iPhone 3.0 has been released few minutes ago I can comment it more.

iCal client on the iPhone does not have proper support for time zones. The result is that all events created by any other client than Apple iCal are displayed incorrectly. Event duration is not counted properly. That makes calendar unusable. Only CalDAV and .ics calendars are affected.

Therefore, the only recommended solution remains using Exchange (ActiveSync) account for syncing calendars. But this does not support other than private user calendar.
  •  
mpermann

Messages: 96
Karma: 0
Send a private message to this user
I did a quick test using the iPhone 3.0 software and a CalDAV added calendar. I used my GMail calendar and setup the calendar on the iPhone using the URL shown on Google's help site for iCal. It connect and the events are displaying on my iPhone properly. Then I added an event on the iPhone and it "synced" up to Google with all the proper details. So to test Kerio_pdobry statement about time zone support I created a new event on Google Calendar with a specific time and various other details and it all pushed down to the iPhone just fine. Maybe because my iPhone and Google calendar are both in the same time zone all worked properly. But, I can say for me, the iPhone 3.0 software is allowing me to connect to my Google calendar using the new CalDAV method. Now I am able to have my work Kerio (using ActiveSync) and my Google Calendar (using CalDAV) syncing to my iPhone. So, this is a good thing. Maybe Kerio_pdobry will elaborate on the specifics of the issue with time zone support.
  •  
Pavel Dobry (Kerio)

Messages: 5245
Karma: 251
Send a private message to this user
It probably works with Google calendar because Google is using same unix time zones as an iPhone. So, everything is good if your client creates event with time zone like "America/Los Angeles, Europe/London or Europe/Prague". Unfortunately, in the real world, most of the clients (including all Windows products and) use different time zone definitions "Pacific Standard Time" or "London, Casablanca" or "Amsterodam, Berlin, Prague". It is also common that the time zone definition used by the event has completely different name, because the name is only a description, not a key.
iCal does not parse the definition of the timezone from the event (meeting request) but tries to match the name. In most cases the name is different and the event is displayed incorrectly.
  •  
intruck

Messages: 2
Karma: 0
Send a private message to this user
I was originally looking at subject: Subscribed Calendar in iPhone 3.0 (problem) [message #62235], which pointed to http://forums.kerio.com/index.php?t=msg&th=15555&sta rt=0#msg_62200. With the issue being the event ending date showing up as 2145 on ical calendar subscriptions. The issue with time zones being the issure sounds good but I can't totally accept that as the reason. I am running our Kerio 6.7 server on Red Hat so in theory the "unix" time zone should work, but with testing, not always.
I tried many various methods of entering events on different pc's or devices and reading the event on a iPhone thru a subscribed calendar and this is basically what I got to work and not work.
If a calendar entry is entered with the all day event checked, or the entry is setup to span 2 or more days the calendar entry displays the correct start and end dates and times. If the entry is left to the default 1/2 hour or set to 1, 4, 6, etc hours the event will display with the ending date in the year 2145.
My first guess would be that the ending date was not put in the record if it was the same as the starting date, unless you mark it as an all day event in which case the ending date and time was set to midnight of the same day.

Upon further investigation an calendar entry that is a 1/2 hour in length the date/time entry looks like this:

DTSTART;TZID="Central Time (US & Canada)":20090707T123000
DTEND;TZID="Central Time (US & Canada)":20090708T130000

but if is marked as an all day event, it looks like this:

DTSTART;VALUE=DATE:20090707
DTEND;VALUE=DATE:20090708

Like I stated earlier the TZ (Time Zone) issue makes sense because TZ tables are somewhat open in regards to the name description for a given zone. But if that was the issue here. WHY does the Start Date and Time display correctly and the ending date/time is incorrect when they are formatted the same?
Especially on the entries that last only a half hour?

[Updated on: Sat, 04 July 2009 00:21]

  •  
LarryS

Messages: 7
Karma: 0
Send a private message to this user
Umm. Way to hijack the thread.

I, too, would like to know the advantages of going with a global list over the subscribed public contacts, which I believe was the question.

Any pros and cons from those who have switched?

Thanks,

Larry
  •  
sedell

Messages: 1168
Karma: 1
Send a private message to this user
LarryS wrote on Wed, 08 July 2009 14:21

Any pros and cons from those who have switched?

Pro: The GAL automatically syncs data from Active Directory.
Con: It's currently broken.
Con: It gives no control over which user addresses are published to the GAL
Con: When creating accounts from Active Directory, they are automatically published to the GAL with no way to control the option to publish/not publish
Con: It allows changes to be made that get overwritten by the next LDAP refresh from AD

Scott
  •  
Pavel Dobry (Kerio)

Messages: 5245
Karma: 251
Send a private message to this user
sedell wrote on Wed, 08 July 2009 22:51


Pro: The GAL automatically syncs data from Active Directory.


Pro: No need to manually edit contacts in public folders. All changes can be done in AD.
Pro: New user/removed user change is automatically applied to the public contact folder (GAL).
Quote:


Con: It's currently broken.
Con: It gives no control over which user addresses are published to the GAL


All user emails are published in GAL. All email addresses are valid and used therefore in 95% of installations it is a big advantage.
Quote:


Con: When creating accounts from Active Directory, they are automatically published to the GAL with no way to control the option to publish/not publish
Con: It allows changes to be made that get overwritten by the next LDAP refresh from AD

AD is a primary source of user contact information so it it required to keep contacts in GAL updated with data from AD. Attributes that are not defined in AD (OD) remain in the contact untouched.

[Updated on: Wed, 08 July 2009 23:09]

  •  
LarryS

Messages: 7
Karma: 0
Send a private message to this user
Thanks for the info!

Larry
  •  
sedell

Messages: 1168
Karma: 1
Send a private message to this user
Kerio_pdobry wrote on Wed, 08 July 2009 16:58


Quote:


Con: It's currently broken.
Con: It gives no control over which user addresses are published to the GAL


All user emails are published in GAL. All email addresses are valid and used therefore in 95% of installations it is a big advantage.

I fail to see how this is an advantage. All I've seen is complaints about this "feature" as addresses that are not meant to be publicly advertised get published. Plus, it makes very little sense. If you have 4 addresses set up for someone, what good does it do to publish all of them? Anyone viewing the GAL is on the same system in the same domain, so ONE address is all they need to send that individual mail. The rest are redundant, unnecessary, and for quite a number of installations, causes problems. Since the first email address usually gets published, one of the reasons to create additional addresses is so you have an address that isn't publicly advertised for other specific purposes.

Kerio_pdobry wrote on Wed, 08 July 2009 16:58


Quote:


Con: When creating accounts from Active Directory, they are automatically published to the GAL with no way to control the option to publish/not publish
Con: It allows changes to be made that get overwritten by the next LDAP refresh from AD

AD is a primary source of user contact information so it it required to keep contacts in GAL updated with data from AD. Attributes that are not defined in AD (OD) remain in the contact untouched.


There is no way to control from Active Directory what users get published to the GAL. In the previous contact list, it was necessary to publish the user to the contact list, it didn't happen automatically. Now, it happens automatically, AND you can't disable it. That's just stellar when you need to create an account that is not to be published, and by the time you log into the admin console to turn off Publish to GAL, it's already been published and everyone knows about the account they weren't supposed to know about.

The second issue is there is no indication in the GAL of which account is an AD account, and which accounts are local accounts. Local accounts need to be updated from within webmail/Outlook. Since there is no indication of what contacts came from AD, and the changes are allowed to be made, it's extremely easy for people who don't have Active Directory Users and Computer open, or the admin console open, to make a mistake and edit an AD contact. There is also no indication of which data in a contact came from AD. There are more fields in a Contact than in AD. Some is stored on the server, some in AD. If changes need to be made on fields that aren't defined in AD, how does the user know which are going to be changed and which are going to remain? Some of their entries in a contact will remain, some will not. There is also no warning anywhere in the logs that I've seen that this manually entered data is getting overwritten. This results in data loss as a) someone editing a contact may have no idea where the contact came from or which specific contact data is stored in AD vs locally, b) changes are allowed to be made, c) the changes get automatically overwritten, d) there is no warning or notice logged that the data got overwritten.

Scott
  •  
elias

Messages: 114
Karma: 0
Send a private message to this user
sedell wrote on Thu, 09 July 2009 04:04

Kerio_pdobry wrote on Wed, 08 July 2009 16:58


Quote:


Con: It's currently broken.
Con: It gives no control over which user addresses are published to the GAL


All user emails are published in GAL. All email addresses are valid and used therefore in 95% of installations it is a big advantage.

I fail to see how this is an advantage. All I've seen is complaints about this "feature" as addresses that are not meant to be publicly advertised get published. Plus, it makes very little sense. If you have 4 addresses set up for someone, what good does it do to publish all of them?

I have to completely agree with this; this is not an advantage. Of all the users I have with second and sometimes third email addresses, there's not a single one that I want published. I suppose I could convert all those secondary addresses to aliases, but why?

I'm at the point where I'm likely going to disable the GAL, but since you've removed the manual publish button, now I'll have to create the initial entries by hand. If I use the GAL, my contacts don't look right and have extraneous data, if I don't use it, then I have to do everything by hand. You took a simple and straightforward process of publishing account info once for each user and then editing it as necessary to create an appropriate corporate address book, into something where there's no control and is much harder to manage.

-Elias
  •  
Jorgen

Messages: 8
Karma: 0
Send a private message to this user
I have to agree with Sedell and Elias!!

An working "straigth forward system" is turned into an "Pain In The *ss solution". I have already complains from 7 customers (in total around 400 mailboxes) and the only fix is to do everything by hand!!!

  •  
gbrown100

Messages: 175
Karma: 1
Send a private message to this user
I must admit I am having issues also, with my windows environment the upgrade to 6.7 wiped all the addresses from non AD contacts, it constantly repeated a particular contact in the Address book (fixed in the patch 1) but now I have several user accounts that are correct in AD, when you click on the To: field and try to pick them you get only one of the 4 email addresses they have and it is not even the Primary one and if you click in the Public Folder contacts they don't appear in there at all any more.

Am eagerly awaiting the next patch before raising a ticket about my issues. Thankfully I have a very understanding client who is manually entering the address info for 100 contacts all over again...

Personally the fact they appear in the offline address book is good but until you can stop multiple email addresses from being published in the GAL I am going to have to disable the GAL altogether I think and will think / test very carefully before installing on any other AD integrated environments.


Previous Topic: Outlook, KOFF and Contact activity tracking
Next Topic: Calendar via Sunbird/Lightning unavailable
Goto Forum:
  


Disclaimer:
Kerio discussion forums are intended for open communication between forum members and may contain information and material posted by members which may be useful in learning about Kerio products. The discussion forums are not intended to provide technical support for any specific product. Any information implied or expressed in the discussion forums is that of the posting member. Kerio is in no way responsible for the information posted in the forums, or its accuracy. Kerio employees may participate in the discussions, but their postings do not represent an offical position of the company on any issues raised or discussed. Kerio reserves the right to monitor and maintain the forums to promote free and accurate exchange of information.

Current Time: Sat Nov 18 12:51:17 CET 2017

Total time taken to generate the page: 0.00574 seconds
.:: Contact :: Home ::.
Powered by: FUDforum 3.0.4.