Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
In diesem Artikel werden bekannte Einschränkungen und bekannte Probleme für Azure Bereitstellungsstapel sowie empfohlene Problemumgehungen aufgeführt, wenn verfügbar.
Bekannte Einschränkungen
- Sie können bis zu 800 Bereitstellungsstapel innerhalb eines einzigen Bereichs erstellen.
- Sie können in einem bestimmten Bereich über bis zu 2.000 Ablehnungszuweisungen verfügen.
- Der Bereitstellungsstapel verwaltet nicht implizit erstellte Ressourcen. Daher können Sie für diese Ressourcen weder Ablehnungszuweisungen noch Bereinigung verwenden.
- Ablehnungszuweisungen unterstützen keine Tags.
- Ablehnungszuweisungen werden im Verwaltungsgruppenbereich nicht unterstützt. Sie werden jedoch in einem Stack auf Verwaltungsgruppenebene unterstützt, wenn die Bereitstellung auf den Abonnementbereich ausgerichtet ist.
- Bereitstellungsstapel können Key Vault-Geheimnisse nicht löschen. Wenn Sie Key Vault-Geheimnisse aus einer Vorlage entfernen, führen Sie auch den Befehl zum Aktualisieren oder Löschen des Bereitstellungsstapels im Trennmodus aus. Die neuesten Versionen von Azure PowerShell und Azure CLI enthalten eine Option zum Trennen nicht deletabler Ressourcen, wodurch versehentliche Fehler verhindert werden.
Bekannte Probleme
- Das Löschen einer Ressourcengruppe umgeht Ablehnungszuweisungen. Im Ressourcengruppenbereich erstellte Bereitstellungsstapel verwalten nicht die übergeordnete Ressourcengruppe, da die Ressourcengruppe nicht in der datei Bicep definiert ist. Daher können Sie die Ressourcengruppe auch dann löschen, wenn der Bereitstellungsstapel Verweigerungszuweisungen erstellt. Beim Löschen der Ressourcengruppe werden der Bereitstellungsstapel und die verwalteten Ressourcen gelöscht. Es wird empfohlen, die Bereitstellung im Abonnementbereich durchzuführen und die Ressourcengruppe in die Bicep-Datei aufzunehmen. Wenn eine Sperre auch für eine Ressource in der Gruppe aktiv ist, schlägt der Löschvorgang fehl.
- Durch das Verschieben einer verwalteten Ressource wird der Stapelschutz entfernt. Ablehnungszuweisungen werden im Ressourcengruppenbereich für Verschiebevorgänge ausgewertet, nicht im Bereich der einzelnen Ressourcen. Daher kann eine Ressource aus der Ressourcengruppe verschoben werden, auch wenn eine Verweigerungszuordnung diese einzelne Ressource schützt, und der Schutz eines Bereitstellungsstapels wird nach dem Verschieben nicht mit der Ressource übertragen. Die verschobene Ressource ist nicht mehr durch den Stapel geschützt und kann außerhalb der ursprünglichen Grenze verwaltet werden. Legen Sie als vorübergehende Abhilfemaßnahme eine schreibgeschützte Sperre für die Ressourcengruppe fest, um Verschiebevorgänge zu blockieren. Vorgänge des Bereitstellungsstapels funktionieren auch bei aktivierter schreibgeschützter Sperre weiterhin – zum Beispiel funktionieren das Lesen des Stapels und der Löschschutz des Stapels nach wie vor. Um den Stapel zu aktualisieren, entfernen Sie die Sperre vorübergehend für die Dauer der Änderung, und wenden Sie sie anschließend erneut an.
- Ein Stack im Bereich einer Verwaltungsgruppe kann nicht an eine andere Verwaltungsgruppe bereitgestellt werden. Er kann nur für die Verwaltungsgruppe des Stapels selbst oder für ein untergeordnetes Abonnement bereitgestellt werden.
- Der Wert
DeleteResourcesAndResourceGroupswird entfernt. Die Azure PowerShell-Befehlshilfe listet einenDeleteResourcesAndResourceGroupsWert für denActionOnUnmanageSwitch auf. Wenn Sie diesen Wert verwenden, trennt der Befehl die verwalteten Ressourcen und die Ressourcengruppen. Dieser Wert wird in einem bevorstehenden Update entfernt. Verwenden Sie diesen Wert nicht. - Generischer Vorlagenüberprüfungsfehler. In einigen Fällen geben die
New-*- undSet-*-Azure PowerShell-Cmdlets möglicherweise einen allgemeinen Fehler bei der Vorlagenüberprüfung zurück, der keine klaren Hinweise auf die erforderliche Maßnahme gibt. Wenn der Fehler nicht eindeutig ist, führen Sie das Cmdlet im Debugmodus erneut aus, um einen detaillierteren Fehler in der unformatierten Antwort anzuzeigen. - Microsoft Graph Anbieter wird nicht unterstützt. Der Microsoft Graph-Anbieter unterstützt keine Bereitstellungsstapel.
- What-if ist noch nicht verfügbar. Der What-If-Vorgang wird für Deployment-Stacks noch nicht unterstützt.
Beheben des Fehlers „Stack nicht synchronisiert“
Beim Aktualisieren oder Löschen eines Bereitstellungsstapels tritt möglicherweise ein Stack-out-of-sync-Fehler auf, der angibt, dass die Ressourcenliste des Stapels nicht ordnungsgemäß synchronisiert ist:
The deployment stack '{0}' might not have an accurate list of managed resources. To prevent resources from being accidentally deleted, check that the managed resource list doesn't have any additional values. If there is any uncertainty, it's recommended to redeploy the stack with the same template and parameters as the current iteration. To bypass this warning, specify the 'BypassStackOutOfSyncError' flag.
Überprüfen Sie die Liste der verwalteten Ressourcen aus dem Azure-Portal, oder stellen Sie die aktuell bereitgestellte Bicep Datei mit denselben Parametern bereit, um die Liste der verwalteten Ressourcen abzurufen. Nachdem Sie die Liste überprüft haben, führen Sie den Befehl mit dem BypassStackOutOfSyncError Schalter in Azure PowerShell (oder --bypass-stack-out-of-sync-error in Azure CLI) erneut aus. Verwenden Sie diesen Schalter erst nach gründlicher Überprüfung der Ressourcenliste. Verwenden Sie sie nicht standardmäßig.