The problem when bringing new equipment into service

When a company receives a new shipment of computers, the main delay usually isn’t delivery but the initial setup. Even 20–30 identical machines can keep the IT team busy for days if each one is prepared manually.

On paper it's simple: install the OS, add the required applications, join the device to the domain and hand it to the user. In practice, differences appear almost immediately between machines, even if the model is the same.

Most often the trouble starts with drivers. One machine may have an up-to-date package, another an older version, and a third may have some components installed automatically after the first boot. As a result, some employees have everything working normally while others face odd failures: unrecognized hardware, unstable network, or misbehaving peripherals.

A similar situation happens with security settings. If policies are applied only after devices are handed out, a risk window opens. The computer is already in use but not yet standardized. For a regular office this is inconvenient. For a government body, bank, school or hospital it is a matter of control and responsibility.

Another issue shows up later: without a unified acceptance log it’s hard to quickly identify where the problem occurred. It could have happened during assembly, OS installation, driver updates, or after the device was given to the user.

Manual provisioning typically leads to four consequences:

deployment of the batch takes longer;
identical PCs behave differently;
security requirements are not met immediately;
troubleshooting takes more time than the initial setup.

A good example is opening a new branch. Even if the shipment is a set of identical office PCs, without a unified approach the IT staff receive machines in different states. One PC is ready to use, another is awaiting certificates, a third needs a driver reinstall, and a fourth didn’t pass proper acceptance.

Therefore, a corporate image is not just for convenience. It reduces manual work, eliminates random differences between devices, and provides clear control at every stage of bringing computers into service.

What should be in a basic image

A base image isn’t meant to install everything possible. Its task is simpler: every new machine should start in the same predictable state. A good image shortens workstation setup time and reduces minor first-day issues.

First, record the exact OS version. Writing just "Windows" is not enough. Specify the build, interface language, architecture and edition, for example Pro or Enterprise. Otherwise you may later find that some features are unavailable or behave differently.

Next, define the mandatory set of applications. The image usually includes only what almost every employee needs: office apps, the approved browser, antivirus or endpoint agent, remote support client, and basic components for printing, digital signatures and internal document management.

It’s important to include not the very newest releases but proven ones. This applies to both apps and OS updates. Better to use recent but tested packages than to get failures across the whole batch.

Also set common parameters: device name template, time zone, language, power scheme, local administrator settings and other basic values. Then the equipment doesn’t look like a random collection of PCs and is easier to track and support.

If an organization buys a batch of office computers GSE L200 Series, it makes more sense to prepare one reference image for the typical employee scenario than to configure each PC separately. This is especially important where dozens of devices need to be commissioned quickly to a single standard.

Equally important is deciding in advance what should not be in the image. By default, avoid test utilities, temporary diagnostic programs, unnecessary user apps, duplicate software, obsolete plugins and personal admin accounts.

The cleaner the base image, the easier it is to update, test and maintain. A practical rule: include only what helps start working immediately after acceptance.

Which drivers to include right away

If you build an image without the right drivers, the device may power on but not be ready for work. This usually becomes apparent on day one: no network, no sound, a flaky touchscreen or missing Wi‑Fi.

Start with the essentials: chipset drivers, network adapters and storage controllers. These determine whether the system sees the hardware correctly, whether the computer can join the domain, receive policies and complete initial setup.

Beyond that, the list depends on the device type. For a typical office PC, chipset, LAN, graphics and audio drivers are often sufficient. For an all‑in‑one or laptop the set is broader: add Wi‑Fi, Bluetooth, camera, touchscreen and power management drivers.

A simple checklist of required categories is useful:

chipset, storage controllers, USB and core system drivers;
network adapters — LAN first, then Wi‑Fi if present;
graphics and audio for productivity apps and video calls;
Bluetooth if headsets, scanners or other peripherals are used;
touch, camera and special modules for all‑in‑ones and mobile devices.

Include only tested versions in the image. Don’t add the entire manufacturer bundle if it brings extra control panels, auto‑updaters and demo utilities. They clutter the system and complicate support.

A good practice is to maintain a separate version table. Record not only drivers but BIOS and, if needed, firmware for network cards, SSDs and other components. This helps quickly understand why two seemingly identical PCs behave differently.

For office PCs in the GSE L200 Series, stable network and graphics drivers are usually critical. For M200 Series all‑in‑ones, touch, camera and wireless modules are additionally important. The more precisely the set matches the specific model, the less manual tweaking the IT team will need.

Which policies to set in advance

With a properly configured image, new computers can be put into use much faster. The main rule is simple: set only policies that enhance security and do not interfere with normal user work.

