Key Parameters of resources . E.g. AADApplication: Current Key results in configuration that can not be compiled.

[andikrueger]

Details of the scenario you tried and the problem that is occurring

Currently the export of AADApplication can cause configurations that can't be compiled. The resource AADApplication uses the display name as key within the resource. Equal Display names can be present various times within AAD. AAD uses the ObjectId to make sure these objects are unique.

There were similar issues with TeamsTeam and TeamsChannel: #1416 and #1716 that already mentioned AADApplication.

Verbose logs showing the problem

Suggested solution to the issue

We need to evaluate options on how to handle resources properly, that use the display name as key. I would add the ObjectId or unique ID within M365 as a second key to these resources. For creating new objects, we would need to set this Guid to be any value or 00000000-0000-0000-0000-000000000000. After the creation of the object, the user would need to change the Guid to a value that should be returned within the Set-Method of these resources. This would further more allow a proper Export and Import (Cloning) of tenants.

The DSC configuration that is used to reproduce the issue (as detailed as possible)

        AADApplication 21663fab-18e5-47e3-996e-c2d5851fc84b
        {
            AppId                     = "d4d65159-9f4f-4fcf-a847-0b4eefaad3e5";
            AvailableToOtherTenants   = $False;
            Credential                = $Credscredential;
            DisplayName               = "SWOTDEMPID100998-Microsoft365DSC-2af04106-0b1b-40b1-bc9b-3e4edf1dc9b9";
            Ensure                    = "Present";
            Homepage                  = "https://VisualStudio/SPN";
            IdentifierUris            = @();
            KnownClientApplications   = @();
            Oauth2RequirePostResponse = $False;
            ObjectId                  = "08fc5cc5-83fa-4598-90c7-6ca11c63b54f";
            PublicClient              = $False;
            ReplyURLs                 = @("https://VisualStudio/SPN");
        }

        AADApplication ee8ecf5c-6cbe-4da2-9b0f-f39f082eff57
        {
            AppId                     = "e1f6c68a-ac6b-4f50-b3a4-816166fcc617";
            AvailableToOtherTenants   = $False;
            Credential                = $Credscredential;
            DisplayName               = "SWOTDEMPID100998-Microsoft365DSC-2af04106-0b1b-40b1-bc9b-3e4edf1dc9b9";
            Ensure                    = "Present";
            Homepage                  = "https://VisualStudio/SPN";
            IdentifierUris            = @();
            KnownClientApplications   = @();
            Oauth2RequirePostResponse = $False;
            ObjectId                  = "ef042d1e-8dbf-4b62-ac15-454585941f40";
            PublicClient              = $False;
            ReplyURLs                 = @("https://VisualStudio/SPN");
        }

The operating system the target node is running

Version of the DSC module that was used ('dev' if using current dev branch)

1.22.525.1

[NikCharlebois]

It is indeed an error I encountered myself on a regular basis. I am opened to suggestions on how to address this, but it doesn't appear to be a simple fix. Keep in mind that we need to support the cloning scenario, which means unique identifier such as IDs cannot be a key parameter.

[andikrueger]

It’s the repeating issue with dsc resources and key parameters. Null values for IDs are not practical as we would need to change this value later on or would run in the same issue as at the moment (Id: null, display name: not unique).

Just some thoughts for starting a discussion:

Could we handle this issue by introducing an additional and not really functional parameter: DisplayNameId: “ThisIsAnAwesomeName==123454321”. That value could be any value - just for uniqueness. If the object within AAD would allow custom properties, we could even store this value.

[NikCharlebois]

Trying to revive this thread. I like this idea. It would clearly be a breaking change across multiple resource however. We should start building a list of resources that are in this bucket. I would recommend that if we move forward with this, that we use a clear, common and distinct name or it. Something like M365DSCUniqueID

[andikrueger]

Name is great 👍

I was wondering if there is any tenant wide storage location we could use to store the M365DSCUniqueId for exports.

[NikCharlebois]

Not to my knowledge. The unique ids would end up being GUID which will ensure there are no conflicts. We could always keep a registry of already used GUID during the Export process to ensure we don't by some miracle re-use the same one inside the same configuration but that would be overkill in my opinion.

[andikrueger]

Following a list of prefixes of resources that could need an additional key parameter:

• AAD
• Intune
• Planner
• SC
• Teams

Resources not included:

• EXO
• O365
• SPO

[NikCharlebois]

Closing this one as other threads are also covering this. Also, we introduced the -Validate switch on the Export-M365DSCConfiguration cmdlet to assist with this.