SuitePeople
NetSuite 2026.1
2026-04-07

SuitePeople Time Clock for Windows 2.0.2.0: Mandatory Restart, No Rollback

SuitePeople Time Clock for Windows ships version 2.0.2.0 with security hardening, removal of rollback to legacy AdiClock, and a new mandatory manual Windows restart after every update.

Affects:SuitePeople Workforce ManagementSuitePeople Time Clock for Windows 2.0.2.0AdiClock (legacy)

Oracle has published version 2.0.2.0 of the SuitePeople Time Clock for Windows desktop client, distributed through the SuitePeople Workforce Management (WFM) SuiteApp. This is a client-side installer update — there are no documented changes to WFM records, SuiteScript modules, or REST endpoints in this release note.

What changed

  • Installer rebrand — the Windows installer, title bar, task bar, and setup window icons now use the Oracle NetSuite logo. Cosmetic only, but worth noting if you have endpoint management tooling (SCCM, Intune, etc.) that fingerprints installers by icon hash or publisher metadata.
  • Security and compliance updates — Oracle states the installer and runtime have been hardened. The release note is vague here; specific CVEs, signing-cert changes, or dependency bumps are not disclosed. Verify the new installer's Authenticode signature and SHA-256 against your software allow-listing before mass deployment.
  • Rollback to AdiClock removed — the legacy AdiClock binary path is no longer a supported downgrade target. Once a device is on 2.0.2.0, you cannot revert. Any runbook, GPO, or MDM policy that pins AdiClock as a fallback must be retired.
  • Manual Windows restart now required after updates — previously the update applied in-place. With 2.0.2.0, after the update installs, the operator must manually restart Windows for changes to take effect. Oracle frames this as a session/data-integrity protection and a way to make the assigned employee aware of the update.

Operational impact

The mandatory restart is the change most likely to bite. If you push Time Clock updates via RMM/MDM during off-hours, the device will sit in a half-updated state until someone physically reboots it. Punch-in/punch-out on that device may behave inconsistently until the restart completes. Plan rollouts around shift boundaries, not overnight maintenance windows.

The release note does not specify minimum Windows version, .NET runtime, or whether SmartScreen/AppLocker rules need updating for the new signed installer. Verify in a pilot before broad deployment.

What to do

  1. Inventory all Windows devices currently running SuitePeople Time Clock (or legacy AdiClock) — Workforce Management admins can cross-reference assigned devices in WFM.
  2. Download 2.0.2.0 from the help topic Updating SuitePeople Time Clock for Windows and validate the installer signature and hash in a test environment.
  3. Update your deployment runbook to include a mandatory post-install Windows restart step. If you use RMM, add a reboot task chained to the install task, or surface a user-visible prompt.
  4. Remove any rollback-to-AdiClock procedures from support documentation. Communicate to L1 support that downgrade is no longer an option — issues must be resolved forward.
  5. Notify shift supervisors and timekeepers in advance so the restart isn't perceived as an outage during a punch window.
  6. After rollout, confirm punches are syncing to WFM as expected and that no devices are stuck pending-restart.

Notes

This release note is light on technical detail — there are no API surface changes, no script governance impacts, and no record schema changes called out. If your integration touches WFM time data via SuiteScript (N/record) or SuiteTalk REST (/services/rest/record/v1/), nothing here should affect those code paths. The change is confined to the desktop client.