Wiederherstellen des Synapse Analytics-Arbeitsbereichs nach dem Übertragen eines Abonnements in ein anderes Microsoft Entra-Verzeichnis (Mandant)

  • Artikel

In diesem Artikel wird beschrieben, wie Sie den Synapse Analytics-Arbeitsbereich nach der Übertragung ihres Abonnements an ein anderes Microsoft Entra-Verzeichnis wiederherstellen. Der Synapse Analytics-Arbeitsbereich ist nach dem Übertragen eines Abonnements an ein anderes Microsoft Entra-Verzeichnis (Mandant) nicht zugänglich.

Wenn Sie versuchen, Synapse Studio nach dem Verschieben zu starten, wird dieser Fehler angezeigt: „Failed to load one or more resources due to no access, error code 403“ (Fehler beim Laden einer oder mehrerer Ressourcen aufgrund fehlenden Zugriffs, Fehlercode 403).

Screenshot of Synapse Studio Error 403 after tenant migration.

Führen Sie die Schritte in diesem Artikel aus, nachdem Sie ein Abonnement mandantenübergreifend übertragen haben, um den Synapse Analytics-Arbeitsbereich wiederherzustellen.

Das Übertragen eines Abonnements in ein anderes Microsoft Entra-Verzeichnis (Mandant) ist ein komplexer Vorgang, der sorgfältig geplant und ausgeführt werden muss. Azure Synapse Analytics erfordert für den ordnungsgemäßen Betrieb Sicherheitsprinzipale (Identitäten). Wenn ein Abonnement in einen anderen Mandanten verschoben wird, ändern sich alle Prinzipal-IDs, Rollenzuweisungen werden aus der Azure-Ressource gelöscht, und systemseitig zugewiesene verwaltete Identitäten werden verworfen.

Informationen zu den Auswirkungen der Übertragung eines Abonnements an einen anderen Mandanten finden Sie unter Übertragen eines Azure-Abonnements in ein anderes Microsoft Entra-Verzeichnis

In diesem Artikel werden die Schritte behandelt, die beim Wiederherstellen eines Synapse Analytics-Arbeitsbereichs nach dem mandantenübergreifenden Verschieben des Abonnements ausgeführt werden müssen.

Voraussetzungen

  • Weitere Informationen zu Diensten oder Ressourcen, die vom Mandantenwechsel betroffen sind, finden Sie unter Übertragen eines Azure-Abonnements in ein anderes Microsoft Entra-Verzeichnis.
  • Speichern Sie alle Rollenzuweisungen für Benutzer, Gruppen und verwaltete Identitäten von Microsoft Entra. Diese Informationen können verwendet werden, um die erforderlichen Berechtigungen für Azure-Ressourcen wie Azure Synapse Analytics und ADLS Gen2 nach dem Mandantenwechsel zuzuweisen. Mehr dazu finden Sie unter Schritt 1: Vorbereiten der Übertragung
  • Speichern Sie alle Berechtigungen, die für Microsoft Entra-Benutzer in dedizierten und serverlosen SQL-Pools erforderlich sind. Microsoft Entra-Benutzer werden nach dem Mandantenwechsel aus den dedizierten und serverlosen SQL Pools gelöscht.

Schritte zum Wiederherstellen des Synapse Analytics-Arbeitsbereichs

Führen Sie nach der Übertragung des Abonnements an einen anderen Mandanten die folgenden Schritte aus, um den Azure Synapse Analytics-Arbeitsbereich wiederherzustellen.

  1. Deaktivieren Sie systemseitig zugewiesene verwaltete Identitäten, und aktivieren Sie sie dann erneut. Weitere Informationen finden Sie weiter unten in diesem Artikel.
  2. Weisen Sie den erforderlichen Microsoft Entra-Benutzer*innen, -Gruppen und verwalteten Microsoft Entra-Identitäten Azure RBAC-Berechtigungen (rollenbasierte Zugriffssteuerung) für den Synapse Analytics-Arbeitsbereich und die erforderlichen Azure-Ressourcen zu.
  3. Legen Sie den SQL Active Directory-Administrator fest
  4. Erstellen Sie Microsoft Entra-Benutzer*innen und -Gruppen ausgehend von den ihnen entsprechenden Benutzer*innen und Gruppen im neuen Microsoft Entra-Mandanten für die dedizierten und serverlosen SQL-Pools neu.
  5. Weisen Sie Microsoft Entra-Benutzer*innen und -Gruppen Azure RBAC für den Synapse Analytics-Arbeitsbereich zu. Dieser Schritt sollte der erste Schritt nach der Wiederherstellung des Arbeitsbereichs sein. Ohne diesen Schritt löst das Starten von Synapse Studio 403-Meldungen aus, da Microsoft Entra-Benutzer keine Berechtigungen für den Arbeitsbereich haben: 
    {"error":{"code":"Unauthorized","message":"The principal '<subscriptionid>' does not    have the required Synapse RBAC permission to perform this action. Required permission:    Action: Microsoft.Synapse/workspaces/read, Scope: workspaces/tenantmove-ws-1/*."}}
  6. Weisen Sie Microsoft Entra-Benutzer*innen, -Gruppen, -Dienstprinzipalen für alle Ressourcen, die in den Arbeitsbereichsartefakten, z. B. ADLS Gen2, verwendet werden, Azure RBAC-Rollen zu. Weitere Informationen zu Azure RBAC in ADLS Gen2 finden Sie unter Rollenbasierte Zugriffssteuerung (Azure RBAC).
  7. Fügen Sie Synapse RBAC-Rollenzuweisungen zu Microsoft Entra-Benutzer*innen und -Gruppen hinzu. Weitere Informationen finden Sie unter Vorgehensweise: Verwalten von Synapse RBAC-Rollenzuweisungen in Synapse Studio
  8. Erstellen Sie alle Microsoft Entra-Anmeldeinformationen und -Benutzer*innen in dedizierten und serverlosen SQL-Pools neu. Weitere Informationen finden Sie unter SQL-Authentifizierung in Azure Synapse Analytics.
  9. Erstellen Sie alle benutzerseitig zugewiesenen verwalteten Identitäten neu, und weisen Sie dem Synapse Analytics-Arbeitsbereich eine benutzerseitig zugewiesene verwaltete Identität zu. Weitere Informationen finden Sie unter Anmeldeinformationen in Azure Data Factory und Azure Synapse.

