ICTICT317 Maintain standard operating environments

A standard operating environment is one agreed build of an operating system, applications, drivers, settings and security controls that an organisation deploys to many devices so that every device is, as far as possible, the same.

Ask why an organisation bothers, and the answer is the whole unit in one sentence: a fleet of identical, centrally managed devices is cheaper to support, faster to fix, easier to secure and simpler to audit than a fleet of devices each configured by hand. If every laptop in a department has the same image, the same patch level and the same policies, a technician who can fix one can fix all of them, a new starter can be productive in an hour rather than a day, and a security control applied once is applied everywhere. Configuration drift, where devices slowly diverge from the standard as people install things and change settings, is the enemy the SOE exists to hold back.

The SOE has a lifecycle rather than a moment of creation. It is designed against the organisation's requirements; built and tested; deployed; then maintained through patching, monitoring and periodic review; and eventually rebuilt when the operating system, the hardware standard or the business needs move on. Maintenance, the word in the unit title, is the long middle of that lifecycle, and it is where most of the real work sits.

Here is the shift worth understanding before anything else on this page, because everything else follows from it. The classic SOE was a golden image: a technician built one perfect machine, captured it as a disk image, and cloned that image onto every new device over the network. That model still exists and is still taught, but it is no longer where the industry is heading. The current model is a cloud-managed configuration: the device arrives from the manufacturer with Windows already on it, and the organisation applies its standard by joining the device to a cloud identity and pushing down settings, applications and policies from a management service. The "environment" is increasingly a set of policies in the cloud rather than a file on a deployment server. A page written only around imaging would teach a real skill that is quietly being replaced; this one teaches both, and is clear about which is which.

The methods for getting an SOE onto a device fall into three families. The names below are Microsoft's, because Microsoft's tooling dominates the Australian corporate desktop, but the concepts apply to any vendor.

Traditional methods work at the disk-image level and assume the organisation owns the deployment infrastructure. Bare metal is a fresh image onto a new or wiped device, with nothing kept. Refresh wipes and re-images an existing device but saves and restores the user's profile and data around the wipe. Replace transfers the user's state to a new device and retires the old one. These are the methods a technician reaches for on-premises, and they remain fully supported through Configuration Manager's operating system deployment; they are not obsolete, but they are no longer the default for a cloud-connected organisation.

Dynamic methods change what a device is without a full re-image. Subscription activation upgrades the edition based on the signed-in account; a device running Windows Pro that a user with a Windows Enterprise entitlement signs into activates the Enterprise features for that session, and reverts when they sign out. Joining the device to the cloud directory and enrolling it in mobile device management (MDM) lets a user sign in with their organisational account and have their applications, settings and policies applied automatically. Provisioning packages carry configuration, settings and apps in a small file that can be applied without an MDM service, useful for one-off or offline setup.

Modern methods start from the device the manufacturer shipped. Windows Autopilot takes an original-equipment build, and when the user signs in with their organisational account, the device configures itself from the cloud with no image to build or maintain. An in-place upgrade moves a device to a newer operating system while keeping the old settings, accounts and data intact.

Two of the details the delivered material carries are now out of date, and it is worth being exact about them because a technician will meet both the old names and the new ones.

The first is Autopilot itself. Microsoft has re-architected it as Windows Autopilot device preparation, generally available since June 2024, which delivers configuration through an enrolment-time device group and gives near real-time deployment reporting; it requires Windows 11, version 22H2 or later, and Microsoft Entra join. Classic Autopilot still runs, but device preparation is the version Microsoft is building on, and it is the one to learn if you are starting now. Details are in Microsoft's overview of Windows Autopilot device preparation and the broader Windows Autopilot overview.

The second is the Microsoft Deployment Toolkit. Older SOE material, including some of what sits behind this unit, treats MDT as a core imaging tool. Microsoft has retired it; the MDT retirement notice, last updated 6 January 2026, states that MDT will receive no further updates, fixes or support, that its integration with Configuration Manager is no longer supported, and that MDT never supported Windows 11. The recommended replacements are Windows Autopilot for cloud-first deployment and Configuration Manager operating system deployment for organisations that still run their own on-premises infrastructure. Existing MDT deployments keep working, but nobody should build a new SOE around it.

