Felsökning från slutpunkt till slutpunkt för Microsoft Entra Connect-objekt och attribut

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 lätt att gå vilse i informationen om det inte finns något uppenbart fel. Men genom att använda metodtips kan du isolera problemet och ge 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ök 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.

Stegen som anges här börjar på lokal Active Directory-nivå och förlopp mot Microsoft Entra ID. De här stegen är den vanligaste synkroniseringsriktningen. Samma principer gäller dock för inverteringsriktningen (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 kopplingar och ursprung för ett objekt.

• Microsoft Entra Connect: Konton och behörigheter
• Felsöka ett objekt som inte synkroniseras med Microsoft Entra ID
• Felsöka objektsynkronisering med Microsoft Entra Connect Sync

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!"

Obs!

Azure AD- och MSOnline PowerShell-modulerna ä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 den 30 mars 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. Observera: Version 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 serverdelså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 har slutförts. När du har återaktivera DirSync måste AADC också 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 några 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 stoppa endast 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 Connector-konto
AADCS	Microsoft Entra kopplingsutrymme
AADCS:AttributeA	Attributet "A" i Microsoft Entra-kopplingsutrymme
Åtkomstkontrollistor	Access Control Listor (kallas även ADDS-behörigheter)
ADCA	AD Connector-konto
ADCS	Active Directory-anslutningsutrymme
ADCS:AttributeA	Attributet "A" i Active Directory Connector Space
ADDS eller AD	Active Directory Domain Services
CS	Kopplingsutrymme
MV	Metaverse
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.

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 sägs när data mellanlagras i anslutningsprogrammets utrymme. 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 Directory Services DirSync Control 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 för tidpunkt 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 inte har importerats från AD. Alla data mellan AD och AADC överförs via LDAP och krypteras som standard.

Om anslutningen till AD lyckas, men objektet eller attributet inte finns i ADCS (förutsatt att domänen eller objektet är i synkroniseringsomfånget), gäller 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 användar-, grupp- och datoregenskaper. 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äcklig behörighet 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 synkroniserings-Service Manager 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.

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

Anslutningsproblem till ADDS har följande orsaker:

• Ogiltiga AD-autentiseringsuppgifter. Adca har till exempel upphört att gälla eller så har lösenordet ändrats.
• Ett "failed-search"-fel, som inträffar när DirSync Control inte kommunicerar med AD Replication Service, vanligtvis på grund av fragmentering av högnä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, hög fragmentering av nätverkspaket, inga skrivbara domänkontrollanter tillgängliga och så vidare. I sådana fall måste du förmodligen involvera katalogtjänsterna eller nätverkssupportteamen 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.

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 med "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 behörigheter som "nekar". 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

  

• Alla

  

• Anpassat ADCA- eller MSOL-konto

  

• Pre-Windows 2000-kompatibel åtkomst

  

• Själv

  

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

Viktigt

Det kan vara svårt att felsöka AD-behörigheter eftersom en ändring i ACL:er inte börjar gälla omedelbart. Tänk alltid på att sådana ändringar är föremål för 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-replikeringen har inträffat.
• 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 Connector .
• 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 objektet eller attributet som misslyckas.
• Lägg tillfälligt till ADCA till företagsadministratörer eller domänadministratörer och starta om ADSync-tjänsten.

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

• När du har kontrollerat 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.
• Engage 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 hjälp av fördröjd replikering importeras inte den senaste informationen från AD, vilket orsakar synkroniseringsproblem där ett objekt eller attribut som nyligen har skapats eller ändrats i AD inte synkroniseras till Microsoft Entra ID eftersom det inte replikerades till domänkontrollanten som Microsoft Entra Anslut 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-användar- och datorkonsolen 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 är konsekventa med respektive ADCS-data. I det här skedet genererar AADC en större belastning på domänkontrollanten och nätverksskiktet.

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

  

• Objektmetadata från alla domänkontrollanter:

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

  

• Sammanfattning av AD-replikering

  repadmin /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 filtreringen av domänen eller organisationsenheten bekräftas börjar alla ändringar av 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-anslutningsappens konfiguration

  Den här situationen inträffar inte lika ofta 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:

  

  Obs!

  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 Connector.

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

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

  

  Obs!

  Det går inte att inkludera eller exkludering av objekttyper eller attribut i synkroniserings-Service Manager.

Felsökningssammanfattning

• Kontrollera funktionen Microsoft Entra app- och attributfiltrering
• Kontrollera att objekttypen ingår i ADCS.
• Kontrollera att attributet ingår i ADCS.
• Kör en fullständig import.

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

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 (eller LocalDB) och nätverksskikt.

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.

  Om du vill hämta en lista över regler för inkommande etableringssynkronisering kör du följande kommando:

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

  

• Kontrollera ursprunget för ADCS-objektet

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

  

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

  Välj Förhandsversion>Generera förhandsversionAvförhandsgranskning> 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.

  

  

• 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 förhindrar att objektet 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 inkommande etableringsregler för "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 synkroniseringsregler Editor.

   

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 du etablerar eller ansluter till synkroniseringsregler) som 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.

   

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

   

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.

   

