Results 1 to 19 of 19
  1.    #1  
    Our Administrator uses Business Connect and ever since his mailbox access time is slowed considerably. This is when he is in the office, on our lan, P4- 2.4, 512 ram, XP, Outlook 2002, 100mpbs connection.

    Whenever he tries to open a new message, he gets a "requesting data from exchange server" message. This delay can last for up to 30 seconds. Basically every function of his mailbox is slowed. He is the only user having this problem. He is also the only bc user. Any ideas would be greatly appreciated.

    He is using the latest version of Business Connect.

    (I posted this in another tread, sorry for the double.)
  2. #2  
    Hm...... I wonder if this is why my outlook has been slow. I'm going to have to check....
  3. #3  
    I have the same issue -- just assumed it was an Exchange problem. Hmmm .... That's not good.
  4. #4  
    Just ran a non-scientific test yesterday, and it apears my performance picked up when I turned off bizz con.
  5.    #5  
    I thought there would be other users experiencing this. I am in the process of moving our Exchange server to a faster box. It will be interesting to see how much, if any, performance increase there will be.

    I am sure I will be calling Sprint about this sometime next week.
  6. #6  
    You may need the service pack for Outlook 2002, if you haven't loaded it already.
  7. #7  
    kad66, did you come up with anything yet? I'm posting this while I wait for my "requesting data" screen to clear ....
  8. #8  
    I just upgraded to Outlook 2003 & have been using an exchange server connection to Exchange 2003 for the past week. I have been seeing the same messages as described above. Thought it was just what happens with Exchange. I'll try shutting off business connection to see if it goes away.

    Paul
  9.    #9  
    Upgraded our Exchange server. Performance was good for a while. Thought the problem had gone away. Then our Administrator leaves me a message complaining about the slow access time of his e-mail. All other users access time is great.

    It is obviously a problem with Business Connect. I am going to have to put aside some time to call Sprint. This problem seems to grow over time. When we first purchased the Treo and started using BC, everything was fine.

    Arg! Why is it always the boss's computer that has the problems?
  10. #10  
    kad66 - Here are some questions to help narrow down things a bit whether it is a pure client side issue or an Exchange server issue...

    Questions to ask a user if they seem to be having this problem:
    1) What version of Exchange are you working on?

    2) What version of the PE client are you using?

    3) What operating system are you using?

    4) Are alerts or push's enabled enabled?

    5) Are any other services (IMAP or POP) configured?

    6) When you see the problem, have you tried to reboot the PE client, Outlook, your workstation?

    If #6 does not clear the problem then it is probably related to the Exchange Server side...


    7) Does this problem go away after a certain period of time? Does it seem to get better at some point during the week?

    If the user says yes (although they may never realize it), then it could be the search table caching issue on the Exchange Server which appears to be a known problem according to this KB article from MS:

    http://support.microsoft.com/?id=216076

    It turns out MS clears these tables every week in the default setting so the symptoms could persist.

    That KB article is pretty detailed and only those with Exchange IT experience would be able to perform the tests in it and tell whether the user is in this state and perform the corrective action and tests recommended by Microsoft.

    What is important here is this could be the culprit and and if it can be shown that this is the case it could be an extremely valuable clue to the sporadic Outlook slowdown issues reported here on TreoCentral. It could also play a big part in BC figuring out how to code around this interesting defect talked about in the MS KB article.
  11. #11  
    For what its worth I am another BC user with the same problem described here. I don't remeber if I had this problem before the upgrade. If I did, I don't think it was as bad becuase I've really been noticing it a whole lot more lately.
  12. #12  
    socomon - Can you narrow the problem to a client or Exchange Seerver problem according to the steps I described previously?
  13.    #13  
    MobileGhost,

    Thanks for the post. As for the questions:

    1) What version of Exchange are you working on? 5.5, sp4
    2) What version of the PE client are you using? BC 6.0.6.111
    3) What operating system are you using? Win XP pro
    4) Are alerts or push's enabled enabled? No
    5) Are any other services (IMAP or POP) configured? No
    6) When you see the problem, have you tried to reboot the PE client, Outlook, your workstation?
    Yes. A reboot improves performance for a short time.
    7) Does this problem go away after a certain period of time? Does it seem to get better at some point during the week? He doesn't think so.

    I can't rule out the problem being with Exchange Server. But I can say without a doubt that the problem only exist with Business Connect. I will examine the KB article for any drawbacks and maybe give it try. I'd rather not go poking around the registry if I don't have too, but I will if I there is a chance it will make a difference.
  14. #14  
    kad66 - Thanks for the info. On #6 Can you quantify a short while? When you get in this condition can you take a look at Task Manager and see how much Mem Usage Connection.exe is taking? Also how much memory do you have?
  15.    #15  
    MobileGhost,

    I am not sure when I will be able to get that info. I haven't spoken to our Administrator this week. I will get with him and check on the mem usage first chance I get. As for RAM in his computer, 512.
  16. #16  
    It sure is nice to finally find others who have had this issue. I have a user with a Treo and I have a PC running Business Connect for him.

    The PCS Business Client Personal Ed. (version 6.0.6.1111) PC is Win2K Pro, Outlook client is Outlook 2000.
    The User's PC: Win2K Pro/SP4 with Outlook 2002. Service packed and patched to hilt for both OS and Office XP.

    Exchange Server: NT4 SP6a with Exchange 5.5, 50 mailboxes.

    The fix discussed in http://support.microsoft.com/?id=216076 does indeed resolve this problem, but only temporarily. If I do not reset the Reset Views Reg setting at least every 3-4 days, then access to the mailbox becomes unbearably slow for the user.

    The other thing that resolves this issue, is if I move his mailbox from one of my Exchange Servers to the other, but I think that might just accomplish a similar thing as the Reset Views does during Information Store maintenance.

    Has anyone else discovered anything new on this issue? Has anyone talked to Sprint Business Connect folks?

    Thanks.
  17. #17  
    timcrean - that's pretty much a 100% verification to the problem and the first I've seen of having somebody with enough control to check it out at the IT level. Some other posters I saw in the Communications Forum I think said that the manufacturer of the software, SEVEN, has a Beta program and apparently this problem is fixed. Rumor has it they are helping these users out that they have been able to get an email to directly and inviting them for a test drive.
  18. #18  
    Originally posted by MobileGhost
    It could also play a big part in BC figuring out how to code around this interesting defect talked about in the MS KB article.
    I'd hardly refer to the MS article as an explanation of a "defect".

    Relevant information for programmers is as follows:

    "There are two methods you can use to search on a folder with Extended MAPI, the Restrict() method and the FindRow() method. The Restrict() method caches the restriction on that folder and is not removed for several days. If the view, filter, or search is using an ever-changing primary index, a new restriction is added each time that the folder is called. This can lead to a severe decrease in the performance of the folder, because every time a change is applied, all the back links have to be accessed.

    Collaboration Data Objects (CDO) 1.21 can also cause the problem. CDOs MessageFilter object is implemented as a MAPI Restrict. If possible, CDO code which relies on MessageFilter should be replaced with equivalent Extended MAPI code using FindRow. This is not always possible though. For instance, CDO code which searches appointments cannot be replaced with Extended MAPI because Extended MAPI does not understand appointment items. In this case, the CDO code should be reevalutated to see if the number of different MessageFilters can be reduced."

    Clearly, what we have is an area of this software which has been poorly written. The authors clearly had an incomplete understanding of the ramifications of their technique, leading to widespread negative impact on Exchange performance among the unsuspecting user base.

    Even when reducing the Aging Time to 24 hours, and the Cleanup Interval to 12 hours, with only 3 people using this application Outlook performance slows horribly.

    Prior to modifying these intervals, Outlook was rapidly rendered virtually unuseable. It borders on criminal negligence in programming, in my opinion.

    The best workaround is to make the registry changes listed in KB159197 and devise a daily maintenance batch operation that stops the Information Store, executes "isinteg -fix -pri -test morefld", then restarts the store. This can be accomplished using the pre and post execution capabilities of most enterprise backup software solutions.

    This will allow your users to continue using this flawed software until Treo comes up with a fix.
  19. #19  
    cbranst2 - Great detailed information and especially the additional fix suggestions. It sounds like you have personal experience with this issue at the programming level.

    The MS KB article describes a problem that occurs in Exchange and how to diagnose it and offers some work-arounds. The fact that Microsoft has to come up with a very detailed KB article to describe this problem and offers the suggestion to tweak the registry is a pretty clear sign that this problem is design flaw on their side in Exchange. The MS work-around (but not a solution) of tweaking a registry is something most Exchange Admins would not consider and rightfully so.

    So at the programming level what good are the call(s) in third party code if they can't be used reliably in Exchange without having this as the symptom? It turns out this problem does not happen for everyone, myself included, and the developers have not been able to reproduce this problem in house for a long time, even given the thousands of BC users out there.

    That is where the mystery has been. Why does this show up with some Exchange servers and not others where usage and extreme testing yield no problems. Without a reproducible case then it becomes a needle in the haystack. The developers have been seeking confirmation to the problem as described by the KB article and fortunately more confirmation and helpful folks have surfaced here just to verify this one specifically. In steps MS fortunately who coughed up this KB article after some developer research by them at the prompting of the BC developers. I would certainly not refer to this as criminal negligence unless you were referring to MS not being robust enough to handle calls from other email clients certainly in a reasonable fashion. If they would let develeopers know up front that certain calls are "less than robust" then that would help dictate the client code.

    I personally think these work-arounds MS suggests are a bit ridiculous and a way to mask what has been a bigger problem for them. But in the short-term this is a way to avoid the problem at the Exchange level until a fix is made either on the MS side or at the BC side. The chances of MS fixing it are slim to none IMHO.

    Now with that said I do know that there is a Beta program in place where this specific problem is addressed. There are a number of TreoCentral users here that have indeed tested this fix who were having that problem. Hopefully it will be a short matter of time when Sprint upgrades and this particular problem is solved once and for all.

Posting Permissions