Bereitstellung auf Azure App Service

Ein Power Portals Pro Portal ist eine Single ASP.NET Core-Anwendung, egal welchen Stack Sie wählen, daher ist die Bereitstellung auf einen gewöhnlichen App-Service eine normale dotnet publish Option. Diese Seite behandelt die zu erstellenden Ressourcen, die vom Portal geliehenen Einstellungen, die wir als Standardeinstellungen vorschlagen und die wenigen Schritte, die speziell für Power Portals Pro und nicht für ASP.NET Core gelten.

Was Sie einsetzen

Beide Vorlagen erzeugen eine Webanwendung und eine Veröffentlichungsausgabe. Es gibt keinen separaten Frontend-Host, keine statische Site-Ressource und keinen zweiten App Service:

Anmerkung

Da der React Publish an npm ausliefert, muss Node auf dem laufenden Rechner installiert werden – auf deinem Laptop dotnet publish oder dem Build-Agenten. Der Client der Vorlage fragt nach Node ^20.19.0 || >=22.12.0. App Service selbst benötigt Node nie; er sieht immer nur die erstellte Ausgabe.

Vorgeschlagene Standardeinstellungen

Ausgangspunkte, keine Regeln – aber das sind das, was wir für ein neues Produktionsportal wählen würden.

1. Erstellen Sie den App-Dienst

Drei Befehle. Ersetze deine eigenen Namen – myportal wird auf dieser Seite verwendet.

Der Name der Webanwendung wird https://myportal.azurewebsites.net und muss global eindeutig sein. Wählen Sie ihn bewusst: Wenn Sie keine benutzerdefinierte Domain vorne setzen, ist es die URL, an die Ihr Lizenzschlüssel gebunden wird.

2. Setzen Sie die Plattformoptionen ein

Das sind die, deren Standardwerte für ein Portal falsch sind.

3. Konfiguration

App-Service-Anwendungseinstellungen erscheinen als Umgebungsvariablen und überschreiben appsettings.json, was genau das ist, was du willst: Lass die Datei in Ruhe und setze hier die Werte pro Umgebung.

Wichtig

Benutzergeheimnisse werden nicht übertragen. Alles, was dotnet user-secrets du während der Entwicklung gespeichert hast, lebt nur auf deinem Rechner. Jeder dieser Schlüssel muss als Anwendungseinstellung – oder als Key Vault-Referenz – neu erstellt werden, sonst startet die bereitgestellte App nicht.

Verwenden Sie einen doppelten Unterstrich für den Abschnittstrenner: D365:ClientId wird zu D365__ClientId. Die Doppelpunktform funktioniert unter Windows App Service, aber nicht unter Linux, ebenso __ wie das Formular, das überall verwendet werden kann.

Immer notwendig

Erforderlich, wenn du diesen Anmeldeanbieter aktiviert hast

Optional

Anmerkung

Die erforderlichen Schlüssel werden mit GetRequiredValuegelesen, sodass ein fehlender Schlüssel beim Start ausgelöst wird, anstatt später beim ersten Dataverse-Aufruf fehlzuschlagen. Im App Service erscheint das als eine Seite, die nie auftaucht – lies den Logstream, und die Ausnahme nennt den Schlüssel.

4. Geben Sie dem Portal eine Adresse an, von der es senden kann

D365__EmailSenderEmailAddress ist das, woher Kontobestätigung und Passwort-Reset-Mails stammen, und das Framework löst das, indem es nach einem Dataverse-Nutzer mit dieser Adresse, dann einer Warteschlange und schließlich einem Team sucht. Verwenden Sie eine Warteschlange. Ihre Adresse benötigt eine gemeinsame Mailbox in Exchange Online, die keine Lizenz erfordert, und alles andere passiert in Dataverse. Die Einstellung auf eine reale Person zu richten, kostet Sie stattdessen drei Dinge:

