Installing the endpoint agent

A runbook, in order, for Windows and Linux. docs/windows-agent/DEPLOYMENT.md is the reference for what gets installed and why each choice was made; this is the sequence to follow.

---

0. What you are installing - read this first

For Windows fleet deployment, download MyDLPAgent.msi. The standalone agent executable remains the Linux artefact and a Windows diagnostic/bootstrap path; it is no longer the enterprise Windows installer.

Where Windows lists it, and where it does not:

You will notice	Why
It is in Windows Search	MSI writes an all-users Start Menu entry. It opens the page from §7 - what this software is, what it has recorded about this machine, and how to have it removed
It is in Programs and Features	Windows Installer owns one per-machine inventory row and its uninstall action - see §8
It is in Task Manager → Startup apps, as MyDLP Session, when installed by the graphical setup program or the MSI	dlp-session.exe starts the per-person session agent at every sign-in, with no window. The clipboard monitor, the justification prompt and the notifications run in it. It is an ordinary HKLM\…\Run value that an administrator can see and disable, and uninstall removes it (DLP-1126). The MSI's entry is written and has not yet been installed on a Windows host (DLP-1214). A scripted install from the standalone download registers none, because it carries no launcher
There is no application window	The agent is a service and a command-line tool. What a person opens is that page, which is a file rather than an application

The MSI places the binary, configures and enrols it before service start, registers the service and shell entry, and supplies rollback, upgrade, downgrade refusal, installer logging and inventory identity. The exact trust boundary and lifecycle are in Windows MSI installer.

1. Decide four things that cannot be defaulted

Decision	Why it is yours
Which paths are monitored	The single largest determinant of both coverage and cost. An agent with no configured paths scans nothing
Whether any of them is a cloud-synced library	Dehydrated placeholders are reported unscanned, on purpose. Correct, and surprising if unread - CAPABILITY_MATRIX.md §7
Antivirus exclusions	Two products walking one tree multiply I/O. Exclude the agent's own state directory from real-time scanning
Whether any policy is warn	A warning needs somebody at a keyboard. On a server estate nothing is delivered and the event says not_delivered - deliberately not failed

2. Get the package

In the console: Endpoints → Agent deployment. Each row gives the platform, the version, the size, the SHA-256 and a detached signature, with two links. For one Windows machine, the row to take is Windows installer (MyDLP-Agent-Setup.exe, §4): a window rather than a command. The bare dlp-agent-windows-x86_64.exe stays for scripted installs, and the MSI for fleets.

• Download - the binary.
• Config - a generated agent.toml for that platform, already carrying your server_url and the right state_dir. It contains no secret. The enrolment token is supplied once on the command line; the device identity is created on the endpoint.

Check the version in that row against the version you expect. The console serves what was last deployed, which is not necessarily what was last built.

3. Verify the package before you install it

dlp-agent verify-package dlp-agent-windows-x86_64.exe --signature <base64 from the console>

dlp-agent verify-package dlp-agent-linux-x86_64 --signature <base64 from the console>

Non-zero exit means do not install it, whatever the hash says. Checking the hash proves the file arrived intact; checking the signature is what makes it trustworthy independently of the server, because a compromised server can report a hash matching whatever it served and cannot forge a signature without the key.

Run this on a machine that is already enrolled. With no --key the command verifies against the keys that endpoint was enrolled with, which the server cannot change without the endpoint noticing - and that independence is the whole point. The public_key_b64 in the console listing is not an independent copy: it comes from the same server as the package.

The first endpoint is a genuine exception. There is no enrolled machine to verify against yet, so the first install is trust-on-first-use over TLS. Do it from a machine you control, keep a copy of the public key from that install in your own key custody, and verify every later package against an enrolled endpoint. Pretending this step is available on endpoint number one would be worse than naming it.

Authenticode

Nothing shipped is Authenticode-signed yet. The console says signed for the Ed25519 signature above and no Authenticode for this, and the distinction is real:

• SmartScreen will warn, and on a managed fleet WDAC or AppLocker may refuse to run the binary at all.
• An administrator double-clicking it sees an unknown-publisher dialog.
• §3's signature check is the substitute, and it is a good one - but it is our check, run deliberately, not one Windows performs for you.

The protected build/HSM workflow is implemented in . DLP-1175 remains blocked on the public-trust organisational certificate and the first production verification record. The key has to be bought and held somewhere this repository is not.

