Dela via

Felsökning av Microsoft Entra Connect-objekt och -attribut från start till slut

  • Artikel

Den här artikeln är avsedd att upprätta en vanlig metod för att felsöka synkroniseringsproblem i Microsoft Entra-ID. Den här metoden gäller situationer där ett objekt eller attribut inte synkroniseras med Azure Active AD och inte visar några fel på synkroniseringsmotorn, i Programvisningsloggarna eller i Microsoft Entra-loggarna. Det är enkelt att gå vilse i informationen om det inte finns något uppenbart fel. Men genom att använda metodtips kan du isolera problemet och tillhandahålla insikter för Microsoft Support-tekniker.

När du tillämpar den här felsökningsmetoden på din miljö kan du med tiden utföra följande steg:

  • Felsöka synkroniseringsmotorlogik från slutpunkt till slutpunkt.
  • Lös synkroniseringsproblem mer effektivt.
  • Identifiera problem snabbare genom att förutsäga i vilket steg de ska ske.
  • Identifiera startpunkten för granskning av data.
  • Fastställ den optimala upplösningen.

Skärmbild av Microsoft Entra Connect-flödesdiagrammet.

Stegen som tillhandahålls här börjar på den lokala Active Directory-nivån och förlopp mot Microsoft Entra-ID. De här stegen är den vanligaste synkroniseringsriktningen. Samma principer gäller dock för omvänd riktning (till exempel för tillbakaskrivning av attribut).

Förutsättningar

Om du vill ha en bättre förståelse för den här artikeln läser du först följande nödvändiga artiklar för att få en bättre förståelse för hur du söker efter ett objekt i olika källor (AD, AD CS, MV och så vidare) och för att förstå hur du kontrollerar anslutningsappar och ursprung för ett objekt.

Felaktiga felsökningsmetoder

Flaggan DirSyncEnabled i Microsoft Entra ID styr om klienten är beredd att acceptera synkronisering av objekt från lokal AD. Vi har sett många kunder använda för vana att inaktivera DirSync på klientorganisationen vid felsökning av problem med objekt- eller attributsynkronisering. Det är enkelt att inaktivera katalogsynkronisering genom att köra följande PowerShell-cmdlet:

Set-MsolDirSyncEnabled -EnableDirSync $false "Please DON'T and keep reading!"

Kommentar

Azure AD- och MSOnline PowerShell-moduler är inaktuella från och med den 30 mars 2024. Mer information finns i utfasningsuppdateringen. Efter det här datumet är stödet för dessa moduler begränsat till migreringshjälp till Microsoft Graph PowerShell SDK och säkerhetskorrigeringar. De inaktuella modulerna fortsätter att fungera till och med mars 30 2025.

Vi rekommenderar att du migrerar till Microsoft Graph PowerShell för att interagera med Microsoft Entra-ID (tidigare Azure AD). Vanliga migreringsfrågor finns i Vanliga frågor och svar om migrering. Obs! Versioner 1.0.x av MSOnline kan uppleva störningar efter den 30 juni 2024.

Detta kan dock vara katastrofalt eftersom det utlöser en komplex och lång backend-åtgärd för att överföra SoA från lokal Active Directory till Microsoft Entra ID/Exchange Online för alla synkroniserade objekt i klientorganisationen. Den här åtgärden är nödvändig för att konvertera varje objekt från DirSyncEnabled till endast molnet och rensa alla skuggegenskaper som synkroniseras från lokal AD (till exempel ShadowUserPrincipalName och ShadowProxyAddresses). Beroende på klientorganisationens storlek kan den här åtgärden ta mer än 72 timmar. Det går inte heller att förutsäga när åtgärden kommer att slutföras. Använd aldrig den här metoden för att felsöka ett synkroniseringsproblem eftersom detta orsakar ytterligare skada och inte åtgärdar problemet. Du kommer att blockeras från att aktivera DirSync igen tills den här inaktiveringsåtgärden är klar. När du har återaktivera DirSync måste AADC återigen matcha alla lokala objekt med befintliga Microsoft Entra-objekt. Den här processen kan vara störande.

De enda scenarier där det här kommandot stöds för att inaktivera DirSync är följande:

  • Du inaktiverar din lokala synkroniseringsserver och vill fortsätta att hantera dina identiteter helt från molnet i stället för från hybrididentiteter.
  • Du har vissa synkroniserade objekt i klientorganisationen som du vill behålla som endast molnbaserade i Microsoft Entra-ID och ta bort från lokal AD permanent.
  • Du använder för närvarande ett anpassat attribut som SourceAnchor i AADC (till exempel employeeId) och du installerar om AADC för att börja använda ms-Ds-Consistency-Guid/ObjectGuid som det nya SourceAnchor-attributet (eller vice versa).
  • Du har några scenarier som omfattar riskfyllda strategier för postlåda och klientmigrering.

I vissa situationer kan du tillfälligt behöva stoppa synkroniseringen eller manuellt kontrollera AADC-synkroniseringscykler. Du kan till exempel behöva stoppa synkroniseringen för att kunna köra ett synkroniseringssteg i taget. Men i stället för att inaktivera DirSync kan du bara stoppa synkroniseringsschemaläggaren genom att köra följande cmdlet:

Set-ADSyncScheduler -SyncCycleEnabled $false

Och när du är klar startar du en synkroniseringscykel manuellt genom att köra följande cmdlet:

Start-ADSyncSyncCycle

Ordlista

