We value your privacy

We use cookies to analyse site traffic and improve your experience. You can accept all cookies or reject non-essential ones. See our Privacy Policy for details.

GR IT SERVICES
  • Contact
Get a quote
  2. Intune and endpoint management
  3. Remediations
Intune remediations, UAE

Recurring scripts only report every seven days unless something changes. Your dashboard is not stale, it is quiet.

Microsoft documents the cycle precisely: within the first six days the client reports only if something changed, and every seventh day it sends a report regardless. Knowing that stops a working remediation being investigated as a broken one.

Book a remediations design sessionSee how they work
Intune remediations for UAE organisations
  • 200Maximum script packages in a tenant
  • 8 hoursFixed policy retrieval interval
  • 2,048Maximum output characters per script
  • exit 1What triggers the remediation script
The shape of the tool

A detection script, a remediation script, and a rule about exit codes.

The whole model rests on one convention, and getting it wrong is the most common reason a remediation appears to do nothing.

  • Each script package consists of a detection script, a remediation script and metadata. The detection script decides whether there is a problem, and the remediation script is what runs when there is.
  • The convention is specific: a remediation script only runs if the detection script uses exit code exit 1, meaning the issue was detected. A detection script that reports a problem in its output but exits zero will never trigger the remediation.
  • Two documented rules save a lot of trouble. Do not put reboot commands in detection or remediation scripts, and do not include sensitive information such as passwords or any personal data in a script that will run across the estate.
  • The encoding requirement catches people too. Scripts should be encoded in UTF-8, and where Enforce script signature check is enabled they must be UTF-8 and not UTF-8 BOM, which is a difference most editors do not surface clearly.
What remediations do

Eight things that decide whether they fix problems or create them.

A remediation is two PowerShell scripts and some metadata, running repeatedly on every assigned device. That combination is powerful and unforgiving, which is why the documented constraints matter more here than in most Intune features.

Detect and fix, as one package

Each script package consists of a detection script, a remediation script and metadata. The remediation script only runs if the detection script exits with code 1, meaning the issue was detected. Any other exit code, including empty output, means the issue was not found and nothing runs.

The reporting cycle that looks like a failure

Recurring scripts follow a seven day reporting cycle. Within the first six days the client reports only if a change occurs, with the first run counting as a change. Every seven days it sends a report regardless. A quiet dashboard usually means nothing changed, not that nothing ran.

Policy retrieval on a fixed schedule

The client retrieves remediation policy after a device or Intune management extension restart, after a user signs in, and once every 8 hours. That 8 hour schedule is fixed based on when the management extension service starts, and user sign-ins do not alter it.

Schedule options, and the one constraint

Once at a specified date and time, hourly with a configurable interval that must be less than 24 hours, or daily at a specified time. Runs use the device local time by default with a Use UTC option, and a missed run happens as soon as the device is online again.

Encoding and signature rules that break scripts silently

Scripts must be encoded in UTF-8, and where Enforce script signature check is enabled they must be UTF-8 rather than UTF-8 with a byte order mark. Uploading a file rather than pasting into the browser is the recommended way to keep the encoding correct.

What signature enforcement actually changes

With signature check enforced, the script runs under the device PowerShell execution policy, which defaults to Restricted on Windows clients and RemoteSigned on Windows Server. Without it, scripts use Bypass. Built-in scripts are signed with their certificate added to the Trusted Publishers store.

Output limits and things not to do

The maximum allowed output size is 2,048 characters, so a verbose script loses its own diagnostic value. Microsoft also states directly not to put reboot commands in detection or remediation scripts, and not to include sensitive information, passwords or personal data in them.

On-demand execution, with a caveat

A remediation can be run on demand against a single Windows device, currently in preview, needing the Run remediation permission under remote tasks. Only one such action can be issued at a time per device, and several issued in quick succession can overwrite each other.

The behaviour that wastes an afternoon

A recurring remediation reports only on change, until day seven.

