AQM 8.5.2 installs, but won't work

[Clifford McGlamry]

Customer has an installation of AQM 8.5.2 for UCCX that we have installed....twice.  We can succesfully get through the entire setup, it validates everything, etc.  But after that the fun begins.

If you try and come back and modify the settings, it refuses to save anything.  It throws an error into the ADMIN log that says:

2012-03-28 16:30:42,614 ERROR QMPI2010 Cannot save information to DB: C:\Program Files (x86)\Common Files\QM\config\db.properties (Access is denied)

2012-03-28 16:30:42,614 WARN  QMPI3002 Could not saved due to the following error: Quality Management Database

The error code dictionary is completely unhelpful.  It tells me that QMPI2010 means it can't save info to the database, and that I should verify that Surrogate and Data API services are running (all the services are running).

I'm scratching my head on this.  It really looks like a permissions problem to me.  I've noticed with other applications that Server 2008/Windows 7 do NOT like things going in and manipulating files after installation. 

Has anyone seen this before?

Cliff

[anchoudh]

Hi Clifford,

Please perform he below actions and see if it helps.

QMPI2010 :

Text:Cannot save information to Directory Services:

Type:Error

Add’l Info:The application could save the data from Directory Services.

Action:Verify Directory Services is running and configured in SQM correctly.

QMPI3002:

Text:Could not saved due to the following error:

Type:Warn

Add’l Info:The application could not save the information.

Action:Verify Directory Services is running.

Reference :

http://www.cisco.com/en/US/docs/voice_ip_comm/cust_contact/contact_center/workforce_optimization/qm_2x/reference/guide/qm-error-codes-cisco.pdf

Hope it helps,

Anand

Please rate helpful posts..

[Clifford McGlamry]

Thanks for the response but actually, that's not helpful at all.  As I stated in the original post, I had reviewed the error code dictionary and checked to ensure that  the services are all running.

However, I did start digging around, and ended up enabling auditing for object access failures, and found the user account that I was logged in as did not have specific rights against the directory C:\Program Files (x86)\Common Files\QM\, though it was a member of the local administrators group (domain account that was a memeber of the local admins group) which did have rights.  I added the account to the permissions on the file path, and at that point it was able to update correctly.  Not sure why it had an issue with it, but I was able to at least get past this issue.