metadata syncy from active directory group

[shuchidxt_gmail_com]

I am looking for exact cause of failure in PROD while metadata sync process trying to update based on active directory.

getting below errors in the log file and error dataset:

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

ERROR: Errors returned from Proc Metadata prevented objects from being Added, Updated, or Deleted.  Table: work.mduchglb_failedobjs
identifies 3 such objects.  Consult the SAS Log for the specific Metadata Server errors returned.

errordataset says 

SYMBOLGEN:  Macro variable SYSERR resolves to 3000
SYMBOLGEN:  Macro variable PROC_MD_RC resolves to 3000

:

Person with this name already exists in the Metadata Server.

Person with this name is being added and deleted.  Cannot determine if this is a new user or an old user with a new keyid.

Userid being added is already owned by another Identity.

[PaulHomes]

The first error "Change data contains changes that will violate integrity constraints in the server..." is from the %MDUCHGV validation macro that validates the set of changes that will be applied to metadata to make sure they can be applied. The second error from %MDUCHGLB (or similar) "Errors returned from Proc Metadata prevented objects ..." is telling you the changes failed to be applied, which you would probably expect is the prior validation step failed. Often people add conditional logic to the process so that if there are validation failures from %MDUCHGV then an attempt to apply the changes is skipped as it is unlikely to succeed and may leave metadata in an undesirable state.

The main validation error to look at is "Person with this name already exists in the Metadata Server." because the others stem from that. Fix that error and the others should disappear. It usually occurs because a user has been manually added to SAS Management Console User Manager plug-in and then the subsequent sync that would add that user from AD cannot add them again because they already exist.  This can be solved one of 2 ways:

1. Delete the manually added user to make way for the AD sync-ed user. This is quite brutal and will destroy any relationships that the user had with other metadata (user-level access controls, responsible party, etc.) If it is a new user that has not really done anything yet it may be acceptable.
2. Alternatively, connect the manually added user to the AD user by manually adding the external identity key to the existing SAS user. This can be done with the SAS Management Console User Manager plug-in. There are examples of the dialog in this blog post Identity Sync: Finding Your Keys. This will effectively connect the SAS user to the AD user so that they can be sync-ed next time. The key value you add should match what you are using in your custom sync code: sAMAccountName, distinguishedName, objectGUID etc.

[shuchidxt_gmail_com]

Thank you. Removing the user from metadata and adding through AD works fine. but again job is failing because of the writing permission issue to the work folder ( while performing delete from metadata and writing to temp file) not sure what is the issue as there is no permission access changed in production environment.

can someone help. 

below is the log snippet for the reference.

SYMBOLGEN:  Macro variable TEMP resolves to work
SYMBOLGEN:  Macro variable DSID resolves to 1
SYMBOLGEN:  Macro variable DSID resolves to 1
SYMBOLGEN:  Macro variable DSID resolves to 1
SYMBOLGEN:  Macro variable N_INTERLEAVE resolves to 0
SYMBOLGEN:  Macro variable TEMP resolves to work
SYMBOLGEN:  Macro variable DSID resolves to 1
SYMBOLGEN:  Macro variable DSID resolves to 1
SYMBOLGEN:  Macro variable DSID resolves to 1
SYMBOLGEN:  Macro variable N_GRPMEMS resolves to 0
SYMBOLGEN:  Macro variable TEMP resolves to work
SYMBOLGEN:  Macro variable CHANGE resolves to updates
SYMBOLGEN:  Macro variable CHANGE resolves to updates
SYMBOLGEN:  Macro variable CHANGE resolves to updates
SYMBOLGEN:  Macro variable CHANGE resolves to updates
SYMBOLGEN:  Macro variable CHANGE resolves to updates
SYMBOLGEN:  Macro variable CHANGE resolves to updates
SYMBOLGEN:  Macro variable CHANGE resolves to updates
NOTE: Table WORK.DELOBJS created, with 97 rows and 3 columns.

NOTE: PROCEDURE SQL used (Total process time):
      real time           0.18 seconds
      cpu time            0.01 seconds
     

SYMBOLGEN:  Macro variable TEMP resolves to work
SYMBOLGEN:  Macro variable DSID resolves to 1
SYMBOLGEN:  Macro variable DSID resolves to 1
SYMBOLGEN:  Macro variable DSID resolves to 1
SYMBOLGEN:  Macro variable N_DELOBJS resolves to 97
SYMBOLGEN:  Macro variable TEMP resolves to work

NOTE: There were 97 observations read from the data set WORK.DELOBJS.
NOTE: The data set WORK.DELOBJS has 97 observations and 3 variables.
NOTE: PROCEDURE SORT used (Total process time):
      real time           0.03 seconds
      cpu time            0.01 seconds
     

