How can we improve Kerio Connect?

Improve - speed up Outlook connector KOFF

404 votes
Sign in
Signed in as (Sign out)
You have left! (?) (thinking…)
Dama shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →


Sign in
Signed in as (Sign out)
  • test Karolini commented  ·   ·  Flag as inappropriate

    This is a waste of time to speed up KOFF. This thread is 7 years old and KOFF is still slow compared to Exchange / Activesync (with same mailbox data) - why not just implement Native Exchange compatibility in Kerio Mail Server and be done with it. We actually plan to migrate to another mail server with native Exchange compatibility because of Kerios / GFIs ignorance on KOFF matter.

  • Johannes Feigl commented  ·   ·  Flag as inappropriate

    we are already using SSD,
    but with big mailboxes it is too slow,
    when searching for mails you can go for a coffee.

    this should be TOP-PRIORITY!

  • Radim Dvořák commented  ·   ·  Flag as inappropriate

    In my opinion the only way is to switch to a SSD. Compare KOFF Firebird database of let's say 10-20 GB size with a PST/OST of the same size and you end up needing SSD anyway. During the last years the SSD size grew and prices dropped significantly, so for a heavy worker that is the way to go now.

  • Markus Mohr commented  ·   ·  Flag as inappropriate

    I can support this. KOFF is REALLY slow with bigger mailboxes, especially for roadworkers with laptops and 5.4k drives. Not everyone runs SSD's.

  • Admin commented  ·   ·  Flag as inappropriate

    Please investigate in the OutlookOfflineConnector. Ist sooooooo slow. Espeacialy Changing beween clander and mail view, or searches in emailfolder with a few thousand mails. Exchange PST or OST are much faster. If KOFF Needs more RAM to be fast, OK! Most PC have plenty of RAM.

  • Dancal commented  ·   ·  Flag as inappropriate

    I really push my customers to choose Kerio vs. Exchange, but now I'm in serious troubles because ALL of my customers are complaining about Outlook (with KOFF) being TOO MUCH SLOW.

    The only improvement that has happened here is relying on customers to purchase fast SSDs... I see no improvement to this issue for 3 years

  • GK commented  ·   ·  Flag as inappropriate

    The only improvement that has happened here is relying on customers to purchase fast SSDs... I see no improvement to this issue for 2 years

  • Benjamin Clot commented  ·   ·  Flag as inappropriate

    How is the performance improvement going? Because the last update dates back 2+ years...
    Synchronization has gotten faster but search speed is awful (8.3.2).

  • C. Spann commented  ·   ·  Flag as inappropriate

    20 users consuming about 120 GB on Windows Terminal Servers just for caching mails that already are online on kerio server! Please STOP that.!

  • Anonymous commented  ·   ·  Flag as inappropriate

    ... also the receiving of messages after 2 weeks of holiday, takes a while and there is no window, no sign, no send/revice-status in outlook.

    For users: it looks like, it doesn't work

  • Drewe commented  ·   ·  Flag as inappropriate

    Please keep this up! We like Kerio but it's too slow on outlook - WAY too slow (we are on 7.4.2). we have many users with >1G, probably 25+ (all the senior management) with 10G+.


  • Ronald Otto commented  ·   ·  Flag as inappropriate

    @administrador: That's not true. It is not the account size but sometimes the folder size that matters.

    i don't understand why PST is so much faster while KOFF is using a database. Maybe there is a way to build KOFF so it uses pst as a storage?

  • Dee Lowndes commented  ·   ·  Flag as inappropriate

    Speed of this has to be improved windows users are used to fast access to there email and searching no matter how they manage there mailboxes. It should be planned and started already as the potential market once sorted is huge for you. As it is we struggle to suggest it to the majority of our clients because the way they work just doesn't suit the speed of the product. If I could give 9 votes to this I would!

    Flat file appears to be the issue so perhaps you should move it to a DB solution and eliminate that problem?

← Previous 1

Feedback and Knowledge Base