Ordlista

Microsoft-miljötermer, förklarade.

Tydliga definitioner för förkortningarna och produkttermerna som dyker upp på EfficientEther-sidor, Microsoft-miljögranskningar och operativa samtal.

Bläddra i resurser Fråga teamet

127 definitioner10 kategorierTydligt språk beskrivningar

V W Z

V

VDIMicrosoft cloud

Virtual Desktop Infrastructure

Virtual Desktop Infrastructure, universally abbreviated VDI, is the general architecture of hosting desktop operating systems and applications on centralised servers rather than on the physical devices end users hold, with users connecting remotely over a display protocol to a virtual machine that behaves, from their perspective, like a local desktop. The concept predates the current cloud era by well over a decade, originating with on-premises solutions like Citrix XenDesktop and VMware Horizon, which required an organisation to own and operate its own hypervisor infrastructure, storage, and networking to host the virtual desktops, giving full control but also full responsibility for capacity planning, patching the hypervisor layer, and disaster recovery. Microsoft's cloud-native entries into this space, Azure Virtual Desktop and Windows 365, are best understood as VDI delivered as a managed or fully managed service rather than a fundamentally different technology: Azure Virtual Desktop runs on Azure infrastructure the organisation still configures and manages directly, including session host pools, host scaling, and image management, while Windows 365 abstracts nearly all of that away into a fixed per-user, per-month Cloud PC subscription with Microsoft handling the underlying host infrastructure. The core VDI trade-off that has held constant across two decades of implementations is cost and control versus operational simplicity: traditional on-premises VDI offers the deepest customisation and can be cheaper at very large, steady-state scale, but demands significant in-house virtualisation expertise and up-front capital investment, whereas cloud VDI models trade some of that control for consumption-based or fixed pricing and dramatically reduced infrastructure management overhead, which is why most net-new VDI deployments today default to Azure Virtual Desktop or Windows 365 rather than standing up new on-premises hypervisor farms. A persistent point of confusion in the market is using "VDI" and "Windows 365" interchangeably, when Windows 365's fixed-cost, always-on Cloud PC model is deliberately simpler and less configurable than the session-pool, autoscale, multi-session VDI model that Azure Virtual Desktop and traditional on-premises platforms use, and choosing between them is a genuine architectural decision driven by use case: task workers and predictable headcount suit Windows 365's flat pricing, while variable or burst capacity, kiosk-style multi-session hosts, and highly customised desktop images tend to be better served by Azure Virtual Desktop's more granular control over host pools, scaling plans, and session density.

VDI 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.

Windows 365 and Cloud PC solution Explore EtherInsights

VHDXApplication modernisation

Virtual Hard Disk v2

VHDX, Virtual Hard Disk v2, is Microsoft's virtual hard disk format, originally built for Hyper-V virtual machines, that also became the original container format used for MSIX App Attach on Azure Virtual Desktop and Windows 365, where a VHDX file holding one or more MSIX packages is attached to a user's session at logon so the application appears available without having been installed into the golden image or session host itself. A VHDX-based App Attach deployment stores an application's MSIX package inside the virtual disk, hosts that disk on a file share reachable by the session hosts, and mounts it as the user signs in, which lets a single application image be shared across many session hosts and updated centrally without touching the underlying image, avoiding the operational overhead of rebuilding and redeploying a full golden image every time an application needs to be added, updated, or removed. VHDX supports both fixed and dynamically expanding disk allocation, and because it is a full virtual disk format rather than a lightweight package container, it carries more overhead at mount time and in storage footprint than the newer CimFS-based App Attach approach that has become the preferred method for new deployments, since a CIM image mounts faster and single-instances shared content more efficiently than a VHDX's block-based structure allows. This does not make VHDX obsolete: it remains fully supported, plenty of existing App Attach estates were built on it before CimFS-based delivery matured, and some tooling or scenarios still default to it, so packaging and virtual desktop teams need to be able to work with both formats rather than assuming every environment they touch has already moved to CIM. Troubleshooting VHDX-based App Attach in practice tends to concentrate on a specific, recurring set of issues: file share permissions and throughput affecting mount time at logon, disk expansion behaviour when using dynamically expanding VHDX files under load, and the operational discipline of keeping the application versions inside deployed VHDX files current as the underlying MSIX packages are updated, since an outdated VHDX will keep serving an old application version until the disk itself is refreshed. For organisations planning or auditing an AVD or Windows 365 estate, knowing whether App Attach is running on VHDX or CIM is a genuinely practical distinction, not a purely technical footnote, because it affects logon performance, storage costs, and which generation of App Attach tooling and guidance actually applies to that environment.

