HomeLessons Learned

Technical source document

Lessons Learned

Rendered from the retained public repository snapshot. Original wording and result boundaries are preserved.

Original GitHub document All documentation

Lessons Learned

Project Status

COMPLETE

Preserve Working Infrastructure

The existing Microsoft Entra Cloud Sync deployment was already functioning and did not need to be rebuilt.

A key operational lesson from this project was to validate the current state before making changes. The working agent, OU scope, Password Hash Synchronization, and existing synchronized users provided a known-good baseline.

Understand Cloud Sync Timing

Microsoft Entra Cloud Sync uses separate synchronization intervals for different functions.

Observed in this lab:

  • Users and Groups provisioning: 20 minutes
  • Password Hash Synchronization: 5 minutes

A newly created or modified directory object should not be treated as failed until the expected provisioning interval has been considered.

This distinction prevents unnecessary troubleshooting, restarts, or configuration changes.

Source of Authority Matters

For synchronized identities, on-premises Active Directory remained the authoritative source for the tested attributes.

Changes were made in Active Directory first and then validated in Microsoft Entra.

The source relationship was verified using:

  • Active Directory objectGUID
  • Base64 source-anchor conversion
  • Microsoft Entra on-premises immutable ID
  • Provisioning log source and target identifiers

Source Anchors Provide Strong Identity Correlation

The controlled user's Active Directory objectGUID was converted to its Base64 source-anchor representation.

That value matched the Microsoft Entra on-premises immutable ID and the provisioning-log source anchor.

This provided direct evidence that the cloud identity was linked to the intended on-premises AD object.

Password Hash Synchronization Is Independent of User Provisioning Timing

Password Hash Synchronization completed on a shorter cycle than Users and Groups provisioning.

Successful Microsoft Entra authentication after an on-premises password change provided practical proof that Password Hash Synchronization was functioning.

Group Synchronization Includes Membership Relationships

Creating a synchronized group is only part of group lifecycle validation.

This project also confirmed that:

  • The security group synchronized to Microsoft Entra
  • The user membership synchronized
  • Provisioning logs processed the membership relationship
  • The group Member property referenced the synchronized user's source anchor

Provisioning Logs Are Essential Troubleshooting Evidence

Provisioning logs provided visibility into:

  • Import from Active Directory
  • Scope evaluation
  • Provisioning into Microsoft Entra ID
  • Modified properties
  • Source IDs
  • Target IDs
  • Success or failure status

They were more useful for determining actual synchronization behavior than relying only on portal object visibility.

Service Running Does Not Mean Every Component Is Healthy

The provisioning agent service was Running while the event log still contained performance-counter errors.

Reviewing the agent event log identified a permissions issue affecting the metrics collector.

Adding the provisioning gMSA to the local Performance Log Users group resolved the registry-access error without reinstalling Cloud Sync.

Validate Commands in Their Correct Context

Test-ADServiceAccount returned False when executed on DC01 because the Cloud Sync gMSA was assigned for use by SYNC01.

The result demonstrated the importance of understanding what a validation command actually tests before interpreting its output as a failure.

Do Not Troubleshoot Normal Delay as an Outage

The group initially appeared missing from Microsoft Entra because a Users and Groups provisioning cycle had not yet completed.

The object eventually synchronized successfully after the expected Cloud Sync interval.

The main operational lesson is:

Confirm the synchronization schedule before escalating normal propagation delay into troubleshooting.

Portfolio Evidence Should Be Sanitized

Useful evidence includes:

  • AD object properties
  • OU scope
  • provisioning status
  • group membership
  • provisioning logs
  • source-anchor correlation
  • synchronization timestamps
  • agent health

Passwords, tokens, authentication secrets, private keys, and other credentials should never be included in portfolio evidence.