Förkortning Namn/beskrivning
AADC Microsoft Entra Connect
AADCA Microsoft Entra-anslutarkonto
AADCS Microsoft Entra-anslutarplats
AADCS:AttributeA Attributet "A" i Microsoft Entra Connector Space
ACL:er Åtkomstkontrollistor (kallas även ADDS-behörigheter)
ADCA AD Connector-konto
ADCS Active Directory-anslutarplats
ADCS:AttributeA Attributet "A" i Active Directory Connector Space
ADDS eller AD Active Directory Domain Services
CS Anslutarplats
MV Metaversum
MSOL-konto Automatiskt genererat AD Connector-konto (MSOL_########)
MV:AttributeA Attributet "A" i metaversumobjektet
SoA Auktoritetskälla

Steg 1: Synkronisering mellan ADDS och ADCS

Mål för steg 1

Avgör om objektet eller attributet finns och är konsekvent i ADCS. Om du kan hitta objektet i ADCS och alla attribut har de förväntade värdena går du till Steg 2.

Skärmbild av A D Connector Space A D-replikering.

Beskrivning för steg 1

Synkronisering mellan ADDS och ADCS sker i importsteget och är det ögonblick då AADC läser från källkatalogen och lagrar data i databasen. Det vill: när data mellanlagras i anslutningsutrymmet. Under en deltaimport från AD begär AADC alla nya ändringar som inträffat efter en viss katalogvattenstämpel. Det här anropet initieras av AADC med hjälp av DirSync-kontrollen för Directory Services mot Active Directory Replication Service. Det här steget innehåller den sista vattenstämpeln som den senaste lyckade AD-importen och ger AD referensen till tidpunkten från när alla (delta)-ändringar ska hämtas. En fullständig import skiljer sig eftersom AADC importerar alla data från AD (i synkroniseringsomfånget) och sedan markerar som föråldrade (och tar bort) alla objekt som fortfarande finns i ADCS men som inte har importerats från AD. Alla data mellan AD och AADC överförs via LDAP och krypteras som standard.

Skärmbild av dialogrutan A A D C-anslutningsalternativ.

Om anslutningen till AD lyckas, men objektet eller attributet inte finns i ADCS (förutsatt att domänen eller objektet är i synkroniseringsomfånget), innebär problemet troligen ADDS-behörigheter. ADCA kräver minst läsbehörighet för objektet i AD för att kunna importera data till ADCS. Som standard har MSOL-kontot explicit läs-/skrivbehörighet för alla egenskaper för användare, grupper och datorer. Den här situationen kan dock fortfarande vara problematisk om följande villkor är uppfyllda:

  • AADC använder en anpassad ADCA, men den har inte fått tillräckliga behörigheter i AD.
  • En överordnad organisationsenhet har blockerat arv, vilket förhindrar spridning av behörigheter från domänens rot.
  • Själva objektet eller attributet har blockerat arv, vilket förhindrar spridning av behörigheter.
  • Objektet eller attributet har en explicit neka-behörighet som hindrar ADCA från att läsa det.

Felsöka Active Directory

Anslutning med AD

I synkroniseringstjänsthanteraren visar steget "Importera från AD" vilken domänkontrollant som kontaktas under Anslutningsstatus. Du ser troligen ett fel här när det finns ett anslutningsproblem som påverkar AD.

Skärmbild som visar området Anslutningsstatus i steget Importera från A D.

Om du behöver ytterligare felsöka anslutningen för AD, särskilt om inga fel uppstått på Microsoft Entra Connect-servern eller om du fortfarande håller på att installera produkten, börjar du med att använda ADConnectivityTool.

Anslutningsproblem med ADDS har följande orsaker:

  • Ogiltiga AD-autentiseringsuppgifter. Adca har till exempel upphört att gälla eller så har lösenordet ändrats.
  • Ett fel vid "misslyckad sökning", som inträffar när DirSync Control inte kommunicerar med AD Replication-tjänsten, vanligtvis på grund av fragmentering av nätverkspaket.
  • Ett "no-start-ma"-fel, som inträffar när det finns namnmatchningsproblem (DNS) i AD.
  • Andra problem som kan orsakas av problem med namnmatchning, problem med nätverksroutning, blockerade nätverksportar, fragmentering av nätverkspaket, inga skrivbara domänkontrollanter tillgängliga och så vidare. I sådana fall måste du förmodligen involvera supportteamen för Katalogtjänster eller nätverk för att felsöka.

Felsökningssammanfattning

  • Identifiera vilken domänkontrollant som används.
  • Använd önskade domänkontrollanter för att rikta in sig på samma domänkontrollant.
  • Identifiera ADCA korrekt.
  • Använd ADConnectivityTool för att identifiera problemet.
  • Använd LDP-verktyget för att försöka binda mot domänkontrollanten med ADCA.
  • Kontakta Directory Services eller ett nätverkssupportteam som hjälper dig att felsöka.

Kör felsökaren för synkronisering

När du har felsökt AD-anslutningen kör du verktyget Felsöka objektsynkronisering eftersom enbart detta kan identifiera de mest uppenbara orsakerna till att ett objekt eller attribut inte synkroniseras.

Skärmbild av felsökningsskärmen för Microsoft Entra Connect.

AD-behörigheter

Brist på AD-behörigheter kan påverka båda riktningarna för synkroniseringen:

  • När du importerar från ADDS till ADCS kan en brist på behörigheter göra att AADC hoppar över objekt eller attribut så att AADC inte kan hämta ADDS-uppdateringar i importströmmen. Det här felet beror på att ADCA inte har tillräcklig behörighet för att läsa objektet.
  • När du exporterar från ADCS till ADDS genererar en brist på behörigheter ett exportfel för "behörighetsproblem".

Om du vill kontrollera behörigheter öppnar du fönstret Egenskaper för ett AD-objekt, väljer Säkerhet>Avancerat och undersöker sedan objektets tillåtna/nekande-ACL:er genom att välja knappen Inaktivera arv (om arv är aktiverat). Du kan sortera kolumninnehållet efter typ för att hitta alla "neka"-behörigheter. AD-behörigheter kan variera kraftigt. Men som standard kanske du bara ser en "Neka ACL" för "Exchange Trusted Subsystem". De flesta behörigheter markeras som Tillåt.

Följande standardbehörigheter är de mest relevanta:

  • Autentiserade användare

    Skärmbild som visar autentiserade användare.

  • Alla

    Skärmbild som visar alternativet Tillåt är inställt på Alla.

  • Anpassat ADCA- eller MSOL-konto

    Skärmbild som visar det anpassade ADCA- eller MSOL-kontot.

  • Pre-Windows 2000-kompatibel åtkomst

    Skärmbild som visar den kompatibla åtkomsten för Windows 2000.

  • Själv

    Skärmbild som visar att SELF-behörigheten är tillåten.

Det bästa sättet att felsöka behörigheter är att använda funktionen "Effektiv åtkomst" i AD-konsolen Användare och datorer . Den här funktionen kontrollerar de gällande behörigheterna för ett visst konto (ADCA) för målobjektet eller attributet som du vill felsöka.

Skärmbild som visar information under fliken Effektiv åtkomst i fönstret Avancerade säkerhetsinställningar.

Viktigt!

Det kan vara svårt att felsöka AD-behörigheter eftersom en ändring i ACL:er inte träder i kraft omedelbart. Tänk alltid på att sådana ändringar omfattas av AD-replikering.

Till exempel:

  • Kontrollera att du gör de nödvändiga ändringarna direkt till närmaste domänkontrollant (se avsnittet "Anslutning med AD"):
  • Vänta tills ADDS-replikering inträffar.
  • Om möjligt startar du om ADSync-tjänsten för att rensa cacheminnet.

Felsökningssammanfattning

  • Identifiera vilken domänkontrollant som används.
  • Använd önskade domänkontrollanter för att rikta in sig på samma domänkontrollant.
  • Identifiera ADCA korrekt.
  • Använd verktyget Konfigurera kontobehörigheter för AD DS-anslutningstjänsten.
  • Använd funktionen "Effektiv åtkomst" i AD-användare och -datorer.
  • Använd LDP-verktyget för att binda mot domänkontrollanten som har ADCA och försök att läsa det misslyckade objektet eller attributet.
  • Lägg tillfälligt till ADCA till företagsadministratörerna eller domänadministratörerna och starta om ADSync-tjänsten.

Viktigt: Använd inte detta som en lösning.

  • När du har verifierat behörighetsproblemet tar du bort ADCA från alla grupper med hög behörighet och anger de ad-behörigheter som krävs direkt till ADCA.
  • Kontakta Directory Services eller ett nätverkssupportteam som hjälper dig att felsöka situationen.

AD-replikering

Det här problemet är mindre troligt att det påverkar Microsoft Entra Connect eftersom det orsakar större problem. Men när Microsoft Entra Connect importerar data från en domänkontrollant med fördröjd replikering importeras inte den senaste informationen från AD, vilket orsakar synkroniseringsproblem där ett objekt eller attribut som nyligen skapades eller ändrades i AD inte synkroniseras till Microsoft Entra-ID eftersom det inte replikerades till domänkontrollanten som Microsoft Entra Connect kontaktar. Kontrollera att det här är problemet genom att kontrollera domänkontrollanten som AADC använder för import (se "Anslutning till AD") och använda AD-konsolen Användare och datorer för att ansluta direkt till den här servern (se Ändra domänkontrollant i nästa bild). Kontrollera sedan att data på den här servern motsvarar de senaste data och om de överensstämmer med respektive ADCS-data. I det här skedet genererar AADC en större belastning på domänkontrollanten och nätverksskiktet.

Skärmbild av alternativet Ändra domänkontrollant i Active Directory.

En annan metod är att använda verktyget RepAdmin för att kontrollera objektets replikeringsmetadata på alla domänkontrollanter, hämta värdet från alla domänkontrollanter och kontrollera replikeringsstatus mellan domänkontrollanter:

  • Attributvärde från alla domänkontrollanter:

    repadmin /showattr * "DC=contoso,DC=com" /subtree /filter:"sAMAccountName=User01" /attrs:pwdLastSet,UserPrincipalName

    Skärmbild av verktyget RepAdmin med showattr.

  • Objektmetadata från alla domänkontrollanter:

    repadmin /showobjmeta * "CN=username,DC=contoso,DC=com" > username-ObjMeta.txt

    Skärmbild av verktyget RepAdmin med kommandot showobjmeta.

  • Sammanfattning av AD-replikering

    repadmin /replsummary

    Skärmbild av verktyget RepAdmin med kommandot replsummary.

Felsökningssammanfattning

  • Identifiera vilken domänkontrollant som används.
  • Jämför data mellan domänkontrollanter.
  • Analysera RepAdmin-resultaten.
  • Kontakta Directory Services eller nätverkssupportteamet för att felsöka problemet.

Domän- och organisationsenhetsändringar samt objekttyper eller attribut som filtrerats eller exkluderats i ADDS Connector

  • Om du ändrar domän- eller organisationsenhetsfiltrering krävs en fullständig import

    Tänk på att även om domänen eller OU-filtreringen bekräftas börjar alla ändringar i domän- eller organisationsenhetsfiltreringen gälla först när du har kört ett fullständigt importsteg.

  • Attributfiltrering med Microsoft Entra-app- och attributfiltrering

    Ett scenario som är lätt att missa för attribut som inte synkroniseras är när Microsoft Entra Connect har konfigurerats med microsoft Entra-app- och attributfiltreringsfunktionen . Om du vill kontrollera om funktionen är aktiverad och för vilka attribut tar du en allmän diagnostikrapport.

  • Objekttyp som undantas i ADDS Connector-konfiguration

    Den här situationen inträffar inte som vanligt för användare och grupper. Men om alla objekt av en viss objekttyp saknas i ADCS kan det vara användbart att undersöka vilka objekttyper som är aktiverade i ADDS Connector-konfigurationen.

    Du kan använda cmdleten Get-ADSyncConnector för att hämta de objekttyper som är aktiverade i anslutningsappen, som du ser i nästa bild. Följande är de objekttyper som ska vara aktiverade som standard:

    (Get-ADSyncConnector | where Name -eq "Contoso.com").ObjectInclusionList

    Följande är de objekttyper som ska vara aktiverade som standard:

    Skärmbild som visar objekttyperna Get-ADSyncConnector.

    Kommentar

    Objekttypen publicFolder finns bara när funktionen E-postaktiverad gemensam mapp är aktiverad.

  • Attribut som undantas i ADCS

    Om attributet saknas för alla objekt på samma sätt kontrollerar du om attributet har valts i AD-anslutningsappen.

    Om du vill söka efter aktiverade attribut i ADDS Connector använder du Synkroniseringshanteraren, som visas i nästa bild, eller kör följande PowerShell-cmdlet:

    (Get-ADSyncConnector | where Name -eq "Contoso.com").AttributeInclusionList

    Skärmbild av AD Connector Synchronization Manager.

    Kommentar

    Det går inte att inkludera eller exkluderas objekttyper eller attribut i Synkroniseringstjänsthanteraren.

Felsökningssammanfattning

Resurser för steg 1

Huvudresurser:

  • Get-ADSyncConnectorAccount – Identifiera rätt anslutningskonto som används av AADC

  • ADConnectivityTool

  • Identifiera anslutningsproblem med ADDS

  • Trace-ADSyncToolsADImport (ADSyncTools) – Spåra data som importeras från ADDS

  • LDIFDE – Dumpa objekt från ADDS för att jämföra data mellan ADDS och ADCS

  • LDP – Testa AD-bindningsanslutning och behörigheter för att läsa objekt i säkerhetskontexten för ADCA

  • DSACLS – Jämföra och utvärdera ADDS-behörigheter

  • Funktionsbehörigheter för Set-ADSync< >– Tillämpa AADC-standardbehörigheter i ADDS

  • RepAdmin – Kontrollera AD-objektmetadata och AD-replikeringsstatus

Steg 2: Synkronisering mellan ADCS och MV

Skärmbild som visar flödesdiagrammet A D C S till MetaVerse.

Mål för steg 2

Det här steget kontrollerar om objektet eller attributet flödar från CS till MV (med andra ord om objektet eller attributet projiceras till MV). I det här skedet kontrollerar du att objektet finns eller att attributet är korrekt i ADCS (beskrivs i steg 1) och börjar sedan titta på synkroniseringsreglerna och ursprunget för objektet.

Beskrivning för steg 2

Synkroniseringen mellan ADCS och MV sker i steget delta/fullständig synkronisering. Nu läser AADC mellanlagrade data i ADCS, bearbetar alla synkroniseringsregler och uppdaterar respektive MV-objekt. Det här MV-objektet innehåller CS-länkar (eller anslutningsappar) som pekar på DE CS-objekt som bidrar till dess egenskaper och ursprunget för synkroniseringsregler som tillämpades i synkroniseringssteget. Under den här fasen genererar AADC mer belastning på SQL Server-skikten (eller LocalDB) och nätverk.

Felsöka ADCS > MV för objekt

  • Kontrollera reglerna för inkommande synkronisering för etablering

    Ett objekt som finns i ADCS men som saknas i MV anger att det inte fanns några omfångsfilter för någon av de etableringssynkroniseringsregler som tillämpades på objektet. Därför projicerades inte objektet till MV. Det här problemet kan inträffa om det finns inaktiverade eller anpassade synkroniseringsregler.

    Kör följande kommando för att hämta en lista över regler för inkommande etableringssynkronisering:

    Get-ADSyncRule | where {$_.Name -like "In From AD*" -and $_.LinkType -eq "Provision"} | select Name,Direction,LinkType,Precedence,Disabled | ft

    Skärmbild som visar kommandot Get-ADSyncRule används för att kontrollera regler för inkommande etablering.

  • Kontrollera ursprunget för ADCS-objektet

    Du kan hämta det misslyckade objektet från ADCS genom att söka på "DN eller Anchor" i "Sökanslutningsutrymme". På fliken Ursprung ser du förmodligen att objektet är en frånkoppling (inga länkar till MV) och att ursprunget är tomt. Kontrollera också om objektet har några fel, om det finns en synkroniseringsfelflik.

    Skärmbild av egenskaperna för anslutningsutrymmesobjektet i A D C S.

  • Kör en förhandsversion av ADCS-objektet

    Välj Förhandsversion>Generera förhandsversion>incheckning för att se om objektet projiceras till MV. Om så är fallet bör en fullständig synkroniseringscykel åtgärda problemet för andra objekt i samma situation.

    Skärmbild av förhandsgranskningsskärmen för A D C S-objektet.

    Skärmbild av skärmen Information om källobjekt i A D C S.

  • Exportera objektet till XML

    För en mer detaljerad analys (eller för offlineanalys) kan du samla in alla databasdata som är relaterade till objektet med hjälp av cmdleten Export-ADSyncObject . Den här exporterade informationen hjälper dig att avgöra vilken regel som filtrerar bort objektet. Med andra ord, vilket inkommande omfångsfilter i etableringssynkroniseringsreglerna hindrar objektet från att projiceras till MV.

    Här följer några exempel på Export-ADsyncObject-syntax :

    • Import-Module "C:\Program Files\Microsoft Azure Active Directory Connect\Tools\AdSyncTools.psm1"
    • Export-ADsyncObject -DistinguishedName 'CN=TestUser,OU=Sync,DC=Domain,DC=Contoso,DC=com' -ConnectorName 'Domain.Contoso.com'
    • Export-ADsyncObject -ObjectId '{46EBDE97-7220-E911-80CB-000D3A3614C0}' -Source Metaverse -Verbose

Felsökningssammanfattning (objekt)

  • Kontrollera omfångsfiltren för regler för inkommande etablering i "In From AD".
  • Skapa en förhandsgranskning av objektet.
  • Kör en fullständig synkroniseringscykel.
  • Exportera objektdata med hjälp av skriptet Export-ADSyncObject .

Felsöka ADCS > MV för attribut

  1. Identifiera regler för inkommande synkronisering och transformeringsregler för attributet

    Varje attribut har en egen uppsättning transformeringsregler som ansvarar för att dirigera värdet från ADCS till MV. Det första steget är att identifiera vilka synkroniseringsregler som innehåller transformeringsregeln för det attribut som du felsöker.

    Det bästa sättet att identifiera vilka synkroniseringsregler som har en transformeringsregel för ett visst attribut är att använda de inbyggda filtreringsfunktionerna i Redigeraren för synkroniseringsregler.

    Skärmbild av redigeraren för synkroniseringsregler i A D C S.

  2. Kontrollera ursprunget för ADCS-objektet

    Varje anslutningsapp (eller länk) mellan CS och MV har en härstamning som innehåller information om synkroniseringsregler som tillämpas på det CS-objektet. I föregående steg visas vilken uppsättning regler för inkommande synkronisering (oavsett om etablering eller koppling av synkroniseringsregler) måste finnas i objektets ursprung för att flöda rätt värde från ADCS till MV. Genom att undersöka ursprunget för ADCS-objektet kan du avgöra om synkroniseringsregeln har tillämpats på objektet.

    Skärmbild av ursprungsskärmen egenskaper för anslutningsutrymmesobjekt.

    Om det finns flera anslutningsappar (flera AD-skogar) som är länkade till MV-objektet kan du behöva undersöka objektegenskaperna för metaversum för att avgöra vilken anslutningsapp som bidrar med attributvärdet till det attribut som du försöker felsöka. När du har identifierat anslutningsappen undersöker du ursprunget för det ADCS-objektet.

    Skärmbild av skärmen Egenskaper för metaversumobjekt.

  3. Kontrollera omfångsfiltren för regeln för inkommande synkronisering

    Om en synkroniseringsregel är aktiverad men inte finns i objektets ursprung bör objektet filtreras bort av synkroniseringsregelns omfångsfilter. Genom att kontrollera synkroniseringsregelns omfångsfilter, data på ADCS-objektet och om synkroniseringsregeln är aktiverad eller inaktiverad bör du kunna avgöra varför synkroniseringsregeln inte tillämpades på ADCS-objektet.

    Här är ett exempel på ett vanligt besvärligt omfångsfilter från en synkroniseringsregel som ansvarar för att synkronisera Exchange-egenskaper. Om objektet har ett null-värde för mailNickName flödar inget av Exchange-attributen i transformeringsreglerna till Microsoft Entra-ID.

    Skärmbild av skärmen Visa regel för inkommande synkronisering.

  4. Kör en förhandsgranskning på ADCS-objekt

    Om du inte kan avgöra varför synkroniseringsregeln saknas i ADCS-objektets ursprung kör du en förhandsversion med hjälp av Generera förhandsversion och Incheckningsförhandsgranskning för en fullständig synkronisering av objektet. Om attributet uppdateras i MV och har en förhandsversion bör en fullständig synkroniseringscykel åtgärda problemet för andra objekt i samma situation.

  5. Exportera objektet till XML

    För en mer detaljerad analys eller offlineanalys kan du samla in alla databasdata som är relaterade till objektet med hjälp av skriptet Export-ADSyncObject . Den här exporterade informationen kan hjälpa dig att avgöra vilken synkroniseringsregel eller transformeringsregel som saknas för det objekt som förhindrar att attributet projiceras till MV (se exemplen Export-ADSyncObject tidigare i den här artikeln).

Felsökningssammanfattning (för attribut)

  • Identifiera rätt synkroniseringsregler och transformeringsregler som ansvarar för att flöda attributet till MV.
  • Kontrollera objektets ursprung.
  • Kontrollera om synkroniseringsregler har aktiverats.
  • Kontrollera omfångsfiltren för synkroniseringsregler som saknas i objektets ursprung.

Avancerad felsökning av pipelinen för synkroniseringsregeln

Om du behöver felsöka ADSync-motorn (även kallad MiiServer) när det gäller bearbetning av synkroniseringsregeln kan du aktivera ETW-spårning på .config-filen (C:\Program Files\Microsoft Azure AD Sync\Bin\miiserver.exe.config). Den här metoden genererar en omfattande utförlig textfil som visar all bearbetning av synkroniseringsregler. Det kan dock vara svårt att tolka all information. Använd den här metoden som en sista utväg eller om den anges av Microsoft Support.

Resurser för steg 2

  • Användargränssnitt för synkronisering av Service Manager
  • Redigeraren för synkroniseringsregler
  • Export-ADsyncObject-skript
  • Start-ADSyncSyncCycle -PolicyType Initial
  • ETW-spårning Av SyncRulesPipeline (miiserver.exe.config)

Steg 3: Synkronisering mellan MV och AADCS

Skärmbild av flödesdiagrammet M V och A D C S.

Mål för steg 3

Det här steget kontrollerar om objektet eller attributet flödar från MV till AADCS. Kontrollera nu att objektet finns eller att attributet är korrekt i ADCS och MV (beskrivs i steg 1 och 2). Granska sedan synkroniseringsreglerna och ursprunget för objektet. Det här steget liknar steg 2, där den inkommande riktningen från ADCS till MV undersöktes, men i det här skedet koncentrerar vi oss på de regler för utgående synkronisering och attribut som flödar från MV till AADCS.

Beskrivning för steg 3

Synkroniseringen mellan MV och AADCS sker i delta-/fullständig synkroniseringssteget, när AADC läser data i MV, bearbetar alla synkroniseringsregler och uppdaterar respektive AADCS-objekt. Det här MV-objektet innehåller CS-länkar (kallas även anslutningsappar) som pekar på DE CS-objekt som bidrar till dess egenskaper och ursprunget för de synkroniseringsregler som tillämpades i synkroniseringssteget. Nu genererar AADC mer belastning på SQL Server (eller localDB) och nätverksskiktet.

Felsöka MV till AADCS för objekt

  1. Kontrollera reglerna för utgående synkronisering för etablering

    Ett objekt som finns i MV men som saknas i AADCS anger att det inte fanns några omfångsfilter för någon av de etableringssynkroniseringsregler som tillämpades på objektet. Se till exempel synkroniseringsreglerna "Ut till Microsoft Entra-ID" som visas i nästa bild. Därför etablerades inte objektet i AADCS. Det här felet kan inträffa om det finns inaktiverade eller anpassade synkroniseringsregler.

    Kör följande kommando för att hämta en lista över regler för inkommande etableringssynkronisering:

    Get-ADSyncRule | where {$_.Name -like "Out to AAD*" -and $_.LinkType -eq "Provision"} | select Name,Direction,LinkType,Precedence,Disabled | ft

    Skärmbild av Get-ADSyncRule som används för att kontrollera regler för utgående synkronisering.

  2. Kontrollera ursprunget för ADCS-objektet

    Om du vill hämta det misslyckade objektet från MV använder du en Metaverse Search och undersöker sedan fliken Anslutningsappar. På den här fliken kan du avgöra om MV-objektet är länkat till ett AADCS-objekt. Kontrollera också om objektet har några fel, om det finns en synkroniseringsfelflik.

    Skärmbild av skärmen Metaversumsökning.

    Om det inte finns någon AADCS-anslutningsapp är objektet troligen inställt på cloudFiltered=True. Du kan kontrollera om objektet är molnfiltrerat genom att undersöka de MV-attribut för vilka synkroniseringsregeln bidrar med värdet cloudFiltered .

  3. Kör en förhandsversion på AADCS-objekt

    Välj Förhandsgranska>Generera förhandsversion>Checka in en förhandsversion för att avgöra om objektet ansluter till AADCS. I så fall bör en fullständig synkroniseringscykel åtgärda problemet för andra objekt i samma situation.

  4. Exportera objektet till XML

    För en mer detaljerad analys eller offlineanalys kan du samla in alla databasdata som är relaterade till objektet med hjälp av skriptet Export-ADSyncObject . Den här exporterade informationen, tillsammans med konfigurationen av (utgående) synkroniseringsregler, kan hjälpa dig att avgöra vilken regel som filtrerar bort objektet och kan avgöra vilket utgående omfångsfilter i etableringssynkroniseringsreglerna som hindrar objektet från att ansluta till AADCS).

    Här följer några exempel på Export-ADsyncObject-syntax :

    • Import-Module "C:\Program Files\Microsoft Azure Active Directory Connect\Tools\AdSyncTools.psm1"
    • Export-ADsyncObject -ObjectId '{46EBDE97-7220-E911-80CB-000D3A3614C0}' -Source Metaverse -Verbose
    • Export-ADsyncObject -DistinguishedName 'CN={2B4B574735713744676B53504C39424D4C72785247513D3D}' -ConnectorName 'Contoso.onmicrosoft.com - AAD'