VHDX 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.

Agentic app packaging solution MSIX packaging solution Explore EtherApps Forge

VMPlatform and integration

Virtual Machine

A Virtual Machine is a software-defined computer that runs its own operating system and applications on top of shared physical hardware, with a hypervisor allocating CPU, memory, storage, and network resources from the underlying host to each VM as though it were dedicated infrastructure. In Azure, virtual machines are the foundational compute building block underneath a large share of an organisation's cloud spend, and they are also one of the most common sources of avoidable Azure cost, because VM billing is driven by the SKU size selected and the hours the VM runs, not by how much of that capacity is actually used, so a VM provisioned for a peak workload that never materialises, or left running outside business hours when nothing depends on it, bills at full rate regardless. Rightsizing is the standard remediation: comparing actual CPU, memory, and disk performance data against the provisioned SKU over a meaningful observation window, then recommending a smaller SKU, a reservation, or a scheduled shutdown where the evidence supports it, and the discipline that separates a credible rightsizing recommendation from a guess is using real workload telemetry rather than acting on SKU size alone, since a VM can look oversized on paper while still carrying legitimate burst headroom a shorter observation window would miss. Idle and orphaned VMs are the other common waste pattern: a VM left running after a project ended, a test environment nobody decommissioned, or a VM whose attached disk keeps billing after the compute resource itself was deleted, all of which show up as steady, unexplained spend that a monthly Azure bill alone rarely makes obvious without dedicated cost visibility. VMs are also the underlying infrastructure for Azure Virtual Desktop session hosts, where the same rightsizing and idle-detection logic applies at the host pool level, and understanding the distinction between AVD's VM-based, admin-managed model and Windows 365's simpler per-user Cloud PC model is itself a cost and operations decision, since AVD gives direct control over VM sizing, image management, and scaling schedules in exchange for taking on that management overhead, while Windows 365 trades that flexibility for a flatter, more predictable per-user cost. For estates managing both traditional Azure VM workloads and Cloud PC fleets, the practical governance need is the same in both cases: real usage data behind every sizing decision, a named owner for every resource so recommendations translate into action rather than sitting in a report, and a repeatable review cycle so rightsizing is a continuous discipline rather than a one-off cleanup exercise that drifts back to waste within a few months of being done.

VM 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.

Explore the portfolio Talk to the team

W

W365Microsoft cloud

Windows 365

