Windows Server 2022 NTP server setup

Question

Windows Server 2022 NTP server setup

Abigail Wilson 20

I have a windows 2022 server set up as an ntp server, 4 other expansion servers pointing to it successfully syncing, and some camera units. The Windows server hosting the NTP has 2 NICs and 2 IPs, 172.22.244.x and 172.22.245.x. The units on the .245 network can sync to the ntp, but the cameras on the .244 network pointing at the 172.22.245.x NTP will not sync.

Everything is currently connected through a managed cisco switch that has no VLAN separation, so everything should be able to see each other, the servers can connect to the camera portals successfully so they are talking, I just don't know why the cameras cannot sync to the .245 NTP server. Does the NTP server somehow need a second IP or is this an issue with the switch somewhere?

0 comments

2 answers

Your answer

Answer 1

James Gamble 165

Hola Abigail,

DNS probably isn’t the issue here if the cameras are configured with an NTP server by IP address. DNS only comes into play if the cameras are trying to resolve a hostname. If you enter 172.22.244.x or 172.22.245.x directly as the NTP server, the DNS setting won’t affect that NTP request.

The more important detail is that 172.22.244.x and 172.22.245.x are different IP subnets, even though everything is connected to the same physical switch. A switch putting everything on the same Layer 2 network doesn’t automatically route between those IP networks. The Windows server can communicate with both because it has a NIC/address in each subnet. The cameras still need a valid route to reach anything outside their own subnet.

Since you’ve now pointed the cameras directly to the server’s 172.22.244.x address and they still don’t sync, I’d check two things next:

Make sure the cameras have the correct subnet mask for the 172.22.244.x network.
Check the Windows Firewall rule’s Profile setting, not just its Remote IP scope.

That second one is easy to miss on a multi-NIC server. One NIC may be classified as Domain while the other is Private or Public, so that a rule can show “Any remote address” but still not apply to traffic arriving on the .244 interface.

You can verify that from PowerShell on the server with: Get-NetConnectionProfile and then check whether UDP 123 is actually listening: Get-NetUDPEndpoint -LocalPort 123

Windows Time uses UDP 123 for both NTP requests and responses. Microsoft also notes that W32Time on a multihomed server can’t be enabled or disabled per individual network adapter; it operates at the service level rather than being bound to a specific NIC.

Because the .245 clients are already syncing, we know the NTP service itself is working. The remaining problem is much more likely to be the .244 network path, firewall profile, or addressing on the cameras rather than DNS.

If all of those look correct, the quickest way to settle it would be to run a short packet capture on the server while one camera attempts to sync. If you see a UDP 123 request arrive on the .244 NIC but no reply leave, that points back to Windows Firewall/W32Time. If no request arrives at all, the issue is on the camera/network side.

Thanks,

James

Abigail Wilson 20 Reputation points

2026-09-23T20:07:52.38+00:00

What should I see when I enter those commands? I can see the network with Get-NetConnectionProfile (it says index 6 category public) and Get-NetUDPEndpoint -LocalPort 123 only returns localaddress :: localport 123 and localaddress 0.0.0.0 localport 123 on the server
Firewall profiles includes domain, private, and public
James Gamble 165 Reputation points

2026-09-23T20:27:24.9866667+00:00

Hola Abigail,

Those results are helpful.

Get-NetUDPEndpoint -LocalPort 123 returning both LocalAddress :: LocalPort 123 & LocalAddress 0.0.0.0 LocalPort 123 means Windows Time is listening on UDP 123 on all IPv6 and all IPv4 interfaces, not just on the .245 NIC. So the NTP service itself appears to be bound correctly for both server IP addresses. Microsoft confirms that W32Time uses UDP 123 and, on a multihomed server, isn’t enabled or disabled per individual adapter.

The more interesting result is that interface 6 is showing NetworkCategory Public. That's important because Windows Firewall evaluates rules against the active network profile and its address scope. So even though the NTP rule says “Any remote address,” it still has to be enabled for the Public profile. A Public profile is also Windows’ most restrictive network classification.

Since you said the firewall rule includes Domain, Private, and Public, that sounds correct, but I’d verify the NTP rules are actually enabled rather than just the GUI settings.

Could you run this on the server?

Get-NetFirewallRule | Where-Object {$_.DisplayName -match 'Network Time|NTP'} | Select-Object DisplayName,Enabled,Profile,Direction,Action

What I’d expect to see is an enabled inbound rule with Action Allow and Public included in Profile.

