Migrating from the Splunk Universal Forwarder to DPLens, with your searches still working.

What maps to what

DPLens is a UK-built, self-hosted log collection and security data pipeline agent for Windows. It sends to Splunk over the protocol forwarders use to reach indexers (cooked S2S, conventionally port 9997) or over the HTTP Event Collector. You set everything below in the agent's console on one machine, or centrally for the fleet in DPLens Manager.

Step 1: inventory what the forwarder does

Don't read inputs.conf in one app folder and assume that's the whole picture. Settings merge across apps, so ask the forwarder for the effective configuration, with the file each line came from:

cd "C:\Program Files\SplunkUniversalForwarder\bin"
.\splunk.exe btool inputs list --debug  > C:\temp\uf-inputs.txt
.\splunk.exe btool outputs list --debug > C:\temp\uf-outputs.txt
.\splunk.exe show deploy-poll

Do this for one representative host per server class (domain controllers, file servers, IIS, SQL Server, workstations). For each, record:

• every enabled WinEventLog stanza, with its index, renderXml, whitelist and blacklist lines
• every monitor stanza, with its sourcetype, index and any whitelist/blacklist on file names
• scripted, perfmon, WinHostMon, WinRegMon or admon inputs, listed separately with an owner and a decision for each
• the tcpout groups, indexers, useACK and SSL settings
• the deployment server and server classes that deliver each app

Then search your Splunk content for anything that reads the forwarder's own logs, such as index=_internal searches on forwarder hosts and forwarder dashboards in the Monitoring Console. That content retires with the forwarder, so plan its successor now (see Monitoring the fleet).

Step 2: map inputs.conf to sources

A typical Windows forwarder configuration:

[WinEventLog://Security]
disabled = 0
index = wineventlog
renderXml = false
current_only = 0
blacklist = 4658,4690
blacklist1 = EventCode="4662" Message="Object Type:(?!\s*groupPolicyContainer)"
blacklist2 = EventCode="5156" Message="Destination Address:\s+(127\.0\.0\.1|::1)"

[WinEventLog://System]
disabled = 0
index = wineventlog
renderXml = false

[monitor://C:\inetpub\logs\LogFiles\W3SVC1\*.log]
disabled = 0
index = web
sourcetype = ms:iis:auto

The same collection in DPLens, set in the agent console or in DPLens Manager:

• A Windows Event Log source for the Security channel, starting from new events, excluding Event IDs 4658 and 4690 at the source. As an XPath query, that exclusion is *[System[(EventID!=4658 and EventID!=4690)]].
• A Windows Event Log source for the System channel, starting from new events.
• A file source for C:\inetpub\logs\LogFiles\W3SVC1\*.log, starting from new lines.
• On the Security pipeline, a filter that drops Event ID 5156 where the destination address is 127.0.0.1 or ::1, the field-based equivalent of blacklist2.
• Each source delivering to the Splunk destination from Step 4.

The configuration examples in the documentation walk through each of these.

Points to watch:

• Start every source from new events. The forwarder has already sent the history. File sources read existing content unless you tell them otherwise, which would re-send every existing IIS log.
• Plain event-code lists belong at the source, where excluded IDs are never collected. Use the source's exclude field or your own XPath query.
• Message regexes need translating, not copying. The UF's blacklist1 matches rendered message text. DPLens filters on event fields. For 4662, the raw ObjectType is a schema GUID rather than the class name, so look up the class's GUID and filter on that.
• One source per channel when the channels need different source values in Splunk, because Splunk metadata overrides are set per source.
• Rendered messages. If searches depend on the rendered Message text, choose the Windows Event Log source's Universal Forwarder classic rendering, and compare the result on Live stream with what the forwarder sends.

Step 3: keep index, source, sourcetype and host

Splunk searches, dashboards and correlation rules key on index and sourcetype. The DPLens documentation puts it bluntly: if they don't match what your content expects, "the data arrives and nothing finds it". Find out what your indexes actually hold today, not what you think they hold:

| tstats count where index=wineventlog OR index=web by index, sourcetype, source

The sourcetype for Windows events depends on your Splunk Add-on for Windows version and on renderXml, so copy what you see here. In DPLens you set each value on the Splunk destination (see index, host, source and sourcetype), as a fixed value or taken from an event field, with per-source overrides. Rendering is chosen per destination, so if your inputs mix renderXml = true and false, use two Splunk S2S destinations to the same indexers, one for each rendering.

Check host too. Taking it from the event's Computer field gives the name Windows records, which may be a fully qualified name where your forwarder sent a short one. Dashboards keyed on host will notice.

Step 4: map outputs.conf to an S2S destination

[tcpout]
defaultGroup = primary_indexers

[tcpout:primary_indexers]
server = idx1.example.com:9997, idx2.example.com:9997, idx3.example.com:9997
autoLBFrequency = 30
useACK = true
clientCert = $SPLUNK_HOME\etc\auth\mycerts\client.pem
sslPassword = <encrypted>
sslVerifyServerCert = true

The equivalent in DPLens is one Splunk S2S destination:

• The pool. List idx1, idx2 and idx3 on port 9997 as a load-balanced pool, rotating every 30 seconds. DPLens spreads traffic across every member, takes a member out of rotation when it stops accepting and brings it back once healthy. Events wait in the disk cache only when every member is down.
• Metadata. Index wineventlog, sourcetype WinEventLog, host from the event's Computer field, and source WinEventLog:Security or WinEventLog:System per source; the IIS source overrides index to web and sourcetype to ms:iis:auto.
• Acknowledgement. useACK maps to indexer acknowledgement on the destination. With it on, an event counts as delivered only once the indexer confirms it. Turn it on where you need indexer confirmation, and measure throughput on the pilot.
• TLS. TLS on S2S is opt-in, as on a stock 9997 receiver, and once it is on, certificate validation is on, against the Windows trust store or a CA you supply. If your indexers require client certificates, add the client certificate and key to DPLens, which stores them as protected secrets.
• Queueing. Each destination has its own disk cache, sized for your outage window. When it fills, the default is to pause collection, and any drop is counted.
• Two tcpout groups (cloning to two Splunk environments) become one pipeline delivering to two destinations, each with its own queue.

Monitoring the fleet after the forwarder

For agent health, alert on the data itself. It is a strong signal whatever agent you run, because it catches an agent that is running but collecting nothing:

| tstats latest(_time) as last_seen where index=wineventlog by host
| where last_seen < relative_time(now(), "-30m")

Alongside it, DPLens Manager monitors fleet health centrally. On each host, the DPLens console shows source health, delivery state, cached backlog and counted losses, and every configuration apply and rollback is recorded in the agent's tamper-evident audit trail.

Step 5: run both and compare

The documented procedure has four steps. Configure DPLens alongside the forwarder, delivering to the same indexers with the same index and sourcetype. Compare what arrives from each over a period you're comfortable with. Stop the forwarder. Remove it.

One optional refinement makes the comparison easier. On a small pilot group, point DPLens at a temporary validation index (for example wineventlog_dplens, created on the indexers first) for a day or two. Then compare like for like:

| tstats count where (index=wineventlog OR index=wineventlog_dplens) host=PILOT-* earliest=-24h
    by index, sourcetype, host

(index=wineventlog OR index=wineventlog_dplens) host=PILOT-* earliest=-24h
| chart count over EventCode by index

Investigate any Event ID whose counts differ beyond what your filters explain. Run your most-used saved searches and dashboards against the validation index, and check that fields extract the same way. Then switch the pilot to the production index and continue as documented.

While both agents run, the same events are sent twice and count twice against a volume-based licence. Keep the overlap short and the pilot small.

Step 6: cut over by server group, with a rollback

1. Order. Pilot first, then member servers, file and application servers, and domain controllers last. DCs carry the most detection content.
2. Start DPLens before stopping the forwarder. Starting from new events, DPLens collects from the moment it starts, so starting it first gives overlap rather than a gap.
3. Stop and disable, don't uninstall yet:

   sc.exe stop SplunkForwarder
   sc.exe config SplunkForwarder start= disabled

4. Watch the group for one full business cycle: counts per sourcetype, your heartbeat search, fleet health in DPLens Manager, and the DPLens Overview for losses and cached backlog.
5. Rollback is the reverse. Set the forwarder back to start= auto, start it, and stop DPLens or disable its pipelines. The forwarder resumes from its own checkpoint, so expect duplicates for the overlap rather than a gap, provided the Windows channel still holds the events. Confirm this on the pilot.
6. Remove the forwarder once the group has been stable for as long as your change process requires, using whatever deployed it. Unsubscribe the hosts from the deployment server at the same time, so it doesn't reinstall apps.

Step 7: deploy at scale

The documentation suggests a sensible order. Configure one machine the way you want the fleet to run, and let it run until you are satisfied with what arrives at the indexers. That configuration is the reference. Then roll it out:

• With DPLens Manager. Included in every subscription, it gives you central configuration, fleet health monitoring, and deployment and upgrades, and it is self-hosted and air-gap capable.
• With your existing tools. Group Policy, Intune, Configuration Manager or an RMM install a single deployment package that carries the configuration with it.
• Golden images and VDI. Install DPLens in the image and apply the configuration on the clones. Clones prepared with sysprep /generalize start with a fresh agent identity, checkpoints and cache, and the change is recorded in the audit trail. Keep secrets and licences out of the image.

A domain licence covers every machine joined to the domain, clones included. The deployment guide has the detail for each route.

Pre-flight checklist

• Effective inputs.conf and outputs.conf captured with btool --debug for each server class.
• Scripted, perfmon, WinHostMon, WinRegMon and admon inputs listed with an owner and a decision.
• Index, source, sourcetype, host and rendering agreed per input, and checked against tstats output.
• Every blacklist and whitelist ported, with message-regex rules rewritten against event fields.
• Every source set to start from new events.
• Every index the configuration names exists on the indexers, including any validation index.
• CA bundle exported; client certificate and key added if the indexers require mutual TLS.
• Acknowledgement decision recorded; disk cache sized per destination.
• Content that reads forwarder _internal data found, with a data-based heartbeat alert in place.
• Licence in place; rollout route (DPLens Manager or your existing tools) chosen and tested on a pilot.
• Rollback steps written down and rehearsed on the pilot group.

For the business case and a side-by-side view, see Splunk Universal Forwarder replacement, the DPLens vs Splunk Universal Forwarder comparison and the Splunk integration.

Splunk is a trademark of Splunk LLC. DPLens is not affiliated with or endorsed by Splunk. The names are used only to say what DPLens interoperates with.

Sources

• DPLens documentation: Sending to Splunk over S2S or HEC
• Splunk documentation: inputs.conf
• Splunk documentation: outputs.conf
• Splunk blog: Controlling 4662 messages in the Windows Security event log
• Microsoft Learn: 4662(S, F) An operation was performed on an object