DKS Profile Agent — GPO Deployment

Overview

The DKS Profile Migration Agent is distributed as a single installer file (DKSProfileAgent.msi) that is identical for every customer — there is no need to request a separate customized installer per deployment. Two pieces of information unique to your organization (an Agent Token and a Customer Code, provided separately by your DKS contact) are passed directly on the install command line through a GPO-managed Scheduled Task, in the same GPO that deploys the software itself. This lets you deploy through your existing GPO tooling in a single step, without any manual per-machine setup.

What you will need

• Domain Admin (or equivalent) access to Group Policy Management Console (GPMC).
• The DKSProfileAgent.msi file (provided by DKS support — the same file works for every customer).
• Your organization's Agent Token and Customer Code (provided separately by your DKS contact).
• An Organizational Unit (OU) containing the target Windows 10/11 computer accounts.

Step 1 — Deploy via a GPO Scheduled Task

A GPO-managed Scheduled Task runs msiexec directly, so your Agent Token and Customer Code go straight on the install command line — one step, one place, no separate registry configuration needed.

1. Copy DKSProfileAgent.msi to a network share every target computer can read (e.g. \\yourserver\Software\DKS\).
2. Open Group Policy Management Console (gpmc.msc).
3. Right-click the OU containing your target computers → Create a GPO in this domain, and Link it here… Name it, for example, “DKS Agent Deployment”.
4. Edit the new GPO → Computer Configuration → Preferences → Control Panel Settings → Scheduled Tasks.
5. Right-click → New → Immediate Task (At least Windows 7) — this runs once, right at the next policy refresh, rather than on a recurring schedule.
6. General tab: name it (e.g. “DKS Agent Install”), set “Run whether user is logged on or not”, tick “Run with highest privileges”, and set “Configure for” to Windows 10.
7. Actions tab → New:
   • Program/script: msiexec.exe
   • Add arguments:

/i "\\yourserver\Software\DKS\DKSProfileAgent.msi" /qn /l*v "C:\dks-agent-install.log" APIURL="https://migrate.draxk.com/api/agent" CUSTOMERCODE="—your Customer Code—" AGENTTOKEN="—your Agent Token—" MODE="EXPORT_RECONFIG_IMPORT" AUTOSTART="true"

The /l*v switch writes a detailed install log to C:\dks-agent-install.log on the target machine — the first place to look if the task runs but the install doesn't take.

8. On the Common tab, tick “Run once” (or set the task's own Settings tab to remove itself once it has run) so it doesn't linger and re-attempt the install indefinitely.

Your specific Agent Token and Customer Code are provided separately by your DKS contact — they are unique to your organization and should be kept confidential.

Step 2 — Verify the deployment

1. On a target machine (or after the next scheduled policy refresh), run: gpupdate /force
2. Confirm the software installed: Settings → Apps, look for “DKS Profile Migration Agent”.
3. Confirm the registry values applied: open regedit, navigate to HKEY_LOCAL_MACHINE\SOFTWARE\DKS\ProfileAgent, and check that AgentToken and CustomerCode show the values you configured. (If Registry Editor was already open, press F5 to refresh — it does not update automatically.)
4. The device should appear under your DKS portal's Devices list within a few minutes of install, even before any user has logged into the machine.

Troubleshooting: did the Scheduled Task actually run?

If a machine shows none of the results above, work through these in order — each one narrows down whether the problem is policy delivery, the task itself, or the install:

1. Did the GPO reach the machine at all? Run gpresult /r on the target and check that your GPO appears under “Applied Group Policy Objects” for Computer Configuration. If it's missing, check the OU/link/security filtering before looking at the task itself.
2. Did the task get created? Open Task Scheduler (taskschd.msc) and look for it in the Task Scheduler Library, or query it directly:

   schtasks /query /tn "DKS Agent Install" /v /fo list

   Check Last Run Time and Last Result — 0 means the action completed; anything else is a Windows error code worth looking up.
3. Did the task actually trigger, and what did it do? Check Event Viewer → Applications and Services Logs → Microsoft → Windows → TaskScheduler → Operational — it logs the task starting, the action (msiexec) starting, and the action's exit code, even if Task Scheduler's own summary above is unclear.
4. Did msiexec itself succeed? Check C:\dks-agent-install.log on the target machine (see the /l*v switch in the command above) — search near the end of the file for Return Value 3 (failure) vs Return Value 1 (success), and scan upward from there for the first real error.
5. Scheduled Task shows Last Result 1622? That's ERROR_INSTALL_LOG_FAILURE — msiexec couldn't open the /l*v log file itself, before the install even started. It happens when the log path points at a folder that doesn't exist yet on a fresh machine (msiexec does not create the log file's parent folder). Use C:\dks-agent-install.log (drive root) for the log path as shown above — always exists, no folder to fail on — rather than a custom folder under %ProgramData%.
6. Log shows Error 1620 / internal error 2203 on the MSI's UNC path? ERROR_INSTALL_PACKAGE_OPEN_FAILED — msiexec couldn't even open the MSI file. The Scheduled Task runs as SYSTEM, which authenticates to network shares as the computer account (COMPUTERNAME$), not as the logged-in user — if the share/NTFS permissions only grant a specific user account access, SYSTEM gets denied and this often surfaces as ERROR_BAD_NETPATH ("network path not found") rather than "access denied". Fix either by granting Domain Computers Read on both the share and NTFS permissions of the MSI's folder, or sidestep it entirely: add a Computer Configuration → Preferences → Windows Settings → Files item to the same GPO that copies the MSI to a local path (e.g. C:\Windows\Temp\DKSProfileAgent.msi) before the Scheduled Task action runs, and point /i at that local path instead of the UNC share.