Microsoft documents the cycle precisely, and it explains almost every case where a working remediation is reported as broken.

  • When a script is set to run once, results are reported after it runs. Recurring scripts behave differently: within the first six days the client reports only if a change occurs, with the first execution counting as a change, and every seven days it sends a report even when nothing changed.
  • So a device that was detected, remediated and is now healthy stops appearing in fresh results until the seventh day comes round. That reads as a device that stopped checking in, and it prompts an investigation into something that is functioning exactly as designed.
  • Policy retrieval has its own rhythm and it is not the same one. The client retrieves remediation policy after a device or management extension restart, after a user signs in, and once every 8 hours, and that 8 hour schedule is fixed from when the management extension service starts rather than reset by sign-ins.
  • The practical consequence is patience during a pilot. A newly assigned remediation may take up to 8 hours to be retrieved before it runs at all, and then its ongoing results follow the seven day reporting rhythm. Testing on a shorter cadence than that produces conclusions the data cannot support.
Ask us to design the schedule properly
How we approach it

Four principles for scripts that run unattended on every device.

The risk profile here is unusual. A remediation is code you are not watching, running on machines you cannot see, repeatedly. Everything below follows from taking that seriously.

We make detection precise before we make remediation clever

The remediation script only runs when the detection script exits with code 1, and any other exit code including empty output means the issue was not found. A detection script that is imprecise either fixes machines that were fine or ignores machines that are not, and both are worse than no automation.

We pilot across a full seven day cycle

Recurring scripts report only on change within the first six days and unconditionally on the seventh. A three day pilot produces a partial picture that looks like a failure, and the temptation is to change the script rather than wait for the reporting rhythm to complete.

We write remediations to be safely repeatable

Scripts rerun every 24 hours and detection runs on the schedule you set, so a remediation is not a one-time action. Microsoft also advises against reboot commands in either script, which rules out the tempting shortcut for anything that would normally require one.

We upload scripts rather than pasting them

Microsoft recommends uploading rather than editing directly in the browser specifically to keep encoding correct, and where signature check is enforced the file must be UTF-8 rather than UTF-8 with a byte order mark. Encoding failures do not announce themselves, they just do not work.

How an engagement runs

Four phases across roughly four to five weeks.

The pilot phase is deliberately longer than it feels it should be, because the reporting cycle means a shorter one cannot produce trustworthy evidence.
  1. 01
    Week 1

    Confirm eligibility and pick the right problems

    Devices must be Entra joined or hybrid joined, and either MDM enrolled running Windows Enterprise, Professional or Education, or co-managed. Licensing must be in place. Then the more useful question: which recurring support tickets are actually detectable and fixable by a script.

    • Device eligibility and edition coverage confirmed
    • Licensing verified before first use
    • Recurring ticket themes analysed for candidates
    • Built-in packages assessed as a starting point
  2. 02
    Week 2

    Write detection carefully, remediation conservatively

    Detection scripts must exit 1 only when the issue genuinely exists, because any other code means nothing runs. Remediation scripts should be idempotent and contain no reboot commands, no credentials and no personal data, all of which Microsoft states explicitly.

    • Detection logic written and exit codes validated
    • Remediation scripts written to be safely repeatable
    • Output kept within the 2,048 character limit
    • Scripts saved as UTF-8 and uploaded rather than pasted
  3. 03
    Weeks 3 to 4

    Pilot across a full reporting cycle

    Deployed to a small device group and left for at least a full seven day reporting cycle, since within the first six days the client reports only on change. Anything shorter produces a picture that looks incomplete because it is, not because anything failed.

    • Pilot assignment to a controlled device group
    • Schedule chosen and UTC decision recorded
    • Results observed across a full seven day cycle
    • Output exported to CSV and reviewed
  4. 04
    Week 5

    Broaden and hand over the operational model

    Wider assignment, on-demand execution permissions granted where the service desk will use it, and a review rhythm so packages are retired when the underlying problem is fixed rather than accumulating toward the 200 package limit.

    • Production assignment completed
    • Run remediation permissions granted where needed
    • Review cadence agreed for retiring packages
    • Runbook covering reporting and retrieval timings
Where this pays off

Six problems remediations are genuinely good at.

The pattern is a recurring, detectable, script-fixable condition that generates tickets. Microsoft ships two built-in packages that show the shape exactly.

Stale Group Policy causing connectivity tickets

One of the two built-in script packages is Update stale Group Policies, and Microsoft notes stale policies lead to helpdesk tickets about connectivity and internal resource access. It needs only assigning, which makes it a reasonable first deployment while the team learns the mechanism.

Office applications failing to start

The other built-in package restarts the Office Click-to-run service, because when that service is stopped Office applications fail to start and generate calls. Both built-ins are signed with their certificate in the Trusted Publishers store, so signature enforcement is not an obstacle.