Felsökningssammanfattning för objekt

  • Kontrollera omfångsfiltren för utgående etableringsregler för utgående etablering från "Ut till Microsoft Entra-ID".
  • Skapa en förhandsgranskning av objektet.
  • Kör en fullständig synkroniseringscykel.
  • Exportera objektdata med hjälp av skriptet Export-ADSyncObject .

Felsöka MV till AADCS för attribut

  1. Identifiera utgående synkroniseringsregler och transformeringsregler för attributet

    Varje attribut har en egen uppsättning transformeringsregler som ansvarar för att flöda värdet från MV till AADCS. Börja med att identifiera vilka synkroniseringsregler som innehåller transformeringsregeln för det attribut som du felsöker.

    Det bästa sättet att identifiera vilka synkroniseringsregler som har en transformeringsregel för ett visst attribut är att använda de inbyggda filtreringsfunktionerna i Redigeraren för synkroniseringsregler.

    Skärmbild av redigeraren för synkroniseringsregler.

  2. Kontrollera ursprunget för ADCS-objektet

    Varje anslutningsapp (eller länk) mellan CS och MV har en härkomst som innehåller information om de synkroniseringsregler som tillämpas på det CS-objektet. I föregående steg visas vilken uppsättning regler för utgående synkronisering (oavsett om du etablerar eller ansluter till synkroniseringsregler) som måste finnas i objektets ursprung för att flöda rätt värde från MV till AADCS. Genom att undersöka ursprunget för AADCS-objektet kan du avgöra om synkroniseringsregeln har tillämpats på objektet.

    Skärmbild som visar information om fliken Ursprung i A A D C S-objektet.

  3. Kontrollera omfångsfiltren för regeln för utgående synkronisering

    Om en synkroniseringsregel är aktiverad men inte finns i objektets ursprung bör den filtreras bort av synkroniseringsregelns omfångsfilter. Genom att kontrollera förekomsten av synkroniseringsregelns omfångsfilter och data på MV-objektet, och om synkroniseringsregeln är aktiverad eller inaktiverad, bör du kunna avgöra varför synkroniseringsregeln inte tillämpades på AADCS-objektet.

  4. Kör en förhandsgranskning på AADCS-objekt

    Om du tar reda på varför synkroniseringsregeln saknas i ADCS-objektets ursprung kör du en förhandsversion som använder Generera förhandsversion och Incheckningsförhandsgranskning för en fullständig synkronisering av objektet. Om attributet uppdateras i MV genom att ha en förhandsversion bör en fullständig synkroniseringscykel åtgärda problemet för andra objekt i samma situation.

  5. Exportera objektet till XML

    För en mer detaljerad analys eller offlineanalys kan du samla in alla databasdata som är relaterade till objektet med hjälp av skriptet "Export-ADSyncObject". Den här exporterade informationen, tillsammans med konfigurationen för (utgående) synkroniseringsregler, kan hjälpa dig att avgöra vilken synkroniseringsregel eller transformeringsregel som saknas i objektet som hindrar attributet från att flöda till AADCS (se exemplen "Export-ADSyncObject" tidigare).

