ICT Field Notes

After moving away from RM CC4, one of the biggest things we needed to take control of was device deployment.

In a school environment, rebuilding devices is not a rare task. Machines get moved between rooms, replaced, repaired, reimaged, repurposed, and prepared for new academic years. If the deployment process is difficult to understand or difficult to change, the whole environment becomes harder to manage.

For us, the goal was simple: build a Windows 11 deployment process that we controlled, understood, and could troubleshoot ourselves.

That led us to Microsoft Configuration Manager, or MCEM/SCCM.

Why we needed a new deployment process

The old environment was still heavily influenced by RM CC4. That had shaped how devices were managed and built, but it no longer fitted the direction we wanted to go in.

We needed to move towards:

• Windows 11
• Microsoft 365 Apps
• Cleaner Active Directory and Group Policy
• Better software deployment
• More standard Microsoft tooling
• A build process we could document and support ourselves

Software deployment had already become a pain point. We had moved to PDQ Deploy because the existing setup did not give us the level of software deployment control we needed.

Office was another major issue. We were stuck using 32-bit Office 2016, which had become unreliable and was regularly freezing or crashing. Moving towards a modern Windows 11 and Microsoft 365 Apps build was a big part of why the old deployment approach needed to change.

The aim was not to build the most advanced deployment platform possible on day one. The first goal was to get a reliable Windows 11 build process that could be repeated, improved, and understood.

Why MCEM made sense

MCEM made sense because the environment was already heavily Microsoft-based.

We were using Active Directory, Group Policy, Windows Server, Microsoft 365, and were moving towards Entra ID and more modern device management. MCEM fitted into that direction.

It gave us a way to manage Windows deployment using standard components:

• PXE boot
• Distribution points
• Boot images
• Task sequences
• Driver packages
• Application packages
• Collections
• Boundaries and boundary groups
• Deployment status
• Logs

That last point matters more than it might sound.

With a proper deployment platform, failure becomes easier to investigate. A failed build is still frustrating, but at least there are logs, status messages, boundaries, content distribution, task sequence steps, and client-side behaviour to investigate.

That was a major improvement over relying on a more opaque or vendor-shaped build process.

The first goal: one reliable Windows 11 build

The first milestone was not perfection. It was one successful, repeatable Windows 11 deployment.

That meant building a task sequence that could:

• Boot over PXE
• Apply Windows 11 Education
• Partition and format the disk correctly
• Apply the right driver package
• Join the domain
• Place the device into the correct structure
• Install core applications
• Install Microsoft 365 Apps
• Apply required configuration
• Leave the machine in a usable state for staff or students

Getting that first successful build working was the important turning point.

Once one device could be built reliably, everything else became easier to improve. Applications could be added. Drivers could be refined. Post-build steps could be improved. Naming conventions could be adjusted. The process could become cleaner over time.

Trying to make the first version perfect would have slowed the whole project down.

PXE was the first major hurdle

PXE boot was one of the first areas that needed proper attention.

On paper, PXE sounds simple: device boots from the network, contacts the deployment infrastructure, gets a boot image, and starts the task sequence.

In practice, there are several moving parts:

• DHCP
• IP helpers or PXE response
• Distribution point configuration
• Boot image distribution
• Network drivers in the boot image
• Boundaries
• Boundary groups
• Collections
• Task sequence deployments
• UEFI support

One of the problems I hit was the classic situation where the device would PXE boot but no deployment would be available.

That kind of issue forces you to understand how Configuration Manager decides whether a device should receive a task sequence. It is not enough for PXE to work. The device also needs to be in scope for a deployment, assigned to the right boundary group, and able to access the correct content.

This is where MCEM starts to teach you how many assumptions are hidden inside a deployment process.

Boundaries and collections matter

One of the biggest early lessons was that boundaries and collections are not just background configuration.

They decide whether clients can find site systems, content, and deployments. If they are wrong, devices may boot into PXE but fail to find anything useful.

For a school environment, where devices are often rebuilt in batches and may be spread across several rooms or network areas, boundaries need to be correct and understandable.

Collections are just as important.

A task sequence can be perfectly built, the boot image can be distributed, and PXE can be working, but if the deployment is not targeted correctly, the device will not see it.

That makes deployment troubleshooting a chain of questions:

• Did the device PXE boot?
• Did it receive the correct boot image?
• Is the boot image distributed?
• Is the task sequence deployed?
• Is the device in the right collection?
• Is the deployment available to unknown computers, known computers, or both?
• Is the boundary group correct?
• Can the device access the content?

