Set-AzBlueprintAssignment using earlier published version of the definition

[MattiasSjobom]

I have an issue to assign an earlier published version of a Blueprint, even though the version number is specified it still goes for the latest published version during assignment. The Blueprint has several published version of which version 48f0df98 in the example below is not the latest version

$bp = Get-AzBlueprint -subscriptionId $sub -name $bpname -version 48f0df98 Set-AzBlueprintAssignment -Blueprint $bp -Name $bpname -SubscriptionId $sub -AssignmentFile $assignmentfile

Despite specifying version for $bp the latest version is always used, assigning this version via the portal works without issues.

[alex-frankel]

What does the assignment file look like in this case? I don't think you should be specifying both the -Blueprint and -AssignmentFile parameters.

[MattiasSjobom]

This is what's specified in the assignment file prior to "resourceGroups" and "parameters" section, used $sub and $bpname in the blueprintId for easier read. When removing the -Blueprint from above it's being prompted for (Blueprint:), when removing the blueprintId in the assignment file I get the following error: Set-AzBlueprintAssignment : Please specify a valid blueprintId to assign to this subscription.

{ "identity": { "type": "SystemAssigned" }, "location": "westeurope", "properties": { "description": "Assignment of mcs-subscription-bp", "blueprintId": "/subscriptions/$sub/providers/Microsoft.Blueprint/blueprints/$bpname", "locks": { "mode": "none"

[alex-frankel]

I think there may be an issue with the validation, but I think the issue is that the blueprint ID in the assignment file needs to include the version as well (should be returned by $bp.id. I am assuming that the -Blueprint is being ignored, even though we say it is required.

[MattiasSjobom]

You are right Alex, adding the version to the end of the blueprint ID in the assignment file provides the desired result. From what I understand you cannot manipulate the strings in an assignment file by using variables, so the only thing I can think of is to create a new definition with a new version based on "old" code that can be assigned if needed. The use case is to re-run a old DevOps pipeline in case of roll-back scenario.

[alex-frankel]

You are right that the assignment file is a simple JSON file with no support for expressions, so all values must be hardcoded. Going to close this issue for now, but feel free to continue the discussion.