Botframework-solutions: Bereitstellungsskript wird mit "Der angegebene App-Dienstplan wurde nicht gefunden" ausgegeben.

pwsh-Ausgabe:

PS /Volumes/Data/Projects/Wendys/Bot/VirtualAssistantSample> ./Deployment/Scripts/deploy.ps1
Bot-Name (wird als Standardname für Ressourcengruppe und bereitgestellte Ressourcen verwendet): robtestbot98776r
Region der Azure-Ressourcengruppe: westus
Passwort für die MSA-App-Registrierung (muss mindestens 16 Zeichen lang sein, mindestens 1 Sonderzeichen enthalten und mindestens 1 numerisches Zeichen enthalten): RandoPwd......3!24jgjd
LUIS Authoring Region (westus, westeurope oder australiaeast): westus
LUIS Authoring Key (zu finden unter https://luis.ai/user/settings): ebfff00807a54....e5ea246974
Ressourcengruppe erstellen ...
Überprüfen der Azure-Bereitstellung ...
Vorlage ist mit bereitgestellten Parametern nicht gültig. Überprüfen Sie das Protokoll, um weitere Informationen zu erhalten.
Fehler: Die Vorlagenbereitstellung 'deployment_dry_run' ist gemäß dem Validierungsverfahren nicht gültig. Die Tracking-ID lautet '0e9e5f83-2b8a-4442-a5c5-080cccb6fab6'. Siehe innere Fehler für Details.
Protokoll: /Volumes/Data/Projects/Wendys/Bot/VirtualAssistantSample/Deployment/Scripts/../deploy_log.txt
Um diese Ressourcengruppe zu löschen, führen Sie 'az group delete -g robtestbot98776r --no-wait' aus.
PS /Volumes/Daten/Projekte/Wendys/Bot/VirtualAssistantSample>

Ich habe eine manuelle Bereitstellung mit ARM versucht und es wird dieselbe Fehlermeldung ausgegeben.

Hallo @rob-derosa, das sieht nach einem Problem mit dem QnA Maker-Dienst in Azure aus. Ich habe mich an das Team gewandt und werde dieses Problem aktualisieren, sobald ich etwas höre.

In der Zwischenzeit müssen Sie möglicherweise die QnA-Dienste aus der Armvorlage entfernen, damit die Bereitstellung funktioniert.

Wo lebt die Armschablone? In der Vorlage habe ich keine gefunden.

Seine Bereitstellung\Ressourcen\template.json

Erwischt. Aktualisiert, um QnA-Referenzen zu entfernen und Bereitstellung funktionierte. Danke für die Problemumgehung.

Update: Dies scheint nur Westus zu betreffen, daher ist der Wechsel in eine andere Region eine weitere Problemumgehung.

gleicher Fehler bei westeurope @lauren-mills

@tamerin-tech - Ich konnte gerade mit der Armvorlage in Westeuropa bereitstellen. Können Sie Protokolle rüberschicken?

Ok, das Team hat sich wieder mit dem Thema beschäftigt.

Versuchen Sie, diese Zeile in diese zu ändern:

"serverFarmId": "[concat('/subscriptions/', Subscription().SubscriptionId,'/resourcegroups/', resourceGroup().name, '/providers/Microsoft.Web/serverfarms/', parameters('appServicePlanName'))]",

Lass es mich wissen, wenn es das Problem behebt.

Hallo @lauren-mills! Wir haben mit Ihrem Vorschlag erfolgreich einen virtuellen Assistenten bereitgestellt.

Im Falle des TypeScript Virtual Assistant ist die folgende Zeile .

Sollten wir die Bereitstellungsskripts für die TypeScript-Lösungen aktualisieren oder einfach warten, um diese Änderungen zu bestätigen?

Ich arbeite an einigen anderen Updates, also kümmere ich mich gleichzeitig darum! Vielen Dank

Leute, ich habe heute das gleiche Problem in einem meiner Abonnements angesprochen und mit der Änderung sagte @lauren-mills, dass es funktioniert, aber ..... gestern habe ich denselben Code (den ich seit mehr als einem Jahr verwende) verwendet in ein anderes Abonnement (und eine Region) und es funktionierte.
wie ist das möglich?
¿Wie kann man plötzlich solche Breaking Changes in einer "Schnittstelle" machen?

Bei diesen Problemen ist es ziemlich schwierig, all das zu automatisieren

Es gab einige regionale Betriebsprobleme mit QnAMaker, die dann behoben wurden und daher behoben werden sollten. Wir haben auch Skripte aktualisiert

Dies geschieht immer noch. In einigen Regionen scheint der "alte Weg" zu funktionieren. Welcher ist "der Gute"?

Ok, das Team hat sich wieder mit dem Thema beschäftigt.

Versuchen Sie, diese Zeile in diese zu ändern:

"serverFarmId": "[concat('/subscriptions/', Subscription().SubscriptionId,'/resourcegroups/', resourceGroup().name, '/providers/Microsoft.Web/serverfarms/', parameters('appServicePlanName'))]",

Lass es mich wissen, wenn es das Problem behebt.

Dies hat mir geholfen, das Problem zu lösen. Ich werde auch die neueste Vorlage / das neueste Skript nehmen, da es darin fixiert zu sein scheint.

Ich bin erst heute auf dieses Problem gestoßen und habe den ganzen Morgen meinen Schwanz gejagt, da ich am Freitag einige andere Änderungen an meinem ARM-Template vorgenommen hatte und ich dachte, dass es damit zusammenhängt. Zum Glück hat @lauren-mills Vorschlag es vorerst gelöst.

Ich bin gerade selbst auf dieses Problem gestoßen.
Ich musste den Pfad der Serverfarmreferenz vor dem AppServicePlanName reduzieren
erwarteter Wert ist "resourceId('Microsoft.Web/serverfarms"

Web-App-Bereich, der jetzt gut funktioniert:
"serverFarmId": "[resourceId('Microsoft.Web/serverfarms', variables('AppServicePlanName'))]",

Hoffe es hilft jemandem

Ich hatte dieses Problem heute und der Grund war eine Nichtübereinstimmung beim "Standort" - stellen Sie sicher, dass Sie intelligent sind und denselben Standort für alle Ihre Ressourcen verwenden ... nicht wie ich :)

"[concat('/subscriptions/', Subscription().SubscriptionId,'/resourcegroups/', resourceGroup().name, '/providers/Microsoft.Web/serverfarms/', parameters('appServicePlanName'))]",

Diese Antwort von Lauren-Mills hat mir den Tag gerettet. Nur dass parameters('appServicePlanName') möglicherweise durch Variablen(''), wenn der Name von Variablen abgerufen wird, nicht von Parametern.