Bulk Update User Profile Attributes (e.g., City) via Microsoft Graph

Directory profile attributes such as city, department, officeLocation, and country drive a surprising amount of downstream behavior in Microsoft 365: address book segmentation, dynamic group membership rules, Viva Insights aggregations, SharePoint profile cards, and conditional access named locations. When these fields are stale, empty, or inconsistent, reports look broken and automation misfires.

This recipe walks through a repeatable pattern for bulk-updating a single user attribute across every member account in the tenant. The working example sets city to a target value (e.g., Iasi) for all employees, but the same pattern applies to any writable property on the user resource.

When to run this

• Office relocation or new HQ address rollout
• HRIS sync drift — directory fell out of step with system of record
• Preparing attributes for a new dynamic group or Conditional Access rule
• One-time cleanup after a merger, acquisition, or rebrand

After completing this recipe you will have:

• A filtered list of member users (excluding guests) whose attribute does not yet match the desired value
• The target attribute (e.g., city) updated to a single consistent value on every targeted account
• A success/failure log suitable for change-management tickets and audit review
• A reusable script you can re-run for other attributes (department, officeLocation, country, state, etc.)

⚠️ Warnings & Gotchas

• Filter by userType eq 'Member' — otherwise you will stamp guest accounts (B2B collaborators from partner tenants) with your internal city, which is incorrect and visible in their home tenant's profile card.
• Service/shared/room accounts may not logically have a city. Consider additional exclusions for accounts matching naming conventions like svc-*, room-*, or accounts with no assigned license.
• Hybrid / directory-synced users: if your on-premises Active Directory is the source of authority (AAD Connect syncing the l attribute), changes made in the cloud will be overwritten on the next sync cycle. Update the on-prem AD attribute instead, or block the attribute from sync.
• Throttling: Microsoft Graph enforces per-app and per-tenant limits. For tenants with more than ~500 users, add a small delay between calls or use $batch (up to 20 requests per batch) to avoid HTTP 429 responses.
• No bulk undo. Always capture the current value for each user before writing, so you can roll back if the change is wrong.
• Dynamic groups whose membership rule references the attribute you are updating will reprocess membership — this can trigger license assignment changes, Conditional Access scope changes, and mail distribution changes. Review rules first.