First, limit unnecessary local administrator rights. Most users don’t need full access and it carries high risk. Someone might accidentally remove important components, install unsuitable software or disable protection. Better to separate roles from the start: IT staff get the access they need, others work under standard accounts.

Password rules and screen lock policies are also important. In practice simple things are often forgotten: short passwords, too long an idle timeout, or no auto‑lock. For an office, school, hospital or government body it’s safer to set a minimum password length, a password rotation period according to internal rules, and automatic lock after a few minutes of inactivity.

Configure updates and time sync in advance. If updates are left uncontrolled, some PCs will reboot at inconvenient times while others remain unpatched. The same applies to exact time: without it there are errors in event logs, domain authentication and certificate operations.

For USB drives and external devices choose a sensible, not overly strict, approach. A full ban doesn’t suit everyone. At minimum, disable autorun, restrict unknown devices and define rules for removable media. In some departments allow only approved models, in others provide read‑only access.

It’s helpful to enable basic event logging by default. Then after handover you can quickly see failed logins, update errors, driver issues or connection of external media.

A typical minimal policy set includes:

restrictions for local administrator rights;
password and auto‑lock rules;
update installation and reboot schedule;
restrictions for USB and external devices;
required level of logging for key events.

If a shipment of GSE computers arrives, such policies let you hand devices to departments almost immediately without per‑PC manual adjustments. IT retains control that can be proven through the logs.

Which certificates to include in the image

Certificates in the corporate image are not just a formality. If they aren’t prepared in advance, new computers will show browser warnings, fail to connect to Wi‑Fi, be unable to access VPNs or require manual email configuration.

A good image should give the device basic trust for the company’s internal infrastructure. Then the employee boots the PC and gets to work, while IT doesn’t spend days doing repetitive fixes.

What to add right away

Include the company’s root and intermediate certificates in the image. This is the trust basis for internal sites, portals, proxy services, document systems and other services that use a private certificate authority.

Without them a user will see security errors even on standard internal resources. For an office or government body this quickly becomes a flood of helpdesk tickets, although the issue could have been prevented during batch preparation.

Also prepare certificates or templates for services that need them:

802.1X‑protected Wi‑Fi;
VPN connections;
corporate email and encryption where used;
access to internal web services without warnings.

Don’t mix up shared and personal levels. Don’t place the same personal certificate on every device in the general image. Root and intermediate certificates are fine to include, while personal user certificates or device‑specific certificates should be issued during domain enrollment, via MDM or another managed process.

Before shipping, check expiration dates and the trust chain. Even a correctly built image will cause problems if an intermediate certificate is about to expire.

A minimum pre‑shipment check should include:

expiration dates of root and intermediate certificates;
correct trust chain for internal services;
status of certificates for Wi‑Fi, VPN and mail systems;
a clear date for the next review.

Equally important is the process for updating certificates. IT should have a straightforward way to replace them without manually touching every computer. This is usually done with group policies, MDM or centralized deployment after the device joins the corporate environment.

How to organize an acceptance log

An acceptance log is not for formalities but for quickly checking each machine after setup. If a month later a question arises about a driver, BIOS or image contents, the log should immediately show what was delivered to the user and in what state.

Keep a single template for the entire batch. This is particularly important when many devices arrive at once for an office, school, hospital or government body and you need to record what was accepted without confusion.

The record should include not only the model but precise device identification: serial number, inventory number and basic configuration. For batches of PCs and all‑in‑ones this helps quickly distinguish similar machines.

Include a separate field for the corporate image version and installation date. This simple line saves a lot of time. If some devices received image 1.3 and others 1.4, differences in settings become obvious.

Also note BIOS or UEFI versions, key drivers, OS and main service agents, and the date of the last update before handover.

After the first boot you don’t need a long multi‑page report. A short checklist confirming that the device is ready is sufficient. Typically record whether the system boots without errors, sees the network, whether audio, USB and the screen work, whether domain or local policies applied, and whether required certificates and mandatory software are installed.

If devices are handed to departments, add a simple status: accepted with no issues, accepted with remarks, or sent back for rework. Then the log becomes an IT working tool rather than an archive.

The entry should end with the responsible staff member, acceptance date and, if the process is formal, a signature or its electronic equivalent. Without this it’s unclear who confirmed the result.

A good acceptance log answers one question: can you tell from a single line what device this is, what’s installed on it and who confirmed it’s ready? If yes, the template is correct.

How to prepare the image step by step

A good image starts not with building Windows but with agreement. If IT wants one set of software, security another, and procurement demands a strict delivery list, you’ll get an image that needs rework after devices arrive.

