Cloud Policy Preferences
26 of the 27 targeting items came with you.
Group Policy Preferences filters every preference item with item-level targeting: 27 targeting items plus a nestable Targeting Collection, combined with And and Or and negated with Is Not. Most of it assumes an on-premises Active Directory. This is what each one becomes on an Entra ID joined, Intune-managed device — and what it costs the device to ask.
Conditions ship with V2.0
Conditions are built and evaluated in the development portal and device API today, and they ship to everybody with Cloud Policy Preferences V2.0. Everything on this page is the mapping as it stands in the project's own reference document, including the parts that are specified but not yet running.
Two things are worth knowing before you read the table. Conditions decided by the service work on the client that is already deployed — there is nothing to change on a device. Conditions that only the device can answer are stored, validated and delivered today, but nothing evaluates them until the 2.0 client ships, and every row that needs it is marked.
The directory it assumed is gone.
Item-level targeting is the single most useful thing Group Policy Preferences does. It is also the part most firmly attached to a domain. LDAP Query needs a directory to query. Organizational Unit needs an OU tree. Site needs Active Directory Sites and Services. Domain needs domain membership. Security Group means an AD group with a Kerberos token.
An Entra ID joined, Intune-managed device has none of those. It has an Entra directory, an Intune device record, and itself. So every targeting item was mapped to something a cloud-only device can genuinely be filtered on, rather than dropped or faked. Twenty-six of the twenty-seven have an equivalent. One does not: PCMCIA Present is the only item dropped outright, as obsolete hardware.
What came out of that exercise is a catalogue of 95 condition properties. Sixty-four are decided by the service at check-in — from the directory and Intune objects it already holds, plus its own clock and run context; thirty-one are read on the device itself. The operators deliberately copy Intune assignment filters — equals, is one of, starts with, contains, is at least, has a value and the rest — so an administrator who has written an Intune filter already knows the grammar, with is in range added for the IP and MAC ranges assignment filters have no equivalent for.
Four rules, applied in order.
Nothing is in the catalogue because it was easy to add. Each property had to pass one of these.
Every targeting item, and what replaces it.
Where a row names two things, the service decides what it can from the directory and the device refines it — live free space rather than the last Intune sync, the actual chassis rather than the reported one, device-local time rather than UTC.
| Group Policy Preferences item | What replaces it on a cloud-native device | Where it is decided |
|---|---|---|
| Battery Present | Whether a battery is present, read from WMI | Device · 2.0 client |
| Computer Name | The device name on the Intune record; the computer name on the device | Service Device · 2.0 |
| CPU Speed | The processor's maximum clock speed | Device · 2.0 client |
| Date Match | Date and day of week on the service clock in UTC; date and day of week in the device's own local time | Service Device · 2.0 |
| Dial-up Connection | Connection type instead: VPN connected, media type, network profile (Domain, Private, Public) and whether the connection is metered | Device · 2.0 client |
| Disk Space | Free and total storage from Intune, as of the last sync; free space on the system drive, read live on the device | Service Device · 2.0 |
| Domain | The tenant is already enforced, so what is left is the join: the Entra trust type (Entra joined, on-premises AD joined, workplace joined) and the Intune join type; on the device, the join state from dsregcmd and the AD domain name for a hybrid device | Service Device · 2.0 |
| Environment Variables | A named variable in machine or user scope, compared on its value | Device · 2.0 client |
| File Match | A path, and the file version behind it | Device · 2.0 client |
| IP Address Match | The IPv4 address of any adapter, against a CIDR block or a start and end address | Device · 2.0 client |
| Language | The user's preferred language and usage location; on the device, the system locale, the user's locale and the installed language packs | Service Device · 2.0 |
| LDAP Query | The attributes an LDAP filter was usually written against, read straight from Entra: department, job title, office location, city, state, country, usage location, company, employee type, preferred language and more — plus the device's category, enrolment profile, ownership and extension attributes 1 to 15 | Service |
| MAC Address Range | The Wi-Fi and Ethernet MAC addresses on the Intune record, with a start and end range; any adapter's MAC on the device | Service Device · 2.0 |
| MSI Query | An installed application by display name or product code, read from the Uninstall keys — never Win32_Product, which triggers a repair | Device · 2.0 client |
| Operating System | Operating system, OS version compared numerically, build number, and Windows edition; on the device, the product type (workstation, server, domain controller), the edition name, the release such as 24H2 and the processor architecture | Service Device · 2.0 |
| Organizational Unit | Administrative unit membership — a different object with the same intent, a delegated subset of the directory. Device category and extension attributes are the alternatives | Service |
| PCMCIA Present | Dropped. Obsolete hardware, and the only item with no replacement | Dropped |
| Portable Computer | Chassis type from Intune; on the device, the chassis type or PC system type read from WMI | Service Device · 2.0 |
| Processing Mode | Nearest useful equivalent, not the same semantics: whether a user is signed in, and on the device the run context — signed in, no user, or Autopilot pre-provisioning | Service Device · 2.0 |
| RAM | Physical memory from Intune, as of the last sync; physical memory read live on the device | Service Device · 2.0 |
| Registry Match | A key and optional value name under HKLM or HKCU, compared on the value data, or simply tested for existence | Device · 2.0 client |
| Security Group | Entra group membership, resolved transitively on both the user and the device, so nested groups behave the way a token does. Include or exclude | Service |
| Site | No cloud equivalent, so the intent is met instead: the user's office location or usage location, or an IP range on the device | Service Device · 2.0 |
| Terminal Session | Session type on the device, console or RDP; and Windows 365 Cloud PC detection from the service | Service Device · 2.0 |
| Time Range | Time of day on the service clock in UTC; time of day in the device's own local time | Service Device · 2.0 |
| User | The user assignment itself, plus patterns on the user principal name — ends with @contoso.com and the like | Service |
| WMI Query | A single read-only SELECT of at most 512 characters, against an allow-list of namespaces, compared on a named property | Device · 2.0 client |
| Targeting Collection, And / Or, Is Not | The rule tree: up to twenty conditions, nested up to three levels deep, every rule and every group negatable | Service Device · 2.0 |
Read the marks honestly. Service means decided at check-in today, with no change to the device. Device · 2.0 means the portal stores and validates the rule and the service delivers it to the device, but nothing evaluates it until the 2.0 client ships — until then a device applies the item without checking that part. Storage and memory values from Intune are as of the device's last sync, which may be hours old, which is exactly why both tiers carry disk and memory. Windows edition, chassis type, join type, processor architecture, Autopilot enrolment and scope tags come from the Graph beta endpoint and are tagged as such in the portal; Cloud PC detection is a heuristic on the model name, not a dedicated field.
A catalogue this big, and the device barely notices.
Conditions were designed backwards from the device: as much as possible decided by the service, as little as possible asked of the endpoint.
No client change at all
Every condition in the service tier is decided at check-in, before anything is sent. The device receives the policies it should have and never learns a rule was evaluated — including the 1.x client already deployed across your estate.
Nothing added to a check-in
Five Graph calls happen anyway, to work out assignment. Conditions read the objects those calls already returned, so they add nothing to a check-in — unless a policy uses one of the handful of properties that need their own lookup, and then only for that policy.
No new permission
Conditions introduce no new Graph permission. The four the platform already needs to validate a device, resolve the signed-in user and work out group membership are the same four that feed every service-tier property.
Two tiers, and why the split exists
The property's prefix decides the tier. Device, user, group, administrative unit, context and time properties are the service tier. Everything read from the machine itself is the device tier.
At check-in the service walks the rule tree and decides everything it can. What is left is pruned out and forwarded to the device inside the policy item. If the service rules alone rule the policy out, it is withheld and nothing reaches the device. If service rules pass and device rules remain, the item is delivered carrying the residual tree. If nothing remains, the item is delivered exactly as it always was. That is what lets a catalogue this large arrive with no client change for the service tier.
What the client actually is
The 2.0 client is a versioned PowerShell module installed once as an Intune Win32 app, plus one Intune remediation carrying two thin scripts — about forty lines each, five to ten kilobytes, that check the module is present and hand over to it. The module carries no URL, no key and no tenant identifier, so the same package is built once and used by every tenant; only the two thin scripts are tenant-specific, and the portal injects those two values as it does today.
The scripts pin a minimum module version, never an exact one, so a module update rolling out over Intune's app sync never breaks the package an administrator uploaded. A device that does not have the module yet says so plainly in the Intune remediation report and changes nothing on the machine.
The efficiency work
The service and the 2.0 client are designed to make an ordinary hour cost almost nothing. This part is the plan the project has written down and is building — it is not live yet:
- The device checks every time, and an unchanged answer costs a few bytes. The service hands out a stamp with each payload and the client presents it on the next check. When nothing has moved the reply carries no body at all — nothing rebuilt, nothing downloaded — and the device evaluates the copy it already holds.
- Results are reported when they change, not every hour. A health and compliance report once a day is the floor; anything that actually moved — an error, or a policy applying for the first time — goes sooner in a small report of just the entries that changed.
- The script never sleeps and never blocks. Intune runs remediation packages one after another on a device, so a script that waits holds up everything behind it. When the service is not ready for a device it says so and the device leaves; the next scheduled run is the retry.
- Remediation reuses what detection just fetched. Intune runs remediation minutes after a non-compliant detection, on the same device, for the same policies. There is no reason to ask twice.
The thirty-one device properties are configurable, validated and delivered today, and nothing checks them until the 2.0 client ships. A 1.x client that receives an item carrying device conditions applies it rather than withholding it — a deliberate decision, because withholding the policy instead would look like a delivery failure. The portal counts those rules and warns you whenever one is saved.
672,672 ways to configure one policy item.
Not a marketing number. This is the shape of a single policy item before a single value has been typed into it, counted from the catalogue the portal and the service share.
| Factor | Count |
|---|---|
| Setting types | 7 |
| Actions per type — create, replace, update, delete | 4 |
| Behaviour options, availability varying by type and action | 4 |
| Type, action and behaviour combined | 286 |
| Assignment shapes | 3 |
| Property and operator pairs for one condition | 783 |
| Distinct configurations of one policy item | 672,672 |
The arithmetic. Type, action and behaviour give 286, not 7 × 4 × 16, because remove when no longer applied and apply once are withheld with delete, and run in the user's context exists only on the four types that touch a user context. A policy is assigned to a single user, to an Entra group, or to a group narrowed by an exclusion list, so 286 × 3 = 858. Each of those can carry no condition at all or any one of 783 property-and-operator pairs, so 858 × 784 = 672,672.
And that is the floor. Two conditions instead of one — 858 × 783 × 783 — passes half a billion, and a policy may carry up to twenty conditions nested three levels deep, each of them negatable with Is Not and grouped with And or Or. The count deliberately leaves out the values themselves, and leaves out the free-text ordering field, which is a number an administrator types: including it would make the total infinite, and an infinite number says nothing.
Seven policy types. Half a million configurations. One remediation. Zero servers.
Condition properties
Sixty-four decided by the service from objects it already holds, thirty-one read on the device itself.
Of 27 targeting items
Every Group Policy Preferences targeting item bar PCMCIA Present has a cloud equivalent.
Client changes needed
The service tier decides at check-in, on the client already deployed, with no new Graph permission.
Bring the targeting with you.
Sign in with the Entra ID account you already have and put your first policy on a device today.
Launch the portal