The service
| Name | dplens |
| Display name | DPLens |
| Start type | Automatic |
| Runs | dplens.exe --service run --config "C:\ProgramData\DPLens\config\agent.yaml" |
| Depends on | The Windows Event Log service, and TCP/IP |
sc.exe query dplens
sc.exe start dplens
sc.exe stop dplens
If it fails
Windows restarts it automatically, with a growing interval between attempts. After repeated failures in a short period it is left stopped rather than restarted forever — a machine in a restart loop is worse than one that has stopped and can be seen to have stopped. The counter resets after a quiet period.
Alert on the service not running. A stopped agent is a silent gap in your logging, and it is the one failure the agent cannot tell you about itself.
On shutdown
The service asks Windows for time to stop cleanly, so that in-flight events are checkpointed rather than abandoned. That means a shutdown or reboot may take a few seconds longer while a busy agent finishes.
The account
By default DPLens runs as NT SERVICE\dplens, a virtual service account created for it.
A virtual service account:
- has no password, and nothing to rotate or leak,
- cannot log on interactively,
- exists only on this machine,
- cannot be used by anything else.
It holds only the privileges it needs to do its job, and nothing else. The Security tab in the console shows the account it is running as.
LocalSystem
If your environment cannot use virtual service accounts, install with SERVICE_ACCOUNT=localsystem. This is a broader account and the choice is recorded in the audit log.
You can switch between the two by installing again with the other value; your configuration and state are kept.
The console runs separately
The console is a separate process with fewer privileges, under its own account, started and supervised by the collection service.
It cannot read your event logs, cannot reach your destinations, and cannot read the secret store. It asks the collection service to do those things and renders the answers.
A fault in the web interface therefore cannot become a fault in collection, and cannot reach the machine's privileges. If the console process dies, the service restarts it; collection is unaffected either way.
Folder permissions
At installation, and again at every service start, DPLens applies and verifies permissions on:
C:\Program Files\DPLens\
C:\ProgramData\DPLens\
C:\ProgramData\DPLens\config\
C:\ProgramData\DPLens\state\
C:\ProgramData\DPLens\state\cache\
Only administrators and the service account may read them. Ordinary users cannot, which matters because these folders hold your configuration, your sealed secrets, your audit log, and — in the cache — log data that has not yet been delivered.
If something changes those permissions, DPLens puts them back at its next start and records having done so. If it cannot verify them, it says so in the console rather than carrying on quietly.
To check them yourself:
icacls C:\ProgramData\DPLens
What DPLens needs to reach
| To do this | It needs |
|---|---|
| Read event log channels | Nothing extra — the service account can, by virtue of being a service |
| Read log files | Read access to the path. Grant it to the service account. |
| Read files on a network share | Access for the computer account, not NT SERVICE\dplens, which is local to the machine |
| Watch files for integrity | Read access to the watched paths |
| Receive syslog or NetFlow | An inbound firewall rule for the port you configured |
| Deliver to your SIEM | Outbound access to the destination address and port |
Secrets
Secret values are sealed to this machine. They cannot be read back, and copying the state folder onto a different, separately-installed machine does not carry them — that copy cannot unseal them.
Sealing is not a boundary between accounts on the same machine; the folder permissions above are. And it is not a reason to bake secrets into an image: seed them on each machine instead. See Golden images and VDI clones.
Application control
If you run AppLocker or Windows Defender Application Control, allow C:\Program Files\DPLens\dplens.exe by publisher or by path.
The agent checks its own signature at start-up and records the result in the audit log, so a change to the installed binary is visible in the record.