Vier Schritte: einer in Exchange, dann drei in Dataverse. Der MCP-Server führt die drei Dataverse-Schritte in einem Aufruf mit create_email_queuedurch, und check_email_sender gibt an, welcher Schritt fehlt, wenn keine E-Mail ankommt:

  1. Erstelle ein geteiltes Postfach mit der Adresse im Exchange-Verwaltungszentrum (Empfänger → Postfächer → Fügen Sie eine gemeinsame Mailbox hinzu). Es ist keine Lizenz erforderlich. Das ist die Server-seitige Synchronisation, sodass ohne sie der letzte Schritt mit einem Fehler zur Validierung der Postfach-Konfiguration auf dem entfernten Server fehlschlägt.
  2. Erstelle eine private Warteschlange mit der Adresse (z. B. noreply@contoso.com), eingehende Lieferung Keine und ausgehende Zustellung Server-Side Synchronization. Der Name der Warteschlange ist das, was die Empfänger als Absender sehen, daher benennen sie sie nach dem Portal und nicht nach einer Person.
  3. Genehmigen Sie die Adresse. Zwei Flags müssen übereinstimmen und befinden sich auf unterschiedlichen Datensätzen: die eigene E-Mail-Adressgenehmigung der Warteschlange und die Genehmigung der Postfachadresse durch den O365-Administrator. Eine Warteschlange wird bei beiden anstehend erstellt, und nur ein Office 365 Global Administrator oder Exchange Administrator kann die zweite Karte genehmigen.
  4. Testen und aktivieren Sie das Postfach unter Power Platform Admin Center → Einstellungen → E-Mail-Konfiguration → Postfächer. Es sendet eine Testnachricht von der Adresse an sich selbst, und das Postfach wird erst gesendet, wenn es erfolgreich ist. create_email_queue Es wird ausgeführt und das Ergebnis gemeldet.

Wichtig

Ein nicht genehmigtes oder nicht getestetes Postfach scheitert stillschweigend. Dataverse akzeptiert die E-Mail, zeichnet sie auf und liefert sie nie aus – was aus Portalsicht nicht von einer erfolgreichen Sendung zu unterscheiden ist. Nichts wird angezeigt, nichts wird als Fehler protokolliert, und das erste Anzeichen von Problemen ist, dass ein Nutzer sagt, er habe seinen Bestätigungslink nie erhalten. Wenn Registrierungs-E-Mails nicht eintreffen, überprüfen Sie zuerst den ausgehenden Status des Postfachs: Nicht ausgeführt bedeutet, dass der Test nie ausgeführt wurde, und Fehler mit einer Warnung zur Validierung der Postfach-Konfiguration auf dem entfernten Server bedeutet, dass die Adresse in Exchange Online kein gemeinsames Postfach hat. check_email_sender meldet beides, mit den Benachrichtigungen des Postfachs.

5. Bewahren Sie die Geheimnisse im Key Vault auf

Gib der App eine verwaltete Identität, gewähre ihr Lesezugriff auf einen Tresor und gib die URI jedes Geheimnisses in die App-Einstellung ein, anstatt das Geheimnis selbst. App Service löst die Referenz für dich auf, und der Wert erscheint weder im Konfigurationsblade, in einem Skript noch in einem Deployment-Log.

Wenn ein Client-Geheimnis abläuft – Entra steht standardmäßig auf ein Jahr – fügen Sie dem Tresor eine neue Version hinzu und starten Sie die App neu. Die App-Einstellung selbst ändert sich nicht.

Der MCP-Server führt diese ganze Sequenz durch: create_managed_identity Erstellt eine vom Benutzer zugewiesene Identität, enable_managed_identity hängt sie der App zu, create_key_vault erstellt den Tresor und gewährt dieser Identität Lesezugriff, und die geheimen Tools akzeptieren destination: "key-vault" es dann – wodurch ein frisch erstelltes Client-Geheimnis von Entra direkt in den Tresor gesendet wird und nur die Referenz in den App-Einstellungen bleibt. Der Wert wird nie zu einer wörtlichen Einstellung und geht nie durch die Hände von jemandem. Geheimnisse, die bereits in deinen Benutzergeheimnissen sind, gehen mit push_secrets_to_key_vault, was dich auffordert, jedes einzelne anzukreuzen, bevor es kopiert wird, und weist die entsprechenden App-Einstellungen darauf hin; dann bestätigt es, check_deployment dass jedes Referenzgeheimnis existiert und dass die Identität der App es lesen darf.

Wichtig

Der Name eines Key Vaults ist 90 Tage nach der Löschung reserviert. Soft Delete ist standardmäßig aktiviert und kann nicht deaktiviert werden, sodass das Löschen eines Tresors seinen Namen nicht freigibt – das Wiederherstellen eines Vaults mit demselben Namen innerhalb dieses Fensters erfordert eine explizite Löschung, die wiederum eine Berechtigung erfordert und irreversibel ist. Es ist die einzige Ressource hier, die nicht billig unmöglich ist, also wählen Sie den Namen genauso bewusst wie den des App Service.

Anmerkung

