From outlook to webapp

tbone

Hey Marty,

I -myself- have 0 problems with kopano webapp, except the dragging attachments from kopano to somewhere else perhaps… its my users that are complaining as they have been using outlook for way too long… but as complaints come my way, I m asking around :)

Thanks allready for all the replies, I will be checking out all mentioned tickets above and see how far this gets .

In the mean time I would also like to point out that some of the lastest outlook 2016’s have a pesky noob-enabled config mode which can be turned off according to this article https://support.microsoft.com/en-us/help/3189194/how-to-disable-simplified-account-creation-in-outlook-2016 (It took me a while to find this so I thought it was a good idea sharing it here.). Maybe something worth putting in the Kopano manuals if it’s not in there allready. I still have to try it, but from within this noob config mode you cant add active-sync servers in outlook prilfe, yuck (EDIT: the procedure mentioned in the article works!)
.

marty

Hi tbone,

Thanks for the link :)
@fbartels might be interested in this.

fbartels

Hi @tbone ,

yes indeed. Microsoft tried to make the setup easier, but totally forgot to implement this for all their account providers. They promised to us to include a registry key to autoconfigure an ActiveSync account again, but I’ll only really believe it, once i’ve seen it.

btw. an automated way of setting this via KOE has been included for every build after version 220.

See https://jira.kopano.io/browse/KOE-134 for more information.

tbone

As for point 1 (MSG / EML) problem I stumbled on this :

http://search.cpan.org/~mvz/Email-Outlook-Message-0.916/script/msgconvert

that provides means to convert those msg files using a perl script. I have just tested this scenario and it actually works. So item 1 on my list is fixed.

Note: on my test system I had to install this perl module Email::Sender::Transport::Mbox using CPAN before the conversion tool worked.

It would be nice if this functionality is seemlesly built into webapp…

I wrote a little php script to process and entire tree of .MSG file (I had to convert over 150 000 msg files on my system spread across loads of dirs). Youonly need to modify the $path variable and verify that the msgconvert utliity is installed in /usr/local/bin. It may be of use to people that have similar issues.

<?php

$path = '/sambashares/';
$msgs = 0;
$recurse=0;
$userjunklist = null;

process($path);

echo "Converted $msgs items\n";
echo count($userjunklist)." items could not be converted due to rediculous quote usage, the list is in /tmp/userjunk.txt\n";
$ptr = fopen('/tmp/userjunk.txt','w');
foreach($userjunklist as $file)
        fputs($ptr,$file."\n");
fclose($ptr);

function process($dir) {
        global $recurse;

        myEcho("Entering $dir\n");

        if( hasMsgFiles($dir) ) {
                myEcho( "Found MSG files.. start conversion\n" );
                convertMsg( $dir );
        }

        // open dir en check if OK
        $dh = opendir( $dir );
        if(!$dh)
                        myEcho( " -ERROR: reading $dir\n");
        else {
                // dir is open nu lezen
                while (false !== ($entry = readdir($dh))) {
                        $fpn = $dir.$entry;

                        if( is_dir($fpn) && $entry != '.' && $entry !='..' && !is_link($fpn)) { // enkel dirs, geen . en .. of symlinks behandelen
                                $recurse++;
                                process( $dir.$entry.'/'); // recurse
                                $recurse--;
                        } 
                }
                closedir($dh);	
        }
}


function convertMsg( $dir ) {
        global $msgs;
        global $userjunklist;
        chdir( $dir );
        foreach( glob($dir.'/*.msg') as $filename) {

                myEcho( " -Converting $filename\n");
                // handle quotes in filenames
                if(strstr($filename,"'") && !strstr($filename,"\""))
                        exec("/usr/local/bin/msgconvert \"$filename\"");
                else if (!strstr($filename,"'") && strstr($filename,'"'))
                        exec("/usr/local/bin/msgconvert '$filename'");
                else if (!strstr($filename,"'") && !strstr($filename,'"'))
                        exec("/usr/local/bin/msgconvert '$filename'");
                else { // converting will throw error in shell 
                        myEcho("Adding $filename to userjunklist\n");
                        $userjunklist[] = $filename;
                }
                $msgs++;
        }
}

function hasMsgFiles( $dir ) {
        if(count(glob($dir.'/*.msg')))
                return( true ) ;
        else return( false );
}

function myEcho( $string ) {
        global $recurse;
        for($i = 0 ; $i < $recurse; $i++)
                echo "-";
        echo $string;
}

tbone

@marty Concerning number 3:

downloading all attachments in a zip is not a solution. People that are used to running outlook they take all kinds of simple thing for granted that dont work in webapp :

replying to a mail, adding received attachments from another mail is impossible without saving the attachements first, and then adding them in the new mail. They want to copy/paste or drag attachments from one incoming mail mail to another outgoing mail.
sorting out attachments to various fileserver locations without having to browse every single time is not possible. Users keep open several explorer windows and want to drag and drop to those locations without saving as.

