The access-control log shows a door opening before the corresponding camera recording, while the employee’s computer shows another time. Before treating those records as one reliable sequence, check their clocks and display zones.
A useful office time plan covers computers, servers, cameras, recorders and other systems used together. It identifies the approved time sources, the expected display settings and who investigates drift or failed synchronisation.
Original concept illustration of workplace devices comparing their clocks with a reference source, not a real installation or forensic finding.
Separate clock accuracy from display settings
A device can have a correct underlying clock but display the wrong time zone. Another can display the intended zone while its clock is drifting. Record both rather than correcting the screen by adding a convenient number of hours.
For each priority system, note its time source, last successful synchronisation where available, configured zone and observed difference from an approved reference. Include the camera and recorder separately: the displayed overlay, recorded event time and exported metadata may come from different components.
Respect the existing Windows time hierarchy
Microsoft’s Windows Time service documentation explains that Active Directory domain members normally use a hierarchy of time sources. The forest-root PDC emulator has a particular role in that design. Domain-managed computers should not be pointed independently at arbitrary external servers merely because their displayed time looks wrong.
Have the administrator identify the actual environment and policy before changing it. A standalone device, a domain member, a virtual machine and a managed appliance may need different investigation. Check the upstream source as well as the endpoint reporting a problem.
ITZ’s office network setup service can review time dependencies across workplace systems. Review Your Office Time Synchronisation with the device types and the records that need to be compared.
Check reachability and synchronisation evidence
Microsoft’s time-service tools and settings reference documents w32tm for diagnosis and NTP use of UDP port 123. An administrator should use the supported tools and logs to inspect the source and synchronisation state, rather than inferring success from general internet access.
Review required network paths narrowly. A firewall rule, DNS problem or unavailable reference can affect synchronisation, but opening unrestricted access is not a diagnosis. Cameras and other appliances need their own supported settings and vendor instructions; a correct Windows server configuration does not automatically configure them.
Make changes carefully around operational records
Preserve the observed offsets and relevant evidence before an adjustment. A substantial clock change can complicate log interpretation and scheduled operations. Coordinate the change with the owners of attendance, access, recording and business applications.
Correcting today’s clock does not establish that historical timestamps were accurate. When reviewing an incident, retain the original records and document the known offset and uncertainty. Avoid editing archived footage or log entries simply to make separate timelines appear aligned.
Verify a representative cross-system event
- Define an authorised, non-sensitive test event and an agreed reference time.
- Record the event in each relevant system and compare the timestamp meaning and display zone.
- Inspect synchronisation status after the test and again after a suitable observation period to detect renewed drift.
- Verify that the expected settings persist after a planned restart or routine network reconnection where safe.
- Document an acceptable operational tolerance, a responsible owner and the alert or review route when it is exceeded.
Choose the tolerance around the actual task; an ordinary office review is not a high-precision timing certification. If the application needs specialist accuracy, establish that requirement explicitly rather than assuming standard office synchronisation will meet it.
Include time in the handover
Keep a device inventory and source map with the network documentation. Recheck after infrastructure replacement, domain changes or recorder migration. The network recovery guide covers retaining configuration, while CCTV retention checks cover the separate question of how much playable history exists.
Review Your Office Time Synchronisation
Bring the affected device list, approximate observed differences and the business records you need to correlate. ITZ can discuss sources, network dependencies and a practical verification plan. Review Your Office Time Synchronisation through the contextual form below.
Microsoft documentation reviewed on 8 November 2026. This is an operational review scope, not an audit opinion, incident finding or guaranteed accuracy claim.