A security setting that keeps drifting back

Where a configuration keeps reverting because of a legacy application or a user action, detection plus remediation restores it on a schedule. That is a compensating control rather than a fix, and it should be recorded as such, but it closes a real gap in the meantime.

An operator with devices nobody can reach easily

Site machines and remote equipment generate the most expensive tickets because somebody has to travel. A remediation that detects and fixes the common failure before anybody notices removes that trip entirely, which is where the return is largest.

A regulated firm evidencing configuration consistency

Per device status with exportable output gives evidence that a specific condition was checked across the estate and corrected where found. That is a stronger position than a policy stating the setting should be correct, because it shows what actually happened.

A service desk that wants a fix button

Run remediation on demand lets an agent run a known-good script package against a single device during a call, in preview, provided the device is online and reachable by Intune and the notification service. That converts a fifteen minute walkthrough into one action.

Three positions

How UAE organisations handle recurring endpoint problems.

The right column is the default state, and its cost is invisible because it is spread across every technician a few minutes at a time.
Problem fixed before the user notices
Remediations, designedOften
Ad hoc scriptsNo
Fixed by the service deskNo
Detection separated from action
Remediations, designedYes
Ad hoc scriptsRarely
Fixed by the service deskNot applicable
Runs on a schedule
Remediations, designedOnce, hourly or daily
Ad hoc scriptsWhen run
Fixed by the service deskOn a ticket
Reporting on effectiveness
Remediations, designedPer device status and export
Ad hoc scriptsNone
Fixed by the service deskTicket counts
Safe to run repeatedly
Remediations, designedDesigned to be
Ad hoc scriptsUnknown
Fixed by the service deskNot applicable
On-demand execution possible
Remediations, designedYes, preview
Ad hoc scriptsYes
Fixed by the service deskYes
Consistent across the estate
Remediations, designedYes
Ad hoc scriptsNo
Fixed by the service deskNo
Technician time per occurrence
Remediations, designedNone
Ad hoc scriptsSome
Fixed by the service deskFull ticket
Auditable
Remediations, designedYes
Ad hoc scriptsNo
Fixed by the service deskPartly
Scales with device count
Remediations, designedYes
Ad hoc scriptsNo
Fixed by the service deskNo
Feature
Remediations, designed
Ad hoc scripts
Fixed by the service desk
Problem fixed before the user notices
OftenNoNo
Detection separated from action
YesRarelyNot applicable
Runs on a schedule
Once, hourly or dailyWhen runOn a ticket
Reporting on effectiveness
Per device status and exportNoneTicket counts
Safe to run repeatedly
Designed to beUnknownNot applicable
On-demand execution possible
Yes, previewYesYes
Consistent across the estate
YesNoNo
Technician time per occurrence
NoneSomeFull ticket
Auditable
YesNoPartly
Scales with device count
YesNoNo
The documented constraints

Ten limits and rules worth knowing before you write a script.

Each of these is published, and each has a failure mode that looks like something else when you hit it without knowing it exists.
ConstraintThe rule
Number of script packagesUp to 200 in a tenant
Trigger for the remediation scriptDetection script must exit 1
Any other exit codeTreated as issue not found, including empty output
Script encodingUTF-8, and not UTF-8 BOM where signature check is enforced
Maximum output size2,048 characters
Hourly schedule intervalMust be less than 24 hours
Custom script rerun frequencyEvery 24 hours
Policy retrievalOn restart, on sign in, and every 8 hours fixed
Reboot commands in scriptsExplicitly advised against
Group assignmentDo not mix user and device groups across include and exclude
How an engagement runs

Five steps, and the candidates come from your ticket data.

