Automated Windows PC Provisioning: A PowerShell Tool with a UI Instead of a Clicking Marathon

The problem everyone knows

A new computer arrives. Someone from IT spends half a day installing the same programs, setting the same options, joining the machine to the domain and removing the preinstalled apps nobody needs. At a manufacturer with two sites this happened a few times a month – and slightly differently each time, depending on who did it.

In 2023 there was already a script for it. It worked as long as you knew which line to comment out first. That is not a tool; it is a memory aid for one person.

What the new tool does differently

In 2026 we replaced the script with a PowerShell tool with a WPF user interface. Choosing PowerShell was deliberate: it is on every Windows machine, IT can read it, and it needs no additional runtime. The UI was added because the tool should also be usable by people who do not want to open a command line.

The core functions:

• Profiles per department. Logistics, engineering, production, administration – each profile is a list of programs, settings and groups. A new profile is a new file, not new code.
• Detection of installed software. Before anything is installed, the tool checks what is already there. A machine being upgraded gets only what is missing.
• Dry run. Every configuration can be rehearsed first. The tool shows what it would do without touching anything.
• Logging. Every run writes a log with timestamp, profile, every step and every error. If a machine causes trouble later, you know how it was set up.
• Opt-in debloating. Preinstalled apps, advertising in the Start menu, telemetry settings – the tool can remove them, but only when explicitly ticked.

Why debloating is opt-in

We were asked why that is not simply the default. Two reasons:

First, some of the preinstalled components are actually needed in certain departments – for instance apps that interact with Microsoft 365. Second, debloating is the part most likely to break when Windows changes. A default run that damages a machine destroys trust in the whole tool. An opt-in you set deliberately is traceable.

The dry run paid off immediately

As with other tools, the dry run was the function with the biggest effect. Before the first productive use it found three errors in the profiles: an installation package that had been renamed, a group that no longer existed in AD, and a setting that had to differ between the two sites. Without the dry run we would have learned that on three real machines.

The AD scripts around it

A machine is only half of it. The other half is Active Directory: who belongs to which department, which security groups exist, is the organisational structure correct? We built a collection of scripts for that, sitting next to the setup tool:

• Set and verify the organisational structure – department, manager, site per user
• Create security groups following a fixed naming scheme
• Maintain addresses and phone lists
• CSV comparison against AD to find discrepancies between the staff list and the directory
• Sync triggers so downstream systems – such as the intranet – are current after a change

These scripts are unspectacular, but they are the reason the profiles in the setup tool work: a “Logistics” profile assumes there is a “Logistics” group and that it is populated correctly.

What we learned

• A script with comments is not a tool. As soon as someone else is supposed to use it, it needs profiles, checks and a UI.
• Detect before installing. Most machines are not new; they are being upgraded.
• Dry run and logging are not extras. They are what turns a script into a reliable tool.
• Plan for site differences early. Keyboard layouts, public holidays, groups – what applies at one site does not automatically apply at the other.

Takeaway

Setting up a PC is one of the most boring tasks in IT – and precisely for that reason one of the most rewarding to automate. The effort for the tool was modest, and it paid for itself after a few machines. More important than the time saved, though, is that every machine is now set up identically and has a log you can read afterwards.