Once I understood that chain, troubleshooting became much more logical.

Driver packages were another key part

Driver management was another area where MCEM gave us more control.

In a school, you often have batches of the same desktop model, which makes driver packages very useful. Once the right drivers are imported, organised, and linked to the task sequence, builds become much more repeatable.

The important thing is to keep driver management clean.

That means:

• using model-specific driver packages where possible
• naming packages clearly
• testing drivers on known hardware
• avoiding unnecessary driver bloat
• documenting which package applies to which device model
• keeping old driver packages under control

Drivers are one of those areas that can quietly become messy if they are not managed properly.

A clean driver package structure makes future rebuilds much easier.

Microsoft 365 Apps and proxy issues

Installing Microsoft 365 Apps was another important part of the Windows 11 build.

The previous Office setup was one of the reasons we needed to modernise. Moving away from 32-bit Office 2016 and towards Microsoft 365 Apps was a big improvement, but it also introduced its own deployment considerations.

In our environment, proxy configuration mattered. If the deployment environment could not reach what it needed, Office installation could fail or behave inconsistently.

That was another reminder that a task sequence is not just about Windows. It depends on the network, internet access, proxy settings, content locations, and the order in which configuration is applied.

When an application install fails during a task sequence, the answer is not always inside the application package itself. Sometimes the issue is networking, permissions, proxy configuration, content distribution, or timing.

Windows apps and image cleanup

Another issue I dealt with was missing built-in Windows apps, such as Photos.

This is the kind of thing that can look minor until users start noticing it. A Windows build can complete successfully but still feel incomplete if expected apps are missing or broken.

That meant looking at app provisioning and making sure the required built-in applications were present in the image or added during the build process.

This is one of the reasons post-build testing matters. A task sequence can technically succeed while still leaving small usability problems behind.

The goal is not just to get to the Windows login screen. The goal is to produce a device that is genuinely ready to use.

What the build process gave us

The biggest improvement was control.

With MCEM, the Windows build process became something we owned.

We could see the task sequence. We could change the steps. We could add applications. We could update driver packages. We could check logs. We could decide what a finished device should look like.

That made the environment easier to support and easier to improve.

It also reduced dependency on the old management platform. Instead of relying on a legacy build process, we had a standard Microsoft deployment system that fitted better with the rest of the environment.

This was especially important as we moved towards Windows 11, Microsoft 365 Apps, Entra ID, and eventually more modern endpoint management.

What I learned

The biggest lesson was to build the process gradually.

It is easy to overcomplicate a task sequence early on. There is always another setting to apply, another application to install, another script to run, another improvement to make.

But the first job is to get a clean, reliable base build.

Once that works, improve it.

My main takeaways were:

• Start with one known hardware model.
• Get PXE working before worrying about the perfect task sequence.
• Keep the first task sequence simple.
• Make sure boundaries and boundary groups are correct.
• Test deployments with both known and unknown devices.
• Keep driver packages clean and model-specific.
• Check logs instead of guessing.
• Document changes as the task sequence evolves.
• Do not assume a successful build means the device is ready.
• Run proper post-build checks.

Things I would do differently

If I were starting again, I would spend more time planning the structure before building too much.

That includes naming conventions for:

• Collections
• Driver packages
• Applications
• Task sequences
• Deployment groups
• Boot images

Configuration Manager can become messy if things are created quickly without a naming structure.

I would also build a clear post-build checklist earlier. It is easy to focus on the technical success of the task sequence and forget that the finished device needs to be tested from a user’s point of view.

A proper post-build checklist should include:

• Domain join
• Correct OU
• Group Policy application
• Network access
• Printing
• Microsoft 365 Apps
• OneDrive sign-in behaviour
• Windows activation
• Device naming
• Required applications
• Event logs
• Device management status

That checklist becomes especially useful when more than one person is building or checking devices.

Final thoughts

Setting up MCEM was one of the most important steps in moving away from the old environment.

It gave us control over Windows deployment and created a foundation for Windows 11, Microsoft 365 Apps, and future endpoint management work.

It was not always simple. PXE, boundaries, boot images, drivers, Office deployment, and application installs all came with their own problems to solve.

But the difference was that the process became understandable.

When something failed, there was a path to investigate. When something needed changing, we could change it. When a device needed rebuilding, we had a repeatable process.

For a school IT environment, that matters.

A reliable deployment process saves time, reduces inconsistency, and gives the IT team much more confidence when managing large numbers of devices.

The goal was never just to install Windows 11.

The goal was to take ownership of the build process.