Felsökningssammanfattning för attribut

  • Identifiera rätt synkroniseringsregler och transformeringsregler som ansvarar för att flöda attributet till AADCS.
  • Kontrollera objektets ursprung.
  • Kontrollera att synkroniseringsreglerna är aktiverade.
  • Kontrollera omfångsfiltren för synkroniseringsregler som saknas i objektets ursprung.

Felsöka pipelinen för synkroniseringsregel

Om du behöver felsöka ADSync-motorn (även kallad MiiServer) när det gäller bearbetning av synkroniseringsregeln kan du aktivera ETW-spårning på .config-filen (C:\Program Files\Microsoft Azure AD Sync\Bin\miiserver.exe.config). Den här metoden genererar en omfattande utförlig textfil som visar all bearbetning av synkroniseringsregler. Det kan dock vara svårt att tolka all information. Använd endast den här metoden som en sista utväg eller om den anges av Microsoft Support.

Resurser

  • Användargränssnitt för synkronisering av Service Manager
  • Redigeraren för synkroniseringsregler
  • Export-ADsyncObject-skript
  • Start-ADSyncSyncCycle -PolicyType Initial
  • ETW-spårning Av SyncRulesPipeline (miiserver.exe.config)

Steg 4: Synkronisering mellan AADCS och AzureAD

