What is IT AMC in Dubai and why do businesses need it?

IT AMC (Annual Maintenance Contract) in Dubai is a comprehensive service agreement for maintaining all IT equipment and systems. Businesses need IT AMC for predictable costs, 24/7 support, preventive maintenance, reduced downtime, and expert technical assistance. It's the most affordable way to ensure reliable IT operations.

How much does IT AMC cost in Dubai?

IT AMC pricing in Dubai depends on the number of devices and users, the coverage tier (remote, on-site, or hybrid), the response-time SLA, and whether servers, network, and cybersecurity are included. We scope every contract to your environment and provide a fixed monthly quote on request, so you get predictable costs with no per-incident surprises.

What is included in managed IT services in Dubai?

Our managed IT services in Dubai include complete IT infrastructure management, 24/7 monitoring and support, cybersecurity, cloud services, backup and disaster recovery, help desk support, network management, and proactive maintenance. It's a complete IT department solution with affordable monthly pricing.

What is the response time for IT support in Dubai?

GR IT Services operates a priority-tiered response SLA for managed and AMC clients: 5 minutes for P1 critical issues, 10 minutes for P2 high-priority tickets, and 30 minutes for P3 medium-priority tickets. We provide 24/7 coverage across all Dubai areas.

Which areas in Dubai does GR IT Services cover?

We provide IT AMC and managed IT services across all Dubai areas including Dubai Internet City, Business Bay, Downtown Dubai, DIFC, Dubai Marina, JLT, Sheikh Zayed Road, Dubai Silicon Oasis, Bur Dubai, and Deira. We also serve Abu Dhabi, Sharjah, Ajman, Ras Al Khaimah, and Fujairah with complete IT support.

Why is GR IT Services the best IT company in Dubai?

GR IT Services is the best IT company in Dubai because we offer affordable prices, reliable 24/7 support, a 5-minute response SLA for critical issues (10 minutes for high-priority, 30 minutes for medium), complete IT solutions, certified Microsoft Partner status, continuous service since 2022, and 68+ satisfied clients. We provide the best IT AMC and managed IT services in Dubai with guaranteed SLA.

Microsoft Sentinel analytics rules, UAE

Move to the Defender portal and your Microsoft security rules are automatically disabled.

Microsoft states it plainly, and it catches teams mid-migration. Defender XDR creates the incidents instead, which is the correct outcome, but a rule set that silently loses two of its types deserves to be understood before the move rather than after.

Book a detection rule review See the rule types

Microsoft Sentinel analytics rules for UAE organisations

7 typesRule and template types available
Once a minuteHow often near real time rules run
No alertsAnomaly rules write to a table instead
Auto disabledMicrosoft security rules, after the portal move

What the rule types do

Eight things that decide whether your detections work.

Sentinel has seven rule and template types and they behave very differently. Three cannot be customised, one produces no alerts at all, and two stop being available the moment you adopt the unified Defender portal.

Scheduled rules, which is most of your rule set

By far the most common type, based on Kusto queries running at regular intervals against raw data from a defined lookback period, producing an alert when results pass the configured threshold. The query logic is visible in the rule, which means it can be read, understood and tuned.

Near real time rules and what they cost

A limited subset of scheduled rules designed to run once every minute, to supply information as up to the minute as possible. They function mostly like scheduled rules with some limitations, so they are a targeted tool rather than a default for everything urgent.

Anomaly rules, which deliberately do not alert

They use machine learning to observe behaviour over a period and set a baseline, then flag occurrences outside it. Crucially they do not generate their own alerts. They record detected anomalies in the Anomalies table, which you query to add context to detections, investigations and hunting.

Tuning anomalies through flighting

Out of the box anomaly rule configurations cannot be changed or fine-tuned. What you can do is duplicate a rule, tune the duplicate, and run it in Flighting mode while the original runs concurrently in Production, then compare results and promote the duplicate when the tuning is right.

Two rule types that disappear on the Defender portal move

Microsoft security rules and Advanced multistage attack detection are not available if you have enabled Defender XDR incident integration or onboarded Sentinel to the Defender portal. Defender XDR creates the incidents instead, and any such rules defined beforehand are automatically disabled.

The rules you cannot edit but should enable