The best remediation ideas are already in your service desk queue. Picking them from there rather than from a list of clever scripts is what makes the return real.
  1. 1

    Confirm eligibility and licensing

    Devices Entra joined or hybrid joined, and either MDM enrolled running Windows Enterprise, Professional or Education, or co-managed. Licensing through Windows Enterprise E3 or E5, Education A3 or A5, or Virtual Desktop Access per user, confirmed by an Intune Service Administrator before first use.

  2. 2

    Choose candidates from recurring tickets

    Themes that repeat, are detectable by script, and are fixable by script without a reboot. The two built-in packages are a useful calibration for the shape of a good candidate, and assigning one of them is a low risk way to prove the mechanism works in your estate.

  3. 3

    Write and validate the scripts

    Detection exiting 1 only when the issue genuinely exists, remediation safe to run repeatedly, output within 2,048 characters, no reboot commands, no credentials or personal data, and everything encoded as UTF-8 and uploaded rather than pasted into the browser.

  4. 4

    Pilot across a full reporting cycle

    Assigned to a controlled device group with the schedule and the UTC decision recorded, then left for at least seven days so the reporting cycle completes. Output exported to CSV and reviewed, because that is where an imprecise detection script reveals itself.

  5. 5

    Broaden and set the operating rhythm

    Production assignment, on-demand permissions where the service desk will use them, and a review cadence that retires packages once the underlying problem is fixed, so the estate does not drift toward the 200 package limit carrying scripts nobody remembers.

Straight answers

What organisations ask about Intune remediations.

Most likely it has not. Recurring scripts follow a seven day reporting cycle: within the first six days the client reports only if a change occurs, with the first run counting as a change, and every seven days it sends a report regardless. A healthy device simply goes quiet in between.

The client retrieves policy after a device or Intune management extension restart, after a user signs in, and once every 8 hours. That 8 hour schedule is fixed from when the management extension service starts, and user sign-ins do not reset it, so it can take that long before anything happens.

Almost certainly the detection exit code. The remediation script only runs if the detection script exits with code 1. Any other exit code means the issue was not found, and that includes an empty output, which is the case people most often overlook when writing a first detection script.

Yes, renamed. Proactive Remediations is now Remediations, found under Devices, Manage devices, Scripts and remediations. The old name still appears in blogs and older articles, which occasionally makes searching for guidance more confusing than it needs to be.

Up to 200. That is generous for most organisations and worth tracking anyway, because packages accumulate as problems are solved and rarely get retired. A review cadence that removes packages whose underlying issue has been fixed keeps the list meaningful.

Users of the devices need Windows Enterprise E3 or E5, which is included in Microsoft 365 F3, E3 or E5, or Windows Education A3 or A5 included in Microsoft 365 A3 or A5, or Windows Virtual Desktop Access per user. An Intune Service Administrator confirms this before first use.

Microsoft advises against it directly, stating not to put reboot commands in detection or remediation scripts. For issues that genuinely need a restart, the remediation should put the machine into the correct state and leave the restart to your normal update or notification mechanism.

The maximum allowed output size limit is 2,048 characters. A verbose script that writes progress messages loses the diagnostic value it was trying to provide, so output should be concise and structured rather than conversational, particularly for scripts you intend to export and analyse.

Microsoft recommends No in its documented settings guidance, and the reason is behavioural. With enforcement on, the script runs under the device execution policy, which defaults to Restricted on Windows clients and RemoteSigned on Windows Server. Without it, scripts use Bypass.

Encoding, most likely. Microsoft recommends uploading scripts rather than editing them directly in the browser precisely to keep encoding correct, and where signature enforcement is on, the file must be UTF-8 rather than UTF-8 with a byte order mark.

Yes, in preview, against a single Windows device. It needs the Run remediation permission under remote tasks, the device online and able to reach Intune and the Windows Push Notification Service, and the Intune Management Extension installed, which happens automatically once any Win32 app, script or remediation is assigned.

No. Only a single Run remediation device action can be issued at a time for the same device, and several issued in a short period can overwrite each other. For a support call that means one action, observed, before considering another.

Once for a one-time fix, daily for most recurring checks, hourly only where the problem genuinely recurs within a day and the interval must be less than 24 hours. Microsoft also advises less frequent schedules for nonurgent or resource-heavy scripts to reduce performance effects on the device.

Either, and Microsoft is explicit about one rule: do not mix user and device groups across include and exclude assignments. Filters are also supported for narrowing the target, which is usually a cleaner way to scope than building another group.

We scope by the number of script packages and how much validation each needs. The free first step: look at your last three months of tickets and find the three most repeated issues. If any of them is detectable and fixable by a script, you already have your first candidate.

Schedule options are Once, Hourly with an interval that must be less than 24 hours, and Daily. Custom script packages are rerun every 24 hours, and clients retrieve policy after a restart, after a user signs in, and once every eight hours.

Recurring scripts follow a seven day reporting cycle. Within the first six days the client reports only if a change occurs, with the first run counting as a change, and every seven days the client sends a report even when nothing changed.
Before you deploy a script