I see in the JIRA ticket that this functionalitey is tagged with medium urgency and roadmap points at 4.0 branch. If you are trying to replace outlook with webapp, this kind of stuff is high priority.

A few other issues Ive encountered:

I had to disable the search function. Mails are regularly not found when this index is enabled. even stuff that was received yesterday is skipped by search function no matter the use of correct filters. My users rely heaviliy on this function …
Server load is very high, every http process takes up 100% cpu and my load is always 15+ where on my zarafa box load never was an issue. the kopano server is 5 years newer in hardware and it cant keep up…

fbartels

Hello @tbone ,

as for your

@tbone said in From outlook to webapp:

I had to disable the search function

and

@tbone said in From outlook to webapp:

every http process takes up 100% cpu

are you really talking about http processes or general processes? if its general processes it could mean that the search has not yet completed the indexing which (depending on tuning, data and hardware) can take some time. In general you are running quite an old version of Kopano Core. I would recommend to update to either the latest stable or the newest nightly (if you don’t have a valid subscription). Currently there are no issues known in regards to indexing new mail.

If you are really talking about http processes sitting at 100% then this is usually a sign of an infinite loop somewhere (at least that was the case when I saw that previously). again updating to the latest version is recommended. if this does not fix it I would recommend to disable plugins to try to narrow down the source of the problem.

To better troubleshoot I would recommend to either open up support cases or at least separate topics on the forum to tackle these issue more structured.

mcostan

@tbone

Hi, is it possible that the initial search has never completed? Did you check the search log file and see what it does?

I have search enabled on the server and I have never encountered problems.

If I receive a new email and perhaps even move it to another folder, and then search it again, it comes back very quickly.

For the http overload, are you running the kopano core on the same server as the http server?

I have split them as following:

a) one VM running httpd
b) one running kopano core
c) one running the DB

It also helps massively if you run the DB on a SSD disk (at least it helped me).

tbone

@fbartels

ok. I will first upgrade to latest version before posting anything else, the search log is filled with errors.

deisenlord

I would just like to second all of tbone’s comments regarding the usability of webapp/deskapp compared to Outlook, especially in the area of drag and drop and seamless opening of attachments. I’ve been personally using webapp/deskapp for over a year and I’m ok, The 35 Outlook users I support do not in any sense of the word find it acceptable simply due to these simple drag and drop features. It is still a HUGE issue for us migrating people from Outlook, in all honestly unless some of these basic features are added we will never get people off Outlook which means to my great, great regret Kopano might not be a long term option for us. BTW in my option, and I’ve worked very hard at testing it, the activesync/KOE Outlook solution is really not an option for a heavy email company like us where users may get 400 emails a day and have 30GB email boxes and 70GB archive stores and they travel. Just. Not. Practical. Period. I ppologize for the rant of sorts, I love zarafa/kopano but feel the client is not evolving fast enough.

marty

@tbone

I’ve created a ticket for downloading multiple attachments as non-zip:
https://jira.kopano.io/browse/KW-1976

Please track it for status updates.

tbone

@deisenlord

yes. for us its the same story. THE biggest problem is that Kopano has dropped the MAPI component for outlook. The activesync/KOE does not - by far - provide a workable alternative. In that sense Kopano is no longer a real exchange alternative. We have used zarafa for several years, coming from other exchange clones including HP OpenMail, Samsung Contact, Scalix and whatnot (all of them providing a MAPI component for outlook). We have huge public folders which huge trees that are now no longer accessible through outlook. Selecting top level trees and trying to add that to KOE will give me errors, and I dont even dare to think that oulook will by trying to sync 2TB over publics over ActiveSync? The only viable solution is to bring back the mapi component for outlook. IMHO. Just today we had a 5 hour IT meeting and we talked about mail issues about 4 hours and 55 minutes.

I really appreciate all the efforts the Kopano staff is putting in this forum to support us, but my advice remains to reinstate the outlook MAPI component asap. Im sure they have lost a lot of customers allready just because of that. Our management is going to put a stop on budget if I have to spend hours and hours searching for fixes or workarounds.

WebApp is a very nice tool, but it’s not an outlook replacement. Most users don’t settle with ‘you will have to get used to that’ as an explanation why something they have been taking for granted for so many years, and no longer work… Especially when some of those users are paying the bills. The ActiveSync protocol in itself is too limited to provide the same user experience the MAPI component did, and I guess we all know that. (I wish I was a fly on the wall at zarafa offices when they discussed to drop the mapi component, Im sure that was an interesting meeting :)) I came across a topic on ms technet from a guy who wanted to migrate his 11K user system to exchange. If they have clients like that I cant understand why they even considered to drop the mapi component. I reckon MS is giving competing companies like zarafa a hard time to keep up with mapi protocols, but regardless this is the one thing that should be (have been) on top of the priority list.

regards,