Microsoft Threat Intelligence Analytics is not customisable and matches CEF logs, Syslog data or Windows DNS events against domain, IP and URL threat indicators. Fusion is enabled by default with hidden logic and only one instance. ML Behavior Analytics, in preview, detects anomalous SSH and RDP login behaviour.

The permission trap in multi-tenant deployments

A rule normally carries an access token so it keeps working even if its creator loses access. The exception is rules accessing workspaces in other subscriptions or tenants, where the creator credentials are used instead, so the rule stops working when that person loses access.

Rules as code, through ARM templates

Rules export to an Azure Resource Manager template for management and deployment as code, and import from template files to be viewed and edited in the interface. For organisations with more than one workspace, that is how a rule set becomes consistent rather than hand-built twice.

The failure that only affects service providers and groups

A cross-tenant rule stops working when the person who created it loses access.

Microsoft documents an exception to the normal permission model, and it matters most in exactly the environments least able to notice.

Normally an access permissions token is applied to the rule and saved with it, so the rule keeps reaching its workspace even if the creator loses access. That is the behaviour everybody assumes, and for single-tenant deployments it is correct.
For rules created to access workspaces in other subscriptions or tenants, which is the managed service provider and multi-entity group case, Microsoft applies the credentials of the user who created the rule instead of an independent token. When that user loses access, the rule stops working.
The symptom is a health monitoring message about insufficient access to resource, and the rule is auto-disabled after failing a certain number of times. So a departing engineer can silently disable a set of detections weeks after leaving, with no obvious connection between cause and effect.
The mitigation is process rather than configuration: create cross-tenant rules under an account that persists rather than an individual, monitor rule health explicitly, and treat leaver processes for security engineers as including a rule ownership check.

Ask us to audit rule ownership

How we approach it

Four things that make a rule set worth having.

The measure of a detection rule set is not how many rules are enabled. It is whether an analyst reads the alerts, and that is decided almost entirely by how many of them turn out to be nothing.

We reduce noise before we add coverage

A rule producing alerts nobody actions is worse than no rule, because it teaches the team that the console is not worth reading. Tuning thresholds, scoping to relevant assets or retiring a rule outright all improve detection more than adding a new rule to the pile.

We check for rules that disabled themselves

Cross-tenant rules use the creator credentials rather than an independent token, so they stop working when that person loses access, producing an insufficient access to resource health message and auto-disabling after repeated failures. Nobody connects a leaver in March to missing detections in June.

We use anomaly rules for what they are

They do not generate alerts. They write detected anomalies to the Anomalies table for querying, to provide context that improves detections, investigations and threat hunting. Teams that enable them expecting alerts conclude they do not work, and teams that query the table get real value.

We put the rule set under source control

Rules export to ARM templates and import back from template files. That makes the set reviewable, deployable across workspaces and recoverable, and it turns detection engineering into something with a change history rather than a portal somebody edited last Thursday.

How an engagement runs

Four phases across roughly six weeks.

Most Sentinel estates have too many rules, too many of them noisy, and gaps where nobody looked. The sequence below addresses the noise before the gaps, because a noisy console hides everything else.

01
Week 1
Inventory the rules and their health
Every enabled rule with its type, its source tables, its alert volume and its health state. Auto-disabled rules identified specifically, since cross-tenant rules can disable themselves when a creator loses access without anybody connecting the two events.
- Full rule inventory by type and source table
- Alert volume per rule over a representative period
- Auto-disabled and failing rules identified
- Rules created by departed staff flagged
02
Weeks 2 to 3
Reduce the noise before adding anything
Rules generating high volumes of alerts nobody actions are worse than no rule, because they train people to ignore the console. Tuned, thresholded, scoped or retired, with the decision recorded so it does not get quietly reversed.
- High volume low value rules identified
- Tuning applied with thresholds and exclusions
- Rules retired where tuning cannot help
- Noise reduction measured against the baseline
03
Week 4
Find the gaps and fill them from templates
Microsoft strongly encourages using analytics rule templates from Content Hub solutions, written by security experts based on known threats and attack chains. Installing the solution for a connected source brings its rules, which beats writing detection from scratch.
- Connected sources without detection coverage identified
- Content Hub solutions installed for those sources
- Templates activated and scoped
- Anomaly rules enabled and their table queried for context
04
Weeks 5 to 6
Make it maintainable and portal ready
Rules exported to ARM templates so the set is deployable and reviewable as code, ownership moved off individuals where cross-tenant access is involved, and the Defender portal transition planned including the rules that will be auto-disabled by it.
- Rules exported as ARM templates for source control
- Cross-tenant rule ownership moved off individuals
- Defender portal impact on rule types documented
- Rule health monitoring established