Skärmbild av synkroniseringsflödesdiagrammet mellan A A D C S och Microsoft Entra ID.

Mål för steg 4

I det här steget jämförs AADCS-objektet med respektive objekt som har etablerats i Microsoft Entra-ID.

Beskrivning för steg 4

Flera komponenter och processer som ingår i import och export av data till och från Microsoft Entra-ID kan orsaka följande problem:

  • Anslutning till Internet
  • Interna brandväggar och ISP-anslutning (till exempel blockerad nätverkstrafik)
  • Microsoft Entra-gatewayen framför DirSync Webservice (även kallad AdminWebService-slutpunkten)
  • DirSync-webbtjänst-API:et
  • Microsoft Entra Core-katalogtjänsten

Lyckligtvis genererar de problem som påverkar dessa komponenter vanligtvis ett fel i händelseloggar som kan spåras av Microsoft Support. Dessa problem ligger därför utanför omfånget för den här artikeln. Det finns dock fortfarande några "tysta" frågor som kan undersökas.

Felsöka AADCS

  • Flera aktiva AADC-servrar som exporterar till Microsoft Entra-ID

    I ett vanligt scenario där objekt i Microsoft Entra ID vänder attributvärden fram och tillbaka finns det fler än en aktiv Microsoft Entra Connect-servrar, och en av dessa servrar förlorar kontakten med den lokala AD men är fortfarande ansluten till Internet och kan exportera data till Microsoft Entra-ID. Varje gång den här inaktuella servern importerar en ändring från Microsoft Entra-ID på ett synkroniserat objekt som görs av den andra aktiva servern återställs därför synkroniseringsmotorn som ändras baserat på inaktuella AD-data som finns i ADCS. Ett typiskt symptom i det här scenariot är att du gör en ändring i AD som synkroniseras med Microsoft Entra-ID, men ändringen återgår till det ursprungliga värdet några minuter senare (upp till 30 minuter). Du kan snabbt åtgärda problemet genom att gå tillbaka till alla gamla servrar eller virtuella datorer som har inaktiverats och kontrollera om ADSync-tjänsten fortfarande körs.

  • Mobilt attribut med DirSyncOverrides

    När administratören använder MSOnline eller AzureAD PowerShell-modulen, eller om användaren går till Office-portalen och uppdaterar attributet Mobile , skrivs det uppdaterade telefonnumret över i AzureAD trots att objektet synkroniseras från lokal AD (även kallat DirSyncEnabled).

    Tillsammans med den här uppdateringen anger Microsoft Entra-ID också en DirSyncOverrides på objektet för att flagga att den här användaren har mobiltelefonnumret "skrivet" i Microsoft Entra-ID. Från och med nu ignoreras alla uppdateringar av det mobila attribut som kommer från den lokala miljön eftersom det här attributet inte längre hanteras av lokala AD.

    Mer information om funktionen BypassDirSyncOverrides och hur du återställer synkronisering av Mobile- och otherMobile-attribut från Microsoft Entra-ID till lokal Active Directory finns i Så här använder du funktionen BypassDirSyncOverrides i en Microsoft Entra-klientorganisation.

  • UserPrincipalName-ändringar uppdateras inte i Microsoft Entra-ID

    Om attributet UserPrincipalName inte uppdateras i Microsoft Entra-ID, medan andra attribut synkroniseras som förväntat, är det möjligt att en funktion med namnet SyncUpnForManagedUsers inte är aktiverad i klientorganisationen. Det här scenariot inträffar ofta.

    Innan den här funktionen lades till ignorerades alla uppdateringar av UPN som kom från lokalt efter att användaren etablerades i Microsoft Entra-ID och tilldelades en licens "tyst". En administratör måste använda MSOnline eller Azure AD PowerShell för att uppdatera UPN direkt i Microsoft Entra-ID. När den här funktionen har uppdaterats flödar alla uppdateringar av UPN till Microsoft Entra oavsett om användaren är licensierad (hanterad).

    Kommentar

    När den är aktiverad kan den här funktionen inte inaktiveras.

    UserPrincipalName-uppdateringar fungerar om användaren inte är licensierad. Men utan funktionen SynchronizeUpnForManagedUsers ändras UserPrincipalName när användaren har etablerats och tilldelas en licensierad som INTE uppdateras i Microsoft Entra-ID. Observera att Microsoft inte inaktiverar den här funktionen för kundens räkning.

  • Ogiltiga tecken och Interna ProxyCalc-tecken

    Problem med ogiltiga tecken som inte ger något synkroniseringsfel är mer besvärliga i attributen UserPrincipalName och ProxyAddresses på grund av den sammanhängande effekten i ProxyCalc-bearbetning som tyst tar bort värdet som synkroniseras från lokala AD. Den här situationen inträffar på följande sätt:

    1. Det resulterande UserPrincipalName i Microsoft Entra-ID:t blir den ursprungliga domänen MailNickName eller CommonName @ (at). I stället för John.Smith@Contoso.comkan till exempel UserPrincipalName i Microsoft Entra-ID bli smithj@Contoso.onmicrosoft.com eftersom det finns ett osynligt tecken i UPN-värdet från lokal AD.

    2. Om en ProxyAddress innehåller ett blankstegstecken tar ProxyCalc bort den och skapar en e-postadress automatiskt baserat på MailNickName i den ursprungliga domänen. "SMTP: John.Smith@Contoso.com" visas till exempel inte i Microsoft Entra-ID eftersom det innehåller ett blankstegstecken efter kolonet.

    3. Antingen orsakar ett UserPrincipalName som innehåller ett blankstegstecken eller en ProxyAddress som innehåller ett osynligt tecken samma problem.

      Om du vill felsöka ett ogiltigt tecken i UserPrincipalName eller ProxyAddress granskar du värdet som lagras i den lokala AD från en LDIFDE eller PowerShell som exporteras till en fil. Ett enkelt trick för att identifiera ett osynligt tecken är att kopiera innehållet i den exporterade filen och sedan klistra in det i ett PowerShell-fönster. Det osynliga tecknet ersätts med ett frågetecken (?), som du ser i följande exempel.

      Skärmbild som visar ett exempel för att felsöka UserPrincipalName eller ProxyAddress.

  • Attributet ThumbnailPhoto (KB4518417)

    Det finns en allmän missuppfattning att när du har synkroniserat ThumbnailPhoto från AD för första gången kan du inte längre uppdatera det, vilket bara är delvis sant.

    Vanligtvis uppdateras ThumbnailPhoto i Microsoft Entra-ID:t kontinuerligt. Ett problem uppstår dock om den uppdaterade bilden inte längre hämtas från Microsoft Entra-ID av respektive arbetsbelastning eller partner (till exempel EXO eller SfBO). Det här problemet orsakar det falska intrycket att bilden inte synkroniserades från lokal AD till Microsoft Entra-ID.

    Grundläggande steg för att felsöka ThumbnailPhoto

    1. Kontrollera att avbildningen är korrekt lagrad i AD och inte överskrider storleksgränsen på 100 kB.

    2. Kontrollera bilden i kontoportalen eller använd Get-AzureADUserThumbnailPhoto eftersom dessa metoder läser ThumbnailPhoto direkt från Microsoft Entra-ID.

    3. Om AD-miniatyrbilden (eller AzureAD)Photo har rätt bild men inte är korrekt på andra onlinetjänster kan följande villkor gälla:

    • Användarens postlåda innehåller en HD-bild och accepterar inte bilder med låg upplösning från Microsoft Entra thumbnailPhoto. Lösningen är att uppdatera användarens postlådebild direkt.
    • Användarens postlådebild uppdaterades korrekt, men du ser fortfarande den ursprungliga avbildningen. Lösningen är att vänta minst sex timmar för att se den uppdaterade avbildningen i Office 365-användarportalen eller Azure Portal.

Ytterligare resurser

Kontakta oss för att få hjälp

Om du har frågor eller behöver hjälp skapar du en supportförfrågan eller frågar Azure community support. Du kan också skicka produktfeedback till Azure-feedbackcommunityn.