4. Köra 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örhandsgranskning med hjälp av Generera förhandsgranskning och Incheckningsförhandsgranskning för en fullständig synkronisering av objektet. Om attributet uppdateras i MV och har en förhandsgranskning bör en fullständig synkroniseringscykel åtgärda problemet för andra objekt i samma situation.

5. Exportera objektet till XML

   Om du vill ha 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 i objektet 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 ursprunget för objektet.
• Kontrollera om synkroniseringsregler har aktiverats.
• Kontrollera omfångsfiltren för synkroniseringsreglerna 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 synkroniseringsregler 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 Service Manager
• Synkroniseringsregler Editor
• Export-ADsyncObject skript
• Start-ADSyncSyncCycle -PolicyType Initial
• ETW-spårning Av SyncRulesPipeline (miiserver.exe.config)

Steg 3: Synkronisering mellan MV och AADCS

Mål för steg 3

Det här steget kontrollerar om objektet eller attributet flödar från MV till AADCS. Se nu till 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å 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 synkroniseringsreglerna 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 för att 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.

   Om du vill hämta en lista över regler för inkommande etableringssynkronisering kör du följande kommando:

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

   

2. Kontrollera ursprunget för ADCS-objektet

   Om du vill hämta det felande 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 flik för synkroniseringsfel.

   

   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 som synkroniseringsregeln bidrar till med värdet cloudFiltered .

3. Köra en förhandsgranskning på AADCS-objekt

   Välj Förhandsgranska>Generera förhandsversion>Genomför 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

   Om du vill ha 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 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 "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 attributet 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 synkroniseringsregler Editor.

   

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 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 på AADCS-objektet kan du avgöra om synkroniseringsregeln har tillämpats på 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öra en förhandsgranskning på AADCS-objekt

   Om du tar reda på varför synkroniseringsregeln saknas i ADCS-objektets ursprung kör du en förhandsgranskning som använder Generera förhandsgranskning 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 "Exportera ADSyncObject" tidigare).

Felsökningssammanfattning för attribut

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

Felsöka pipelinen för synkroniseringsregeln

Om du behöver felsöka ADSync-motorn (även kallad MiiServer) när det gäller bearbetning av synkroniseringsregler 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 Service Manager
• Synkroniseringsregler Editor
• Export-ADsyncObject skript
• Start-ADSyncSyncCycle -PolicyType Initial
• ETW-spårning Av SyncRulesPipeline (miiserver.exe.config)

Steg 4: Synkronisering mellan AADCS och AzureAD

Mål för steg 4

I det här steget jämförs AADCS-objektet med respektive objekt som etableras 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)
• Den Microsoft Entra gatewayen framför DirSync-webbtjänsten (även kallad AdminWebService-slutpunkten)
• DirSync-webbtjänst-API:et
• Katalogtjänsten Microsoft Entra Core

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ända attributvärden fram och tillbaka finns det fler än en aktiv Microsoft Entra Anslut 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äller synkroniseringsmotorn den ändringen 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 till 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 Admin 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 även 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 attributet som kommer från den lokala miljön eftersom det här attributet inte längre kommer att 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 lokalt efter att användaren etablerades i Microsoft Entra ID och tilldelade 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).

  Obs!

  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 kommer att 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 genererar något synkroniseringsfel är mer besvärliga i attributen UserPrincipalName och ProxyAddresses på grund av den sammanhängande effekten i ProxyCalc-bearbetningen 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 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 blanksteg tar ProxyCalc bort den och skapar automatiskt en e-postadress baserat på MailNickName i den initiala domänen. "SMTP: John.Smith@Contoso.com" visas till exempel inte i Microsoft Entra ID eftersom det innehåller ett blanksteg efter kolonet.

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

     Om du vill felsöka ett ogiltigt tecken i UserPrincipalName eller ProxyAddress undersöker du värdet som lagras i den lokala AD från en LDIFDE eller PowerShell som exporteras till en fil. Ett enkelt sätt 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.

     

• Attributet ThumbnailPhoto (KB4518417)

  Det finns en allmän missuppfattning om 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 delvis är sant.

  Vanligtvis uppdateras ThumbnailPhoto i Microsoft Entra ID 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 ger ett falskt intryck av att bilden inte har synkroniserats 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 på att se den uppdaterade avbildningen i Office 365-användarportalen eller Azure Portal.

Ytterligare resurser

• Felsöka fel under synkronisering
• Felsöka objektsynkronisering med Microsoft Entra Connect Sync
• Felsöka ett objekt som inte synkroniseras med Microsoft Entra ID
• Microsoft Entra Anslut enstaka objektsynkronisering

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.