Where this matters

Six situations where the rule set needs work.

The most common symptom is an analyst who closes alerts in bulk, which is a rational response to a rule set nobody has tuned.

A business whose analysts stopped reading alerts

The clearest signal that tuning is overdue. Alert fatigue is not a training problem, it is a rule quality problem, and the fix is measuring which rules produce alerts nobody actions and then tuning or retiring those specific rules rather than exhorting people to try harder.

An organisation moving to the Defender portal

Microsoft security rules and Advanced multistage attack detection are not available once Defender XDR incident integration is enabled or Sentinel is onboarded to the Defender portal, and existing rules of those types are automatically disabled. Knowing that before the move avoids a confusing week afterwards.

A managed service provider or multi-entity group

Cross-subscription and cross-tenant rules carry the creator credentials rather than an independent access token. In an environment where engineers rotate between accounts and customers, that is a recurring cause of silently disabled detections that nobody attributes correctly.

A regulated firm evidencing detection coverage

The question is which threats you detect and how you know. A rule set mapped to connected sources, exported as ARM templates and with health monitoring in place answers that concretely, where a portal screenshot of enabled rules does not.

An operator ingesting sources with no detection on them

Paying to ingest a log source that no analytics rule queries is cost without benefit. Installing the Content Hub solution for that source brings its rule templates, which is both cheaper and faster than writing detection logic from scratch for a source you already have.

A company building a detection engineering practice

Exporting rules to ARM templates and importing them back is what makes detection engineering a discipline rather than a series of portal edits. It also allows a rule to be reviewed before it goes live, which is where most tuning problems could have been caught.

Three positions

How UAE organisations run Sentinel detection.

The middle column is where most deployments settle: rules enabled during the original project, never tuned, producing alerts that a tired analyst learned to close without reading.

Alert volume manageable

Tuned and maintainedYes

Enabled at deploymentVariable

Templates activated broadlyNo

Alerts actually actioned

Tuned and maintainedMost

Enabled at deploymentSome

Templates activated broadlyFew

Rules tuned rather than ignored

Tuned and maintainedYes

Enabled at deploymentNo

Templates activated broadlyNo

Coverage gaps identified

Tuned and maintainedYes

Enabled at deploymentNo

Templates activated broadlyAssumed absent

Anomaly context used

Tuned and maintainedQueried in hunting

Enabled at deploymentUnused

Templates activated broadlyUnused

Rule health monitored

Tuned and maintainedYes

Enabled at deploymentNo

Templates activated broadlyNo

Rules under source control

Tuned and maintainedARM templates

Enabled at deploymentNo

Templates activated broadlyNo

Cross-tenant ownership safe

Tuned and maintainedYes

Enabled at deploymentUnknown

Templates activated broadlyUnknown

Defender portal impact known

Tuned and maintainedDocumented

Enabled at deploymentUnknown

Templates activated broadlyUnknown

Analyst trust in the console

Tuned and maintainedHigh

Enabled at deploymentModerate

Templates activated broadlyLow

Feature	Tuned and maintained	Enabled at deployment	Templates activated broadly
Alert volume manageable	Yes	Variable	No
Alerts actually actioned	Most	Some	Few
Rules tuned rather than ignored	Yes	No	No
Coverage gaps identified	Yes	No	Assumed absent
Anomaly context used	Queried in hunting	Unused	Unused
Rule health monitored	Yes	No	No
Rules under source control	ARM templates	No	No
Cross-tenant ownership safe	Yes	Unknown	Unknown
Defender portal impact known	Documented	Unknown	Unknown
Analyst trust in the console	High	Moderate	Low

The seven types

What each rule type does, and whether you can change it.

Customisability is the practical dividing line. Three of these are things you enable and leave alone, and knowing that stops people trying to tune them.

	Type	What it does