Fifteen checks that prevent an awkward rollback.

A remediation runs unattended, repeatedly, on every assigned device. That is exactly why the review before deployment deserves more care than the script itself.

Eligibility

  • Are devices Entra joined or hybrid joined?
    One of the two is required.
  • What Windows edition are they on?
    Enterprise, Professional or Education.
  • Do users hold a qualifying licence?
    Enterprise E3 or E5, Education A3 or A5, or VDA.
  • Has an Intune Service Administrator confirmed licensing?
    Required before first use.
  • How many packages do we already have?
    The limit is 200.

Script safety

  • Does detection exit 1 only when the issue exists?
    Nothing else triggers remediation.
  • Is the remediation safe to run repeatedly?
    It will run again.
  • Any reboot commands in either script?
    Advised against explicitly.
  • Any credentials or personal data?
    Also advised against.
  • Is output under 2,048 characters?
    Beyond that it is truncated.

Deployment

  • Are scripts UTF-8 and uploaded, not pasted?
    Encoding breaks silently.
  • Is signature check enforced deliberately?
    It changes the execution policy used.
  • Have we mixed user and device groups?
    Do not, across include and exclude.
  • Is the schedule under 24 hours if hourly?
    A stated constraint.
  • Are we testing across seven days?
    The reporting cycle needs it.
Related reading

The pages around this one.

Intune endpoint analytics

The wider analytics surface remediations reporting sits alongside.

Learn more

Win32 app packaging

The other place Intune runs code you wrote on managed devices.

Learn more

Intune configuration profiles

Settings delivery, and the first thing to try before a script.

Learn more
Next step

Find the three most repeated issues in your last three months of tickets.

If any of them is detectable by a script and fixable without a reboot, it is a remediation candidate. That is the whole qualifying test, and your ticket queue already contains the answer.

Book a remediations design sessionCall +971 56 613 2743

Related Services

Explore more solutions that work great with this service

Intune Device Query

Ask the device instead of taking the screen

Learn more

Endpoint Analytics

Measured device experience, and the refresh evidence

Learn more

Win32 App Packaging

Packaging, detection rules and deployment that works

Learn more

Intune Configuration Profiles

Settings catalog, templates and conflict management

Learn more

Intune Suite

Eight advanced capabilities, and one trial each per tenant

Learn more

Intune Remote Help

Remote support scoped by role, with both parties authenticated

Learn more

MDM Solutions Dubai

Device management across Windows, Apple and Android

Learn more

Microsoft Intune

Device management and endpoint security

Learn more
GR IT SERVICES

Leading IT services provider in Dubai,
delivering enterprise-grade solutions
for businesses across the UAE.

Microsoft CSP PartnerCISGuard

Get the Helpdesk app

Raise and track IT tickets from your phone.

Download on the App StoreGet it on Google Play
Learn more about the app

Microsoft 365

  • Microsoft 365 Administration
  • M365 Reporting & Auditing
  • Microsoft 365 Licensing
  • Microsoft Copilot
  • Microsoft 365 Apps
  • Windows 365 Cloud PC
  • Microsoft SharePoint
  • Outlook & Exchange

Security

  • Microsoft Defender
  • Microsoft Purview
  • Microsoft Intune
  • Microsoft Entra
  • Compliance Manager
  • Cybersecurity Audits
  • Copilot for Security
  • Microsoft Sentinel
  • Microsoft Priva

Infrastructure

  • Google Workspace
  • Cloud Migration Services
  • Data Analytics & BI
  • Active Directory
  • Server Management
  • Apple Business
  • Apple Jamf Pro
  • IP Telephone
  • Data Backup
  • Website Development

IT Services

  • Managed IT Services
  • IT Support Dubai
  • IT AMC Dubai
  • New Office IT Setup
  • IT Relocation
  • Remote IT Support
  • On-Call IT Support
  • Startup IT Business Kit
  • Disaster Recovery & BC

Company

  • About Us
  • Careers
  • Contact
  • Blog

Contact

  • Iris Bay Tower, Office 903,
    Business Bay, Dubai, UAE
  • +971 56 613 2743
  • hello@gritservices.ae
  • gritservices.ae

© 2026 GR IT Services. All rights reserved.

Privacy PolicyTerms of UseCookie Policy