Programetablering i karantänstatus

  • Artikel

Microsoft Entra-etableringstjänsten övervakar hälsotillståndet för din konfiguration. Det placerar också appar med feltillstånd i ett "karantäntillstånd". Om de flesta, eller alla, av de anrop som görs mot målsystemet konsekvent misslyckas markeras etableringsjobbet som i karantän. Ett exempel på ett fel är ett fel som tas emot på grund av ogiltiga administratörsautentiseringsuppgifter.

I karantän:

  • Frekvensen för inkrementella cykler minskas gradvis till en gång per dag.
  • Etableringsjobbet tas bort från karantänen när alla fel har åtgärdats och nästa synkroniseringscykel startar.
  • Om etableringsjobbet ligger kvar i karantän i mer än fyra veckor inaktiveras etableringsjobbet (slutar köras).

Hur gör jag för att veta om mitt program är i karantän?

Det finns tre sätt att kontrollera om ett program är i karantän:

  • I administrationscentret för Microsoft Entra går du till Identity>Applications>Enterprise-programprogrammets<>namn>>Etablering och granskar förloppsindikatorn för ett karantänmeddelande.

    Provisioning status bar showing quarantine status

  • I administrationscentret för Microsoft Entra går du till filtret Identitetsövervakning>och hälsogranskningsloggar>> på Aktivitet: Placera i karantän och granska karantänhistoriken. Vyn i förloppsindikatorn enligt beskrivningen ovan visar om etableringen för närvarande är i karantän. Granskningsloggarna visar karantänhistoriken för ett program.

  • Använd Microsoft Graph-begäran Hämta synkroniseringsjobb för att programmatiskt hämta status för etableringsjobbet:

        GET https://graph.microsoft.com/beta/servicePrincipals/{id}/synchronization/jobs/{jobId}/

  • Kontrollera din e-post. När ett program placeras i karantän skickas ett engångsmeddelande via e-post. Om karantänorsaken ändras skickas ett uppdaterat e-postmeddelande som visar den nya orsaken till karantänen. Om du inte ser något e-postmeddelande:

    • Kontrollera att du har angett ett giltigt e-postmeddelande i etableringskonfigurationen för programmet.
    • Kontrollera att det inte finns någon skräppostfiltrering i inkorgen för e-postavisering.
    • Se till att du inte har avslutat prenumerationen på e-postmeddelanden.
    • Sök efter e-postmeddelanden från azure-noreply@microsoft.com

Varför är mitt program i karantän?

Nedan visas de vanligaste orsakerna till att ditt program kan hamna i karantän

beskrivning Rekommenderad åtgärd
SCIM-efterlevnadsproblem: Ett HTTP/404-svar som inte hittades returnerades i stället för det förväntade HTTP/200 OK-svaret. I det här fallet har Microsoft Entra-etableringstjänsten gjort en begäran till målprogrammet och fått ett oväntat svar. Kontrollera avsnittet administratörsautentiseringsuppgifter. Se om programmet kräver att du anger klient-URL:en och att URL:en är korrekt. Om du inte ser något problem kontaktar du programutvecklaren för att se till att deras tjänst är SCIM-kompatibel. https://tools.ietf.org/html/rfc7644#section-3.4.2
Ogiltiga autentiseringsuppgifter: När vi försökte auktorisera åtkomsten till målprogrammet fick vi ett svar från målprogrammet som anger att de angivna autentiseringsuppgifterna är ogiltiga. Gå till avsnittet administratörsautentiseringsuppgifter i konfigurationsgränssnittet för etablering och auktorisera åtkomst igen med giltiga autentiseringsuppgifter. Om programmet finns i galleriet går du igenom självstudien för programkonfiguration för att se vilka steg som krävs längre.
Duplicerade roller: Roller som importeras från vissa program som Salesforce och Zendesk måste vara unika. Gå till programmanifestet i administrationscentret för Microsoft Entra och ta bort dubblettrollen.

En Microsoft Graph-begäran om att få status för etableringsjobbet visar följande orsak till karantän:

  • EncounteredQuarantineException anger att ogiltiga autentiseringsuppgifter har angetts. Etableringstjänsten kan inte upprätta en anslutning mellan källsystemet och målsystemet.
  • EncounteredEscrowProportionThreshold anger att etableringen överskred tröskelvärdet för deposition. Det här villkoret inträffar när mer än 40 % av etableringshändelserna misslyckades. Mer information finns i information om tröskelvärden för deposition nedan.
  • QuarantineOnDemand innebär att vi har identifierat ett problem med ditt program och har ställt in det i karantän manuellt.

Tröskelvärden för deposition

Om tröskelvärdet för proportionell deposition uppfylls hamnar etableringsjobbet i karantän. Den här logiken kan komma att ändras, men fungerar ungefär så som beskrivs nedan:

Ett jobb kan sättas i karantän oavsett antal fel för problem som administratörsautentiseringsuppgifter eller SCIM-efterlevnad. I allmänhet är dock 5 000 fel minst för att börja utvärdera om de ska placeras i karantän på grund av för många fel. Ett jobb med 4 000 fel hamnar till exempel inte i karantän. Men ett jobb med 5 000 fel skulle utlösa en utvärdering. En utvärdering använder följande kriterier:

  • Om mer än 40 % av etableringshändelserna misslyckas eller om det finns fler än 40 000 fel hamnar etableringsjobbet i karantän. Referensfel räknas inte som en del av tröskelvärdet på 40 % eller 40 000. Det kan till exempel vara ett referensfel att det inte går att uppdatera en chef eller en gruppmedlem.
  • Ett jobb där 45 000 användare inte kunde etableras skulle leda till karantän eftersom det överskrider tröskelvärdet på 40 000.
  • Ett jobb där 30 000 användare misslyckades med etableringen och 5 000 lyckades skulle leda till karantän eftersom det överskrider tröskelvärdet på 40 % och minst 5 000.
  • Ett jobb med 20 000 fel och 100 000 lyckade fel hamnar inte i karantän eftersom det inte överskrider tröskelvärdet för 40 % fel eller maxvärdet på 40 000 fel.
  • Det finns ett absolut tröskelvärde på 60 000 fel som står för både referensfel och icke-referensfel. Till exempel kunde 40 000 användare inte etableras och 21 000 manageruppdateringar misslyckades. Det totala antalet är 61 000 fel och överskrider gränsen på 60 000.

Varaktighet för återförsök

Logiken som dokumenteras här kan vara annorlunda för vissa anslutningsappar för att säkerställa bästa kundupplevelse, men vi har vanligtvis nedanstående återförsökscykler efter ett fel:

Efter felet sker det första återförsöket om 6 timmar.

  • Det andra återförsöket sker 12 timmar efter det första felet.
  • Det tredje återförsöket sker 24 timmar efter det första felet.

Återförsök görs var 24:e timme efter det tredje återförsöket. Återförsöken pågår i 28 dagar efter det första felet varefter depositionsposten tas bort och jobbet inaktiveras.
Om någon av återförsöken ovan får ett lyckat svar placeras jobbet automatiskt ur karantän och ska återuppta det regelbundna synkroniseringsbeteendet.

Hur gör jag för att få ut mitt program ur karantän?

Lös först problemet som gjorde att programmet placerades i karantän.

  • Kontrollera programmets etableringsinställningar för att kontrollera att du har angett giltiga administratörsautentiseringsuppgifter. Microsoft Entra-ID måste upprätta ett förtroende för målprogrammet. Kontrollera att du har angett giltiga autentiseringsuppgifter och att ditt konto har nödvändiga behörigheter.

  • Granska etableringsloggarna för att undersöka vilka fel som orsakar karantän och åtgärda felet. Gå till Microsoft Entra ID>Enterprise Apps>Etableringsloggar (förhandsversion) i avsnittet Aktivitet.

När du har löst problemet startar du om etableringsjobbet. Vissa ändringar av programmets etableringsinställningar, till exempel attributmappningar eller omfångsfilter, startar automatiskt om etableringen åt dig. Förloppsindikatorn på programmets etableringssida anger när etableringen startades senast. Om du behöver starta om etableringsjobbet manuellt använder du någon av följande metoder:

  • Använd administrationscentret för Microsoft Entra för att starta om etableringsjobbet. På programmets etableringssida väljer du Starta om etablering. Den här åtgärden startar om etableringstjänsten helt, vilket kan ta lite tid. En fullständig initial cykel körs igen, vilket rensar depositioner, tar bort appen från karantänen och rensar eventuella vattenstämplar. Tjänsten utvärderar sedan alla användare i källsystemet igen och avgör om de omfattas av etableringen. Detta kan vara användbart när ditt program för närvarande är i karantän, som beskrivs i den här artikeln, eller om du behöver göra en ändring i attributmappningarna. Observera att den inledande cykeln tar längre tid att slutföra än den typiska inkrementella cykeln på grund av antalet objekt som behöver utvärderas. Du kan lära dig mer om prestanda för inledande och inkrementella cykler här.

  • Använd Microsoft Graph för att starta om etableringsjobbet. Du har fullständig kontroll över vad du startar om. Du kan välja att rensa depositionspunkter (för att starta om depositionsräknaren som ackumuleras mot karantänstatus), rensa karantän (för att ta bort programmet från karantän) eller rensa vattenstämplar. Använd följande begäran:

        POST /servicePrincipals/{id}/synchronization/jobs/{jobId}/restart

Ersätt {ID} med värdet för program-ID:t och ersätt {jobId} med ID: t för synkroniseringsjobbet.