SQL 2017 CU10 on Windows Server 2019 - Availability Group Listener fails to obtain IP from DHCP We have a few instances of SQL 2017 CU10 Standard on several Windows Server 2016 machines, and normally we create Basic Availability Groups with Listeners obtaining IPs from our DHCP (192.168.112.0/22 network).

We have static IPs for servers and DHCP for Basic AG Listeners.

Everything worked fine, however Listeners for AGs created on new (fully updated) Windows 2019 servers fail to get an IP address from DHCP.


I've checked our DHCP on new servers and it works perfect, server itself does obtain IP from our DHCP which means that DHCP is working fine.
I've tried to create a Listener with Static IP on new Windows Server 2019 and it works good, which means that AD permissions on OU for cluster computer account are okay (double checked it too).
I've tried to create an AG with a Listener on existing Server (Windows 2016) and Listener created there successfully obtains an address from DHCP, which means that our DHCP pool is not exhausted.
Actually there is one thing different, our new servers are connected to a freshly set up VLT-stack of Dell S4148F-ON switches, however as far as it has all VLANs configured and DHCP is working normally (see #1) I don't see any reason to blame the network.
When I capture traffic on physical interface in Wireshark on 2019 machine I see a number of broadcasts from DHCP server (Dell N3000 core switch) containing what I assume is a leased client address: Your (client) IP address: 192.168.113.143.


But it looks like the server does not accept them (?), the error I'm receiving is: Cannot bring the Windows Server FailoverClustering (WSFC) resource (ID ...) online (Error code 5942). &lt;...&gt;

In System Event Log I see two instances (based on two attempts, according to Wireshark) of Event ID 1240: Cluster IP address resource 'db11_192.168.112.0' failed to obtain a leased IP address.

And I've found nothing of interest in Failover Cluster Event Logs, just a detailed log of resource transitioning to failed state.

Maybe I'm missing something, but I don't see any other difference between old and new servers except new ones run Windows Server 2019.

Would be happy if someone suggests any further diagnostics since I've run out of ideas, thanks in advance.
Just wanted to confirm that the trouble was Server 2019 - after we reinstalled to Server 2016 everything works fine.