flowchart TD
  A[New or existing device needs the SOE] --> B{Cloud-managed organisation with Entra ID and Intune?}
  B -- Yes, new OEM device --> C[Autopilot device preparation: device configures itself from the cloud]
  B -- Yes, existing device to refresh --> D[Reset and reprovision, or in-place upgrade]
  B -- No, on-premises infrastructure --> E{Keep the user's data?}
  E -- No --> F[Bare metal image via Configuration Manager OSD]
  E -- Yes --> G[Refresh: back up profile, image, restore profile]
  C --> H[Enrol in MDM, apply policies, apps and updates]
  D --> H
  F --> H
  G --> H

The delivered material names a spread of tools, and several have been renamed or absorbed into other products. Getting the names right matters, because a technician reads current documentation, sits current exams and works in current consoles, all of which use the new names, while the study material and older colleagues still use the old ones.

Microsoft has pulled its device-management products under one brand, the Microsoft Intune family of products. Within it, Microsoft Intune is the cloud service for mobile device and application management, and Microsoft Configuration Manager is the on-premises product that used to be called System Center Configuration Manager, or SCCM. The intermediate brand many decks still use, Microsoft Endpoint Manager, was introduced in 2019 and then retired; if you see "Endpoint Manager" or "SCCM" in a document, read it as Intune plus Configuration Manager. The two are designed to work together through co-management and tenant attach, so an organisation can keep its Configuration Manager investment while moving workloads such as patching to the cloud at its own pace.

Around those sit the components a deployment actually uses. Windows Deployment Services and the Deployment Image Servicing and Management tool (DISM) handle network boot and image servicing. Third-party imaging tools such as Acronis, Clonezilla and the open-source FOG project still have a place, particularly in schools and small organisations; Symantec Ghost, named in older material, is long past its prime and is a marker of a dated source rather than a current recommendation. A directory service provides the identity and policy foundation: on-premises Active Directory with Group Policy, cloud Microsoft Entra ID with Intune configuration profiles, or a hybrid of the two.

A quick reference for the renames, because they trip up almost everyone moving from the study material to the workplace:

The names that changed

SCCM, then System Center Configuration Manager, then Microsoft Endpoint Configuration Manager, is now Microsoft Configuration Manager, part of the Microsoft Intune family.

Azure Active Directory, or Azure AD, is now Microsoft Entra ID (the rename was announced in July 2023 and the product names changed through late 2023). On-premises Active Directory keeps its name; only the cloud service was renamed.

Microsoft Endpoint Manager, the 2019 umbrella brand, has been retired in favour of the Microsoft Intune brand.

The Microsoft Deployment Toolkit (MDT) is retired, with Autopilot and Configuration Manager OSD as its replacements.

For decades the centre of an SOE was the Windows domain. A device was joined to Active Directory, and Group Policy Objects pushed settings, security controls and software to every domain-joined machine. That model still runs in most established organisations and is still worth knowing well; Group Policy, the Group Policy Management Console and the gpresult command that reports which policies actually applied are all live skills.

What has changed is that the domain is no longer the only, or even the main, place organisations manage devices from. Cloud identity, through Microsoft Entra ID, and cloud device management, through Intune, now do much of the same work for devices that may never touch the corporate network. Where Group Policy pushed a registry setting to a domain-joined desktop in the office, an Intune configuration profile or the settings catalog (Microsoft's name for it) pushes the equivalent setting to a laptop enrolled in MDM anywhere in the world. A device can be joined to Active Directory, to Entra ID, or to both in a hybrid arrangement, and the choice shapes how the SOE is deployed and maintained.

Underneath the tooling is a shift in thinking that reaches well past this unit but belongs in it, because it changes what "securing the SOE" means. The old model trusted the network: a device inside the corporate firewall was treated as safe. The current model, zero trust, treats no network as safe and moves the security boundary onto identity and device health. Every access request is checked against who the user is, whether the device is compliant, and what they are trying to reach, regardless of where they are connecting from. For an SOE technician the practical consequence is that device compliance, checked and enforced through Intune, is now a security control in its own right; a device that has fallen behind on patches or lost its encryption can be blocked from organisational resources until it is brought back into line. The SOE is not just a build any more; it is the thing that keeps a device trusted.

The unit lists five device types, and each earns its place in an SOE for a different reason. A kiosk is a locked-down, single-purpose device in a public space, such as a wayfinding screen in a shopping centre or a self-service terminal; the value of central management is that its narrow configuration and its restrictions can be enforced and never quietly changed. A laptop is a general-purpose portable device, and central management keeps it patched and secured even when it rarely comes into the office. A desktop is the same idea fixed to one location. A thin client is a lightweight device whose real processing happens on a server, so the endpoint holds little and is cheap to replace. A virtualised workstation takes that further into the cloud, where the user reaches a full desktop that runs somewhere else and streams to whatever device is in front of them.

That last category is where currency matters, because the modern virtualised workstation has names and products the older material predates. Microsoft's cloud desktop offerings are Windows 365, which delivers a persistent Cloud PC to each user, and Azure Virtual Desktop, which delivers pooled or personal session desktops from Azure. Both are managed through the same Intune console as physical devices, which is the point: a technician increasingly manages physical and cloud desktops through one pane rather than treating them as separate worlds.

Selecting hardware for an SOE is a balancing act, not a shopping list. The delivered material frames it well: weigh the outcome the organisation wants, the budget, the skills of the people who will support it, how the SOE will be deployed, and whether proprietary, custom or specialised hardware is needed. In practice a technician standardises on well-supported business hardware from a small number of vendors, so that HP, Dell, Lenovo or Apple can be supported consistently and bought in volume, because a narrow, well-chosen hardware standard is cheaper to maintain and image than a broad, ad hoc one.

One current hard constraint sits underneath all of that, and it is the single most common surprise for anyone building an SOE today. Windows 11 will not install on hardware that lacks a Trusted Platform Module version 2.0, UEFI with Secure Boot, and a supported 64-bit processor. Windows 10 reached the end of Microsoft support on 14 October 2025, so a current SOE is a Windows 11 SOE, and the hardware standard has to meet the Windows 11 floor before anything else is decided. The requirements are set out in Microsoft's Windows 11 requirements and the Windows 10 end of support page. Organisations that cannot move a device to Windows 11 in time can buy Extended Security Updates for Windows 10 for a limited period, but that is a stopgap that costs money and buys time, not a destination.

An SOE build is more than the operating system. It carries a standard set of applications: a productivity suite such as Microsoft 365, a standardised web browser such as Microsoft Edge or Google Chrome, endpoint security such as Microsoft Defender, a remote access or VPN client, a PDF reader, communication and collaboration tools such as Microsoft Teams, the line-of-business applications the organisation actually runs on, and the management agent that lets the device receive updates and policy. It carries the drivers that let the operating system talk to the hardware: graphics, wired and wireless network adapters, audio, chipset, storage controllers and any peripherals the role needs. And it assumes a hardware baseline: a processor and memory sufficient for the workload, solid-state storage, which is now the standard rather than a luxury, and network connectivity that matches the organisation's infrastructure.

How applications get into the build has moved with the deployment model. In an imaged SOE, applications are installed into the golden image before capture. In a cloud-managed SOE, applications are packaged and delivered by Intune after the device provisions itself: as Win32 apps, as Microsoft Store apps, or from the Enterprise App Catalog, which lets an administrator deliver and update common applications without repackaging them by hand. The Windows Package Manager, winget, has also become a common way to install and update applications from the command line and in scripts. The principle the older material teaches still holds, that applications are standardised and centrally delivered rather than installed by hand; only the delivery mechanism has changed.

Choosing an operating system for an organisation is a decision about more than the software. The considerations are optimisation, whether the operating system helps the business work efficiently; training and support, whether it is easy to learn and support and so keeps help-desk load down; security, where uniformity makes anomalies easier to spot; automation, how well it integrates with the organisation's other services; and cost, whether through a single licence, a volume licence or an open-source option.

Operating systems present themselves through different interfaces, and each suits a different setting. A graphical user interface suits office staff using productivity applications. A command-line interface suits an administrator configuring a server, running scripts or troubleshooting a device remotely. A menu-driven interface suits a kiosk or point-of-sale terminal where the device does one job and users must not reach the wider system. A touch interface suits retail, hospitality or field work on tablets. A voice interface suits hands-free settings. Underneath the interface, the operating system does the work the unit names as knowledge: managing the file system, allocating memory to programs, and scheduling processes so many programs share the processor.

A technician manages much of this through the built-in Windows administrative tools, and knowing where each one lives is a practical skill. Computer Management gathers most of them in one console. Event Viewer holds the logs. Local Users and Groups sets account restrictions. Shared Folders exposes shared locations. Task Scheduler runs tasks automatically at set times. Device Manager shows hardware status and driver versions. These are the tools a technician opens every day to see what a device is doing and to change it.

Automatic patching is the maintenance task the unit cares most about, and it is where the delivered material has aged most visibly. The idea is unchanged and correct: management software checks each device for the updates it needs and deploys any that are missing, so the fleet stays patched without a technician visiting each machine. The tools named to do it, though, have moved on, and one line in particular in the source material, that "SCCM is the current option used over the older WSUS", now reads as a snapshot of about 2021 rather than the current position.

Here is where patching actually sits as at 2026. Windows Server Update Services, WSUS, the long-standing on-premises patch service, was formally deprecated by Microsoft on 20 September 2024. Deprecated does not mean dead: WSUS still ships in Windows Server 2025, still works, and is still supported for years to come, so organisations are not being forced off it overnight. But it is receiving no new features, and Microsoft's direction is clearly towards cloud-based patching. The announcement is on Microsoft's WSUS deprecation notice, and the deprecation is recorded on the WSUS overview page.

The current alternatives are cloud-native. Windows Update for Business is a set of policies, applied through Intune or Group Policy, that control how and when devices take updates directly from Microsoft's update service rather than from an on-premises server. Windows Autopatch goes a step further: it is a managed service, built on Intune and Windows Update for Business, that moves devices through update rings automatically, holds and rolls back updates that cause problems, and reports on the fleet's patch state, so much of the scheduling and monitoring a technician used to do by hand is done by the service. Azure Update Manager handles the equivalent job for servers and cloud workloads. Configuration Manager still manages updates for organisations that run it, now typically co-managed with Intune. The shape of the decision has changed: it is less "which on-premises server distributes patches" and more "how much of the patch lifecycle do we hand to a cloud service".

Whatever the tool, the discipline is the same. Updates are scheduled outside business hours, tested on a small group before they reach everyone, staged in rings so a bad update is caught early, and recorded so the organisation can prove what was applied and when. Microsoft releases most security updates on the second Tuesday of each month, Patch Tuesday, which is why so many patch schedules are built around it.

An SOE is tested before it is trusted, and the testing happens in stages that move from the narrow to the real. Unit testing checks a single component, one application, driver or script, in isolation during the build. Integration testing checks that the components work together once combined into the full build. Pilot or staging testing deploys the SOE to a small, representative group of real devices to catch problems that a lab never shows. User acceptance testing puts the build in front of the people who will actually use it, to confirm that it does their job. Regression testing, run after any later patch or change, confirms that the change has not broken something that used to work. Each stage involves the right people: the build technician early, the wider IT team and selected users in the pilot, department representatives at acceptance, and the maintenance technician for regression.

The point of staging is worth stating plainly, because it is the difference between a controlled rollout and an outage. An update or a new build that looks perfect in the lab can still break a line-of-business application, a printer driver or a security control in the field. Deploying to a pilot ring first means a problem affects five people, not five hundred, and can be fixed before it reaches everyone.

When a device on the SOE misbehaves, a technician reaches for a known set of tools. For live system behaviour, the Microsoft Sysinternals suite is the standard: Process Explorer and Process Monitor for what is running and what it is touching, Autoruns for what starts automatically, and TCPView for network connections. Windows Performance Monitor and Task Manager show processor, memory, disk and network use against sensible thresholds. For hardware, MemTest86 tests memory, CrystalDiskInfo reads a drive's health data, and vendor tools such as Dell SupportAssist or HP diagnostics test the rest. For the network, ping, tracert, nslookup, netstat and Wireshark diagnose connectivity, name resolution and policy problems. For logs, Event Viewer is the first stop. For configuration, Group Policy results through gpresult, the Registry Editor for settings not exposed elsewhere, and DISM for servicing an image round out the kit.

Telling whether the SOE is meeting the organisation's needs is a separate skill from fixing a single device, and it draws on evidence rather than instinct. Help-desk data and user feedback reveal recurring issues; performance monitoring shows whether the hardware standard is holding up under real workloads; compliance and policy auditing confirms that required settings are actually applied across the fleet; comparing the current build against the deployment plan reveals drift; and scheduled reviews reassess whether the SOE still fits as the business changes. A worked example makes the loop concrete: if help-desk tickets show slow application launches, and monitoring shows memory sitting at ninety per cent or more during normal work, the finding is that the hardware baseline is too low; the fix is to raise the memory in the SOE hardware specification, free memory in the short term by trimming startup programs, update the deployment plan, and redeploy at the next maintenance window.

The deployment plan is the SOE's reference document, and the unit expects you to be able to build one. At a minimum it records the scope and objectives, the build specification (operating system version, applications, drivers, hardware standard and security settings), the chosen deployment method and procedure, the testing and acceptance criteria, the schedule for updates and maintenance, and the approval and distribution arrangements. The update schedule sets out when patches are applied, the tool used, who approves and monitors them, and how updates are staged; the maintenance measures record the ongoing tasks, each with a frequency, a responsible person and a way of recording that it was done.

Around the plan sit the other records: maintenance and activity logs, patch and update reports from the management tools, incident and issue logs, hardware and software inventory reports, and checklists and sign-off forms. Consistent documentation is not bureaucracy for its own sake; it gives accountability through a clear audit trail, continuity so any technician can pick up the work, compliance evidence for audits, faster troubleshooting because past changes are recorded, and standardisation so records can be compared over time and new staff can find their way. The plan is created, approved by the right person, distributed to the people who need it, and stored securely for the life of the SOE.

Deploying the SOE is only half the job; the other half is making each device hard to compromise. The baseline controls the delivered material teaches are still exactly right. A password policy sets complexity, length, expiry and history; a typical standard is a minimum of ten characters, complexity enabled, a thirty-day expiry and a memory of the last ten passwords, though current guidance from bodies such as the ACSC leans towards longer passphrases and away from forced regular expiry, so the specific numbers are worth checking against the organisation's own policy. Full-disk encryption through BitLocker protects data if a device is lost or stolen. Endpoint protection through Microsoft Defender guards against malware. The firewall is configured, unnecessary services and accounts are removed, and least privilege is applied so ordinary users are not local administrators.

Current practice adds a few controls the older material predates, and they are worth building into a modern SOE. Security baselines in Intune apply Microsoft's recommended security settings as a managed package rather than a long manual checklist. Windows LAPS (Local Administrator Password Solution) manages and rotates the local administrator password automatically, closing a gap that used to let one shared local password unlock every machine in the fleet. Configuration Refresh periodically reapplies policy so a device that drifts is quietly pulled back to the standard. And the direction of travel in authentication is away from passwords altogether, towards phishing-resistant methods such as Windows Hello for Business and passkeys, which an SOE technician will increasingly be asked to deploy and support.

Maintaining an SOE is regulated work, and a technician has to know which laws and policies bear on it. The Privacy Act 1988 (Cth) governs how personal information is handled; when working on client devices, a technician does not access or keep personal data beyond what the task needs, deploys appropriate access controls and encryption, and reports any suspected breach rather than concealing it. The Work Health and Safety Act 2011 places a duty of care that shows up on site as cable management, correct manual handling of hardware, and following the client's induction. The Copyright Act 1968 (Cth) means every piece of software in the build is properly licensed, with licence keys and volumes recorded, and no trial or pirated software in production. The Spam Act 2003 shapes how email and messaging are configured. Anti-discrimination and accessibility law, including the Disability Discrimination Act 1992, means the SOE is configured so it can be used by everyone, with attention to accessibility settings, screen-reader compatibility and sensible defaults.

Alongside legislation sit the organisation's own documents: the ICT policy and procedures manual, the device security policy that dictates the mandatory settings, the work-brief confirmation procedure that says scope is checked before work starts, and the document storage and retention policy that governs how records are kept. The Office of the Australian Information Commissioner holds the current Australian Privacy Principles, and Safe Work Australia holds the model WHS laws, both of which are worth reading in their current form rather than from a summary, because the privacy regime in particular has been changing.

The unit says nothing about artificial intelligence, because when it was written there was nothing settled to say. That is now the largest gap in its scope, and for an SOE unit the gap is specific and practical: managing artificial intelligence has become part of maintaining the standard operating environment, in two distinct ways.

The first is that AI is now something the technician deploys and governs on the endpoint. Microsoft has put Copilot into the standard Windows and Microsoft 365 experience, and an SOE technician is increasingly the person who decides how it appears and behaves on managed devices. The Microsoft Copilot app is deployed and managed like any other application through Intune, following Microsoft's guidance on deploying the Copilot app. Whether Copilot is enabled, pinned to the taskbar, or blocked is an administrative decision made in the management console, not something left to each user. The governance question sits underneath it: where an AI assistant can reach organisational data, the organisation has to decide what it may see, and the answer runs back through the same identity, compliance and data-protection controls the rest of this page describes. Microsoft frames this as applying zero trust to Copilot, which for a technician means the familiar work of device enrolment, compliance policies and conditional access, now applied so that only healthy, compliant devices can use the AI tools against organisational data.

The second is that AI is starting to help do the endpoint management itself. Copilot in Intune is an assistant built into the management console that can summarise what a policy does, surface conflicting settings, explain a device's compliance state and help draft queries, so some of the analysis a technician used to do by hand can be done in natural language. It is built on Microsoft Security Copilot and gated by the same role-based access as the rest of Intune, so it sees only what the signed-in administrator is allowed to see. It is an assistant, not an authority, and the discipline is the same as anywhere else AI touches technical work: its output is checked against the actual device and the actual policy before it is acted on, because a confident wrong answer in a management console can be pushed to a thousand machines.

The honest summary, written as the moving position it is, is that AI has arrived on the managed desktop faster than any syllabus could follow, that the tools and their names are changing every few months, and that the durable skill is not any one feature but the habit of treating AI on the endpoint as something to be deployed deliberately, governed through the existing controls, and verified rather than trusted.

These notes were built from the delivered ICTICT317 material in the unit folder, principally the assessor guide and the training.gov.au unit descriptor generated by the Future Skills Organisation on 17 December 2024, which supplied the elements, performance criteria, foundation skills, performance and knowledge evidence and assessment conditions used in the scope block and to decide coverage.

The currency material was verified in September 2026 against Microsoft's own documentation. The Azure Active Directory to Microsoft Entra ID rename is from the Microsoft Entra "New name for Azure Active Directory" article (announced July 2023, product names changed through late 2023). The Configuration Manager branding and the Microsoft Intune family of products are from "What is Configuration Manager?" and the version 2303 branding note. The Microsoft Deployment Toolkit retirement is from the Microsoft "Microsoft Deployment Toolkit (MDT) retirement notice", last updated 6 January 2026. Windows Autopilot device preparation is from Microsoft's "Overview of Windows Autopilot device preparation". The WSUS deprecation of 20 September 2024 is from the Windows IT Pro Blog "Windows Server Update Services (WSUS) deprecation" and the "WSUS overview" deprecation note. Windows Autopatch and Windows Update for Business are from the "Windows Autopatch FAQ". The Windows 10 end-of-support date of 14 October 2025 and the Windows 11 hardware floor are from Microsoft's "Windows 10 end of support" and "Windows 11 requirements" pages. The Copilot administration material is from "Copilot in Intune" and "Deploy the Microsoft Copilot app". Sysinternals is Microsoft's "Sysinternals" documentation. The legislation references point to the Office of the Australian Information Commissioner and Safe Work Australia. All Microsoft and government links were read in September 2026.