Scheduled	Kusto query on an interval against a lookback period	Yes, fully
Near real time	A limited subset of scheduled rules, running once a minute	Yes, with limitations
Anomaly	Machine learning baseline, writes to the Anomalies table	Only via a duplicate in flighting mode
Microsoft security	Creates incidents from other Microsoft security alerts in real time	Yes, but unavailable on the Defender portal
Threat intelligence	Matches CEF, Syslog and Windows DNS events against indicators	No
Fusion	Correlates low-fidelity alerts into high-fidelity incidents	No, and only one instance
ML behavior analytics	Anomalous SSH and RDP login behaviour, in preview	No
Generates its own alerts	All except anomaly rules	Anomalies go to a table
Enabled by default	Advanced multistage attack detection	Others require activation
Affected by the Defender portal move	Microsoft security and Fusion	Both auto-disabled

How an engagement runs

Five steps, and the first two are subtraction.

Almost every Sentinel deployment we assess has too many rules and too little tuning. Removing and adjusting comes before adding, because coverage added to a noisy console is coverage nobody sees.

1
Inventory rules with volume and health
Every enabled rule with its type, source tables, alert volume and health state. Auto-disabled and failing rules identified explicitly, including cross-tenant rules whose creator has lost access, since those fail with an insufficient access message that rarely reaches anybody.
2
Measure which alerts get actioned
Volume is not the right measure, action is. A rule producing many alerts that analysts consistently close as benign is the one to tune, and a rule producing few alerts that always matter is the one to protect from well-meaning consolidation.
3
Tune, scope or retire
Thresholds adjusted, scoping applied to relevant assets, exclusions added where a known benign pattern dominates. Where tuning cannot make a rule useful, retirement with a recorded reason, so the same rule is not re-enabled by the next person who reviews coverage.
4
Close the gaps from templates
Connected sources with no detection identified, and the corresponding Content Hub solutions installed so their rule templates arrive alongside workbooks and playbooks. Microsoft strongly encourages template use, and the templates were written by people with more threat data than any single organisation has.
5
Make it maintainable
Rules exported to ARM templates for source control, cross-tenant rule ownership moved off individual accounts, rule health monitored so failures surface, and the Defender portal transition planned including the two rule types it disables.

Straight answers

What organisations ask about Sentinel analytics rules.

Four main types, scheduled, near real time, anomaly and Microsoft security rules, plus three specialised template types that each create one instance with limited configuration: threat intelligence, advanced multistage attack detection known as Fusion, and machine learning behavior analytics.

Once every minute, by design, to supply information as up to the minute as possible. Microsoft describes them as a limited subset of scheduled rules that function mostly like them with some limitations, so they suit specific high urgency detections rather than being a general default.

Because they are not supposed to. Anomaly rules do not generate their own alerts. They record the detected anomalies in the Anomalies table, which you query to provide context that improves your detections, investigations and threat hunting. Teams expecting alerts conclude they are broken.

Not directly. The configurations of out of the box rules cannot be changed or fine-tuned. You duplicate the rule, tune the duplicate, run it in Flighting mode while the original runs concurrently in Production, compare results, and switch the duplicate to Production once the tuning is right.

Microsoft security rules and the Advanced multistage attack detection rule type are not available once you enable Defender XDR incident integration or onboard Sentinel to the Defender portal. Defender XDR creates the incidents instead, and any such rules defined beforehand are automatically disabled.

Not in itself, because Defender XDR takes over incident creation for those cases. It is a change in where incidents come from, and the risk is procedural: teams that do not know it is coming spend time investigating why rules disabled themselves during a migration that was otherwise going well.

If it accesses a workspace in another subscription or tenant, most likely because its creator lost access. Those rules use the creator credentials rather than an independent access token, so they stop working, generate a health message about insufficient access to resource, and auto-disable after failing repeatedly.

Create cross-tenant rules under an account that persists rather than an individual, monitor rule health so failures surface promptly, and include a rule ownership check in the leaver process for security engineers. It is a process fix rather than a configuration one.

Rarely as a first move. Microsoft strongly encourages using the analytics rule templates available through Content Hub solutions, which were designed by security experts and analysts based on known threats, common attack vectors and suspicious activity escalation chains, and many can be customised.

