Van Entra Connect Sync naar Cloud Sync: wat de begeleide migratie meeneemt en wat achterblijft

Samantha Kloos-Kilkens
14-10-2026 · Samantha Kloos-Kilkens

Sinds Entra Connect Sync 2.6.91.0 zit er een taak "Transition to Cloud Sync" in de Connect-wizard, en Microsoft zet tenants in golven over. De tool is bewust smal en de meeste enterprise-omgevingen vallen erbuiten, dus deze blog gaat over de rest: welke Connect Sync-functies Cloud Sync anders of helemaal niet afhandelt, wat je eerst moet inventariseren, en hoe je de overstap zo inricht dat er een weg terug blijft.

Twee parallelle stalen bruggen over een rivier, van onderaf Foto: Getty Images via Unsplash

Wat Microsoft in september heeft uitgebracht

De begeleide migratie kwam mee met Connect Sync 2.6.91.0, uitgebracht op 16 september 2026 (een week later gevolgd door hotfix 2.6.92.0 voor een fout bij het registreren van de Pass-through Authentication-agent via de wizard). Er staat geen preview-label bij en de functie is alleen beschikbaar in de Azure public cloud. Het is de uitvoering van de plan-for-change die Microsoft in april in de What's new publiceerde: tenants krijgen per golf bericht via Message Center, Connect Health en e-mail, te beginnen met tenants waarvan Cloud Sync de configuratie nu al volledig ondersteunt.

De documentatie van de migratietool beschrijft de stappen. Je start hem op de actieve Connect-server (op een staging server werkt hij niet), meldt je aan als Hybrid Identity Administrator en geeft per forest Domain Admin-gegevens op, die de wizard gebruikt om de gMSA voor de provisioning agent in te richten. Daarna volgt een readiness review, installeert en registreert de tool de provisioning agent, maakt hij per domein in scope een Cloud Sync-configuratie aan die nog uitgeschakeld is, en vraagt hij je per domein Provision on Demand op een representatief object te draaien. Bij activatie wordt Cloud Sync ingeschakeld en gaat Connect Sync in staging mode. De validatiepagina vergelijkt precies één totaalgetal ("Total Objects") tussen beide engines plus de status van de jobs; Microsoft zegt er uitdrukkelijk bij dat individuele objecten, groepslidmaatschappen en writeback niet worden gecontroleerd. Connect Sync moet twee weken geïnstalleerd blijven als validatieperiode.

Lees de voorwaarden goed: één forest, maximaal 2.000 objecten in scope, OU-scoping op basis van insluiten met hooguit 30 geselecteerde containers per domein, en geen van de blokkerende functies (custom sync rules, group filtering, een afwijkende UPN, directory extensions, device synchronization, niet-ondersteunde writeback). Wat de tool overzet: user- en group-sync, password hash sync, password writeback, Exchange hybrid writeback en domein- en OU-scoping. Word je geblokkeerd en staat er toch een deadline in je notificatie, dan is de gedocumenteerde route een supportverzoek voor een tijdelijke uitzondering, met je readiness report en een migratieplan erbij. In de praktijk is de begeleide tool dus voor kleine, opgeruimde tenants, en komt de rest uit bij de handmatige route, waar de verschillen hieronder het plan bepalen.

Wat Cloud Sync anders afhandelt

Ik heb de vergelijkingstabel in de decision guide gebruikt zoals die er na de update van 6 oktober uitziet, samen met de tabel met ondersteunde scenario's. Die lijst is in de loop der jaren flink veranderd, dus kijk er opnieuw naar als je dit leest. Voor een gemiddelde enterprise-inrichting zijn dit de punten die ertoe doen:
  • Sync rules. De rule engine van Connect (precedence, join rules, scoping filters, transformaties met expressies) heeft geen tegenhanger; Cloud Sync werkt met attribute mappings en de expression builder. Reconciliatie buiten de normale cyclus om wordt ook niet ondersteund.
  • Filtering. OU-scoping werkt in beide. Filteren op attribuutwaarden is "Limited" volgens de decision guide en niet ondersteund volgens de scenariotabel; ga uit van de strengste lezing. Group-based filtering in Connect blokkeert de begeleide tool.
  • Schaal. Cloud Sync ondersteunt 150.000 objecten per AD-domein en groepen tot 50.000 leden, tegenover 250.000 leden in Connect.
  • Meerdere forests. Cross-forest references en het samenvoegen van attributen uit meerdere domeinen kan alleen in Connect, en de Exchange-topologie met een account forest en een resource forest staat ook als Connect-only. Bij disconnected forests loopt Cloud Sync juist voor.
  • Devices. Device sync voor hybrid join is eind september generally available geworden in Cloud Sync en moet je apart aanzetten, maar de begeleide tool ziet het nog als blokkade. Device writeback komt niet naar Cloud Sync, en de scenariotabel noemt Windows Hello for Business als Connect-only, wat ik lees als de certificate trust-inrichtingen die op device writeback leunen.
  • Authenticatie. Cloud Sync configureert geen PTA of AD FS. PTA en Seamless SSO blijven na de migratie werken en blijven volgens Microsoft beheerbaar via de configuratiewizard van Connect Sync. Gebruik je ze, dan verdwijnt Connect dus niet helemaal van je server.
  • Source anchor. Cloud Sync gebruikt ms-DS-ConsistencyGuid met objectGUID als fallback, en dat kun je op geen ondersteunde manier aanpassen (Cloud Sync FAQ). Een Connect-installatie die jaren geleden met een ander attribuut als sourceAnchor is ingericht, moet dat eerst oplossen.
