Glossaire
Termes du parc Microsoft, expliqués.
Définitions claires pour les abréviations et termes produits qui apparaissent sur les pages EfficientEther, les revues de parc Microsoft et les conversations opérationnelles.
M
Application manifest
An application manifest is the structured descriptor file inside a package that declares what the application is, what it needs, and what it is allowed to do. For an MSIX package this is the AppxManifest.xml file that Windows reads before, during, and after installation to understand the package it is handling. The manifest carries the package's identity, name, publisher, version, and processor architecture. That identity, combined with the publisher name embedded in the signing certificate, is what Windows uses to determine whether a newly installed package is a fresh application or an update to one already present. This is why identity fields in the manifest have to stay consistent across an application's release history rather than being treated as free-form metadata. Beyond identity, the manifest declares the package's dependencies on shared framework packages and their required version ranges. It also declares the capabilities it needs, ranging from ordinary capabilities like internet access to restricted capabilities such as running processes outside the package's sandbox. Restricted capabilities require additional justification and, for Store-distributed applications, Microsoft review before they will be granted. The manifest also declares its extension points, file type associations, protocol handlers, startup tasks, context menu entries, and similar integrations with the rest of Windows that a traditional installer would have configured through registry writes scattered across the system. Because the manifest is declarative rather than the sequence of imperative install actions a traditional installer script represents, it is also what makes an MSIX package's behaviour predictable and inspectable before installation. Reviewing a manifest tells a packager or a security team exactly what an application will be able to do and touch on a device, without having to trace through and reverse-engineer an installer's actual runtime behaviour. The manifest schema itself has evolved across Windows releases, with newer capabilities and extension points introduced in step with new OS versions. A manifest authored against an older schema version may not be able to declare newer capabilities even where the underlying OS supports them, which is a practical reason packaging teams need to track which manifest schema version their tooling targets. Manifest authoring is also where many of the compatibility issues that surface during MSIX conversion get resolved in practice, whether that means adding a Package Support Framework fix-up reference, adjusting a capability, or correcting a file type association. This makes the manifest the file packagers return to most often once an initial conversion or capture has produced a working first draft.
Manifest matters during Windows 11, Intune, Azure Virtual Desktop, and Cloud PC programmes because application blockers can delay the whole rollout. The practical question is whether the term helps capture, package, sign, deploy, or troubleshoot an app with less rework.
Mobile Device Management
MDM is the practice of enrolling an entire device into a management authority. This lets the organisation apply configuration, enforce security policy, monitor compliance, and, if necessary, remotely lock or wipe the device as a whole, rather than managing only the corporate applications running on it. In the Microsoft ecosystem, MDM enrolment is handled through Microsoft Intune, using the device's native management channel: the Windows MDM stack via CSPs (Configuration Service Providers) on Windows, Apple's MDM protocol via Apple Push Notification service on iOS/iPadOS and macOS, and the Android Enterprise framework on Android. Intune acts as the cloud-based MDM authority, issuing commands and policy across all of them from one console. Once a device is MDM-enrolled, it becomes visible and controllable to a degree that Mobile Application Management alone cannot match. This includes full configuration profiles, compliance policy evaluation feeding into Conditional Access, endpoint security controls like BitLocker enforcement, remote actions such as full wipe, retire, or fresh start, and inventory data covering installed applications, OS version, and hardware detail. That level of control is exactly why MDM is the natural fit for corporate-owned devices, where the organisation has clear ownership and legal standing to manage the whole device. It is also why MDM is a harder sell for personally owned BYOD hardware, where a full wipe destroys personal data alongside corporate data. Android Enterprise's work profile and Apple's User Enrolment modes exist specifically to give a lighter-touch MDM option for BYOD, one that partitions a managed work container from the personal side of the device without full device-wide control. MDM enrolment methods differ meaningfully in operational effort. Windows Autopilot enables zero-touch MDM enrolment straight from Windows Setup on new or reset devices, Apple Business Manager or Apple School Manager provides equivalent supervised, zero-touch enrolment for Apple hardware purchased through those programmes, and Android Enterprise's fully managed mode does the same for corporate Android devices. Devices acquired outside those channels typically require manual, user-driven enrolment instead, which is slower to roll out and more prone to incomplete adoption across an estate. A recurring operational issue in mature MDM estates is enrolment drift: devices that were wiped and rebuilt outside the managed provisioning flow, devices that left MDM through an OS reset without a corresponding retire action in Intune, or duplicate device records left behind after a re-enrolment. All of these inflate licence counts against devices that are no longer actually receiving policy. This is why device inventory reconciliation between Intune, Entra ID, and actual active hardware is a standing housekeeping task rather than a one-off setup step.
MDM matters for endpoint teams because device, app, compliance, update, and troubleshooting signals often sit across several Microsoft admin areas. Linking these terms back to Intune and device-reporting routes helps readers move from definition to action.
Multifactor Authentication
Multifactor Authentication requires a user to prove their identity with more than one type of evidence, typically something they know such as a password, combined with something they have such as a phone or hardware key, or something they are such as a fingerprint, rather than accepting a password alone. This closes off the overwhelming majority of account compromise that stems from credential theft, phishing, or password reuse across breached sites, since a stolen password on its own no longer grants access. Microsoft supports several methods with meaningfully different security properties, and the differences matter more than they first appear. SMS and voice call codes are the weakest widely deployed option, vulnerable to SIM-swapping and interception, and Microsoft has been actively steering organisations away from them. The Microsoft Authenticator app with push notifications and number matching is a substantial improvement, requiring the user to enter a displayed number rather than simply approving a bare 'yes' prompt; this was introduced specifically to counter MFA fatigue attacks, where an attacker with a stolen password floods a user with approval requests until one is accepted out of habit or irritation. Phishing-resistant methods, FIDO2 security keys, Windows Hello for Business, and certificate-based authentication, represent the strongest tier, since they are cryptographically bound to the specific service being authenticated to and cannot be relayed or replayed the way a one-time code can. How MFA gets enforced is as important as which method is used. Security Defaults provide a basic, non-configurable baseline suitable for smaller tenants with no Conditional Access licensing. Per-user MFA is the older, less flexible mechanism that forces every sign-in regardless of context. Conditional Access-driven MFA, requiring Entra ID P1, is what most mature organisations actually run, since it allows MFA to be required selectively, for risky sign-ins, unmanaged devices, or sensitive applications, rather than uniformly, which reduces user friction without reducing security where it actually matters. Registration coverage is a frequent operational gap: users who have never completed MFA registration cannot be enforced against. If Conditional Access is set to require MFA without confirming registration completion first, unregistered users get abruptly locked out. This is why registration campaigns with a defined enforcement date, rather than a single policy flip, are the standard rollout pattern. Legacy authentication protocols that predate modern authentication, older versions of POP, IMAP, and some line-of-business application connectors, cannot prompt for MFA at all. They need to be blocked outright rather than assumed harmless, since they represent a complete bypass of MFA regardless of how well the rest of the policy is configured.
MFA matters because identity, access, endpoint, and data controls shape how Microsoft environments are protected. Readers should understand the term and then be able to move into security assessment, conformity, or remediation guidance.
Microsoft Entra ID
Microsoft Entra ID is Microsoft's cloud-based identity and access management service, formerly branded Azure Active Directory until its 2023 rename. It is the directory and authentication backbone underneath virtually every other Microsoft cloud service. Microsoft 365, Azure, Windows 365, Dynamics 365, and any third-party application configured for single sign-on all authenticate users against an organisation's Entra ID tenant. At its core, it stores and manages identity objects: users, groups, devices, and registered applications. It also issues the tokens that prove a user's identity and group memberships to every connected application, using open standards including OAuth 2.0, OpenID Connect, and SAML. Its licensing structure follows a Free, P1, and P2 tier model that materially gates which security capabilities are available. The free tier covers basic authentication and a limited set of Conditional Access controls. P1 adds full Conditional Access policy support, dynamic group membership, and self-service password reset. P2 adds Identity Protection's risk-based sign-in and user-risk detection along with Privileged Identity Management for just-in-time elevation of administrative roles. This means an organisation's actual security posture on paper can be significantly overstated if P2 features are assumed to be active when the licensed tier only supports P1. Conditional Access is the policy engine most administrators interact with most directly, letting access be gated on conditions such as user or group, device compliance state, network location, sign-in risk level, and application being accessed. Misconfigured or overly permissive Conditional Access policies are a recurring source of both security exposure and user friction, since a single badly scoped policy can either fail to block a genuinely risky sign-in or lock out an entire department. Hybrid identity is another area with real operational weight. Many organisations still run on-premises Active Directory alongside Entra ID, synchronised via Microsoft Entra Connect (formerly Azure AD Connect), with authentication handled either through password hash synchronisation, pass-through authentication, or federation. The choice between these affects both resilience if on-premises infrastructure goes down and the attack surface exposed by each method. For licence and cost governance, Entra ID sits at a slightly awkward position: P1 and P2 are sold both as standalone SKUs and bundled inside EMS and the higher Microsoft 365 tiers. This means the same entitlement can be paid for multiple times across an estate if licence assignment is not actively reconciled against what a user is actually entitled to through their other Microsoft 365 licence.
Microsoft Entra ID matters because Microsoft 365, Azure, Windows 365, Teams, and related services are usually managed as one estate. The term connects to planning, cost, configuration, security, and day-two operational decisions across that estate.
Microsoft Graph
Microsoft Graph is the unified API gateway Microsoft provides in front of Microsoft 365, Entra ID, Intune, Windows, Teams, SharePoint, Outlook, OneDrive, and the wider Microsoft cloud. It exposes users, groups, licences, devices, mail, calendars, files, security signals, and administrative actions through one consistent REST endpoint, SDK set, and permissions model, rather than a separate API per service. Before Graph consolidated this, integrating with Microsoft 365 meant working against several distinct APIs, each with its own authentication pattern and data shape. Graph replaced that with a single object model and a single OAuth 2.0 and Entra app registration flow. This is why nearly every serious piece of Microsoft cloud tooling built in the last several years, including licence optimisation, device management, and security reporting products, is built on top of it rather than around it. Access to Graph is governed by scoped permissions: delegated for actions performed on behalf of a signed-in user, or application-level for unattended background access. The distinction between read and write scopes is the practical line between a tool that can see tenant state and a tool that can change it. Reading licence assignments, device compliance state, or Secure Score data needs only read scopes, while an offboarding or remediation action, such as revoking sessions, removing a licence, or updating a Conditional Access policy, needs write scopes. This is why a well-built tool requests the narrowest permission set that its features actually use, and treats any write-capable app registration as something a tenant admin should review carefully before consenting to. Working with Graph at any real scale surfaces two practical engineering problems every vendor in this space has to solve properly. The first is throttling: Graph enforces rate limits per tenant and per resource type, meaning a naive full-tenant licence or device pull can be rejected or slowed under load and needs batching, paging, and back-off handled correctly. The second is change tracking: Graph exposes delta queries that return only what changed since the last sync, rather than forcing a full re-pull every time. This is the difference between a reporting tool that can refresh near real time and one that lags badly on anything beyond a small tenant. Graph's audit and activity data, including sign-in logs, directory audit logs, and Intune device event data, is also the evidence layer that tenant backup, drift detection, and offboarding audit trails are built from. A tool that can show a defensible, timestamped record of who changed what, or that every step of an offboarding run succeeded or was skipped, is drawing that record from Graph's own audit surface rather than reconstructing it independently. For IT teams evaluating any Microsoft 365 or Azure tool, the practical questions worth asking are which Graph permissions it requests, whether it separates read access from write access clearly, and whether it is transparent about what it does with the data it pulls. This matters because Graph access is effectively a standing key into the tenant.
Microsoft Graph matters because integrations, APIs, virtual machines, and delivery pipelines are how Microsoft estate data and automation become usable. These terms help readers understand how systems connect before they decide what to build or automate.
Microsoft Teams
Microsoft Teams is Microsoft's unified communication and collaboration platform, combining persistent chat, video and audio meetings, file collaboration, and an extensible app and workflow layer into a single client. It has become the default real-time collaboration surface for most Microsoft 365 organisations since Skype for Business was retired. Structurally, Teams is built on top of other Microsoft 365 services rather than being a standalone data store. Each team is backed by a Microsoft 365 group, its files live in a connected SharePoint Online document library, its chat and channel messages live in Exchange Online-adjacent storage, and its meeting recordings default to OneDrive or Stream. This means Teams governance and Teams storage cost are really governance and storage decisions about several other services wearing a single front end. Licensing follows the wider Microsoft 365 structure, with Teams included in Business Basic and above. Separate add-on licensing is required for Teams Phone (PSTN calling and a phone system replacing traditional telephony) and for Teams Premium, which layers on advanced meeting intelligence features like live translation and meeting recaps atop the base product. Teams sprawl is one of the most common and most underestimated operational problems in mature Microsoft 365 estates. Because any user can create a new team in a couple of clicks, organisations that do not enforce a naming convention, an approval workflow, or a lifecycle/expiration policy through Entra ID group-based governance routinely accumulate hundreds or thousands of abandoned, near-duplicate, or single-purpose teams that nobody owns. Each one still consumes storage, still appears in search results, and still represents an access-control surface that has to be reviewed during any security or compliance audit. Guest access, where external users are invited into a team, is another area demanding active management. It is genuinely useful for cross-organisation collaboration, but left unreviewed it becomes a slow accumulation of external accounts with standing access to internal channels and files long after the original project or relationship ended. Teams' integration with the Microsoft Graph API and its app store also makes it a common vector for third-party and custom application access into a tenant. Reviewing which apps and bots have been consented into a Teams environment, and what Graph permissions they were granted, is a standard part of the same governance exercise that covers channel sprawl and guest access, rather than a separate concern.
Microsoft Teams matters because Microsoft 365, Azure, Windows 365, Teams, and related services are usually managed as one estate. The term connects to planning, cost, configuration, security, and day-two operational decisions across that estate.
Microsoft Installer package
MSI, the Microsoft Installer package format, is the traditional Windows installer technology built around the Windows Installer service. An .msi file is not a simple archive but a relational database of tables describing every action the installation needs to perform: which files to copy and where, which registry keys to create, and which shortcuts to add. In many real-world packages it also specifies which custom actions to run, arbitrary scripts or executables invoked during install that fall outside the standard, well-behaved Windows Installer actions the format was designed around. MSI has been the dominant enterprise application packaging format for decades and remains widely deployed today, particularly for applications that genuinely need machine-wide installation, elevated system access, driver installation, or Windows service registration. None of these map cleanly onto MSIX's per-package isolation model. This is why MSI and scripted alternatives like PSADT continue to have a legitimate place alongside MSIX in a mixed packaging estate, rather than being fully replaceable by it. The characteristic weakness that has driven much of the industry's move toward MSIX is MSI's uninstall reliability. An MSI's custom actions can write files and registry keys outside what the Windows Installer engine itself tracks, and years of install, patch, and uninstall cycles accumulate small inconsistencies. As a result, uninstalling an MSI-packaged application frequently leaves behind orphaned registry keys, residual files, and configuration drift that a clean uninstall should have removed, a problem that compounds across a device's lifetime as more applications are installed and removed. In a packaging and estate management context, MSI is most often encountered from two directions. The first is as the source material for converting a legacy application into MSIX, where having the original MSI available is generally the cleanest starting point because its declarative table structure can be translated fairly directly, in contrast to capturing a live installation when the original installer has been lost. The second is as the target format itself for applications a packaging team has deliberately decided not to convert, because the effort or risk of resolving MSIX's isolation constraints outweighs the benefit for that specific application. Licence reclaim and cost-optimisation tooling also intersects with MSI in practice. Many older, high-value line-of-business applications an organisation is trying to track usage of or right-size licensing for are still MSI-packaged, so estate visibility work frequently has to reconcile MSI-based deployment records with the application and licence inventory a cost or compliance team is trying to maintain.
MSI matters during Windows 11, Intune, Azure Virtual Desktop, and Cloud PC programmes because application blockers can delay the whole rollout. The practical question is whether the term helps capture, package, sign, deploy, or troubleshoot an app with less rework.
MSIX app package
MSIX is Microsoft's modern Windows application packaging format, built to replace the ad hoc mix of traditional installers, App-V virtual applications, and manual deployment scripts with a single, consistent package structure. It gives every packaged application a stable package identity, containing its own isolated file and registry state. This is what makes MSIX installs and uninstalls reliably clean: removing an MSIX application removes everything it wrote, without the leftover files, orphaned registry keys, and configuration drift that traditional installers are notorious for leaving behind after years of install and uninstall cycles. Deployment and update support are built into the format itself rather than bolted on afterward, enabling silent installs, staged and phased rollouts, and differential updates that only transfer the parts of a package that actually changed. All of this integrates directly with Microsoft Intune for enterprise distribution. Getting a legacy Win32 application into MSIX is rarely a purely mechanical conversion. The practical work concentrates in a small number of predictable places: file type associations, environment variables, startup shortcuts, and any script that assumes unrestricted write access to shared system locations. This is because MSIX's file and registry virtualisation redirects writes to an isolated per-package location by default. Applications that genuinely need broader system access, such as those installing a driver, a system-level service, or requiring true machine-wide write permissions, are not good MSIX candidates on their own. This is where Package Support Framework fix-ups or App Attach can extend compatibility, and where some applications are better suited to IntuneWin or a scripted PSADT package instead. The source material available for the conversion largely decides the effort required. Converting from the original installer, where it can still be found, is generally the cleanest and most maintainable route. A capture-first repackage from a live, already-installed application is the practical fallback when the original installer has been lost, which is common in older, long-lived estates. MSIX applications can additionally be delivered without full local installation through App Attach on Azure Virtual Desktop and Windows 365, or sideloaded onto managed devices from a trusted internal source using the estate's own signing certificate rather than requiring public store distribution.
MSIX matters during Windows 11, Intune, Azure Virtual Desktop, and Cloud PC programmes because application blockers can delay the whole rollout. The practical question is whether the term helps capture, package, sign, deploy, or troubleshoot an app with less rework.
.msixbundle
An MSIX bundle, distributed as a .msixbundle file, is a container that packages multiple related MSIX packages together into a single distributable file. It is most commonly used to combine architecture-specific builds of the same application, x86, x64, and ARM64, or to bundle an application's base package together with optional resource packages containing language packs or other add-on content that not every installation needs. The bundle carries its own manifest, distinct from the manifest inside each individual package it contains, which describes what the bundle holds. This lets the installing device, whether that is the Microsoft Store, Intune, or a manual sideload, automatically select and install only the packages that are actually applicable to that specific device, rather than requiring a publisher to produce and distribute a separate file for every architecture and language combination an application supports. This matters operationally for any organisation distributing an application across a mixed device fleet. Rather than a packaging team maintaining, and an IT team tracking, several separate MSIX files per application, one for each architecture in use across the estate, a single .msixbundle upload to the Store, Intune, or an internal distribution point covers the full combination. The correct package is resolved automatically at install time, based on the target device's processor architecture and configured language. Bundles are particularly relevant wherever an application genuinely needs native builds per architecture, rather than relying on x86 or x64 emulation on ARM64 devices. Windows on ARM's emulation layer, while broadly effective, carries a performance cost that a native ARM64 build avoids. Bundling is therefore the practical way to offer the better native experience where it is available, without fragmenting distribution into separate per-architecture releases. It is worth distinguishing a bundle from an ordinary MSIX package clearly, since the two are sometimes used loosely as if interchangeable. A single .msix file is one specific package for one specific architecture and language, while a .msixbundle is a wrapper around several such packages. Tooling, signing, and validation steps in a packaging pipeline need to account for both layers, the bundle manifest and each inner package's own manifest, when troubleshooting why a particular device received, or failed to receive, the version of the application appropriate to it.
MSIX bundle matters during Windows 11, Intune, Azure Virtual Desktop, and Cloud PC programmes because application blockers can delay the whole rollout. The practical question is whether the term helps capture, package, sign, deploy, or troubleshoot an app with less rework.
Managed Service Provider
MSP, Managed Service Provider, describes an IT service delivery model in which an external provider takes ongoing operational responsibility for a customer's IT estate, monitoring, maintenance, security, helpdesk support, and often strategic technology guidance, typically under a recurring contract rather than being engaged only for discrete projects. That is what distinguishes an MSP relationship from traditional break-fix or project-based IT consultancy. It is worth being precise about how MSP relates to CSP, Cloud Solution Provider, since the two terms get used almost interchangeably in casual conversation despite describing genuinely different things: MSP describes the service delivery model, the ongoing management relationship itself, while CSP describes a specific Microsoft partner licensing and billing channel through which cloud subscriptions are sold and administered. A great many companies operate as both an MSP and a CSP simultaneously, managing a customer's Microsoft 365 and Azure environment day to day while also being the entity that bills them for the underlying licences, but the two roles are not the same thing and a provider can hold one without the other. For an MSP managing multiple client tenants, the operational challenge that shapes most of its tooling requirements is genuinely one of scale and multiplication: a task that is straightforward in a single organisation's tenant, tracking licence utilisation, flagging inactive accounts, right-sizing subscription tiers, has to be repeated consistently and reliably across every client tenant the MSP manages, and doing that manually, tenant by tenant, does not scale much past a handful of clients before oversights and inconsistent practices creep in. This is the specific gap that multi-tenant cost and licence optimisation tooling is built to close for MSPs: rather than an engineer manually checking usage reports in each client's admin centre on its own schedule, a genuinely multi-tenant tool surfaces licence waste, inactive accounts, and cost anomalies across the entire client book from one place. That matters commercially as well as operationally, because an MSP that can demonstrate proactive cost management across its client base has a stronger, more differentiated value proposition than one offering only reactive support, and because licence waste identified and reclaimed on a client's behalf is a direct, easily quantified example of the value an MSP relationship is supposed to deliver.
MSP matters because Microsoft estate decisions often have a commercial owner as well as a technical owner. Clear cost, licence, and partner language helps teams prove value, reclaim waste, and agree the next action before spend becomes harder to challenge.
O
OneDrive for Business
OneDrive for Business is Microsoft's cloud file storage and synchronisation service for individual users within Microsoft 365, distinct from the consumer OneDrive service despite sharing a name and client application. It is built on the same underlying SharePoint Online storage infrastructure that also powers Teams file storage and SharePoint document libraries. This means OneDrive is more accurately understood as an automatically provisioned personal SharePoint site per user than as a genuinely separate storage product. Each licensed user gets a dedicated storage allocation, 1TB by default on most Microsoft 365 business and enterprise SKUs, with the ability to pool additional storage from unused licences in the tenant up to a much higher cap. Files sync bidirectionally between the cloud and local devices through the OneDrive sync client. This client also handles Known Folder Move, a widely deployed configuration that redirects a user's Desktop, Documents, and Pictures folders into OneDrive automatically, so that files saved locally are backed up and available across devices without the user needing to deliberately save into a OneDrive folder. This local-cloud sync relationship is also where the most common OneDrive support issues originate: sync conflicts when the same file is edited offline on two devices, and sync client errors from file paths exceeding Windows length limits. Another common source of confusion is the difference between a file being "available offline" (fully downloaded locally) and using Files On-Demand, which shows a file in Explorer without it actually being downloaded until opened. This distinction trips up users troubleshooting why a file appears present but will not open without an internet connection. Externally, OneDrive is the mechanism behind most individual file and folder sharing links sent out of a Microsoft 365 tenant. Sharing defaults (anyone with the link, versus specific people, versus organisation-only) are configured at the tenant level in the SharePoint admin center but can be further restricted per site. Uncontrolled default sharing settings are therefore a recurring data governance and compliance exposure, since a permissive tenant default can result in sensitive files being shared far more broadly than a user intended, often without them realising the org-wide default was set to allow it. From a Windows 365 and Azure Virtual Desktop perspective, OneDrive interacts directly with Cloud PC and session host design. Because Cloud PCs and multi-session hosts are effectively disposable or shared compute, OneDrive with Known Folder Move redirection is a standard part of ensuring a user's files persist correctly across a Cloud PC resize, a reprovision, or a shared session host where the user's profile is not guaranteed to be the same machine session to session.
OneDrive matters because Microsoft 365, Azure, Windows 365, Teams, and related services are usually managed as one estate. The term connects to planning, cost, configuration, security, and day-two operational decisions across that estate.
P
Microsoft Entra Privileged Identity Management
Microsoft Entra Privileged Identity Management addresses one of the most consistently exploited weaknesses in identity security, standing privileged access, by converting administrative roles from permanently active assignments into eligible assignments that must be explicitly activated, for a defined and limited time window, before they actually grant any privilege. A compromised privileged account with no active PIM activation grants an attacker nothing beyond whatever standing access remains, drastically shrinking the number of accounts that are exploitable as Global Administrator or equivalent at any given moment compared to an environment where every administrator simply holds their role permanently. Activation can be configured to require Multifactor Authentication even for users already authenticated, a written justification describing why the elevated access is needed right now, an associated ticket number tying the activation to a specific documented change, and, for the most sensitive roles, approval from a designated second party before activation takes effect. Every activation is logged with full detail on who activated what, when, for how long, and why, giving genuine audit-quality evidence rather than the vague 'who has admin rights' answer most organisations without PIM can actually provide. PIM applies across both major role systems in a Microsoft cloud estate, Entra ID directory roles and Azure resource roles at the subscription, resource group, or resource level, and PIM for Groups extends the identical eligible-and-time-bound model to group membership itself, so that membership of a group which happens to carry elevated application or resource permissions can be made just-in-time rather than standing, without needing a native PIM role at all. Access reviews scoped specifically to privileged roles are a standard complement, since eligible assignments themselves need periodic recertification: an account eligible for Global Administrator that nobody has actually activated in a year is a strong candidate for removal. PIM alerts flag activity that bypasses the intended workflow entirely, such as a role being activated outside PIM through direct assignment, or unusually high volumes of activation for a given role, both of which typically indicate either a misconfiguration or an active compromise attempt. In practice, the most common failure mode is not the absence of PIM but its incomplete adoption: an organisation licenses and configures PIM correctly for its most senior administrators while leaving departmental or delegated admin roles, Exchange Administrator, SharePoint Administrator, Helpdesk Administrator, on permanent standing assignment, which leaves a meaningful share of the tenant's actual privileged attack surface outside the control PIM was deployed to provide. PIM requires an Entra ID P2 licence or the Governance add-on, and its effectiveness depends heavily on activation friction being calibrated correctly, since requirements set too loosely fail to meaningfully reduce risk, while requirements set too strictly push administrators toward requesting standing access instead, defeating the model entirely.
PIM matters because identity, access, endpoint, and data controls shape how Microsoft environments are protected. Readers should understand the term and then be able to move into security assessment, conformity, or remediation guidance.
Windows 365 provisioning policy
A Windows 365 provisioning policy is the configuration object, created and managed in the Microsoft Intune admin center, that defines how new Cloud PCs get built and assigned for a given group of licensed users. It ties together the image to deploy, the network configuration to attach to, and the language and region settings into a single reusable template. Windows 365 executes this template automatically whenever a licensed user in the assigned Entra ID group needs a Cloud PC provisioned. Its core components are the image, either a Microsoft-provided gallery image or an organisation's own custom Windows image published to an Azure Compute Gallery, and the network connection type, either a Microsoft-hosted network for the simpler managed networking model or a specific Azure network connection for organisations that need the Cloud PC deployed inside their own virtual network. It also specifies the target Entra ID group whose members will have Cloud PCs automatically provisioned as they are licensed, along with optional settings like a Cloud PC naming template and, for hybrid Entra join scenarios, the target on-premises Active Directory domain and organisational unit. Assignment is group-based rather than individual, which is both the policy's main operational strength and its most common source of misconfiguration. Adding a user to the assigned Entra ID group and licensing them for Windows 365 triggers automatic provisioning with no further administrator action required, which scales well. But it also means an incorrectly scoped or overly broad group can trigger unintended provisioning. Equally, forgetting to remove a departed employee from the assignment group promptly can leave a licensed, running, and billing Cloud PC sitting idle for weeks before anyone notices, which is one of the most common and avoidable sources of ongoing Windows 365 waste in real deployments. Multiple provisioning policies are the normal way organisations handle different user segments needing different configurations. For example, an organisation might use separate policies for standard knowledge workers on a lighter image and network configuration versus a developer or power-user segment on a heavier custom image with access to internal source control systems through an Azure network connection. Keeping these policies cleanly separated by group, rather than trying to force one policy to serve every user type, is standard practice for both manageability and cost control. Provisioning policy health, and its associated Azure network connection health where applicable, are the first two things worth checking whenever new Cloud PC provisioning fails or stalls. A failed domain join credential, an exhausted subnet, or an image no longer available in the target region will all surface as provisioning failures traceable back to the policy configuration, rather than to the user's licence assignment itself.
Provisioning policy matters because Microsoft 365, Azure, Windows 365, Teams, and related services are usually managed as one estate. The term connects to planning, cost, configuration, security, and day-two operational decisions across that estate.
Package Support Framework
Package Support Framework is a Microsoft open-source runtime that applies compatibility fix-ups to an MSIX-packaged application at the moment it launches. It addresses behaviours such as incorrect file and registry redirection, wrong working-directory assumptions, and environment-variable mismatches, so a legacy application behaves correctly inside MSIX's isolated container without any change to its original source code. PSF works by inserting a launcher and a configurable runtime layer in front of the packaged application. When the app starts, PSF intercepts specific system calls the application makes and redirects, corrects, or supplements them according to a JSON configuration file. It can also optionally run PowerShell start or stop scripts before or after the application itself runs. That last capability, PSF's ability to execute scripts as part of application launch, is precisely where governance attention belongs. PSF start scripts run with the same trust as the application itself, and independent research has confirmed they genuinely execute under interactive activation, though non-interactive automation testing can under-report whether they ran. A clean install and a successful launch is not, on its own, evidence that a configured script actually executed as intended. The defensible operational position, based on that research, is to treat PSF as a trusted, full-trust compatibility layer rather than a routine default applied to every package. This means preferring packaging an application as native MSIX with no fix-ups first, adding PSF only where genuine runtime evidence shows it is needed to fix a specific compatibility problem, signing and inventorying every PSF binary shipped in a package, and treating any PSF script as managed code subject to the same review and change control as application code, rather than as an incidental packaging detail. PSF is also the mechanism that most often needs specific validation when an application is delivered through App Attach rather than a local install, since attach timing and shared-storage behaviour under App Attach can interact with PSF fix-ups differently than a purely local MSIX install does. EtherApps Forge applies PSF fix-ups only where captured runtime evidence shows they are genuinely required, rather than as a default step in every packaging run.
PSF matters during Windows 11, Intune, Azure Virtual Desktop, and Cloud PC programmes because application blockers can delay the whole rollout. The practical question is whether the term helps capture, package, sign, deploy, or troubleshoot an app with less rework.
Microsoft Purview
Microsoft Purview is Microsoft's unified family of data governance, risk, and compliance tools, covering the Microsoft 365 estate, Azure data services, and, increasingly, third-party and multicloud sources through its data map and connector framework. It was brought together under a single portal and licensing structure after Microsoft consolidated what were previously separate compliance centre and Azure Purview products into one brand. Under that umbrella sit a set of distinct capabilities that are often referred to individually and are frequently the actual point of interest rather than "Purview" as a whole: sensitivity labels for classifying and protecting content based on data type and business impact, retention labels and policies for keeping or disposing of content in line with legal and regulatory requirements, eDiscovery for identifying and collecting content relevant to legal matters and investigations, insider risk management for detecting potentially risky user activity, Data Loss Prevention (DLP) for stopping sensitive information leaving through email, chat, or file sharing, audit for capturing and searching the activity log across Microsoft 365 workloads, and information barriers for restricting communication between defined groups of users. This breadth is also the source of the most common practical confusion: Purview features are split across Microsoft 365 E3, E5, A5, and standalone add-on SKUs, so a specific capability, such as Premium eDiscovery, advanced audit with longer retention and higher-bandwidth access to the Management Activity API, or automatic sensitivity label classification, may not actually be available or fully functional in a given tenant's current licensing even though the Purview portal itself is visible to every administrator. For organisations working towards ISO/IEC 27001, ISO 22301, SOC 2, or UK GDPR-driven data protection obligations, Purview is frequently the operational engine behind the paper policy: retention labels implement the documented records retention schedule, sensitivity labels implement the data classification policy, DLP policies implement the acceptable use and data handling controls, and audit and eDiscovery together provide the evidence trail an auditor or regulator will ask to see. The practical risk in Purview deployments is less about the tools' capability and more about governance discipline: label taxonomies that grow uncontrolled, retention policies that conflict with each other across overlapping scopes, or DLP rules tuned so loosely they generate alert fatigue and get ignored. All of these point to the same underlying lesson that Purview is a policy enforcement engine, not a substitute for the organisation actually deciding, documenting, and periodically reviewing what its data governance rules should be.
Purview matters because customers, resellers, and procurement teams need evidence that controls are defined, operated, and reviewable. A useful glossary definition should help a reader connect the term to audit preparation, policy work, or repeatable assurance activity.
Q
Quarterly Business Review
A Quarterly Business Review is a recurring, structured meeting between a service provider or internal IT function and the business stakeholders it serves. It is used to step back from day-to-day operational tickets and review performance, delivered value, risk, service quality, and roadmap priorities over a longer horizon than any single incident or change request. For a managed service provider running Microsoft 365 and Azure estates on behalf of customers, the QBR is typically where cost optimisation work becomes visible and defensible to a commercial audience. Licence reclaim totals, rightsizing savings, and idle-resource cleanup are presented as a before-and-after trend rather than a one-off report, because a single quarter of good numbers proves less than a repeatable pattern of control. A credible QBR needs three things to avoid becoming a status-update ritual nobody values. The first is a consistent baseline that each quarter is measured against, so trends are genuinely comparable rather than restated from a shifting starting point. The second is evidence behind every claimed saving, distinguishing realised savings that have actually reduced a bill from identified opportunity that has only been found, since blending the two undermines trust the first time a customer checks the invoice. The third is named ownership, connecting each finding and action back to a person or team accountable for it via cost allocation, rather than presenting spend and waste as an anonymous total. Beyond cost, a well-run QBR for a Microsoft estate typically also covers security posture and compliance evidence. Certifications such as Cyber Essentials or ISO 27001, and outstanding compliance gaps, are exactly the kind of slower-moving risk that a ticket-by-ticket operational relationship rarely surfaces on its own. For an MSP managing many tenants, the QBR is also where the cost of manually rebuilding a licence, resource, and savings report for every customer each quarter becomes obvious. This is why the practice increasingly depends on tooling that can produce that evidence consistently across a multi-tenant estate, rather than a spreadsheet assembled fresh each cycle.
QBR matters when teams need repeatable day-two work rather than one-off fixes. Definitions in this area should help readers connect reporting, review, remediation, backup, drift, and evidence capture to a controlled operating model.
R
Role-Based Access Control
Role-Based Access Control is the practice of granting permissions through named roles that bundle a defined set of actions, rather than assigning individual permissions to individual users one at a time. This makes access both easier to reason about and easier to audit, since reviewing who holds the Exchange Administrator role answers the access question directly, whereas reverse-engineering equivalent permissions granted piecemeal across dozens of individual assignments does not. In a Microsoft cloud estate this concept actually spans two related but distinct systems that get confused constantly, even by experienced administrators. Entra ID roles, such as Global Administrator, User Administrator, or Exchange Administrator, control administrative actions within the identity and Microsoft 365 service layer. Azure RBAC, built around roles such as Owner, Contributor, and Reader, controls access to Azure resources, subscriptions, resource groups, and individual resources like virtual machines or storage accounts. The two systems have separate role definitions, separate assignment mechanisms, and, critically, separate places to check when investigating who can actually do what. This means a full access review has to cover both, rather than assuming one implies coverage of the other. Both systems support custom roles for cases where the built-in role definitions grant either too much or too little, letting an organisation define, for example, a role that can reset user passwords but not modify Conditional Access policies. Azure RBAC roles can also be scoped tightly, applying only to a single resource or resource group rather than an entire subscription. This is one of the more effective and underused ways to limit blast radius when access genuinely only needs to cover one workload. The principle RBAC is meant to serve, least privilege, is that a user or service should hold only the access actually required for their function and no more. That principle is easy to state and consistently hard to maintain in practice, since role assignments tend to accumulate as people change jobs and rarely get revisited or removed when a broader role is no longer needed. This is exactly the gap that role-assignable groups, periodic access reviews, and, for genuinely privileged roles, Privileged Identity Management's just-in-time activation are designed to close, converting standing, always-on privileged access into time-bound access granted only when there is an active, justified need for it. Getting RBAC design wrong tends to fail in one of two directions, both costly. Overly broad roles create unnecessary attack surface and make a single compromised account far more dangerous than it needs to be. Overly fragmented custom roles create an administrative burden that eventually pushes teams back toward granting excessive access, simply because working out the correct narrow role every time becomes impractical.
RBAC matters because identity, access, endpoint, and data controls shape how Microsoft environments are protected. Readers should understand the term and then be able to move into security assessment, conformity, or remediation guidance.
Remediation
Remediation is the corrective action taken once a finding has been identified, whether that finding is a security misconfiguration, a compliance gap, tenant configuration drift away from an approved baseline, licence waste, or an oversized Azure resource. It is the step that turns visibility into an actual outcome rather than a report that gets read once and filed away. Finding a problem and fixing it are genuinely separate disciplines with different skill and risk profiles: identifying that a privileged role assignment violates least-privilege, that a Conditional Access policy has drifted from its baseline, or that a VM is running at a fraction of its provisioned capacity requires analysis and correct interpretation of data, while remediating each of those requires writing and safely executing the specific PowerShell, Graph API call, or portal change that fixes it without breaking something else in the process. That is why many tools stop at reporting and leave remediation as a manual follow-up task for an already-stretched admin. AI-assisted remediation is increasingly used to close that specific gap, generating the PowerShell or configuration change needed for a given finding inline, next to the finding itself, so an admin reviews and runs a concrete fix rather than researching the correct command from documentation or a forum post. The discipline that keeps this safe is treating AI-generated remediation code as a draft for human review rather than something that executes automatically, since a generated script that is subtly wrong for a specific tenant's configuration can cause more damage than the finding it was meant to fix. Remediation also spans a spectrum of risk and reversibility that governs how much automation and how much human approval is appropriate at each point: read-only findings and reporting carry no risk and can run continuously and automatically, low-risk remediation such as flagging an inactive licence for review is safe to surface without confirmation, and high-impact, hard-to-reverse actions, most obviously full user offboarding that revokes sessions, blocks sign-in, resets passwords and MFA, cancels meetings, sets a mailbox auto-reply, and removes licence, group, and admin role assignments, should require an explicit human confirmation before running and should be logged step by step, since some of those actions cannot be quietly undone if they were triggered against the wrong account. Evidence is what separates defensible remediation from remediation nobody can later prove happened: a per-action log showing which specific fix was applied, when, by whom or by which automated run, and whether it succeeded or was skipped, is what an auditor or a Quarterly Business Review needs to see. It is also what protects the organisation if a remediation action is later questioned, since finding a problem, fixing it, and being able to prove both steps happened correctly are three distinct requirements that credible tooling and process both need to satisfy.
Remediation matters when teams need repeatable day-two work rather than one-off fixes. Definitions in this area should help readers connect reporting, review, remediation, backup, drift, and evidence capture to a controlled operating model.
Azure Reservations
An Azure reservation, also called a reserved instance, is a one-year or three-year commitment purchase that discounts the billing rate for a specific, matching configuration, such as a particular virtual machine size family in a particular Azure region, in exchange for that upfront commitment. Reservations are a billing construct rather than a change to how a resource runs: the workload behaves identically, only the price applied to matching usage changes. Three mechanics decide how well a reservation performs in practice. Scope determines how widely the discount can apply, from a single subscription up to a shared scope across an entire billing context. A shared scope is generally the most forgiving choice, because the discount searches for any matching resource across the estate rather than sitting unused if one subscription stops consuming it. Instance size flexibility means a reservation for virtual machines can cover other sizes within the same flexibility group, not only the exact size purchased, using a ratio Azure applies internally, though it does not cross between different VM families. Exchange and refund policy governs what happens if the underlying need changes. This policy has been revised by Microsoft more than once, most recently tightening the window in which a reservation purchased for one configuration can be exchanged for another. The current terms should always be checked at the point of purchase, rather than assumed from memory. The core risk with any reservation is the same regardless of these mechanics: it only pays off if the matching resource keeps running for the length of the term. A reservation bought for a virtual machine that is later resized, moved, or decommissioned becomes a sunk commitment rather than a saving. For that reason, reservations suit steady, well-understood workloads with no expected change in size or region, such as an always-on database tier or a line-of-business application that has held its shape for a year. They should always be purchased after rightsizing, not before, so the commitment reflects the workload the estate actually needs rather than the oversized footprint it started with.
Reserved Instances matters because Microsoft estate decisions often have a commercial owner as well as a technical owner. Clear cost, licence, and partner language helps teams prove value, reclaim waste, and agree the next action before spend becomes harder to challenge.
Azure resource group
An Azure resource group is a logical container within an Azure subscription that holds related resources, virtual machines, storage accounts, virtual networks, disks, and so on, for a solution. This lets them be managed, monitored, secured, and billed as a coherent unit, rather than as a flat, undifferentiated list of every resource in a subscription. Every Azure resource must belong to exactly one resource group at all times, and resource groups themselves belong to a subscription. A resource group has a defined region for its own metadata, but the resources inside it can span multiple regions. This is a common point of confusion for anyone assuming a resource group implies geographic co-location of everything within it. The practical value of resource groups shows up in three places. The first is access control: Azure role-based access control (RBAC) role assignments made at the resource group level automatically apply to every resource inside it, letting an administrator grant a team contributor access to an entire application's infrastructure with one assignment rather than one per resource. The second is lifecycle management: deleting a resource group deletes every resource inside it in one operation, which is both a powerful cleanup tool for tearing down an entire test environment in seconds and a genuinely dangerous one if a resource group is deleted without a clear understanding of everything it actually contains. The third is cost visibility: Azure Cost Management can filter and report spend by resource group, making it the natural unit for attributing Azure cost to a specific project, department, application, or environment, provided resources were organised into groups deliberately rather than dumped into one another for convenience. Common resource group design patterns include grouping by application (all resources for one workload together, deleted together when the workload is retired), by environment (separate groups per environment, such as one holding production Azure Virtual Desktop session hosts and one holding the development or pilot session hosts), or by lifecycle (grouping resources that share the same deployment and update cadence). The choice matters, because a poorly designed grouping strategy, most commonly one enormous shared resource group holding every resource an organisation has ever created, actively defeats the access control, cleanup, and cost attribution benefits resource groups exist to provide. That forces administrators back to manually tagging and filtering individual resources to get the clarity a well-structured resource group layout would have given for free. Naming conventions and mandatory tagging policies, often enforced automatically through Azure Policy at the subscription or management group level, are the standard mechanism organisations use to keep resource group structure consistent as the number of teams creating resources grows.
Resource group matters because Microsoft 365, Azure, Windows 365, Teams, and related services are usually managed as one estate. The term connects to planning, cost, configuration, security, and day-two operational decisions across that estate.