Your UDP output already tells us W32Time is listening correctly, so if the firewall rule is also active for Public, I’d stop looking at DNS. Since the cameras are using an IP address for NTP, DNS doesn’t participate in that NTP connection.

At that point, the next likely question is whether the server is actually receiving the cameras’ UDP packets on port 123 on the .244 interface. If the firewall output looks correct, I’d check that next.

Thanks,

James
Abigail Wilson 20 Reputation points

2026-09-23T20:36:00.01+00:00

The results of that command look good:

DisplayName : NTP Server (UDP 123)

Enabled : True

Profile : Any

Direction : Inbound

Action : Allow

Running a wireshark on the NIC when I refresh the camera's NTP IPs, I don't think I see any UDP protocol with 123 as src or dst port?
James Gamble 165 Reputation points

2026-09-23T20:46:14.02+00:00

Hola Abigail,

That’s a very useful result. If Wireshark on the server’s .244 NIC doesn’t show any UDP traffic to or from port 123 when you trigger an NTP refresh on the camera, then the request is almost certainly not reaching the Windows server at all.

That means the Windows Time service and Windows Firewall are probably not the problem. You’ve already confirmed that W32Time is listening on UDP 123 on all IPv4 interfaces, and the inbound firewall rule is enabled for all profiles.

At this point, I’d focus on the camera’s local network configuration.

The most likely items are:

Subnet mask - Make sure the camera’s subnet mask actually places the camera and the server’s 172.22.244.x address on the same local subnet. For example, if the camera is 172.22.244.50 and the server is 172.22.244.10 with a /24 mask, they should communicate directly without a gateway.

Default gateway - If the camera believes the NTP server is outside its local subnet due to an incorrect subnet mask, it will try to send traffic to its default gateway instead. If the gateway is missing or wrong, the NTP packet will never reach the server.

Camera-side NTP behavior - Some cameras don’t immediately send an NTP request just because the configured address is saved. They may only poll on a timer, at startup, or when a specific “sync now” function is used.

Switch port/VLAN configuration - Even though there’s no intentional VLAN separation, I’d still verify that the camera switch port and the server’s .244 NIC port are actually in the same untagged/access VLAN. A managed switch can still separate traffic at Layer 2 even if there isn’t an obvious routed VLAN design.

If the server-side capture sees no UDP 123 request, Windows never had a chance to accept, reject, or respond to the NTP request. The problem is upstream of W32Time. I’d do one very simple test next. From another normal Windows machine on the 172.22.244.x network, try querying the server directly: w32tm /stripchart /computer:<server-172.22.244.x> /dataonly /samples:5

If that works, it proves the .244 NIC, Windows Firewall, and NTP service are all functioning correctly on that subnet. Then the remaining issue is almost certainly specific to the camera config or its switch path. If you want, post the camera IP address, subnet mask, default gateway, and the server’s .244 IP/mask, and I can double-check the addressing.

Thanks,

James
Abigail Wilson 20 Reputation points

2026-09-23T21:21:35.1966667+00:00

w32tm /stripchart /computer:<server-172.22.244.11> /dataonly /samples:5 now only gives me "No such Host is known". The expansion servers still seem to be syncing their time from the ntp and this command worked earlier. The only thing that changed was one NIC had both .244 and .245 IPs and I moved them to separate NICs as it will be on site (this is in a test environment right now). They are still both plugged into the same switch. Could this error still be caused by the switch layer issue? This is a cisco switch and I have now been told cisco switches at default programming cannot handle requests like this, so it very well may work at site with the properly configured site switch
James Gamble 165 Reputation points

2026-09-23T21:46:11.3833333+00:00

Hola Abigail,

There are two separate things here, and one of them may be much simpler than it looks. First, for the w32tm test, don't include the angle brackets. If you entered this literally: w32tm /stripchart /computer:<server-172.22.244.11> /dataonly /samples:5

Windows will try to resolve that text as a hostname. Since you're testing by IP address, use: w32tm /stripchart /computer:172.22.244.11 /dataonly /samples:5

If that works, then "No such host is known" was just from the command syntax and not an NTP or switching problem.

On the Cisco side, I'd be cautious with the statement that a default Cisco switch "cannot handle requests like this." NTP is simply UDP traffic on port 123. A Layer 2 switch doesn't need any special NTP awareness to forward it.

If the camera and the server's 172.22.244.11 interface are truly in the same VLAN and have compatible subnet masks, the camera should ARP for 172.22.244.11 and send the Ethernet frame directly to the server. No routing is involved at all.

Where the switch or network design becomes important is if the .244 and .245 networks are actually different VLANs or routed subnets. Traffic between them then requires a Layer 3 gateway/router. Simply plugging both NICs into the same physical switch doesn't make the two IP networks routable to each other.