Exchange hybrid-attributen, directory extensions, password writeback en group writeback v1 staan als ondersteund in beide. Let op het verschil bij directory extensions: het platform ondersteunt ze, maar de begeleide tool neemt ze niet mee.

Wat je vooraf inventariseert

Het eerste wat ik op papier wil hebben, is de set custom rules. Connect-servers verzamelen in de loop der jaren regels waarvan niemand meer weet wie ze heeft toegevoegd: een cloudFiltered-regel uit een opschoonproject, een gekloonde "In from AD - User Join" met een andere UPN-expressie, een JoinNoFlow-regel van een oude group writeback-migratie. Standaardregels hebben een ImmutableTag en custom rules niet, en daarop kun je betrouwbaar filteren: 
# Uitvoeren op de actieve Connect Sync-server
Import-Module ADSync

$connectors = @{}
Get-ADSyncConnector | ForEach-Object { $connectors[$_.Identifier] = $_.Name }

$rules = Get-ADSyncRule

# Custom rules: geen ImmutableTag
$rules | Where-Object { [string]::IsNullOrEmpty($_.ImmutableTag) } |
    Sort-Object Direction, Precedence |
    Select-Object Precedence, Direction, Name, LinkType, Disabled,
        SourceObjectType, TargetObjectType,
        @{ Name = 'Connector'; Expression = { $connectors[$_.Connector] } } |
    Export-Csv .\custom-sync-rules.csv -NoTypeInformation

# Uitgeschakelde standaardregels, meestal vervangen door een kloon
$rules | Where-Object { $_.ImmutableTag -and $_.Disabled } |
    Select-Object Precedence, Direction, Name
Per custom rule geeft Export in de Synchronization Rules Editor je de volledige PowerShell, inclusief scoping filters en transformaties; dat is wat je vertaalt naar Cloud Sync attribute mappings of bewust laat vallen. Exporteer daarnaast de complete configuratie via "View or Export Current Configuration" in de wizard. De documentatie over import en export wijst erop dat alleen wijzigingen via de wizard automatisch worden geëxporteerd; wat in de rules editor of met PowerShell is gedaan, ontbreekt in de JSON-bestanden in %ProgramData%\AADConnect totdat je zelf exporteert.

De tweede controle is de source anchor op groepen. De pilot-tutorial vermeldt dat Connect Sync ms-DS-ConsistencyGuid standaard niet vult voor groepen, terwijl Cloud Sync die nodig heeft voor de hard match: 
Get-ADGroup -Filter * -SearchBase 'OU=Pilot,DC=contoso,DC=com' -Properties 'mS-DS-ConsistencyGuid' |
    Where-Object { -not $_.'mS-DS-ConsistencyGuid' } |
    Select-Object Name, DistinguishedName
Zet daar je grootste groepen bij, het aantal objecten per domein, eventuele device writeback, en of PTA of federatie via de Connect-wizard is ingericht.

De migratie naast elkaar draaien

Blokkeert de tool, dan beschrijven de handmatige migratierichtlijn en de pilot-tutorial het coexistence-model: een inbound rule die cloudNoFlow op True zet voor de pilotscope en een outbound rule met link type JoinNoFlow die op cloudNoFlow filtert, voor users, groups en contacts. Twee details glippen er makkelijk doorheen. JoinNoFlow is geen read-only modus: het houdt het aanmaken en verwijderen van objecten en updates van gewone attributen tegen, maar wijzigingen in member en manager stromen gewoon door. En je haalt de pilot-OU of gerelateerde objecten tijdens de coexistence niet uit de scope van Connect Sync; dan verdwijnen de connector space-objecten en exporteert Connect het wegvallen van verwijzingen, wat je terugziet als groepslidmaatschappen die in Entra ID verdwijnen. Scope verwijderen doe je als laatste, per batch, als Cloud Sync aantoonbaar leidend is voor de objecten en hun verwijzingen.

