none
Lync/ucmapi prevent Outlook from Opening

    Question

  • Hi Everyone,

    We've been encountering the following problem:

    When a workstation loses connectivity to our Exchange servers, either through the Exchange server itself going down or loss of internet connectivity, some users will be unable to reopen Outlook once connectivity is restored and will be presented with the message "Cannot open your default e-mail folders.  The attempt to log on to Microsoft Exchange has failed."  Event viewer shows the following:

    Microsoft Outlook

    Cannot open your default e-mail folders.  The attempt to log on to Microsoft Exchange has failed.

    P1: 300032

    P2: 14.0.6029.1000

    P3: heqz

    P4: 0x8004011D

    This doesn't happen to all users and it seems to require connectivity to be lost for at least a few minutes.  We have determined that ending the ucmapi.exe process fixes this issue, but we'd like to determine the root cause to prevent having to go around killing ucmapi processes on hundreds of computers.  Lync, which I believe spawns the ucmapi process, is able to regain connectivity without issue.   

    The clients are running Windows 7 x64 with Lync 2010, Outlook 2010 (32 and 64 bit flavors - it happens on both) and Exchange 2007.  

    Thanks in advance for your help.  Please let me know if I can provide any additional information.

    -Ethan

    Tuesday, November 15, 2011 11:36 PM

All replies

  • Hi Ethan,

    Here’re some suggestions for you.

              Please update your server and client to the latest version.

              Please check this hotfix for Outlook 2010.

              Please confirm all the relevant services are started.

              Please refer to this post.

    If any, please feedback.

    Thursday, November 17, 2011 6:52 AM
    Moderator
  • Hi Noya,
    Thanks for your reply.
    • Server and client are on the latest version
    • That hotfix is already installed in our environment
    • All services are started
    • I believe that post references a different problem where Outlook won't close properly.  The issue I'm seeing involves Outlook not opening.  
    I've been able to compile a list of steps that I can follow to reproduce the problem.  It only works about half the time which makes me think something is messing up when UCMAPI is doing it's check for updated free/busy.
    Here are the steps:
    1. Open Lync and Outlook
    2. Open task manager and wait until ucmapi.exe process starts
    3. Disable internet connectivity for ~10 minutes to simulate lack of connection to Exchange
    4. Try to send/receive in Outlook - Outlook will hang
    5. Close Outlook and try to reopen - Outlook will be unable to find Exchange and will ask you to Retry, Work Offline or Cancel
    6. Restore internet connectivity
    7. Try to reopen Outlook - error message "Cannot open your default e-mail folders.  The attempt to log on to Microsoft Exchange has failed"
    I currently have an open ticket with the MS Integration team and I'll keep this thread updated.
    -Ethan

    • Edited by EthanTS Thursday, November 17, 2011 7:08 PM
    Thursday, November 17, 2011 7:07 PM
  • Hi Ethan,

    We have the exact same problem. Only difference is that we use Communicator client for Office Communications Server 2007 R2.

    Migrated users from Exchange 2007 sp2 to Exchange 2010 sp1, after that we experience the exact same problem.

    did you get any solution from Microsoft ?

    -Terje

    Tuesday, November 29, 2011 8:11 AM
  • Hi Ethan,

    We're having scattered intances of this issue as well.  So far we only have reports of it at locations that aren't directly connected to our network backbone....so the issue being triggered by an interruption of network connectivity seems to be a good possibility.

    Let us know if you get a response from Microsoft on this.

    Wednesday, November 30, 2011 4:11 PM
  • I'm still having a back and forth with MS about this and have gotten escalated several times.  I'll let you guys know if I hear anything more.  

    Out of curiosity, do either of you have tracing enabled for Lync?  In my test environment I wasn't able to replicate this error with tracing enabled but that doesn't mean that it still doesn't happen.  

    Wednesday, November 30, 2011 4:57 PM
  • We just started testing with tracing enabled after coming across the following technet link today (the issue mentioned in the link doesn't fit this thread exactly but it seemed close enough to warrent giving tracing a try): http://social.technet.microsoft.com/Forums/en-US/ocsucintegration/thread/14702a6d-096c-469e-8952-34850cc1dcd6

    The initial results from first couple of test machine we enabled it on seem to indicate it resolves (or at least masks) the issue.

    Wednesday, November 30, 2011 6:01 PM
  • That's what I've noticed too.  I'm tempted to try it out , but we use roaming profiles so I first need to redirect the tracing directory to a local folder.  I've tried to do this with the FileDirectory key in HKCU\Software\Microsoft\Tracing\Communicator but Lync resets it to %userprofile%\tracing each time it opens.  I've posted about this here: http://social.technet.microsoft.com/Forums/en-US/ocsclients/thread/775e2c88-c195-4315-9787-46ce31287642 

     

     

    Wednesday, November 30, 2011 7:01 PM
  • I was able to solve the issue I mentioned in my last post about tracing.  I'm slowly going to be rolling out enabling Lync tracing with the folder redirection to see if that's a plausible workaround. 

    I'll still be holding out for a real fix from MS though. 

    Wednesday, November 30, 2011 10:03 PM
  • Still nothing from MS on an official fix.  Tracing is looking promising now.  I've enabled it on 10% of our environment and no reported errors from that segment yet.  

    Does anyone know if there's any documentation on how the tracing logs are kept?  I think they're culled routinely but I want to make sure they're not building up because they do get large fast. 

    Thursday, December 08, 2011 7:44 PM
  • Just a "heads up"....I ran into this issue again today on one of the machines I enabled Lync logging (Tracing).  I had to resort to the old fix of chopping the ucmapi process before I could get Outlook to open for the user.  Admittedly the user had gone for a longer time (about a week) without having the issue since we enabled tracing, but it does not appear to be a definitive fix.
    Monday, December 12, 2011 9:16 PM
  • Thanks for the notice.  I've pushed out tracing to about 10% of users and haven't heard anything from them yet about the UCMAPI issue.  I'm going to keep rolling it out but I'll be sure to keep an eye out for any UCMAPI problems. 

    Still have the open ticket with MS and it is not moving fast.

    Thursday, December 15, 2011 6:35 PM
  • I just confirmed today that enabling tracing does not fix this problem.  I'm still working with Microsoft on a fix, but I'm not holding my breath. 

    Jetmech, out of curiosity, what versions of Windows, Lync & Exchange are you running?

    Monday, December 19, 2011 7:15 PM
  • Windows XP SP3

    Lync 2010 (4.0.7577.275)

    Exchange 2010

    Monday, December 19, 2011 7:34 PM
  • Any feedback from MS on this yet Ethan?  We're still seeing this issue on a scattering of our remote machines (partial T1 type connections).

    Monday, March 12, 2012 2:12 PM