First, draft a short image specification. Record who it’s for, which models it will be used on, which components are mandatory and what cannot be changed without separate approval.

Practical sequence

Consolidate requirements into one document. IT is responsible for compatibility and administration, security for policies and trusted certificates, procurement for the delivery contents and acceptance criteria.
Build the first version for one specific model, not for all devices at once. For example, if the company buys GSE L200 Series desktops, test the image on that platform first.
After the first successful installation, test the image on a small batch. One PC shows that the system boots, but several devices will reveal recurring failures, update or domain login issues.
When testing passes, finalize the composition. Record OS, driver, application, policy and certificate versions and the approval date.
Separately document post‑delivery steps: which updates are applied on day one, what the local IT specialist does and what remains unchanged until the next approved image.

This sequence reduces unnecessary manual work. If the image is tested on one model, then on a small batch and then frozen, support becomes noticeably easier.

Readiness is also clear: the device boots, completes initial login, sees the network, applies required rules and doesn’t prompt to manually install basic components. If this repeats reliably on the test batch, the image can be rolled out to the full shipment.

Example for an office or government body

Imagine a district administration or large office receiving 100 new workstations in one shipment. If each computer is set up manually, the IT team loses days or even a week. One PC lacks a driver, another didn’t receive policies, and a third user cannot log into the internal system.

With a ready corporate image the picture is different. All PCs arrive with the same basic configuration: necessary drivers are preinstalled, unnecessary features are disabled, security rules set, certificates added for internal services and secure email.

For government institutions this is especially important. Devices must quickly connect to the domain, document management system, internal portals and printers without lengthy on‑site adjustments. If the image is prepared and tested on a pilot batch, employees can start work the same day.

Acceptance is simpler in practice. The IT specialist only needs to check the computer name, user account, network connection and the entries in the log. This takes minutes, not hours.

Common mistakes when preinstalling

The main mistake is trying to make one image for every case. People start piling in extra programs, old utilities, trial versions and tools no one uses. Such an image takes longer to install, is harder to test and more likely to fail in the first days.

If an employee needs a standard office PC, they don’t need the same set as an operator, accountant or administrator. The simpler the base image, the easier it is to maintain and update.

One of the costliest errors is using one image for incompatible models. Even if hardware looks similar, drivers, firmware and service components may differ. Desktops and all‑in‑ones require different approaches, and servers even more so. If the shipment contains different lines, for example L200 Series, M200 Series and S200 Series, separate images by device type from the start.

Another frequent issue is forgotten certificates. The image was prepared, but shipment leaves weeks or months later. During that time certificates may expire, trust chains change or internal security requirements evolve. Acceptance looks fine at first, then access, signing or connection errors begin.

It’s also risky to include policies without security team approval. Users may end up with either too broad privileges or excessive restrictions and be unable to perform simple tasks: install an update, connect a token or access a service.

A useful pre‑release checklist is simple:

the image contains only required programs;
each model has its own tested variant;
certificates are refreshed before shipment;
policies are agreed between security and IT;
a rollback image is available.

Lack of a fallback image is often underestimated. If an error is found after mass deployment, without a rollback you’ll have to fix every PC manually. It’s much safer to store the last stable version and a change log.

Quick checks and next steps

Before mass handover it’s useful to run a short acceptance on 2–3 test PCs. This takes less time than later fixing dozens of identical user issues. A good image should pass this check without manual fixes.

In 10 minutes you can verify five things:

the PC boots without warnings or unexpected prompts;
Device Manager shows no unknown devices or driver errors;
the network works immediately, with access to the domain, required segment, shared resources and printing;
policies have applied and certificates are in the correct stores;
the acceptance log is filled so support can quickly see what’s installed and checked.

If any item fails, don’t release the image. Errors at the reference build stage almost always repeat across the entire batch.

Separately test domain login and printing. These are common spots for small but annoying failures: wrong time, missing root certificate, an incompatible printer driver or a partially applied policy.

After testing, record the image version and update rules. Don’t change contents during deployment without documenting what changed. Otherwise one batch will behave differently from another and finding the cause will take longer.

If the manufacturer or a system integrator supplies the equipment, agree the image composition, driver versions, policies and support boundaries in advance. For organizations in Kazakhstan this approach is particularly convenient for large rollouts. For example, GSE.kz as a manufacturer and integrator can handle a unified model range, base configuration and ongoing support so the IT team doesn’t have to assemble the process piece by piece.

The final step is simple: approve the reference image, test it on a small group and only then roll it out to the entire batch. This accelerates commissioning and significantly reduces support requests in the first week.