Hi @LimitlessTechnology-2700
I would really like to go away from scripts and use out-of-box solutions therefore I want to utilize the provisioning service as much as possible.
In my case, all "formalName" from SF have values, and it was working before (a month ago when I was testing it).
For some weird reason, it stopped working.

To test it, I took my own account where "cn" has been set by the provisioning service from "mizi" to "Michał Ziemba"
I have renamed my "cn" using PowerShell to "Michal Z." and provision on-demand my account from SF to AD. And got the issue described in the initial post.

Here is what attributes are coming from SF:
formalName: Michał Ziemba

And I use direct mapping of formalName to cn

It works flawlessly for all new users. And it was working for old users as well, but suddenly stopped.

/Mike

It is working now. Thank you.

Hi, The issue started after the initial synced had been done with success. There are no failures in the provisioning logs, only skips for accounts that are not in scope. But as I see no new accounts have been provisioned as I adjusted the scope. I am testing in the test environment, so I can start all from scratch, but I thought it would be a nice opportunity to catch the error and see the reason as I couldn't find it documented. /Mike ![200157-333.png][1] [1]: /answers/storage/attachments/200157-333.png

Thank you @EmilyDu-MSFT for the PowerShell sample.
My goal was to set the field automatically whenever a new file is created in the documented library.
And the solution with PowerShell needs to be run from time to time as I guess, right?

It has already been checked and done.
It didn't help.

Hi @MarileeTurscak-MSFT
It is hard to say if there was a rule ID. I will check when I see it again.
For now, it works OK.

@MarileeTurscak-MSFT
I have added the service account to the domain admins AD group and after restart of the provisioning agent, it worked.
Inheritance is enabled in all OUs.
How to avoid adding the service account to a domain admins AD group?
I have granted 'write' permission to the ms-DS-ConsistencyGuid attribute for the service account on the root domain level and removed the service account from domain admins, restarted the provisioning agent, and get the same error again.

Hi @LimitlessTechnology-2700
The inheritance is enabled in all OUs. I have double-checked it.

Hi @sikumars-msft
I gave it a try and it throws an error:

Error code
SystemForCrossDomainIdentityManagementBulkOperationResponseError

Error message
{"Exceptions":[{"SerializedExceptionString":"{\"ClassName\":\"Microsoft.ActiveDirectory.SynchronizationAgent.Contract.SerializableDirectoryOperationException\",\"Message\":\"The user has insufficient access rights.\",\"Data\":null,\"InnerException\":null,\"HelpURL\":null,\"StackTraceString\":null,\"RemoteStackTraceString\":null,\"RemoteStackIndex\":0,\"ExceptionMethod\":null,\"HResult\":-2146233088,\"Source\":null,\"WatsonBuckets\":null,\"ResponseResultCode\":\"InsufficientAccessRights\",\"ResponseErrorMessage\":\"00000005: SecErr: DSID-0315274B, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0\",\"SerializedException\":\"Details:\\r\\nType: System.DirectoryServices.Protocols.DirectoryOperationException\\r\\nThe user has insufficient access rights.\\r\\nStack trace:\\r\\n\\r\\nServer stack trace: [...]

I have checked Event logs on the local AD DC server where I have AzureAD Connect Provisioning Agent installed and there are no errors.
I noticed that the AzureAD Connect Provisioning Agent runs with provAgentgMSA$ service account. So I granted this account full access to the Organization Unit (OU) I operate with, but this didn't help.

Can you tell what user and what rights I need to adjust to get it to work?
/Michal

Thank you for the answer.
Can you advise where to put the request?
As I recall the User voice platform is not in use anymore, or am I wrong?

Thank you for your answer. Now it is clear.