A setting drifts back. A technician fixes it. It drifts again. Without a baseline, every fix is a guess about what "right" looked like.
TenantVigil turns that into a comparison: the versioned baseline against what Microsoft returns now. This article walks through the steps, in order, and keeps the preview and deployment stages separate.
Record the desired configuration
Start with a baseline template. A partner admin creates and versions it through the API route, then reviews the customer assignment. There is no template editor in the portal.
A template is immutable once created. That matters: the comparison has a fixed reference. If you want a new reference, create a new version instead of editing the old one.
A baseline is your intended configuration. It is not an automatic repair policy. It does not change a customer tenant by itself.
Compare observed settings
The next scan compares observed settings with the baseline. The product checks safety conflicts before deployment and leaves unknown inputs unknown.
The comparison is a review step. It shows what differs and what cannot be read. A source that did not return is shown as not read, never as passing.
Work from the diff. A large diff is a plan for a conversation, not a reason to start changing everything at once.
Read not read and fail as different facts
A drift diff can show three things: a setting matches, a setting differs, or a source could not be read.
Keep the last two separate. A check that could not be read is not evidence that the setting is wrong. A check that differs from the baseline is not automatically unsafe. It is a difference to review.
When you present drift to a customer, use the same separation. "This setting changed" and "we could not read this setting" lead to different next actions.
Keep the baseline small enough to maintain
Start with the settings you actually support. A baseline that lists every possible control is hard to review and easy to ignore.
Add settings when your team can own the follow-up. A baseline with no owner for its drift is a wish list, not an operating target.
Preview a change before deployment
A preview stays visibly a preview. The product shows Nothing is sent to Microsoft for a preview stage. Do not relabel a preview as a deployment.
Use the preview to check the exact target and the approval path. When the plan looks right, move it toward approval.
See Review desired state and drift for the difference between preview and deployment.
Stage canaries and rings
Deployments use canaries and rings. Start with one customer or one small group, review the result, then widen the ring.
Write the ring order down before you start. For example: one pilot customer, then three customers, then the rest of the assigned group. Review the receipt after each ring before the next one.
Executable rings are limited to CIS-1.1.1 report-only administrator-MFA canaries, with each customer's Microsoft consent and separate provider approval. Ordinary Conditional Access, security-defaults and Intune selections remain manual changes your team applies.
The execution path is limited to supported changes. TenantVigil only reads your Microsoft 365 tenant. It never changes a setting: you apply each fix yourself. Each native change still needs its own Microsoft permission grant and callback registration.
Do not promise unattended self-healing. The product compares drift and stages supported changes; it does not repair every drifted setting automatically.
Run the comparison on a schedule
Drift review works best when it repeats. Compare each customer on the same schedule you use for scans, and keep the comparison short enough to finish.
A recurring review catches the setting that drifted back after the last fix. A one-time baseline catches nothing later.
Assign the comparison to a named owner. If nobody owns the review, the baseline becomes a document instead of an operating target.
What a good baseline contains
A good baseline names the settings your service actually manages. For each setting, it should be clear who approves a change, who runs it and what the receipt should show.
It should not list every setting in Microsoft 365. A shorter baseline that your team owns beats a complete one that nobody reviews.
When a customer asks why a setting is in the baseline, point to the customer's own requirement. The baseline is the record of that decision, not a substitute for it.
Own the follow-up
Drift links to owned service work and reports. Assign unresolved drift to a technician instead of leaving it in a shared list.
Later scans can keep the line from a verified canary through its plan, receipt and owned case. That line is what a customer report should show: what drifted, what you planned, what Microsoft returned, and what remains open.
Include drift in the customer report
Reports are built from stored scan results, so the data-as-of time is visible. Use that to show the customer what changed and what you did about it.
Keep the report factual. Show the baseline, the observed difference and the receipt states. Do not turn an Applied; not verified result into a green check mark.
See Prepare a customer service report for the report workflow.
What to do next
Pick one customer. Create one baseline version, run the comparison, and read the drift diff before you plan any change. Then work one supported change from preview through approval and its receipt.
If the first comparison shows more drift than you can fix this week, own the top items and report the rest as open work. A baseline is most useful when it tells the truth about what still needs attention.