UCM 4.2.3 to 7.1.3 Upgrade - DMA Errors

Answered Question
Dec 17th, 2009

Hi All,

We are about to under take a 7.1 upgrade and I am currently checking over the DMA logs, I have cleaned up the majority of warnings but we have a lot of auto-corrected entries similar to the following. Are these anything to be concerned about, what is actually happending and being corrected here? Are any changes actually being made to the config?

12/04/2009  20:53:08
Corrected Message: Repeated entry: richarj has a dnorpattern that is repeated (6012). richarj DNorPattern has been corrected.

Condition: A user is associcated with a primary extension. The same extension number may be associated by another user in a different partition

Solution: Associate a unique primary numplan to the user

I have this problem too.
0 votes
Correct Answer by David Hailey about 6 years 11 months ago

Jason,

The auto-corrected log contains data found during the export that is not compliant with the DB schema in 7.1(3).

Are they anything to be worried about?  No, you don't need to do anything with auto-corrected items.

What is actually happening and being corrected here?  User to extension relationships in 4x are different than in Linux platform versions.  Basically, DMA is saying that the extension noted is already assigned as a primary extension in the DB.  While this is really seen at the DB level, you can look at the user settings and how extensions are specified in 4x and then compare to 7x to see what it looks like at a system level.

Are there any changes being made to the config?  Yes and no.  Yes, there are changes being made in the DMA file so when you import that data into a 7x cluster - that's what you'll get.  No, your production data (4x) is not being changed.

Is there something you can do to feel better about this?  You can look up the extension in the 4x system and verify the config (i.e., shared line or listed as primary extension for multiple users, etc).  From there you can either make changes you feel are necessary to have correct data and then re-run DMA or, if it's not biggie to you, you can just go with the auto-corrections.  I would say it's pretty standard to go with these as they are.  What is likely happening in the DMA export file is that all of these users are being created without a primary extension - which you can easily take care of after the ugprade, as needed.  If you have the equipment to do so, you can also set up a VMWare Publisher and then import your data as a lab test and then run queries or just make some manual configuration checks as well.

Hope that helps...

Hailey

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Correct Answer
David Hailey Sun, 12/20/2009 - 19:03

Jason,

The auto-corrected log contains data found during the export that is not compliant with the DB schema in 7.1(3).

Are they anything to be worried about?  No, you don't need to do anything with auto-corrected items.

What is actually happening and being corrected here?  User to extension relationships in 4x are different than in Linux platform versions.  Basically, DMA is saying that the extension noted is already assigned as a primary extension in the DB.  While this is really seen at the DB level, you can look at the user settings and how extensions are specified in 4x and then compare to 7x to see what it looks like at a system level.

Are there any changes being made to the config?  Yes and no.  Yes, there are changes being made in the DMA file so when you import that data into a 7x cluster - that's what you'll get.  No, your production data (4x) is not being changed.

Is there something you can do to feel better about this?  You can look up the extension in the 4x system and verify the config (i.e., shared line or listed as primary extension for multiple users, etc).  From there you can either make changes you feel are necessary to have correct data and then re-run DMA or, if it's not biggie to you, you can just go with the auto-corrections.  I would say it's pretty standard to go with these as they are.  What is likely happening in the DMA export file is that all of these users are being created without a primary extension - which you can easily take care of after the ugprade, as needed.  If you have the equipment to do so, you can also set up a VMWare Publisher and then import your data as a lab test and then run queries or just make some manual configuration checks as well.

Hope that helps...

Hailey

Jason Nash Sun, 12/20/2009 - 22:56

Hi Hailey,

Thanks for your reply, very helpful. I thought this may be the case but just wanted to justify and cover off all entries in the DMA logs. I have already imported the DMA data successfully in a VMware environment so I will take a look at the config in more detail as you advise.

I think it is probably related to the shared lines and extension mobility.

Jason

Actions

This Discussion