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, and 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, and 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, which 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, the capabilities it needs, ranging from ordinary capabilities like internet access to restricted capabilities such as running processes outside the package's sandbox, which require additional justification and, for Store-distributed applications, Microsoft review before they will be granted, and 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, so 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, adding a Package Support Framework fix-up reference, adjusting a capability, or correcting a file type association, making 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 so that the organisation can 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, with Intune acting 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: 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, and why it's 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 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, whereas devices acquired outside those channels typically require manual, user-driven enrolment 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 which inflate licence counts against devices that are no longer actually receiving policy, and which 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, which 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, which 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; and 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, and 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, and if Conditional Access is set to require MFA without confirming registration completion first, unregistered users get abruptly locked out, which 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, so 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, and 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, and it 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, and 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, meaning 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, and 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, and 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, so 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, exposing 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, which 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, and 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, which 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: throttling, since 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; and change tracking, since Graph exposes delta queries that return only what changed since the last sync rather than forcing a full re-pull every time, which 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, since 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, and 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, which 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, and separate add-on licensing required for Teams Phone (PSTN calling and a phone system replacing traditional telephony) and 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 consuming storage, still appearing in search results, and still representing 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, since it is genuinely useful for cross-organisation collaboration but, left unreviewed, 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 make it a common vector for third-party and custom application access into a tenant, so 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.
MSIApplication modernisation Microsoft Installer package
MSI, the Microsoft Installer package format, is the traditional Windows installer technology built around the Windows Installer service, in which 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, which shortcuts to add, and, in many real-world packages, 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 which map cleanly onto MSIX's per-package isolation model, which 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: because an MSI's custom actions can write files and registry keys outside what the Windows Installer engine itself tracks, and because years of install, patch, and uninstall cycles accumulate small inconsistencies, 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: 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, and 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.
MSIXApplication modernisation 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, which 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 which integrate directly with Microsoft Intune for enterprise distribution. Getting a legacy Win32 application into MSIX is rarely a purely mechanical conversion, and 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, since 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, which 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, while 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, 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 and 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, with the correct package 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, since Windows on ARM's emulation layer, while broadly effective, carries a performance cost that a native ARM64 build avoids, making bundling 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, and 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.
MSPCommercial and channel 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, which 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, and while 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, 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, which 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.