The fact that this changed when you moved .244 and .245 from one NIC to two separate NICs is also worth noting. That can expose interface/VLAN/route differences that weren't visible when both addresses lived on the same adapter.

I'd do the corrected w32tm test against 172.22.244.11 first. If that works from another .244 Windows device, but the camera still produces no UDP 123 traffic in the server-side Wireshark capture, then Windows and the switch path to the server are probably fine, and I'd focus on the camera.

If the corrected w32tm command also fails on another .244 device, then we should next look at the .244 NIC's IP address, subnet mask, switch port/VLAN membership, and the Windows routing table.

One additional command that would be very useful is:

Get-NetIPConfiguration

That'll show the IP addresses, subnet prefixes, gateways, and interface associations for both NICs, so we can make sure Windows is routing between the two networks as you expect.

Thanks,

James
Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.
Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.
Abigail Wilson 20 Reputation points

2026-09-24T13:32:30.15+00:00

The result of the correct stripchart is error: 0x800705B4

The camera IP is .244.210/24 gateway .244.1

please see attached for the get netip result
James Gamble 165 Reputation points

2026-09-24T13:53:04.4466667+00:00

Hola Abigail,

The 0x800705B4 result is a timeout. In this case, w32tm sent the NTP request but didn’t receive a valid reply before timing out.

Given the information you’ve provided, I don’t think DNS is involved, and I wouldn’t assume this is a Cisco limitation either. NTP is just UDP 123 traffic, and a Cisco switch doesn’t need any special configuration to forward it within the same VLAN.

The camera addressing is important:

Camera: 172.22.244.210/24

Gateway: 172.22.244.1

NTP server: 172.22.244.11

Because both the camera and the NTP server are in the 172.22.244.0/24 network, the camera should not use its default gateway to reach 172.22.244.11. It should ARP directly for 172.22.244.11 and send the NTP packet directly to that MAC address.

That means a Layer 3 routing issue isn’t required to explain this. However, a Layer 2 VLAN mismatch absolutely could.

Simply having both NICs connected to the same Cisco switch doesn’t guarantee they’re in the same broadcast domain. If the camera port and the server’s .244 NIC port are assigned to different VLANs, the camera’s ARP request for 172.22.244.11 will never reach the server, even though both devices have addresses in the same /24. In that situation, neither device would try to use the gateway because each believes the other is local.

That would also fit your Wireshark result. If you don’t see any UDP 123 traffic from the camera on the server’s .244 NIC, the request isn’t reaching Windows.

One thing I’d like to clarify before going further: where did you run the w32tm /stripchart test that returned 0x800705B4? Was it from the NTP server itself, one of the expansion servers, or another machine on the 172.22.244.0/24 network?

Thanks,

James

Answer 2

Hello Wilson,

Thank you for posting question on Microsoft Windows Forum!

Based on the issue description. Well! The possible cause for this issue might be an asymmetric routing and source IP mismatch on multi-homed Windows Servers, combined with strict NTP client behavior in IP cameras. It is not a switch issue, and the NTP server does not need a new IP. It already has the exact IP the cameras should be using. On the other hand, the Windows Time service on a multi-homed server can not control which interface it uses to send replies.

The suggestion here is to point .244 cameras to the server's .244 IP. Since your server already has an IP in the 172.22.244.x range on NIC 1, reconfigure the .244 cameras to point directly to the server's 172.22.244.x IP address. This ensures request and response traffic stays strictly within the same subnet and interface, bypassing cross-NIC routing issues.

Another suggestion is to verify that the Windows Firewall rule for Network Time Protocol (UDP-In) permits traffic from the .244 subnet across all active firewall profiles (Domain, Private, Public). Open Windows Defender Firewall with Advanced Security. Then locate the inbound rule for Network Time Protocol (UDP-In). Under the Scope tab, ensure Remote IP address is set to Any IP address (or explicitly includes 172.22.244.0/24).

You can consult the following link for further reference.

https://learn.microsoft.com/en-us/windows-server/networking/windows-time-service/Windows-Time-Service-Tools-and-Settings

Hope the response provided some helpful insight. If you find this answer useful, please feel free to hit “Accept Answer” so I know it addresses your concern.

Abigail Wilson 20 Reputation points

2026-09-23T19:37:52.81+00:00

This makes sense, though when I point the cameras to the .244 address they still do not sync. I checked the firewall and remote is set to any address.

Would the DNS settings affect this? I have their DNS also set to the same .245 server and address