Hinweis

Achten Sie darauf, dass die folgenden Schritte erst ausgeführt werden, nachdem Sie sich von der erfolgreichen Verschiebung des Abonnements in einen anderen Mandanten überzeugt haben.

Deaktivieren Sie die systemseitig zugewiesene verwaltete Identität für den Synapse Analytics-Arbeitsbereich, und weisen Sie sie erneut zu.

In diesem Abschnitt wird gezeigt, wie Sie Azure CLI oder Azure PowerShell verwenden, um die systemseitig zugewiesene verwaltete Identität für Ihren Azure Synapse Analytics-Arbeitsbereich zu deaktivieren und erneut zu aktivieren. Ziehen Sie in Azure CLI oder Azure PowerShell die folgenden Schritte in Erwägung.

$resourceGroupName="Provide the Resource group name"
$workspaceName="Provide the workspace name"
$subscriptionId="Provide the subscription Id"

$url = "https://management.azure.com/subscriptions/$subscriptionId/resourceGroups/$resourceGroupName/providers/Microsoft.Synapse/workspaces/$workspaceName\?api-version=2021-06-01"

In diesem nächsten Beispiel wird die systemseitig zugewiesene verwaltete Identität für den Arbeitsbereich deaktiviert.

az rest --method patch --headers  Content-Type=application/json   `
--url  $url `
--body '{ \"identity\":{\"type\":\"None\"}}'

Für den provisioningState des Arbeitsbereichs sollte Erfolg angezeigt werden, und der Identitätstyp sollte nach dem Ausführen des vorstehenden Befehls None (Ohne) sein. Wenn Sie den folgenden Befehl ausführen, wird der Wert von provisioningState möglicherweise als „Bereitstellung“ angezeigt, dann dauert es einige Minuten, bis der Status zu „Erfolg“ wechselt. Der Wert von provisioningState sollte „Erfolg“ sein, bevor die systemseitig verwaltete Identität für den Arbeitsbereich wieder aktiviert wird.

Verwenden Sie den folgenden Codeausschnitt, um den Status des Arbeitsbereichs abzurufen, um Bereitstellungsstatus und Identitätstyp zu erfahren:

az rest --method GET --uri $uri

Der resultierende JSON-Code sollte diesem ähnlich sein:

   {
  "id": "/subscriptions/<subscriptionid>/resourceGroups/TenantMove-RG/providers/Microsoft Synapse/workspaces/tenantmove-ws",
  "identity": {
    "type": "None"
  },
  "location": "eastus",
  "name": "tenantmove-ws",
  "properties": {
    "connectivityEndpoints": {
      "dev": "https://tenantmove-ws.dev.azuresynapse.net",
      "sql": "tenantmove-ws.sql.azuresynapse.net",
      "sqlOnDemand": "tenantmove-ws-ondemand.sql.azuresynapse.net",
      "web": "https://web.azuresynapse.net?workspace=%2fsubscriptions%2<subscriptionid>b%2fresourceGroups%2fTenantMove-RG%2fproviders%2fMicrosoft.Synapse%2fworkspaces%2ftenantmove-ws"
    },
    "cspWorkspaceAdminProperties": {
      "initialWorkspaceAdminObjectId": "<object id>"
    },
    "defaultDataLakeStorage": {
      "accountUrl": "https://tenantmovedemowsstorage.dfs.core.windows.net",
      "filesystem": "demo",
      "resourceId": "/subscriptions/<subscriptionid>/resourceGroups/TenantMove-RG/providers/Microsoft.Storage/storageAccounts/tenantmovedemowsstorage"
    },
    "encryption": {
      "doubleEncryptionEnabled": false
    },
    "extraProperties": {
      "WorkspaceType": "Normal"
    },
    "managedResourceGroupName": "tenantmove-ws-managed-rg",
    "privateEndpointConnections": [],
    "provisioningState": "Succeeded",
    "publicNetworkAccess": "Enabled",
    "sqlAdministratorLogin": "sqladminuser",
    "trustedServiceBypassEnabled": false,
    "workspaceUID": "<workspace UID>"
  },
  "resourceGroup": "TenantMove-RG",
  "tags": {},
  "type": "Microsoft.Synapse/workspaces"
}

Der nächste Befehl aktiviert die systemseitig verwaltete Identität für den Arbeitsbereich erneut:

az rest --method patch --headers  Content-Type=application/json   `
--url  $url `
--body '{ \"identity\":{\"type\":\"SystemAssigned\"}}'

Der nächste Befehl ruft den Arbeitsbereichstatus ab. Der Wert von provisioningState sollte „Erfolg“ lauten. Der Wert von provisioningState ändert sich von „Bereitstellung“ in „Erfolg“. Der Identitätstyp wird in SystemAssigned geändert.

az rest --method GET --uri $uri

Nächste Schritte