TenuVaultDesktopPractical guide
How to test Intune changes before production
Test an Intune change by applying it to a small pilot first, either a pilot group in your production tenant or a separate development tenant, and only then widening it. Back up before every change so you can roll back. With a development tenant, promote the tested policy to production deliberately rather than rebuilding it by hand, and review the difference before it is written. TenuVault Pro and MSP promote policies from a development tenant to production through a reviewed change set with a backup first and a rollback.
At a glance
- Intune has no built-in staging area: a saved policy change reaches every assigned device at its next check-in.
- Pilot groups and deployment rings limit who receives a change first; assignment filters can narrow it further.
- A separate development tenant isolates tests completely, but its policies have to be moved to production afterwards.
- TenuVault Dev to Prod promotes Settings Catalog, compliance, endpoint security and device configuration policies from a development tenant to production on Pro and MSP.
- Promotion plans read both tenants and write nothing; production is backed up before apply, secrets are never copied and a rollback change set is available.
Test in production with pilot rings
The common approach is to test inside the production tenant. Create the new or changed setting as a separate policy, assign it to a small pilot group of IT staff and a few willing users, watch device status and support tickets, then widen the assignment in rings.
Keep the pilot policy separate from the policy everyone has until the test passes, because editing the live policy reaches every assigned device at its next check-in. Take a backup before you start, so you can put the original back if the change misbehaves.
Test in a development tenant
A separate tenant isolates tests completely: nothing you do there reaches production users. The cost is that the tested policy then has to get into production, and rebuilding it by hand invites mistakes. Group IDs, assignment filters and scope tags are different in each tenant, and secret values such as certificates or passwords do not transfer.
Move the policy deliberately: compare it with what production has, map its tenant-specific references, review the difference and keep a way back.
Promote from development to production with TenuVault
TenuVault's Dev to Prod promotes selected policies from a development tenant into production, one way and on demand. It supports Settings Catalog policies, compliance policies, endpoint security policies and device configuration profiles, up to 25 at a time.
- Choose the source tenant and the policies, and for each one whether to create a new policy or update a named production policy. A matching name never picks the target for you.
- Planning reads both tenants and writes nothing. Blocked items show why, and tenant-specific references such as groups, filters and scope tags are mapped explicitly.
- New policies are created unassigned by default, and assignments are promoted only if you include them after reviewing their mapped groups and filters. Secret values are never promoted.
- The change set is reviewed against the live production tenant, approved and applied. Production is backed up first, and a rollback change set reverses the apply.
Practice the way back
A test plan is only as good as its rollback. Practice restoring a policy from backup before you need it, and record how long it takes and what you had to fix by hand, such as assignments.
Read the technical guides
Product scope reviewed . Check your installed release and the current plan table before using a workflow.
Frequently asked questions
Does Intune have a test or staging mode for policies?+
No. A saved policy change reaches every assigned device at its next check-in. Test by creating the change as a separate policy for a pilot group, or in a separate development tenant, before changing the policy everyone has.
Do I need a separate test tenant for Intune?+
Not always. Pilot groups and rings in production are enough for many changes. A development tenant isolates risky tests completely, but then you need a reliable way to move tested policies to production.
How do I copy a tested policy from a dev tenant to production?+
Export it from the development tenant and import it into production, then remap groups, filters and scope tags and set secret values again. TenuVault Pro and MSP do this with Dev to Prod: plan, review against production, apply with a backup first and roll back if needed.
Are assignments copied when promoting a policy to production?+
Not by default in TenuVault. New policies are created unassigned, and assignments are included only when you choose to after reviewing the mapped groups and filters.