Noch besser: Lassen Sie das Dataverse-Client-Geheimnis ganz fallen. Setzen D365__ManagedIdentityId Sie auf die Client-ID einer verwalteten Identität und das Portal authentifiziert sich als diese Identität bei Dataverse, ohne Geheimnis und daher ohne Ablauf. Es gibt keine Umgebungsprüfung und keinen Build-Switch: Die Einstellung gehört in die Konfiguration des App Services und appsettings.jsonnicht in , sodass sie lokal fehlt und bei der Bereitstellung vorhanden ist, und ein Build verhält sich in beiden korrekt korrekt. Verwenden Sie eine benutzerzugewiesene Identität – eine systemzugewiesene wird mit der App erstellt und vernichtet, die je nach Deployment-Slot unterschiedlich ist, sodass beim Neuaufbau der App eine neue Identität entsteht und der Dataverse-Anwendungsbenutzer, der auf der alten basiert, verwaist wird. Die Identität benötigt weiterhin diesen Anwendungsbenutzer, erstellt aus seiner Anwendungs-ID und nicht aus der Haupt-ID, die das Azure-Portal zuerst anzeigt. Dies gilt nur, wenn sich der App Service und die Dataverse-Umgebung im selben Entra-Mandanten befinden; falls nicht, siehe "Wenn Dataverse in einem anderen Tenant ist " unten.

Wenn Dataverse in einem anderen Tenant ist

Alles oben Genannte setzt voraus, dass der App Service und die Dataverse-Umgebung zum selben Entra-Tenant gehören – der übliche Fall, wenn eine Organisation ihr eigenes Portal hostet. Wenn Sie das Portal betreiben und Ihr Kunde die Dataverse-Umgebung besitzt, befinden sie sich in unterschiedlichen Tenants, und die Identity Advice ändert sich.

Wichtig

Eine verwaltete Identität kann sich nicht allein bei Dataverse in einem anderen Tenant authentifizieren. Ihr Service Principal gehört zum eigenen Tenant des Abonnements und kann nicht in den von jemand anderem eingewilligt werden, sodass es nichts gibt, wogegen das Dataverse des Kunden einen Anwendungsbenutzer erstellen könnte. Setzen D365__ManagedIdentityId Sie nicht allein in dieser Form – das Portal würde ein Token erhalten und dann bei jedem Anruf abgelehnt werden, was sich eher wie eine defekte Sicherheitsrolle als wie die falsche Art von Identität anfühlt. Es kann jedoch auch die Zugangsdaten einer Multi-Tenant-App-Registrierung sein, die die Grenze zwischen den Tenants überschreitet: siehe die erste Option unten.

Das Portal meldet sich als App-Registrierung an, für die der Mieter des Kunden einen Service Principal hat. Es gibt drei Möglichkeiten, das zu organisieren, und sie unterscheiden sich darin, wer die Lebensdauer der Zugangsdaten kontrolliert:

Egal, wofür du dich entscheidest, ein Administrator im Kunden-Tenant muss der Registrierung einmal zustimmen. Das ist es, was dort den Service Principal erstellt – ein Objekt, das deine Client-ID trägt, an das ihr Dataverse dann einen Anwendungsbenutzer binden kann. Schick ihnen diesen Link:

Wichtig

Die Zustimmung kommt vor dem Anwendungsbenutzer, nicht danach. Bis es geschehen ist, gibt es keinen Service-Principal im Kunden-Tenant, daher scheitert das Erstellen des Dataverse-Anwendungsbenutzers mit einem Fehler über eine unbekannte Anwendung – der weder Tenants noch Zustimmung erwähnt und der verwirrendste Punkt auf diesem Weg ist. Diesen Schritt können Sie nicht für sie ausführen: Es ist ihr Tenant, der Zugriff auf eine Registrierung gewährt, die er nicht besitzt, daher benötigt sie ihre Autorität statt deine.

Speichern Sie dieses Geheimnis in Key Vault statt in einer Anwendungseinstellung. Es handelt sich um eine Zugangsdaten gegen die Daten einer anderen Person, und eine wörtliche Einstellung ist von jedem mit Beitrag in der App lesbar und wird mit jedem Export der Konfiguration übertragen. check_deployment Melden Sie es, falls nicht.

6. Veröffentlichen

Framework-abhängig veröffentlichen, die Ausgabe zippen, die Zip pushen. Auf einem React-Portal baut dasselbe dotnet publish auch das SPA und stadelt es in wwwroot.

Zippen Sie den Inhalt des Publishing-Ordners, nicht des Ordners selbst – App Service entpackt das Archiv direkt in die Wurzel der Website, sodass ein verschachteltes Top-Level-Verzeichnis eine Seite erzeugt, die nichts bedient.

