CM4.x to 6.x DMA failure

Unanswered Question
Sep 3rd, 2008
User Badges:

I get the following error in my DMAErrors.log.


***> DATA PROCESSING TESTS REVEALED AN ISSUE WHICH GENERATED THE FOLLOWING EVENT:

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.


--Patrick

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
MICHAEL CARTER Mon, 09/08/2008 - 05:17
User Badges:

Dear Patrick,


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


Yours sincerely,


Michael.

hypnotoad Mon, 09/08/2008 - 12:11
User Badges:

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.


--Patrick



LARRY KEEFER Thu, 06/11/2009 - 11:11
User Badges:

Patrick,


Did you get this issue resolved with TAC?


I'm getting the same errors.

hypnotoad Fri, 06/12/2009 - 16:00
User Badges:

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.


--Patrick

MICHAEL CARTER Tue, 09/09/2008 - 00:34
User Badges:

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:


https://x.x.x.x/CCMAdmin/phoneconfig.asp?pkid={a633cd29-90c0-4424-a708-09854

87b9429}



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,


Michael.

hypnotoad Tue, 09/09/2008 - 08:13
User Badges:

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.


Thanks,


--Patrick

hypnotoad Mon, 09/15/2008 - 14:34
User Badges:

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.


--Patrick


mdury Tue, 05/04/2010 - 12:43
User Badges:

Michael,

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


Thanks

hypnotoad Tue, 05/04/2010 - 12:46
User Badges:

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


--Patrick

n.warburton Wed, 05/05/2010 - 03:12
User Badges:

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 www.dominocomms.com 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!)

Actions

This Discussion