PowerLeap Logo

Copilot Studio Friction

Bei Änderungen an diesem Eintrag benachrichtigt werden

Eine E-Mail, wenn sich Status oder Lösung ändert — Double-Opt-in, kein Tracking, Abmeldelink in jeder E-Mail.

Benutzer erhalten „Unable to provision connection"-Prompts statt Antworten

Abgemildertseit 8. Juli 2026

Zuletzt verifiziert

Details & Verwandtes

Einschätzung

Vertrauensstufe
Mehrfach belegtMehrere unabhängige Quellen beschreiben dasselbe Verhalten.
Schweregrad
Blockierend
Typischer Zeitverlust
Stunden

Identifikation

Wissen & GroundingAuthentifizierung & IdentitätAlle Kanäle

Verifikation & Änderungen

  1. Verifiziert

    Doku-Check durch Mensch: Dossier sections A7/C3 and connector docs re-read during seed migration; connection prompts still reported despite service-principal setup.

  2. Änderung

    Vorläufig durch den Product Owner freigegeben; externe LLM-Qualitätsprüfung ausstehend.

  3. Änderung

    Ersteintrag aus dem Seed-Dossier erstellt (Migrationswelle 1).

Verwandt

Automatisch übersetzte Fassung — massgeblich ist das englische Original.

Sind Sie hier richtig?

  • Sie haben Azure SQL oder eine andere Wissensquelle verbunden, die eine eigene Verbindung benötigt.
  • In Ihren eigenen Tests als Maker funktioniert alles.
  • Endbenutzer erhalten „Unable to provision connection" statt einer Antwort.
  • Oder Benutzer sehen einen Zustimmungsprompt, der FederatedKnowledgeSearchOperation erwähnt.
  • Sie haben einen Dienstprinzipal konfiguriert und erwartet, dass Benutzer nichts sehen.

Falls stattdessen Antworten mit veralteten oder fehlenden SQL-Daten eintreffen → Erwartungen an Live-Daten, nicht dieser Eintrag (Eintrag geplant). Falls stattdessen Wissen ohne jeden Prompt nichts zurückgibt → siehe Knowledge returns nothing — and no error is shown. Falls stattdessen ein Flow mit Berechtigungsfehlern fehlschlägt → siehe Flow fails with the user's permission errors despite "Maker-provided credentials".

Was passiert

Einige Wissenstypen, etwa Azure SQL, lesen Daten über eine benutzerspezifische Verbindung. Eine Verbindung speichert, wer das zugrunde liegende System abfragen darf. Oft wird ein Dienstprinzipal konfiguriert — ein technisches Konto, das für alle abfragen soll. Community-Berichte zeigen, dass Benutzer dennoch aufgefordert werden, ihre eigene Verbindung zu provisionieren, das heisst zu erstellen. Benutzer, die den Prompt nicht abschliessen können, erhalten „Unable to provision connection" statt Antworten. Andere sehen einen Zustimmungsprompt für einen föderierten Wissenssuchvorgang. Es ist wie eine Kantinenkarte, die jeder Mitarbeitende noch an einem Automaten aktivieren muss, den niemand erklärt hat.

Für Technikerinnen und Techniker

  • Community-Berichte, dokumentiert per 2026-07-08, zeigen, dass die Prompts trotz Dienstprinzipal-Konfiguration bestehen bleiben; wo verfügbar, wird eine verwaltete Identität empfohlen.
  • Zwei dokumentierte Grenzen sind hier relevant, Stand 2026-07-08.
  • Connector-Antworten über 500 KB schlagen fehl.
  • Der Azure SQL-Connector erzwingt ein Abfragetimeout von 40 Sekunden.
  • Der Zustimmungsprompt nennt den internen Vorgang FederatedKnowledgeSearchOperation.

So beheben Sie es

Lösung 1

Community-Workaround

Die Daten stattdessen über einen Agent-Flow bereitstellen

  1. Erstellen Sie einen Agent-Flow, der die Datenbank mit einer festen Maker-Verbindung abfragt.
  2. Geben Sie das Ergebnis als Text an den Agent zurück.
  3. Entfernen Sie die Wissensquelle, welche die Prompts ausgelöst hat.
  4. Aktualisieren Sie die Anweisungen des Agents, damit er den Flow für Datenfragen nutzt.

✅ Sie sollten jetzt sehen: Benutzer erhalten Datenantworten ohne jeden Verbindungsprompt.

  1. Halten Sie die Arbeit des Flows innerhalb der dokumentierten Grenzen aus dem Techniker-Abschnitt.

Lösung 2

Community-Workaround

Die Authentifizierungseinrichtung der Verbindung überprüfen

  1. Öffnen Sie die Verbindungseinstellungen der Wissensquelle.
  2. Prüfen Sie, ob für Ihre Datenbank eine verwaltete Identität verfügbar ist; Community-Berichte empfehlen sie gegenüber einem Dienstprinzipal.
  3. Testen Sie mit einem echten Endbenutzerkonto, nicht mit Ihrem Maker-Konto.

✅ Sie sollten jetzt sehen: Ein Testbenutzer erreicht Antworten ohne den Provisioning-Fehler.

Prüfen, ob es funktioniert hat

Stellen Sie als echter Endbenutzer im veröffentlichten Kanal eine Datenfrage. Erwartet: Eine Antwort trifft ein, ohne Verbindungs- oder Zustimmungsprompt.

Falls es nicht funktioniert hat

  • Sie haben mit Ihrem Maker-Konto getestet. Ihre eigenen Verbindungen verdecken das Problem; testen Sie immer erneut mit einem Endbenutzerkonto.
  • Der Kanal liefert weiterhin die alte Konfiguration. Siehe Teams answers with an old version of your agent.
  • Der Flow stösst an eine Grenze. Antworten über 500 KB oder Abfragen über 40 Sekunden schlagen fehl, dokumentiert per 2026-07-08.
  • Erwartungen, keine Fehler. Falls Daten eintreffen, aber veraltet sind, ist das ein separates Thema (Eintrag geplant).

So verhindern Sie es künftig

  • Übernehmen Sie die Regel „Live-Daten kommen aus einem Flow, nicht aus Wissen", wenn Sie den Datenzugriff planen.
  • Testen Sie jede neue Datenquelle vor dem Rollout mit einem echten Endbenutzerkonto.

Belege

  • MVP-Blogmatthewdevaney.com

    Kommentarverläufe unter diesem Praktiker-Beitrag berichten, dass Endbenutzer trotz konfigurierter Dienstprinzipal-Authentifizierung 'Unable to provision connection'-Fehler erhalten.

  • Offizielle Dokumentationlearn.microsoft.com

    Die Dokumentation des Azure SQL-Connectors legt ein Abfragetimeout von 40 Sekunden fest und beschreibt die Authentifizierungsanforderungen des Connectors.

  • Offizielle Dokumentationlearn.microsoft.com

    Dokumentiert, dass Connector-Antworten über 500 KB fehlschlagen — eine Grenze, die über Verbindungen abgerufene Daten einschränkt.