Windows 365 is Microsoft's Cloud PC service, the product family that provisions and hosts the individual Cloud PC desktops users connect to, positioned as the simpler alternative to self-managed Azure Virtual Desktop for organisations that want a persistent, personal Windows desktop without owning the underlying infrastructure decisions. It is licensed in two main editions matched to different usage patterns: Windows 365 Enterprise, for users who need a dedicated, always-available, one-to-one desktop, licensed per user at a fixed monthly rate sized by vCPU, RAM, and storage; and Windows 365 Flex, formerly branded Windows 365 Frontline, for shift-based, part-time, or rotating cohorts where provisioning against peak concurrent usage rather than total headcount produces a materially better fit and lower cost. The commercial proposition against Azure Virtual Desktop is predictability: a Windows 365 seat has a flat, published monthly price with no separate compute, storage, or networking line items to forecast, and no session-host sizing, scaling automation, or patching burden for the underlying infrastructure, since that is Microsoft's responsibility rather than the customer's. That simplicity is also the boundary of the model: because a Cloud PC is dedicated to one user, Windows 365 does not offer the shared, multi-session economics that make Azure Virtual Desktop cost-effective for high-density pooled cohorts, so estates with a genuine mix of dedicated knowledge-worker and shared or specialist usage typically end up running both services side by side rather than choosing one exclusively. Migration into Windows 365 from an existing Azure Virtual Desktop estate is supported through Microsoft's migration API, a REST interface built on Microsoft Graph that provisions a Cloud PC from a snapshot of a prepared virtual hard disk, though it currently targets persistent, single-session, Entra-joined or hybrid-joined machines rather than pooled multi-session host pools, which need a fresh Windows 365 or Flex build rather than a direct migration. Deciding whether a given cohort belongs on Windows 365 or Azure Virtual Desktop comes down to persistence needs, concurrency pattern, and administrative appetite rather than price alone, which is why a directional cost comparison against the current AVD or on-premises baseline is the usual first step before committing to a migration plan.

W365 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.

Explore EtherInsights Cloud cost optimisation solution Windows 365 and Cloud PC solution

WCAGCompliance

Web Content Accessibility Guidelines

WCAG, the Web Content Accessibility Guidelines, is the internationally recognised technical standard for making web content usable by people with disabilities, published by the World Wide Web Consortium's Web Accessibility Initiative (W3C WAI) and organised around four core principles, commonly remembered by the acronym POUR: content must be Perceivable (available to the senses, such as text alternatives for images and captions for video), Operable (usable via keyboard alone, with no time limits that cannot be extended, and no content that triggers seizures), Understandable (readable and predictable, with clear error identification and input assistance), and Robust (compatible with current and future assistive technologies such as screen readers). Each guideline under those principles is broken into testable success criteria, and each criterion is assigned a conformance level of A, AA, or AAA, with AA representing the level almost universally adopted as the practical compliance bar in both regulation and procurement, since AAA includes some criteria widely regarded as impractical to apply site-wide. The current stable version in wide use is WCAG 2.1, with WCAG 2.2 adding further success criteria (such as clearer focus indicators and consistent help placement) and formally recommended as the version organisations should be targeting for new or updated content. For UK organisations, WCAG 2.1 AA is the explicit technical standard referenced by the Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018, and it functions as the de facto benchmark that courts and regulators reference under the Equality Act 2010's requirement to make reasonable adjustments, even for private-sector organisations with no direct statutory citation. In a Microsoft 365 and Azure context, WCAG conformance is not automatic even when using accessible-by-default platforms: SharePoint intranet sites, Power Apps and Power Pages applications, Teams-embedded content, and custom Azure-hosted web applications are all capable of introducing accessibility failures through custom theming, low-contrast colour choices, missing alt text on uploaded images, poorly structured heading hierarchies, or custom components that are not properly keyboard-operable, regardless of how accessible the underlying platform chrome is. Automated scanning tools such as axe or Lighthouse can reliably catch a meaningful subset of WCAG failures, typically estimated at around 30 to 40 percent of total issues, such as missing alt attributes and insufficient colour contrast, but criteria that depend on judgement, like whether alt text is actually meaningful or whether a tab order is logical, require manual testing, ideally including testing with an actual screen reader and keyboard-only navigation, before a genuine AA conformance claim can be made.

WCAG 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.

Certifications and security IT operations and compliance solution

Windows 365 FlexMicrosoft cloud

Windows 365 Flex

