When we are using the device policy setting for an SSID, a couple of things will occur.
First, it will not stop a "blocked" device type from attempting to connect to the AP but it will deny any traffic from that device starting at the AP. It can be thought of as a deny any-any firewall rule assigned by the AP to that specific type of device.
Second, when we are using the device policy setting how we obtain the device details to mark them as iOS, android, windows, etc, is we push them through a transparent splash page. Client identification is done by examining the User-Agent string field of an HTTP GET, and to force this GET the transparent splash is used as opposed to waiting for an HTTP GET from the device. This could be triggering the connection delay on the Windows device, and why you are seeing this "further action needed message". If it is reliably reproduced on the Windows devices then a quick test could be to disable device policies on the impacted SSID connect a known impact Windows device and see if the behavior reproduces.
If we are seeing a consistency between this setting and this behavior on Windows devices I would advise opening a support case for further review of the behavior.