Microsoft Entra ID · Microsoft Intune · Active Directory · .NET · Automation
Syncing Entra device attributes
Keep selected Entra device attributes in sync with AD and Intune, with explicit mappings and a worker that knows when Graph is asking it to slow down.
- Drafted
- Published
- Updated
- Reading time
- 4 min
- Author
- Roberto Gramellini
Source:
Extension Attributes Automation
· revision a40c4be1
- Entra extension attributes
- Intune device metadata
- Active Directory synchronization
- Microsoft Graph throttling
- Extension Attributes Automation
Syncing Entra device attributes
Sometimes you only need one small piece of device information next to the Entra object. The information exists, but one value is in on-premises Active Directory and another is in Intune. Keeping those attributes aligned by hand soon becomes a job in its own right. And an old value that looks perfectly reasonable can be worse than a blank field.
Extension Attributes Automation puts that recurring work in a .NET worker service. It maps selected AD and/or Intune values into Entra extension attributes. Scheduling, retries, diagnostics, notifications, health checks and a web dashboard surround the synchronization, so you have somewhere to look when a value is not what you expected.
Agree on the mapping first
Reading a property from AD or Intune is not particularly difficult. Deciding which source owns a target attribute, then applying that decision consistently, takes more care. This is especially true when both sources are involved. Two scripts writing the same field do not become a governance process just because both have a schedule.
Each configured mapping names the target extension attribute, source attribute and data source, with an optional regular expression and default value. The helper validates this before doing any processing. Duplicate target mappings are rejected; there is no quiet competition to see which source writes last. It then retrieves the Entra devices and processes the mappings with concurrency limited by a semaphore.
For me, the useful part is being able to read a mapping and understand the whole decision: take this source, extract this portion, use this fallback if it is missing. Choose that fallback carefully. "Unknown" may look untidy in a report, but it is more honest than a plausible value invented to make the report tidy.
Resilience when Graph says “not yet”
At some point Graph will ask the worker to slow down. A temporary 429 should not leave the attributes permanently out of date. The Graph-specific Polly policy honours Retry-After when supplied; otherwise it uses exponential backoff with jitter. Retry attempts are logged, which helps distinguish a slow synchronization from one that has stopped.
Code excerpt: honor the service's retry window
The abbreviated section below, from PollyPolicies.cs, shows the retry count and how the service's requested delay is used.
.WaitAndRetryAsync(
retryCount: 5,
sleepDurationProvider: (retryAttempt, outcome, context) =>
{
if (outcome.Result?.StatusCode == HttpStatusCode.TooManyRequests)
{
var retryAfter = outcome.Result.Headers?.RetryAfter;
if (retryAfter?.Delta.HasValue == true)
return retryAfter.Delta.Value;
}
var baseDelay = TimeSpan.FromSeconds(Math.Pow(2, retryAttempt));
return baseDelay.Add(TimeSpan.FromMilliseconds(Random.Shared.Next(0, 1000)));
});
The full policy also understands the HTTP-date form of Retry-After and handles transient HTTP failures, with warning logs. There is still a limit to the retries. Waiting politely gives temporary failures a chance to clear; it does not guarantee that a request will eventually succeed.
Components and data flow
For a controlled test, the worker can run in console mode; for recurring use, it can run as a Windows service. Quartz.NET schedules the jobs, and the helper layer keeps the AD, Intune and Entra interactions separate.
The dashboard shows operational status and device-processing functions. Health checks cover configuration and the connected directories/services, while notifications can bring failures to an operator. Otherwise the monitoring plan tends to become "someone will remember to open the log." We know how that meeting ends.
Before adopting it
Before enabling scheduled writes, check the target tenant, who owns each mapping, and whether the source values are actually reliable. Review Graph application permissions and where certificates or secrets are stored. I would start with a few mappings and a small test cohort, compare the source values with the resulting Entra objects, then read the audit trail.
Regular expressions and defaults deserve the same review as the source selection. They decide what ends up in the directory; they are not just convenient string handling.
The project is GPL-3.0 licensed; review its LICENSE and the repository before reuse. This article's implementation references are pinned to a40c4be. Automation can keep metadata in sync; it cannot decide whether the mapping is a good idea. That still requires an administrator.