Antivirus / endpoint security exclusions (e.g. ESET Endpoint Security)

If the customer's machines run managed endpoint security (ESET, and similarly for other vendors), it can silently block the install itself, or block the agent afterward from touching Outlook's profile registry keys or PST files — the Scheduled Task then shows Last Result 0 (it ran) while the MSI log or the agent's own log shows an “Access denied”/quarantine-style failure. Add these exclusions before rolling the GPO out — ideally as a policy pushed centrally (ESET PROTECT / ESMC) to the same OU/group as the GPO, not machine-by-machine:

1. Real-time file system protection → exclusions (paths, not processes):

   \\yourserver\Software\DKS\*
   C:\Program Files\DKS Profile Agent\*
   C:\ProgramData\DKS\*

   The first is wherever you staged the MSI for the network install; the second is where it installs to; the third covers both the install log and the PST export/backup folder the agent writes to during migration.
2. Excluded processes (a separate ESET feature — stops ESET scanning files opened by a given process, which matters here since the agent reads/writes large PST files): add C:\Program Files\DKS Profile Agent\DKSProfileAgent.exe.
3. HIPS (Host Intrusion Prevention System): if HIPS is in Interactive or Smart mode it can block the agent's registry writes to the Outlook profile keys (HKCU\Software\Microsoft\Office\...\Outlook) or its logon autostart entry. Add a HIPS rule allowing DKSProfileAgent.exe for registry and file operations.
4. Firewall: allow outbound HTTPS (443) from DKSProfileAgent.exe to migrate.draxk.com — the agent calls this for every check-in.
5. Confirming ESET is actually the cause: on the target machine, open ESET → Tools → Log files → Detected threats (or HIPS log) around the time the Scheduled Task ran — a blocked install or blocked file/registry access from msiexec.exe or DKSProfileAgent.exe there confirms it, versus a genuine install error in C:\dks-agent-install.log.

Fixed issue: device not appearing until someone logs in

Earlier versions of the installer only registered the device with the DKS portal once an end user actually logged into the machine and the agent auto-started via a logon entry. Under GPO Computer Configuration deployment specifically — which installs pre-logon, running as SYSTEM with no interactive session at all — this meant newly-imaged or freshly-deployed machines could sit installed for hours or days without ever showing up under Devices in the portal, until someone happened to sign in.

This has been fixed. The installer now performs a one-time, immediate registration call to the portal as part of installation itself, running under the SYSTEM account — before anyone has logged in. This works because device registration is a plain network call with no dependency on an interactive desktop, unlike the Outlook automation itself.

Practical effect for your rollout: you can confirm a wave of machines installed correctly by checking the Devices list right after deployment, without waiting for end users to sign in. The Outlook migration itself will still only begin once each user actually logs into their machine — that part cannot be changed, as it is a Windows-enforced limitation, not a DKS one.

---

Questions during deployment? Contact your DKS support representative.