Om na elke batch de aantallen te vergelijken gebruik ik gewoon Microsoft Graph PowerShell in plaats van het voorbeeldscript op de migratiepagina: 
Connect-MgGraph -Scopes 'User.Read.All'
$ou = 'OU=Pilot,DC=contoso,DC=com'
$synced = Get-MgUser -All -Filter 'onPremisesSyncEnabled eq true' `
    -Property id,userPrincipalName,onPremisesDistinguishedName
($synced | Where-Object { $_.OnPremisesDistinguishedName -like "*,$ou" }).Count

Een weg terug houden

Voor de handmatige route is de rollback gedocumenteerd: schakel de Cloud Sync-configuratie uit en zet de custom no-flow rules uit, wat een full sync op de connectors veroorzaakt. Voor de begeleide tool staat er geen rollbackprocedure op de pagina. De migratie-FAQ zegt dat terugdraaien kan omdat Connect in staging mode staat, terwijl de troubleshooting-tabel zegt dat je bij een mislukte activatie de herstelinstructies van de wizard volgt en de Cloud Sync-resources die de migratie heeft aangemaakt niet uitschakelt of verwijdert.

Ik behandel de periode van twee weken als een klassieke wissel van staging server en oefen die eerst in een testtenant: eerst de Cloud Sync-configuraties uitschakelen zodat er maar één engine exporteert, dan een initial sync cycle op Connect, de openstaande exports bekijken met csexport en CSExportAnalyzer, en pas dan staging mode uitzetten. Houd rekening met password hash sync: die gaat verder vanaf het laatste watermark als staging mode uitgaat, en na twee weken staging kan het inhalen uren duren. Recent gewijzigde wachtwoorden werken in die tijd nog niet in de cloud.

Twee andere deadlines die meelopen

MC1237727 (februari 2026) kondigde aan dat Connect Sync-versies onder 2.5.79.0 op 30 september 2026 zouden stoppen. Op 30 september, de dag van de deadline zelf, heeft Microsoft dat op de hardening-pagina verschoven naar 7 april 2027 (de MC-post zelf is niet bijgewerkt), en een dag later de lat hoger gelegd: de pagina vraagt nu 2.6.84.0 of hoger met application-based authentication. Zit je tenant niet in een vroege golf, dan upgrade je Connect dus nog voordat je ervan afstapt, en 2.6.92.0 bevat meteen de transitietaak.

De hard match-hardening geldt voor beide engines, ongeacht de clientversie: sinds 1 juli 2026 (het deel over beheerrollen was aangekondigd voor 1 juni) wordt een hard match geblokkeerd als bij het doelaccount al een onPremisesObjectIdentifier is ingevuld, of als het een privileged rol heeft of ervoor eligible is. Cloud Sync neemt bestaande objecten over via een hard match, dus gesynchroniseerde accounts met een privileged rol in je pilotscope test je expliciet. Het is ook een goede reden om de sync-migratie niet te combineren met een domeinherstructurering of forest-verhuizing.

Waar je begint

Draai deze week de inventarisatie van je rules op de actieve Connect-server, exporteer de configuratie, en kijk in Message Center en Connect Health of er al een melding over je golf is. Is de lijst custom rules leeg en zit je binnen de limieten, dan is de begeleide tool waarschijnlijk voor jou; zo niet, kies één pilot-OU en richt de no-flow rules eerst in een testomgeving in.

Update oktober 2026: Op 21 oktober heeft Microsoft de migratie-FAQ herschreven en de zin geschrapt dat je kunt terugdraaien; er staat nu alleen dat de tool Connect Sync in staging mode zet en dat Connect Sync tijdens de validatieperiode geïnstalleerd blijft. Zie de staging-wissel hierboven dus als je eigen terugvaloptie die je oefent, niet als ondersteunde rollback, en volg bij een mislukte activatie de herstelinstructies van de wizard.

Bronnen

Geschreven door een expert van Argus IT

Zo’n expert in je team, of zelf zo werken in security, IAM of cloud?

Neem contact op Werken bij Argus IT

Blijf op de hoogte

Schrijf je in voor onze nieuwsbrief en ontvang een seintje wanneer we een nieuw artikel publiceren of nieuws te delen hebben.