Details of the scenario you tried and the problem that is occurring
Looks to be similar scenario as Issue #63, Pull #64
When setting multiple "ScopeNames", the order is checked along with the contents. While the resource is configured correctly, the Test will always return $False unless the order seen in the verbose logs matches the MOF order.
Verbose logs showing the problem
[[AdfsApplicationPermission]ServiceNow] The parameter 'ScopeNames' is not in the desired state. Expected 'allatclaims, email, openid', Actual 'email, openid, allatclaims'. (ADFSCOMMON0003)
[[AdfsApplicationPermission]ServiceNow] client role 'ServiceNow Server Application ID' server role 'ServiceNow Server Application ID' is not in the desired state. (AG008)
This seems to be related to the order that the MOF stores the data vs how the configuration is set.
Suggested solution to the issue
Compare Desired ScopeNames to current ScopeNames with no consideration of order
The DSC configuration that is used to reproduce the issue (as detailed as possible)
Details of the scenario you tried and the problem that is occurring
Looks to be similar scenario as Issue #63, Pull #64 When setting multiple "ScopeNames", the order is checked along with the contents. While the resource is configured correctly, the Test will always return $False unless the order seen in the verbose logs matches the MOF order.
Verbose logs showing the problem
This seems to be related to the order that the MOF stores the data vs how the configuration is set.
Suggested solution to the issue
Compare Desired ScopeNames to current ScopeNames with no consideration of order
The DSC configuration that is used to reproduce the issue (as detailed as possible)
The operating system the target node is running
Version and build of PowerShell the target node is running
Version of the DSC module that was used
1.3.1