SYMBOLGEN:  Macro variable OUTREQUEST resolves to
SYMBOLGEN:  Macro variable RECFM resolves to

NOTE: The file _OUTXML is:
      Filename=/workspace/wfeaa/saswork/SAS_work5E8A0002EA59_cppra00a0147/#LN00036,
63                                                         The SAS System                            11:45 Friday, November 23, 2018

      Owner Name=wfavaecm,Group Name=eaa,
      Access Permission=-rw-rw-r--,
      Last Modified=23Nov2018:11:46:33

NOTE: 2 records were written to the file _OUTXML.
      The minimum record length was 10.
      The maximum record length was 16.
NOTE: DATA statement used (Total process time):
      real time           0.00 seconds
      cpu time            0.01 seconds
     

SYMBOLGEN:  Macro variable TEMP resolves to work
SYMBOLGEN:  Macro variable STR resolves to ObjType
SYMBOLGEN:  Macro variable STR resolves to ObjId

NOTE: The file _OUTXML is:
      Filename=/workspace/wfeaa/saswork/SAS_work5E8A0002EA59_cppra00a0147/#LN00036,
      Owner Name=wfavaecm,Group Name=eaa,
      Access Permission=-rw-rw-r--,
      Last Modified=23Nov2018:11:46:33,
      File Size (bytes)=28

NOTE: 97 records were written to the file _OUTXML.
      The minimum record length was 31.
      The maximum record length was 34.
NOTE: There were 97 observations read from the data set WORK.DELOBJS.
NOTE: The data set WORK.NULL_ has 97 observations and 4 variables.
NOTE: DATA statement used (Total process time):
      real time           0.03 seconds
      cpu time            0.00 seconds
     

NOTE: The file _OUTXML is:
      Filename=/workspace/wfeaa/saswork/SAS_work5E8A0002EA59_cppra00a0147/#LN00036,
      Owner Name=wfavaecm,Group Name=eaa,
      Access Permission=-rw-rw-r--,
      Last Modified=23Nov2018:11:46:33,
      File Size (bytes)=3201

NOTE: 6 records were written to the file _OUTXML.
      The minimum record length was 10.
      The maximum record length was 34.
NOTE: DATA statement used (Total process time):
      real time           0.00 seconds
      cpu time            0.01 seconds
     

SYMBOLGEN:  Macro variable OUTRESPONSE resolves to
SYMBOLGEN:  Macro variable RECFM resolves to

ERROR: The user does not have permission to perform this action.
NOTE: PROCEDURE METADATA used (Total process time):
      real time           0.11 seconds
      cpu time            0.00 seconds
     
NOTE: The SAS System stopped processing this step because of errors.
64                                                         The SAS System                            11:45 Friday, November 23, 2018

SYMBOLGEN:  Macro variable SYSERR resolves to 3000
SYMBOLGEN:  Macro variable PROC_MD_RC resolves to 3000

[Kurt_Bremser]

Such programs need to connect to the metadata as sasadm@saspw.

[PaulHomes]

That looks more like a metadata permissions issues than a work folder (file system) issue. Who are you running the AD sync code as? wfavaecm? I usually recommend a dedicated service account (in AD and SAS) for this type of process. The SAS identity for the service account needs, at a minimum, to be a member of the "Metadata Server: User Administration" role to be able to make changes to SAS identities and logins. If you envisage the AD sync process needing to make changes relating to any unrestricted users then you would need to go further and use an unrestricted user (a member of the "Metadata Server: User Unrestricted" role (e.g. sasadm@saspw like @Kurt_Bremser suggested). I choose user admin first and only unrestricted if absolutely necessary (i.e. principle of least privilege).

[shuchidxt_gmail_com]

Yes using wfavaecm id having access to perform such action. this process was running fine with this id until today but failed stating the error in the log though no change in the permission of id.

[PaulHomes]

In that case I would suggest double checking/tracing the appropriate role membership of the wfavaecm login. You could also try logging into SAS MC with that userid/password and see what it can/can't do.

I have seen scenarios in the past where changes in one sync process (group/role membership changes) have disrupted the ability of a service account to perform its actions next time it runs ... and of course occasionally manual changes can be made that break things too.

[Kurt_Bremser]

You can't sync a simultaneous delete and add, or a change of a user-id. You have to first delete and then add, or you manually remove the old definition from the metadata and then run your sync.

[shuchidxt_gmail_com]

Yes that's what the admin did . He deleted the users from metadata which were duplicated and re run the process  but it failed again because of the writing permission issue.

Thanks