Showing results for 
Search instead for 
Did you mean: 

CM4.x to 6.x DMA failure

I get the following error in my DMAErrors.log.


The error number is: [-691]

The error message is: [-691 Missing key in referenced table for referential constraint


The following additional event information is available:

This record was not processed because another record it needs,

(see reference name listed below), is missing. This likely may be due to a previous error

already reported in the log above, or the result of Directory Services Export issues

reported separately, or due to missing Product, Locale, or other add-on definition CSV

files that should exist on the source system but do not.

SUGGESTED ACTION: Resolve all prior reported issues. If none, look at the Suspected Field,

if listed, for an indication of what data reference could not be resolved. Some hints:

- if ...DirGroup related, check for a Directory Export failure

- if ...Locale related, check for a missing Locale Plug-In

Re-execute DMA when all other issues are addressed.

Suspected Field/Item Is [DMABack_Admin.fk_functionroledirgroupmap_fkdirgroup]

TABLE NAME IS [FunctionRoleDirGroupMap ]

fkdirgroup ''

fkfunctionrole '6eb94885-ff7e-4e3f-bc51-c419a21941db'

pkid newid(

I've been working with Cisco on this problem for the last seven weeks and am getting nowhere. Can anyone help?

I've requeued the case twice and keep getting the same TAC engineer.



can you please email me the entire DMAErrors.log file at, Thanks.

It is sent.


The following link discusses possible causes for error -391 and -691 and has 3 possible solutions in it. Have a look at them and let me know if you have any questions.


Dear Patrick,

I have exactly the same error message, did you resolve this issue? I'd really appreciate some help...

Yours sincerely,


I have not. I've gone through the URL that was posted earlier without luck. I think it has something to do with the Active Directory integration.

I have a TAC case open on this and with some luck, Cisco will come through. Unfortunately, the assigned TAC engineer is a moron. I have re queued the case twice and keep getting the same guy.

The last straw was when he deleted half a dozen SQL server accounts which caused the entire phone system to fail for six hours. I had to open a P1 case to get it fixed.

I have a call into my Cisco account manager and am waiting to hear back.



Did you get this issue resolved with TAC?

I'm getting the same errors.

I did. TAC ended up doing a lot of database cleanup. I would run DMA and send the logs. They would do some DB work the next day and I would try again. We kept at this until it was fixed.

Good luck with your upgrade.



Dear Patrick,

I had a TAC case open and received the following response:


Note the 'fkdevice' field in the above data. Using the value from the fkdevice field, go to:



Where, x.x.x.x is the IP address of the Publisher server.

This will display the phone configuration window. Under the extension mobility section, for the 'Log Out Profile' drop down box - set this to 'Not Selected' and save the change (you may be required to disable the extension mobility feature on this phone for the change to be saved successfully).

Repeat the above procedure for each similar error and re-run the DMA after that.


I'm re-runing the DMA now and expect the issues to be resolved...

Hope this helps you.

Yours sincerely,


That is good info. I don't have a problem with 'fkdevice'. My errors involve 'fkfunctionrole'. I used the URL trick you posted and it displayed the functional group in question. I can't update or delete any of them so I'll pursue this as I think it might be the problem.



My problem has been solved. The TAC case had to be escalated to someone that actually knew what to do.

The error message had to do with the SuperUserGroup and how it fits in with MLA. TAC deleted the MLA configuration from the database and had me reinstall Directory Integration to reset the database to a default configuration. That did the trick.

I have been able to use the exported data to build a 6.1 server for testing.



I am having the same issue. I would like to try your method and see if it fixes it

Would you happen to have the TAC Service request number?  I wanted to see if TAC could reference it if necessary.

5 points


The original TAC case was 609046281. I hope this helps.


BTW, and although not strictly relating to the DMA failures. If you are in the process of migrating from CCM4 to CUCM5+ you lose the pins / passwords etc. This can be a real pain having to notify the users that the pin has changed (coupled with a security issue of setting all to the same pin!).

There is a way around this, there is a tool at to help over come the pin migration issue. I have used it on a 8000+ phone migration and it works a treat, probably saving my customer 10-15 days of pain (sending out new pins to users who dont even have email!)

Recognize Your Peers
Content for Community-Ad