UCC Client disables MAPI on restart

Answered Question
Sep 25th, 2009
User Badges:
  • Bronze, 100 points or more

I have a customer with UCC Server installed and working just fine.  The client software though has an interesting issue. Under the Email Setting tab in the client pop up there is a check box for Enable MAPI.  We check this box, choose to use the default outlook profile, click apply and connect.  Success.  Then we restart the computer...and the check box is unchecked and the call connector contacts page in outlook doesn't work. 


The customer is concerned that his non-techie employees won't remember on a daily basis to check that box, making the software useless for those employees.  I feel he is overreacting, especially since this only seems to happen to around half the users, but I still see his point.  Is this a known issue at all, has anyone come across this problem, or does anyone have suggestions for troubleshooting this?  My first thought is a crazy Windows interaction, but I welcome all speculation.


I've attached an image of the tab I'm referring to.

Attachment: 
Correct Answer by John Platts about 7 years 6 months ago

Is this customer running UCC Client on Windows Vista? If so, a copy of the ucc.xml file might have been stored in the following directory:

C:\Users\\AppData\Local\VirtualStore\Windows32


where is replaced with the actual user name.


You might need to delete the ucc.xml files located in the VirtualStore to fix this problem.


I have noticed that the UCC Client actually writes files to the c:\Windows\System32 directory. This is really a no-no, even on Windows XP and earlier versions of Windows, and is really a must fix problem. The UCC Client should be writing them to a subdirectory of the directory returned by SHGetFolderPath(..., CSIDL_COMMON_APPDATA, ..., ..., ...) instead of writing them to the c:\Windows\System32 directory. The ACL of this subdirectory should be set such that all users of this computer should be able to read, write, and create files in this subdirectory. This would eliminate problems on Windows Vista and Windows 7, especially if UAC had been enabled, and would solve the problems associated with writing to c:\Windows\System32.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Correct Answer
John Platts Fri, 09/25/2009 - 11:19
User Badges:
  • Silver, 250 points or more

Is this customer running UCC Client on Windows Vista? If so, a copy of the ucc.xml file might have been stored in the following directory:

C:\Users\\AppData\Local\VirtualStore\Windows32


where is replaced with the actual user name.


You might need to delete the ucc.xml files located in the VirtualStore to fix this problem.


I have noticed that the UCC Client actually writes files to the c:\Windows\System32 directory. This is really a no-no, even on Windows XP and earlier versions of Windows, and is really a must fix problem. The UCC Client should be writing them to a subdirectory of the directory returned by SHGetFolderPath(..., CSIDL_COMMON_APPDATA, ..., ..., ...) instead of writing them to the c:\Windows\System32 directory. The ACL of this subdirectory should be set such that all users of this computer should be able to read, write, and create files in this subdirectory. This would eliminate problems on Windows Vista and Windows 7, especially if UAC had been enabled, and would solve the problems associated with writing to c:\Windows\System32.

Skyler Spence Fri, 09/25/2009 - 11:26
User Badges:
  • Bronze, 100 points or more

That's interesting information, and I'll definitely investigate the entries that the client is making to that directory for any clues.  However the customer is running Windows XP for all users.

Skyler Spence Tue, 09/29/2009 - 14:00
User Badges:
  • Bronze, 100 points or more

Any other advise out there?  I am currently unable to open a TAC case regarding this issue due to problems with my Cisco account.  If this is at all an issue with the Call Connector client I would expect others to have encountered the problem before.  If it's a Windows problem....well then I'm not surprised. :)

Actions

This Discussion