Windows 365 Flex, formerly branded Windows 365 Frontline, is the Windows 365 edition designed for shift, part-time, and rotating cohorts who need Cloud PC access at different times of day rather than dedicated, full-time use, and it is licensed against peak concurrent usage instead of total headcount, which is the single most consequential difference from Windows 365 Enterprise. Under Enterprise licensing, every named user requires their own paid seat regardless of how much or little they actually use it; under Flex, a pool of Cloud PC licences is provisioned to cover the maximum number of people genuinely active at the same time, so a 400-person shift-based estate with 120 peak concurrent users is licensed and costed against that 120 figure, not the full 400. This makes Flex economics highly sensitive to getting the concurrency number right: understating peak concurrent usage produces a pool too small to meet real demand at busy periods, while overstating it erases the cost advantage Flex exists to provide, so a credible concurrency figure needs to come from genuine usage data, such as sign-in and session logs from an existing AVD or VDI estate, rather than an estimate based on headcount or shift-roster theory alone. Flex suits contact centre and retail shift patterns, warehouse and clinical staff who log in briefly between tasks, and part-time or contingent workers whose desktop need is real but intermittent; it is a poor fit for standard knowledge workers who need their desktop available and in the same state throughout a working day, since non-concurrent provisioning assumes users are not all active simultaneously, an assumption that breaks down for always-on office cohorts. Segmenting an estate correctly between Enterprise and Flex candidates, based on genuine work pattern and concurrency rather than department or seniority, is usually the highest-leverage decision in a Windows 365 rollout, because pushing the wrong cohort into Flex creates capacity shortfalls during peak hours, while pushing a genuinely intermittent cohort into Enterprise pays for full-time persistence nobody is using.

Windows 365 Flex 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.

Explore EtherInsights Cloud cost optimisation solution Windows 365 and Cloud PC solution

Z

Zero TrustIdentity and security

Zero Trust

Zero Trust is a security architecture built on the premise that no user, device, or network location should be trusted by default, regardless of whether it sits inside or outside a traditional network perimeter, replacing the older model where anything already inside the corporate firewall was implicitly trusted, a model that stopped matching reality once remote work, cloud-hosted applications, and personal devices meant most access no longer traversed that firewall at all. Microsoft's framing of Zero Trust rests on three operating principles: verify explicitly, meaning every access request is authenticated and authorised based on all available signals, identity, device health, location, and data sensitivity, rather than being granted on the basis of network position alone; use least privilege access, limiting what any given identity can reach to only what its current task genuinely requires, ideally through just-in-time rather than standing access; and assume breach, designing controls on the expectation that some compromise will eventually occur and that its impact should be minimised through segmentation, monitoring, and rapid detection rather than relying entirely on prevention succeeding. These principles get applied across six generally recognised pillars, identities, endpoints, applications, data, infrastructure, and network, and Zero Trust is deliberately not a single product that can be purchased and switched on; it is a strategy realised through the coordinated configuration of existing tools, Conditional Access enforcing per-request identity and device signals, Multifactor Authentication and phishing-resistant credentials strengthening the identity pillar, Intune-enforced device compliance feeding into access decisions, Purview sensitivity labels and DLP protecting data regardless of where it moves, and network micro-segmentation limiting lateral movement once a foothold is gained, none of which delivers Zero Trust in isolation. The most common implementation failure is treating Zero Trust as a single project with a completion date, deploying Conditional Access and calling the initiative finished, when in practice the assume-breach principle demands ongoing work: continuous monitoring, regularly re-evaluated trust signals, and periodic access reviews that catch privilege creep, since a security posture that was correctly configured on day one degrades steadily as roles change, new applications get added, and exceptions accumulate if nothing revisits it. For organisations coming from a VPN-centric, perimeter-based model, the transition is as much cultural and procedural as it is technical, since it requires accepting that internal network traffic gets scrutinised with the same rigour as external traffic, and that 'the user is already on the corporate network' stops being treated as a legitimate access justification on its own.

Zero Trust 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.

Security and conformity solution Explore EtherInsights