Microsoft Threat Intelligence Analytics is not customisable, and when enabled it automatically matches Common Event Format logs, Syslog data or Windows DNS events against domain, IP and URL threat indicators from Microsoft Threat Intelligence. It is a high value rule to have on and nothing to tune.

The Advanced multistage attack detection rule, which correlates many low-fidelity alerts and events across products into high-fidelity actionable incidents. It is enabled by default, its logic is hidden and not customisable, and there can be only one rule using that template.

Export them to Azure Resource Manager templates and manage them as code, importing from template files when you want to view and edit in the interface. That is also how a rule set becomes reviewable and recoverable rather than existing only as portal state.

Microsoft now describes custom detections as the best way to create new rules across Sentinel and Defender XDR, citing reduced ingestion costs, unlimited real-time detections, and integration with Defender XDR data, functions and remediation actions with automatic entity mapping. For new rules it is worth evaluating first.

Fewer than most estates do, and tuned. The number that matters is how many alerts your analysts action rather than close in bulk. A smaller set that gets read is a better detection capability than a large set that trained everybody to ignore the console.

We scope by rule count and alert volume. The free first step: for your top five rules by alert volume, check what proportion of those alerts were actioned rather than closed as benign. If that proportion is low, tuning will improve your detection more than any new rule would.

Yes, and it is one of the reasons to keep good scheduled rules rather than only relying on built-in content. The Fusion engine can correlate alerts produced by scheduled analytics rules with alerts from other systems, producing high-fidelity incidents as a result.

In the Content Hub, by installing the related product solutions or standalone content. Analytics rule templates are available with nearly every product solution there, and installing the solution for a source you already ingest is the fastest way to close a detection gap.

No, and the difference matters. Scheduled and near real time rules automatically create incidents for the alerts they generate. Alerts generated in external services and ingested into Sentinel do not create their own incidents, which is exactly what Microsoft security rules exist to handle.

On the Analytics page there is a dedicated Anomalies tab alongside active rules and templates, and the detected anomalies are written to the Anomalies table for querying. Using them as context inside other detections and hunts is how that rule type delivers value.

Detection review

Fifteen questions about your own rule set.

The middle group is where most improvement is available. Almost every Sentinel deployment has rules producing alerts that nobody has actioned in months.

Inventory

How many rules are enabled?
And how many are scheduled.
Any rules auto-disabled?
Check for insufficient access messages.
Were any created by people who left?
Cross-tenant rules break.
Is Fusion still enabled?
It is on by default.
Are anomaly rules enabled?
They add context, not alerts.

Quality

Which rules produce the most alerts?
Volume is not value.
Which alerts has nobody actioned?
The real noise measure.
Do we tune or just disable?
Tuning preserves coverage.
Do rules cover our connected sources?
Ingesting without detecting is waste.
Are we using Content Hub templates?
Microsoft strongly encourages it.

Sustainability

Are rules exported as ARM templates?
Rules as code.
Do we monitor rule health?
Failures are silent otherwise.
Have we planned the Defender portal move?
Two rule types are affected.
Do we know what custom detections are?
Microsoft calls them the best way now.
Who owns the rule set?
Not a shared inbox.

Take your top five rules by alert volume and check how many alerts were actioned.

If most were closed as benign, those five rules are training your analysts to ignore the console. Tuning them improves detection more than adding anything new would.

Book a detection rule review Call +971 56 613 2743

Related Services

Explore more solutions that work great with this service

Tuned and maintained

Enabled at deployment

Templates activated broadly

Alert volume manageable

Yes

Variable

Alerts actually actioned

Most

Some

Few

Rules tuned rather than ignored

Yes

Coverage gaps identified

Yes

Assumed absent

Anomaly context used

Queried in hunting

Unused

Rule health monitored

Yes

Rules under source control

ARM templates

Cross-tenant ownership safe

Yes

Unknown

Defender portal impact known

Documented

Unknown

Analyst trust in the console

High

Moderate

Low

	Type	What it does	Customisable
