The VISUS Deployment Toolkit (formerly project Deimos) aims to provide a partial replacement of the Microsoft Deployment Toolkit (MDT) for internal use at VISUS. The main motivation for this project are that (i) MDT seems to be abandoned by Microsoft and (ii) is based on VBS which is a deprecated feature in Windows 11. Project Deimos does not provide a full replacement for MDT, but only for the deployment tasks performed at VISUS.

The project consists of several components that limit the number of times the PXE image needs to be updated. This is mainly achieved by running the bulk of the deployment tasks from the deployment share and having a small bootstrapper that only mounts the share.

This is a minimal application that mainly mounts the deployment share into WinPE and starts the agent from the share. The boostrapper depends on Visus.DeploymentToolkit.Bootstrapping, which contains tasks that need to be performed by the boostrapper, but might also be used by the agent itself. Generally, as few tasks as possible should be placed here, because changes in the bootstrapper and its library require the PXE image to be rebuilt.

The agent performs the installation from WinPE and finalises it when booting into the installed operating system from the disk. The agent can use the tasks from Visus.DeploymentToolkit.Bootstrapping as well as the main deployment tasks defined in Visus.DeploymentToolkit. The steps performed by the agent include:

1. Partitioning the disk using the VDS.
2. Formatting the partitions using the VDS.
3. Applying the image to the disk using DISM.
4. Configuring the boot manager using BCDEdit.
5. Rebooting into the installed operating system.
6. Applying the unattend.xml file to the installed operating system.

The image builder is intended to create images to be served by the TFTP server. It must run on a machine with the Windows Automated Installation Kit (WAIK), including the Windows PE addon, installed. The image builder runs a built-in task sequence that

1. Copies the WinPE sources from the WAIK into a temporary folder
2. Mounts the boot.wim file used by WinPE
3. Copies an unattend.xml file from the deploymentshare into the boot.wim
4. Customises the unattend.xml in the boot.wim, most importantly to automatically run the bootstrapper
5. Copies the bootstrapper into the boot.wim
6. Commits the changes to the boot.wim

The task runner tool allows for executing individual tasks from the deployment toolkit. The application needs the following parameters, either via the command line or via appsettings.json: The StateFile where tasks relying on existing state can obtain this information from, and the Task, which is the class name of the work item to be executed. Parameters to the tasks (public properties of the task object) can be set via the Parameters configuration section.

For instance, one can create a deployment share via the Visus.DeploymentToolkit.Tasks.PrepareDeploymentShare task like this:

Visus.DeploymentToolkit.TaskRunner.exe /Task=PrepareDeploymentShare /Parameters:Path=d:\DeploymentShare

We do not have an installer yet, so the application needs to be built from source and deployed manually.

On the machine serving the deployment share, the Windows Automated Installation Kit (WAIK) must be installed as it provides the necessary imaging tools. Make sure to also install the '''Windows PE addon''', which contains the source files for the boot image used by the deployment agent. The WAIK is assumed to be installed in its default location (see Waik namespace).

Everything is expected to reside in a "deployment share", which is a shared folder the machines to be installed will access, with the following subfolders:

The binary folder holds the exectutable files of the agent. Publish the Visus.DeploymentToolkit.Agent project to this folder. Make sure to publish it in a self-contained way, because the WinPE image will not have the .NET runtime installed.

This folder holds the binaries of the bootstrapper that is embedded in the WinPE image. Publish the Visus.DeploymentToolkit.Bootstrapper project to this folder. Make sure to publish it in a self-contained way, because the WinPE image will not have the .NET runtime installed.

This folder holds the drivers that can be injected into the WinPE image and the installed operating system. You can use subfolders to organise the drivers.

This folder holds the operating system images. Typically, these are WIM files captured from a gold machine.

This folder holds the JSON files with the installation task sequences.

This folder holds template files, most importantly for the unattend.xml file that is used to configure the operating system.

All steps that can be executed by Project Deimos must implement the Visus.DeploymentToolkit.ITask interface. Typically, this is achieved by inheriting from Visus.DeploymentToolkit.Tasks.TaskBase. Tasks are configured via their public properties. The actual work is performed within ExecuteAsync.

Task sequences are usually authored by end users in the form of JSON files that are deserialised by the Visus.DeploymentToolkit.Workflow.ITaskSequenceStore. However, task sequences can also be created programmatically like this:

ITaskSequenceFactory tasks; // This should be injected from the DI.

tasks.CreateBuilder()
    .ForPhase(Phase.PreinstalledEnvironment)
    .Add<CopyWindowsPe>()
    .Add<MountWim>()
    .Add<CopyFiles>((t, s) => {
        ArgumentNullException.ThrowIfNull(s.DeploymentShare);
        ArgumentNullException.ThrowIfNull(s.WimMount);
        t.Source = Path.Combine(s.DeploymentShare!, DeploymentShare.Layout.BootstrapperPath);
        t.Destination = Path.Combine(s.WimMount.MountPoint, "deimos");
        t.IsRecursive = true;
        t.IsRequired = true;
        t.IsCritical = true;
    })
    .Add<UnmountWim>()
    .Add<CreateWindowsPeIso>()
    .Build();

The aforementioned tasks usually do only very little actual work besides processing user-provided parameters. For instance, the task for copying files mainly checks that all parameters are valid, but the actual copy is made by a copy service. This is the case for the majority of tasks, and the rationale behind this design is that certain basic work might be needed by multiple tasks. In order to build such compound tasks that use basic services, the services are provided by the dependency injection mechanism for reuse.