4. Install

One Windows machine: the installer (DLP-627)

Run MyDLP-Agent-Setup.exe. Windows asks once for permission to install - it writes to Program Files and registers a service - and then a window, never a console, takes you through four pages:

1. What this agent does on this computer. First, and not skippable: what it checks, what it sends, and what it never records.
2. Connect - the server address and the one-time enrolment token from Endpoints → Agent deployment. http:// is refused beside the field rather than quietly upgraded, because the token travels over it (DLP-506).
3. Installing, with a bar and the step named: Verifying package, Writing the configuration, Enrolling with https://…, Installing service, Starting protection. There is no Cancel once this starts: the machine is being changed, and stopping halfway is the half-installed agent the installer exists to prevent.
4. Protection is active - this computer's name as it appears under Endpoints - or Setup did not finish, with one of three sentences: the server refused the token (make a new one), the server could not be reached (check the address, proxy, firewall), or this machine does not trust the server's certificate (install your organisation's certificate authority). A failure before the service step says no service was left installed, and Back returns to the form with what was typed still there.

Underneath it is the same dlp-agent install the MSI and the command line use: the installer carries the agent, checks it is the one it was built with, and runs install --progress hidden, handing it the token in its environment and never on a command line another process could read. It writes the same Apps & Features entry, so removal is the same.

A Windows fleet: the MSI

For a Windows fleet, use the MSI from an elevated deployment context:

msiexec.exe /i MyDLPAgent.msi /qn /norestart `
  SERVERURL=https://dlp.example.com ENROLLTOKEN=<one-time-token> `
  /l*v C:\Windows\Temp\mydlp-install.log

The token is a hidden secure MSI property and is not retained or printed in the MSI log. A failed enrollment rolls back without registering or starting a service. A higher-version package upgrades without a second token and preserves endpoint identity.

Running it again over an agent that is already there (DLP-441)

An upgrade is the ordinary path, not something to prepare for. Running the installer on a machine that already has the agent:

• stops the service, and waits for it to actually stop - sc stop asks, it does not wait, and a copy attempted against a service still in STOP_PENDING is the copy that fails;
• if the image is still loaded - started outside the service, or a handle that has not closed - renames the existing binary aside and copies the new one into the name that is now free. Windows permits renaming a loaded image even where it refuses to overwrite one. The displaced file is removed by the next run, once nothing holds it;
• leaves the service as it found it. An installer run is not a decision to start an agent somebody stopped on purpose - a machine under investigation, or one where the agent is being held off while something else is fixed. It starts the service if this run created it, or if it was running before.

Until v0.213.0 the installer stopped at Access is denied and asked the operator to stop the service by hand, which also meant a re-enrolment after a revoke never reached the console: the copy failed before enrolment was attempted.

Standalone bootstrap path

Double-click the downloaded .exe. Windows asks for administrator rights, then a window asks two questions:

  MyDLP endpoint agent - setup

  Server address (e.g. https://dlp.example.com): _
  Enrolment token (console → Administration): _

and it does the rest. On Linux the same thing is sudo ./dlp-agent-linux-x86_64 with no arguments. Either way it is dlp-agent setup, which can also be typed.

The standalone Windows executable still supports this console flow for a single-machine recovery or diagnostic install. It is not the fleet deployment artefact and does not replace the MSI transaction or inventory identity.

The elevation prompt comes before the questions, deliberately: an enrolment token is single-use, and asking somebody to paste one and only then telling them to start again as an administrator would spend it on a run that cannot finish.

Standalone, non-interactively

# Windows, from an elevated prompt
.\dlp-agent-windows-x86_64.exe install --server https://dlp.example.com

# Linux
sudo ./dlp-agent-linux-x86_64 install --server https://dlp.example.com

install is the same work with the answers passed rather than asked, which is what a deployment tool needs. It does every step: places the binary, writes the configuration and the state directory, enrols, registers the service and starts it.

install --server https://dlp.example.com --token <token>

DLP_ENROLLMENT_TOKEN works too, and is the better choice - a token on a command line is in the shell history and in the process list, readable by anyone on the machine for as long as the command runs. That is also why setup asks for it rather than taking it as a flag.

Flag	For
--token	Non-interactive installs. Omit it at a terminal and you are asked
--prefix <dir>	Everything under one directory instead of the platform's locations
--no-start	Register the service, leave it stopped
--no-service	Place and enrol only; supervise it yourself
--force	Replace an existing configuration and identity

It is safe to re-run. Nothing is copied that is already in place, no configuration is overwritten, and a machine that already has an identity is not re-enrolled. A run that failed part-way resumes rather than starting again.

The order, and why enrolment is not last

Place → configure → enrol → register the service → start.

Enrolment is fourth rather than last on purpose. It is the step that makes the machine exist: the row under Endpoints is written by the enrolment handler and by nothing else, so a machine with the binary in place and the service running is, from the console, not installed at all. Putting enrolment before service registration means a spent or mistyped token fails while nothing has been registered - and the command says so rather than reporting success.

If you see this, the install did not work, whatever else succeeded:

✗ This machine is NOT enrolled, so it will not appear in the console
  however healthy it looks here.

What it configures

Item	Windows	Linux
Binary	C:\Program Files\MyDLP\dlp-agent.exe	/opt/mydlp/bin/dlp-agent
Notification-area icon	The cyberkap mark, in every signed-in person's session, unless the tenant turned it off (tray_icon). Windows 11 starts a new icon in the hidden-icons overflow ("^"). To show it, the person uses Settings → Personalisation → Taskbar → Other system tray icons. Windows records the choice per user under HKCU\Control Panel\NotifyIconSettings (IsPromoted), which is not a documented interface. The agent does not set it, because it is the person's setting (DLP-1958)	none
Toast image	C:\Program Files\MyDLP\cyberkap.png, the mark Windows draws on the agent's notifications. Written by the console install and by every update, shipped as a file by the MSI, removed with the folder (DLP-1898). Named to Windows only when the agent runs from Program Files	none
Configuration	C:\ProgramData\MyDLP\agent.toml	/etc/mydlp/agent.toml
State	C:\ProgramData\MyDLP\agent	/var/lib/mydlp/agent
Service	MyDLPAgent, delayed automatic start, LocalSystem, restricted DACL, three escalating restart delays	mydlp-agent.service, Restart=always, the full hardening set from deploy/mydlp-agent.service

The generated configuration holds two settings - the server URL and the state directory - because everything else has a default that is right for most machines, and a file listing forty settings invites somebody to change one without knowing what it does. It holds no secret: the token is never written, and the device key pair is generated on the endpoint with the private half never leaving it.

5. Installing by hand instead

The one command is what the steps below do, and they remain supported for an estate that wants each one under its own change control.

Windows, manually

msiexec.exe /i MyDLPAgent.msi /qn /norestart `
  SERVERURL=https://dlp.example.com ENROLLTOKEN=<one-time-token> `
  /l*v C:\Windows\Temp\mydlp-install.log

The MSI deliberately keeps file placement, enrollment, service registration and start inside one rollback boundary. Splitting those steps by hand would recreate the partial-install state the package exists to prevent.

Linux, manually

sudo install -D -m 0755 dlp-agent-linux-x86_64 /opt/mydlp/bin/dlp-agent
sudo install -D -m 0600 agent.toml /etc/mydlp/agent.toml
sudo install -d -m 0700 /var/lib/mydlp
sudo cp deploy/mydlp-agent.service /etc/systemd/system/
sudo systemctl daemon-reload && sudo systemctl enable --now mydlp-agent

Run systemd-analyze verify /etc/systemd/system/mydlp-agent.service after any local edit: systemd only warns about a directive in the wrong section and then ignores it, so a mistake leaves the default in place and looks like it worked. Then enrol - §6.

The systemd unit is the watchdog, deliberately rather than incidentally: a process that restarted itself from somewhere unexpected, hid from the process list or resisted being killed would be indistinguishable from malware, and would be treated as malware by whatever endpoint protection is already installed. systemd is the opposite - visible where an administrator already looks, and systemctl disable --now mydlp-agent stops it in one command by somebody entitled to.

6. Enrol

1. Console → Administration → Generate enrolment token. It is single-use.
2. Get it to the endpoint by whatever your fleet already trusts.
3. Run it:

dlp-agent.exe enroll --token <token>

sudo DLP_AGENT_CONFIG=/etc/mydlp/agent.toml /opt/mydlp/bin/dlp-agent enroll --token <token>

The token is consumed once, never persisted and never logged. It is only as protected as whatever carries it - a token in the body of a plain-text Group Policy startup script is readable by every authenticated user in the domain. That is a property of that deployment choice rather than of this agent, which is exactly why it is written down here.

The key pair is generated on the endpoint. The private half never leaves it.

7. Check it worked, on the endpoint

dlp-agent doctor          # everything needed to work, checked
dlp-agent status          # identity, policy version, queue depth
dlp-agent capabilities    # what THIS machine can observe, not what its platform can
dlp-agent history         # what it has reported
dlp-agent requests        # what somebody asked for, and what was decided
dlp-agent requests --withdraw EXC7K2   # take back your own pending request (through the service)
dlp-agent ui              # the page, for the person whose machine it is

ui and requests are the two written for the person whose machine it is rather than for you.

ui is the page. On Windows they do not need the command: Start → MyDLP finds the same page, which is what the entry is for. It is also named in the justification prompt and in every block notice, because those are where most people first hear that this software exists.

requests answers what happened to the thing I asked for (DLP-461). It reads the endpoint's own ledger rather than asking the server, deliberately: the person most likely to run it is the one whose endpoint cannot reach it, and an answer that has not arrived reads as still waiting rather than as a guess in either direction. Its four state words are in the reader's own language, because they are the whole content of the answer. The same rows are on the page under What you asked for, which appears only once something has been asked.

doctor answers the connection question twice. Agent's server connection is what the running agent recorded: when it last reached the server, and its last failure with the error if nothing has reached it since. Server reachable from doctor is doctor's own signed probe, made from the prompt you ran it in. It is not a check-in (DLP-1311): it collects none of the commands queued for the endpoint, records no health, does not move the console's "last seen", and fetches no policy. When the second passes and the first fails, the server is up and the difference is in the service's context (its account, its proxy, or the network at that moment) (DLP-1310).

capabilities is the one to read before promising anything: it answers for the machine in front of you rather than for its operating system, which is the distinction that matters as soon as any channel is conditional.

Then confirm the endpoint appears in the console with a recent last_seen_at. An endpoint that enrolled and never checked in is a connectivity problem, and doctor will usually already have said so.

8. Removing it

The ordinary way is the button. Settings → Apps → cyberkap Endpoint Agent → Uninstall. It runs dlp-session.exe --uninstall, which has no console (DLP-1320). The permission prompt names cyberkap Endpoint Agent. The same uninstall the commands below run then runs hidden, and records the removal as authorised (windows-add-remove-programs, which is what actually happened rather than a change ticket nobody has). It ends with one Windows dialog that says the agent was removed, or what did not happen: events that could not be sent, the server not told, a service that would not stop.

On an install the setup program made, uninstall also stops and deletes the MyDLPAgent service, and deletes C:\Program Files\MyDLP as soon as nothing in it is running. Before DLP-1320 it left both, and the service went on calling a server that refused it. On an MSI install, Windows Installer removes the service and the files itself. Either way, what stays is anything quarantined (C:\ProgramData\MyDLP\agent\quarantine), which is your organisation's data; everything else the agent kept in its state directory goes (DLP-1338).

An uninstall ordered from the console removes the same things (DLP-1323). The service delivers what is queued and tells the server, then starts a detached dlp-agent uninstall that removes the service, the program folder, the state, the listing and the Start menu entry. Before, the console's order wiped the identity and stopped the service, which stayed registered to start again at the next boot.

Use the commands below when you want your own change reference on the record, when there is no console session, or when the entry is not there - an agent installed by hand, or by a build older than v0.126.

Run uninstall before you delete anything. It is the only step that tells the server, delivers the events still queued, and removes the key material; and it is the agent's own executable that does it. Delete the executable first and that step is gone - what is left is a directory you have to take ownership of, and a console that reads the removal the way it reads an unauthorised one.

Windows, in an elevated PowerShell (right-click → Run as Administrator; the state directory is closed to everything but SYSTEM and Administrators, so an ordinary prompt gets Access is denied on the third line and no explanation):

& "C:\Program Files\MyDLP\dlp-agent.exe" uninstall --confirm `
    --authorization "CHG-1234" --reason "decommissioned"

That removes the service and the program folder too, on a setup-program install (the folder goes a few seconds after the command exits). On an agent from before DLP-1320, stop and delete the service yourself first and remove the folder after: sc.exe stop MyDLPAgent, sc.exe delete MyDLPAgent, Remove-Item -Recurse -Force "C:\Program Files\MyDLP". Deleting C:\ProgramData\MyDLP as well destroys anything quarantined, so look first.

Linux:

sudo systemctl disable --now mydlp-agent
sudo /opt/mydlp/bin/dlp-agent uninstall --confirm \
    --authorization "CHG-1234" --reason "decommissioned"
sudo rm -rf /etc/systemd/system/mydlp-agent.service /opt/mydlp/bin/dlp-agent \
    /etc/mydlp/agent.toml /var/lib/mydlp
sudo systemctl daemon-reload

C:\ProgramData\MyDLP and /var/lib/mydlp are the state directory. They are listed because uninstall empties them and does not remove them: it deletes the files it put there and leaves the directory, the configuration file beside it, and anything quarantined. Leaving them behind does not leave a secret - the identity, the device key and the EDM keys are gone by then - but it does leave a machine that looks half-uninstalled to the next person who looks.

When the directory will not delete

C:\ProgramData\MyDLP\agent - Access is denied from an elevated prompt means the ACL outlived the account that owned it. The directory is deliberately protected - SYSTEM and Administrators, no inheritance - so take it back first. Since DLP-1556 the service also sets the folder above it, C:\ProgramData\MyDLP, at every start: SYSTEM and Administrators write, Users read and nothing more, with no inheritance from ProgramData. Before that it kept ProgramData's grant letting any user create files and folders in it. Since DLP-1690 the service also gives agent.toml its own protected ACL of the same shape, owned by Administrators, at every start. If an account other than SYSTEM or Administrators owned it, the Application log gets a warning naming that owner, because the file decides which server the endpoint reports to. The same commands take it back:

takeown /F "C:\ProgramData\MyDLP" /R /D Y
icacls "C:\ProgramData\MyDLP" /grant Administrators:F /T
Remove-Item -Recurse -Force "C:\ProgramData\MyDLP"

From a non-elevated prompt the same message means only that the prompt is not elevated. That is the ACL doing its job: an agent whose state any user could delete is not tamper-resistant, and the same protection is what made a non-elevated enrolment report itself as a spent token until DLP-285.

--authorization, with a z. --confirm is required and the command refuses without it. --authorization is not enforced by the parser - an agent that could not be uninstalled because somebody had no ticket number would teach administrators to kill the process instead - but leaving it off does not make the removal quiet, it makes it unexplained: the server is not told, the endpoint stops reporting, and the console reads that the way it should read an unauthorised removal.

Queued events are delivered first, where the server can be reached. Removed: identity, EDM keys, cached policy, the event queue, the fingerprint cache, local history, the run marker and the agent's own logs. Left behind on purpose: quarantined files, because they are your data rather than the agent's, and an uninstall is the wrong moment for software to decide it should be destroyed. The command counts them and names the directory.

9. Rolling out to more than one machine

1. One machine first, for a week, with the policies you actually intend - not a reduced set. Most surprises are about which paths were monitored and what that cost, and neither shows up on an idle test box.
2. Then a ring, chosen for variety rather than convenience: a laptop that goes offline, a machine with a cloud-synced library, one with the antivirus your fleet actually runs.
3. Compare dlp-agent capabilities on a real endpoint against what the policy asks for before enabling anything preventive. A policy asking for more than a channel supports is reduced to what it supports and the incident records both - which is honest, and is not the same as the control you thought you had.
4. Only then the fleet.

Group Policy (DLP-219)

Copy the template to the domain's central store:

\\<domain>\SYSVOL\<domain>\Policies\PolicyDefinitions\MyDLP.admx
\\<domain>\SYSVOL\<domain>\Policies\PolicyDefinitions\en-US\MyDLP.adml

Both ship in deploy/windows/policy/. The settings then appear under Computer Configuration → Administrative Templates → MyDLP → Endpoint agent.

Everything there writes to HKLM\SOFTWARE\Policies\MyDLP\Agent, which the agent reads at start-up. Policy overrides agent.toml, deliberately: a machine somebody edited by hand must not be a machine outside the policy. The agent logs which settings came from policy and which came from the file, at info, because a value that cannot be traced to its source is one nobody can change with confidence.

Policy does not override the product's own refusals. A policy that points an endpoint at plain http is rejected by the same rule that rejects a hand-edited file that does.

How to package the MSI, issue and rotate the tokens, and stage rings with Group Policy is in Rolling the Windows agent out with Group Policy. One point shapes it. A fresh install needs a token, and the MSI takes it from either ENROLLTOKEN or the EnrollmentToken Group Policy setting. On the second route the service enrols at its first start, so the runbook's startup script runs msiexec with no properties and the token is never on a command line (DLP-1191).

The enrolment token in a GPO, said plainly

A token set in Group Policy is readable by every authenticated user in the domain. Registry policy travels through SYSVOL, and SYSVOL grants Authenticated Users read. Anybody with a domain account can read it, take it, and enrol a machine of their own into your tenant.

That is a property of Group Policy rather than of this product, and the setting exists anyway - because the alternative is not that nobody does it, it is that everybody does it in a deployment script with the same exposure and no warning. The same sentence is in the ADMX help text, where an administrator is standing when they type it.

Use it only with a token whose exposure you have accepted: short-lived, minted for one imaging run, with a use count matched to the number of machines. Not a long-lived one with a high use count.

An endpoint that is already enrolled ignores it. The token is used once, is never written into agent.toml, and is not retained.

The service is what uses it (DLP-558; until then nothing read the value). On start, an endpoint with no identity and a token in policy reports RUNNING and then enrols, retrying from 30 seconds up to every 15 minutes until it succeeds or the service is stopped - an image usually boots before its network is up. Event 2001 says it enrolled and as which device; event 3004 says it is still waiting and why. Neither carries the token. An endpoint with no identity and no token still fails to start, as before, because it has nothing to run.

10. What this runbook cannot give you yet

• MSI evidence is from one hosted Windows image, not a domain-joined fleet, a genuine Server 2016 machine, a disk-full volume or a reboot.
• No production Authenticode signature yet (DLP-1175), so SmartScreen warns and application control may refuse the binary outright. The protected signing implementation and its remaining external setup are in .
• No packaged browser extension on Windows (DLP-236), so the browser upload channel is not covered there however the agent is installed.
• Operator-driven major upgrades are built, and so is the offline path as far as staging: dlp-agent update --from <directory> reads an update-manifest.json beside the artefact, refuses an expired manifest or an agent below the manifest's upgrade floor, and verifies size, digest and signature against the keys the endpoint was enrolled with - not against anything that arrived on the same medium. It then stops and says the artefact is staged. It does not run the installer (DLP-447, DLP-448). Automatic signed update orchestration remains the separate work decided in SPIKE-009.
• The installer has not been clicked through on Windows at all. A CI step is written to drive it on windows-latest through UI Automation, and it has not yet passed on windows-latest (Windows CI status). It would check that the window opens with no console, the first page is what the agent does, http:// is refused beside the field, and an unreachable server ends on its own failure page with no service left - and keep a screenshot of each page. The success page needs a management server behind https:// with a certificate the runner trusts, which CI does not have; nor does CI set dark mode or 200% scaling. Those screenshots are a person's to take (DLP-627).
• Removing it from Apps & Features still opens a console: the entry runs dlp-agent uninstall --interactive, which asks for elevation and says whether the server was told. It is correct and it is not a window yet.
• The bare executable's own double-click wizard (console, DLP-283) is still there for anybody who runs dlp-agent-windows-x86_64.exe directly; its UAC request and console-ownership check compile for the target and have not been clicked. The installer is the path to give a person.
• install is written to be exercised end to end on windows-latest, and has not been, there or anywhere else: the windows-e2e job has not yet got past enrolment (Windows CI status). windows_verification.ps1 step 7b would run it twice: once with a token that cannot work, to assert that a failed enrolment registers no service, and once with a token the script mints through the API, which places the binary, enrols, registers the service, starts it, and then waits for the endpoint's last_seen_at to turn non-null. What is asserted about the service is what sc.exe was told - binPath ending in service, delayed-auto, LocalSystem, the escalating restart actions, the day-long failure reset, and a descriptor that lets administrators remove the agent and ordinary users only watch it. This is a GitHub runner, so it is one machine, one Windows build, and a loopback server.
• None of this has been run against a fleet. The steps are the ones the product supports; the number of machines they have been performed on is small.