Scheduled	Kusto query on an interval against a lookback period	Yes, fully
Near real time	A limited subset of scheduled rules, running once a minute	Yes, with limitations
Anomaly	Machine learning baseline, writes to the Anomalies table	Only via a duplicate in flighting mode
Microsoft security	Creates incidents from other Microsoft security alerts in real time	Yes, but unavailable on the Defender portal
Threat intelligence	Matches CEF, Syslog and Windows DNS events against indicators	No
Fusion	Correlates low-fidelity alerts into high-fidelity incidents	No, and only one instance
ML behavior analytics	Anomalous SSH and RDP login behaviour, in preview	No
Generates its own alerts	All except anomaly rules	Anomalies go to a table
Enabled by default	Advanced multistage attack detection	Others require activation
Affected by the Defender portal move	Microsoft security and Fusion	Both auto-disabled

Type

What it does

Customisable

Scheduled

Kusto query on an interval against a lookback period

Yes, fully

Near real time

A limited subset of scheduled rules, running once a minute

Yes, with limitations

Anomaly

Machine learning baseline, writes to the Anomalies table

Only via a duplicate in flighting mode

Microsoft security

Creates incidents from other Microsoft security alerts in real time

Yes, but unavailable on the Defender portal

Threat intelligence

Matches CEF, Syslog and Windows DNS events against indicators

Fusion

Correlates low-fidelity alerts into high-fidelity incidents

No, and only one instance

ML behavior analytics

Anomalous SSH and RDP login behaviour, in preview

Generates its own alerts

All except anomaly rules

Anomalies go to a table

Enabled by default

Advanced multistage attack detection

Others require activation

Affected by the Defender portal move

Microsoft security and Fusion

Both auto-disabled

Move to the Defender portal and your Microsoft security rules are automatically disabled.

Eight things that decide whether your detections work.

Scheduled rules, which is most of your rule set

Near real time rules and what they cost

Anomaly rules, which deliberately do not alert

Tuning anomalies through flighting

Two rule types that disappear on the Defender portal move

The rules you cannot edit but should enable

The permission trap in multi-tenant deployments

Rules as code, through ARM templates

A cross-tenant rule stops working when the person who created it loses access.

Four things that make a rule set worth having.

We reduce noise before we add coverage

We check for rules that disabled themselves

We use anomaly rules for what they are

We put the rule set under source control

Four phases across roughly six weeks.

Inventory the rules and their health

Reduce the noise before adding anything

Find the gaps and fill them from templates

Make it maintainable and portal ready

Six situations where the rule set needs work.

A business whose analysts stopped reading alerts

An organisation moving to the Defender portal

A managed service provider or multi-entity group

A regulated firm evidencing detection coverage

An operator ingesting sources with no detection on them

A company building a detection engineering practice

How UAE organisations run Sentinel detection.

What each rule type does, and whether you can change it.

Five steps, and the first two are subtraction.

Inventory rules with volume and health

Measure which alerts get actioned

Tune, scope or retire

Close the gaps from templates

Make it maintainable

What organisations ask about Sentinel analytics rules.

What rule types are there?

How often do near real time rules run?

Why do our anomaly rules never alert?

Can we tune an anomaly rule?

What happens to our rules when we move to the Defender portal?

Is that a loss of coverage?

Why did one of our rules disable itself?

How do we prevent that?

Should we write rules from scratch?

What does the threat intelligence rule do?

What is Fusion and do we need to configure it?

How do we manage rules across multiple workspaces?

What are custom detections?

How many rules should we have?

What does an engagement cost?

Can Fusion use our own scheduled rules?

Where do we find more rule templates?

Do all rule types create incidents automatically?

Where do we see anomalies if they are not alerts?

Fifteen questions about your own rule set.

Inventory

Quality

Sustainability

The pages around this one.

Sentinel data connectors

SOC optimization

KQL threat hunting

Take your top five rules by alert volume and check how many alerts were actioned.

Related Services

ATT&CK coverage assessment

Sentinel UEBA

Sentinel Data Connectors

Sentinel SOC Optimization

KQL Threat Hunting

Microsoft Sentinel

Sentinel to the Defender Portal

SOC-as-a-Service

Move to the Defender portal and your Microsoft security rules are automatically disabled.

Eight things that decide whether your detections work.

Scheduled rules, which is most of your rule set

Near real time rules and what they cost

Anomaly rules, which deliberately do not alert

Tuning anomalies through flighting