This article introduces key planning concepts for using OneDeploy builds effectively. It explains what a build is, why builds are useful, how OneDeploy differs from traditional imaging, and how to decide how many builds you should maintain.
What is a Build?
A Build is a collection of components from the OneDeploy Library that are deployed to a device during a deployment event.
A typical build consists of:
- An Operating System
- Software Packages
- Device Drivers
- Any associated configuration and customisation
Because OneDeploy is modular, not every library component necessarily applies to every device, even when deploying the same build. Drivers and software packages can be configured to install only when specific conditions are true, such as:
- A particular device model
- A Vendor or hardware family
- A deployment location or environment
This flexibility allows a single standardised build to be deployed across multiple hardware types while still supporting the differences between device models.
Why Have a Build?
A standardised build helps ensure consistency across deployed devices, which can reduce support effort and improve predictability.
With a build-based approach:
- Devices are rebuilt to a known standard
- User experience and configuration become consistent
- Variance between endpoints is reduced over time
Some organisations choose to retain OEM factory installations (for example, via AutoPilot), which can be valid in certain scenarios. However, OEM images can introduce challenges such as:
- Unpredictable configurations
- Outdated drivers or software
- Vendor pre-installed applications (“bloat”)
The correct approach depends on organisational requirements and operational goals.
OneDeploy Builds Versus Images
Traditional deployment systems often rely on maintaining large, static image files. OneDeploy instead works by assembling the build dynamically at deployment time.
During a OneDeploy deployment:
- Windows is installed cleanly from scratch
- Applicable device drivers are injected based on local hardware detection
- Software packages are installed as required
Because builds are instruction-based templates rather than monolithic images:
- New builds can be created or edited in seconds
- There is no accumulation of large image files
- Drivers and applications can be updated independently without rebuilding an image
This leads to clean installations that include only the components required for the target device.
How Many Builds Should I Have?
The number of builds you require depends on your environment and requirements.
A separate build is always required when:
-
The base operating system differs
Beyond that, build count is usually driven by:
- Different software requirements
- Different device roles
- Operational preference
Many organisations aim to maintain as few builds as possible, sometimes even a single build, to reduce complexity and simplify deployment processes.
Example: Core Users and Finance Users
Consider an Organisation with:
- A core set of applications required by most users
- Additional applications required only by the finance department
There are several valid approaches.
Option 1: A Single Unified Build + Post-Deployment Software Delivery
Create one build containing only the core applications, and deliver finance-specific software later using a management tool such as Intune or MECM.
Advantages
- Only one build template to maintain
- Lower risk of selecting the wrong build at deployment time
- Devices can transition roles over time without redeployment
Disadvantages
- Finance applications may not be immediately available after deployment
- Requires a post-deployment software delivery mechanism
- Role Targeting must be managed (for example, via groups or policies)
Option 2: Separate Builds Per Use Case
Create:
- A core user build
- A finance build (core + finance applications)
Advantages
- All required software is present immediately after deployment
- Less reliance on post-deployment delivery tooling
Disadvantages
- Multiple builds must be maintained in parallel
- Changes must be replicated carefully across builds
- Converting a device between roles may still require additional tooling or redeployment
Option 3: A Generic Build With No Built-In Applications
Create a minimal build and deliver all applications through post-deployment management.
Advantages
- Build template remains simple and stable
- Aligns closely with an AutoPilot-style “factory” experience
- Suitable for environments where application delivery is fully managed elsewhere
Disadvantages
- Applications may not be available immediately after deployment
- Ongoing software maintenance shifts entirely to the management platform
- Delays become more noticeable if all applications are delivered post-build
Common Questions
Is it possible to run a single build across all hardware models?
Yes. OneDeploy’s modular Driver and software handling is designed to support a “One Build, Many Devices” approach when planned correctly.
When should I create separate builds?
Separate builds are typically required when the operating system or core software requirements differ significantly between device roles.
Do I need a post-deployment management tool?
Not always but is highly recommended. It is helpful for delivering role-specific applications, updates, and ongoing configuration after deployment.
Related Articles
- What is OneDeploy
- Getting Started Guide
- Deployment → Builds
- Library → Operating Systems
- Library → Software Packages
- Library → Drivers
- DriverApps Overview