Salted PsDscRunAsCredentials considered conflicting values

foreach ($node in $nodes) {
            Script $node {
                DependsOn            = xxx
                PsDscRunAsCredential = $DomainCreds
                GetScript            = { xxx }
                TestScript           = { xxx }
                SetScript            = { xxx }

The above code fails to run when credentials are encrypted. This looks like a bug, is it? why does it even complain, as those resources have different ID’s. Using wmf 5.1


The resources ('[script]node1' and '[script]node2') have conflicting values of following properties: 'PsDscRunAsCredential'. Ensure that their values match.

on the mof itself it says something like:

PsDscRunAsCredential = MSFT_CREDENTIAL_REF1 for the first resource and PsDscRunAsCredential = MSFT_CREDENTIAL_REF2 for the second. Which makes little sense (i understand why it says so, but I mean, why would it complain about that), but I cant control it anyway so, wth?

I’m not sure why they’re taking PsDscRunAsCredential as a key property - that does seem wrong. I’d file an issue on GitHub. But the ID isn’t the problem - that isn’t a key property, so its uniqueness doesn’t matter here.

what do you mean resourceId uniquness doesnt matter? I cant have 2 script resources in the same configuration unless they are identical (so useless)?

But anyway, how do I create several script resources if this behaves like this?

ps. there was an issue already ( which got closed… so any point in opening another one?

Each resource defines for itself one or more “key properties.” Like, with the File resource, it’s the UNC, I think. Anyway, you can only define one resource block with a given key property value. Yes, the ID you assign - Node1, Node2 - does have to be unique, but that isn’t the only thing which has to be unique. No given resource can share the same key property values.

In this case, it would seem that the PSRunAsCredential is somehow being taken as a key property, meaning you can only use it once per configuration. That’s obviously dumb.

That issue was correct, but it was opened in the wrong place. I think you need to open it at

but the set-script properties are also different (at least when expanded). so how does it check for uniqueness?

The schema MOF for the resource determines what’s considered a key property. The Get/Set/Test aren’t, so they don’t count.