Der Publishing-Dialog von Visual Studio macht das Gleiche interaktiv, und ein GitHub Actions oder Azure Pipelines-Workflow macht das auf Push. Der einzige zusätzliche Schritt für ein React-Portal ist ein Node-Setup-Schritt vor dem Build, da dotnet publish es an NPM auslagert.

7. Die Lizenz auf die bereitgestellte URL zeigen

Die Website-Lizenz ist an eine URL gebunden. In der modellgetriebenen App Power Portals Pro öffnen (oder erstellen) Sie den Portal-Website-Eintrag mit Ihrem Lizenzschlüssel und setzen die URL auf die Produktions-URL des gerade installierten Portals – https://myportal.azurewebsites.netoder auf Ihre eigene Domain, falls eine davon vorankommt.

Registrieren Sie nur die Produktions-URL . Die Validierung akzeptiert -devauch , -test, -uat, -stage und -prod Suffix-Hosts sowie dieselben fünf als führende Subdomains, sodass andere Umgebungen keinen separaten Datensatz benötigen. Die Lizenzierungsseite enthält die vollständige Liste.

Wichtig

Mach das, bevor du den Datenverkehr sendest. Jeder datenbereitende Endpunkt überprüft die Lizenz, sodass das Portal angezeigt wird, bis der Datensatz existiert und mit dem Host übereinstimmt, aber jeder Datenaufruf kommt zurück 402.

8. Fügen Sie die Produktionsumleitung URI hinzu

Wenn das Portal eine Microsoft-Anmeldung anbietet, kennt die Registrierung der Anmelde-App immer noch nur deine localhost-Redirect-URI. Füge die bereitgestellte URI dazu hinzu – Entra akzeptiert mehrere, sodass die lokale weiterhin funktioniert:

Dasselbe Muster gilt für die anderen Anbieter auf ihren eigenen Callback-Pfaden (/signin-google, /signin-facebook). Fügen Sie pro Umgebung einen und einen pro benutzerdefinierten Domain hinzu.

Einsatzplätze

Ein Staging-Slot und ein Tausch geben dir eine aufgewärmte App und einen sofortigen Rollback. Sie sind das Einzige, wofür es sich wirklich lohnt, Basic zu verlassen – und der Grund, es zu verlassen, wenn du sie brauchst, statt im Voraus. Zwei Dinge brauchen Pflege.

Datenschutzschlüssel sind pro Slot. ASP.NET Core speichert den Schlüsselring unter %HOME%, von dem jeder Slot eine eigene Kopie hat, sodass ein Swap ihn ersetzt – und jedes Authentifizierungscookie, das vom vorherigen Slot ausgegeben wird, wird unentschlüsselbar. Alle sind ausgeloggt. Stellen Sie den Schlüsselring an einen Ort, an dem beide Slots gemeinsam sind, bevor Sie auf Swapping setzen:

Markiere die umgebungsspezifischen Einstellungen als Slot-Einstellungen , damit sie während eines Swaps zurückbleiben. Die URL der Dataverse-Umgebung ist diejenige, die ankommt: Ohne sie bringt das Tauschen eines Staging-Slots, der auf eine Sandbox zeigt, diese Sandbox-Verbindung in die Produktion.

Skalieren

Skalieren ist eine Entscheidung, die man trifft, wenn man den Bedarf dafür misst, nicht wenn man bereitstellt. Eine Instanz der Standardstufe führt überraschend viel Portal-Verkehr.

All das von einem KI-Agenten aus erledigt

Der Power Portals Pro MCP-Server kann jeden Schritt auf dieser Seite ausführen. Binden Sie den Ordner einmal an ein Abonnement, an einem Terminal – die Bindung gehört zu diesem Ordner, sodass mehrere Projekte gleichzeitig verschiedene Kunden ansprechen können und sich maschinell nichts ändert:

Anmerkung

Jedes Tool, das in Azure etwas ändert, zeigt Ihnen, was es tun wird, bevor Sie zur Bestätigung gebeten werden, einschließlich der tatsächlichen monatlichen Kosten für Ihre Region, mit dem Hinweis, dass die Einzelhandelsliste jede Enterprise Agreement oder Reservierung ignoriert, die Sie halten. Werkzeuge, die nur lesen, fordern nie. Der Server verwendet die Azure-CLI nicht und liest oder ändert nie seinen angemeldeten Zustand.

Fehlerbehebung