BookmarkSubscribeRSS Feed
🔒 This topic is solved and locked. Need further help from the community? Please sign in and ask a new question.
sram4790
Obsidian | Level 7

Issue with Active Directory Macro. Found the following error with AD macro run:

 

ERROR: Change data contains changes that will violate integrity constraints in the server or cause other errors during this or
future synchronizations. See mduchgv.mduchgverrors for information regarding problems encountered.

 

ERROR: Validation errors detected by %mduchgv.  Load not attempted.

 

With more analysis , identifed the dataset "mduchgverrors" which is loaded with Duplicate entries. Not really sure how to proceed with the AD sync run. Please advise.

 

1 ACCEPTED SOLUTION

Accepted Solutions
Timmy2383
Lapis Lazuli | Level 10
When I get this error it's usually bc there is an account in metadata that had some of its properties changes (usually in AD) and the sync job recognizes that the account needs to be changed but can't change it, usually because something with the unique ID (like employee ID or whatever) changed somehow. In my case it was that the casing of the user ID changed in the source, and the job recognizes that it's the same user but can't change the unique identifier.

I've always been able to fix by deleting the users in question from metadata (the users in your mduchgverrors dataset) and then rinning the sync job again.

View solution in original post

11 REPLIES 11
Timmy2383
Lapis Lazuli | Level 10
When I get this error it's usually bc there is an account in metadata that had some of its properties changes (usually in AD) and the sync job recognizes that the account needs to be changed but can't change it, usually because something with the unique ID (like employee ID or whatever) changed somehow. In my case it was that the casing of the user ID changed in the source, and the job recognizes that it's the same user but can't change the unique identifier.

I've always been able to fix by deleting the users in question from metadata (the users in your mduchgverrors dataset) and then rinning the sync job again.
sram4790
Obsidian | Level 7
Hi Timmy,



You mean to say , the dataset "mduchgverrors" to be emptied in the available location and rerun the Sync job? Or delete the entire dataset and run the sync?


Timmy2383
Lapis Lazuli | Level 10

I would rerun the sync job entirely.

sram4790
Obsidian | Level 7

Hi ,

 

So we need to re run the entire sync with a manual deletion of entries with dataset "mducghv" . As the entire sync is already happening here on a daily basis and the error seems to be persisting. I believe it would be wise to run , emptying the dataset "mducghv".

Timmy2383
Lapis Lazuli | Level 10
What do you mean by "emptying the dataset"? If there are any records in that dataset then you don't want it to run the metadata import step as this could corrupt soe metadata. You should investigate why you keep getting records in this dataset and try to fix it at the root.

I would compare the records in the "update" library for those IDs on the mducghv dataset with the current metadata for those users. You may be able to make changes in metadata or you may need to adjust the code of the job to account for anamolies in AD.
sram4790
Obsidian | Level 7

Hi Timmy,

 

I meant removing all the entries from the dataset mduchgv. 

 

The comparison between user ids with update library which is from mduchgv dataset with Metadata is going to be a cubersome process, as i find all metadata defined users with the error list. 

 

Also there are two set of errors "Person with this name already exists in the Metadata Server." and "Userid being added is already owned by another Identity." for the same id and the number of users with the error list is more than 1000 and both the errors combined its becoming more than 2000 entries with the mduchgv dataset.

 

Not sure what will be right procedure to follow here? 

Timmy2383
Lapis Lazuli | Level 10
Was the sync job already implemented before and running without errors? I would want to first investigate a couple users and figure out what has changed in AD that is different from what is in metadata before doing anything else.
sram4790
Obsidian | Level 7

Yes this is sync job is a successfully running job, which was working fine till a week before. But due to unknown reasons facing the current issue. 

 

Can you please elaborate on this sentence of "

Timmy2383
Lapis Lazuli | Level 10
Look at the datasets under the "updates" library created by the job and compare these with what was extracted from metadata (I think the default libname in the job is "metadata"). Datasets I would look at would be "person", "personinfo" and maybe "email".

Look up a couple of the users that are showing up on your mdugchv dataset. Try to see what updates are being attempted for those users.
sram4790
Obsidian | Level 7

Hi Timmy,

 

here the issue seems to be due to keyids. Already existing Users are lacking the external ID parameter(checked the same from SMC), but at the same time the new chnages datasets part of the AD sync is having this key id.

 

Now the fix can be as follows:

 

1.Recover the metadata from a best available metadata backup

2.Remove all the users from metadata and then run the AD sync job 

3.Modify the adsync program, such a way that the job will take the error table as exception table, with that it will continue add the new users to metadata and will not change anything for the existing metadata users

 

Considering the Risk and Impact , we are confused to make a decision here. Can you please comment which could the right option to go ahead? Thanks again!!

 

 

Timmy2383
Lapis Lazuli | Level 10
I can't say exactly what would be "right", but I can say what I would do if in the same situation based on similar issues I've had in the past. I would 1) take a metadata backup, 2) delete the users from metadata and then 3) run the sync job.

I would not want to modify the sync job and mess with the errors table bc the error will likely persist, and if you changed it to always ignore these users then legitimate changes (I.e. Phone numbers, email, job descriptions, etc) would get missed.

sas-innovate-2024.png

Join us for SAS Innovate April 16-19 at the Aria in Las Vegas. Bring the team and save big with our group pricing for a limited time only.

Pre-conference courses and tutorials are filling up fast and are always a sellout. Register today to reserve your seat.

 

Register now!

Discussion stats
  • 11 replies
  • 3276 views
  • 0 likes
  • 2 in conversation