Forum Discussion
Weird Printing Issue: Windows Shared Printers accessible/visible via Hostname but not via IP Address
If someone else has this issue, here is the answer from Microsoft:
The Cause (back story) is multi-tiered. This is the basic rundown. Service Startup There have been many changes in WIndows to improve service startup times at boot. This allows some services to start earlier than they did in the past. A service may fail to start if it has a network dependency and times out before DAD is complete and the interface and IP are ready for use. Hardware Improvements in computer hardware is a major factor. All modern processors have multiple cores/threads, allowing parallel processing of operating system tasks. The speed of processors has also increased dramatically. These changes allow an operating system like Windows to perform multiple tasks faster and in parallel, and thus dramatically improve service start time. The amount of available RAM has increased quickly. This means less paging to disk, also improving startup time. The most significant improvement has been to storage. Storage is now primarily flash-based (SSD), and commonly uses a high speed NVMe interconnect. Even storage backends, like a NAS or SAN, are all-flash based these days. IO, latency, and throughput improvements between old spinny disks (HDD) and NVMe SSDs is in an order of magnitude of about 150+ times faster. This change happened in a time span of less than 10 years. The Result Prior to the improvements it took double-digit seconds for services to start on boot. Back when DAD was first added to Windows it could take minutes before all the services were ready.
Compensating for DAD was not necessary, so most code simply ignored the IP address state. The combined change of service startup behaviour and recent hardware improvements have allowed service startup to take single-digit seconds. Well before an IP address is ready to use, based on Windows behavior and RFC requirement. Simply changing the DAD transmit default for IPv4 to 1 is not a long-term solution. As hardware and service continue to improve it is feasible that even a single second's delay will be enough to cause a service failure at boot. Services experiencing the issue must be changed to monitor the IP address state prior to attempting a network connection or binding to an IP. Known Issues This is a list of common issues that CSS may face related to DAD and service startup. Service Using a Domain Account Fails to Start Services using a domain account have a special dependency on the network being ready and accessible to perform authentication with the domain controller. The service will not start without being authenticated. When the service starts and times out faster than it takes for the network to be ready, which is typically related to waiting on DAD to complete, then the service will not start. This is commonly seen with SQL Server, but it can happen to any service using a domain account for logon.
This issue can worked around by reducing the number of DAD transmits, disabling DAD, or setting the Recovery option on the service to restart. See the workaround:
Service Cannot Bind to an IP Address on Start This issue happens when the service tries to bind a service to an IP address but times out or errors out before the network is ready. Again, this typically happens because of the DAD wait. The network stack cannot bind a service to an IP address that is not in a Preferred state. This issue is seen often with the spooler (Print Server) service. Issues like this can be worked around by disabling DAD or setting the service startup to "Automatic (Delayed Start)". Other workarounds may not work when the service doesn't fail/stop, it simply continues without a service binding to an IP address. IPv6 Addresses Disappear from DNS Server on Reboot The DHCP client may request DNS registration before IPv6 DAD is complete. When this happens the IPv6 address is deleted/disappears from the DNS server during Dynamic DNS updating by the DNS client.
I hope this will help you and I would like to draw your attention to the fact that at the moment there is no final solution found.
If someone else has this issue, here is the answer from Microsoft:
The Cause (back story) is multi-tiered. This is the basic rundown. Service Startup There have been many changes in WIndows to improve service startup times at boot. This allows some services to start earlier than they did in the past. A service may fail to start if it has a network dependency and times out before DAD is complete and the interface and IP are ready for use. Hardware Improvements in computer hardware is a major factor. All modern processors have multiple cores/threads, allowing parallel processing of operating system tasks. The speed of processors has also increased dramatically. These changes allow an operating system like Windows to perform multiple tasks faster and in parallel, and thus dramatically improve service start time. The amount of available RAM has increased quickly. This means less paging to disk, also improving startup time. The most significant improvement has been to storage. Storage is now primarily flash-based (SSD), and commonly uses a high speed NVMe interconnect. Even storage backends, like a NAS or SAN, are all-flash based these days. IO, latency, and throughput improvements between old spinny disks (HDD) and NVMe SSDs is in an order of magnitude of about 150+ times faster. This change happened in a time span of less than 10 years. The Result Prior to the improvements it took double-digit seconds for services to start on boot. Back when DAD was first added to Windows it could take minutes before all the services were ready.
Compensating for DAD was not necessary, so most code simply ignored the IP address state. The combined change of service startup behaviour and recent hardware improvements have allowed service startup to take single-digit seconds. Well before an IP address is ready to use, based on Windows behavior and RFC requirement. Simply changing the DAD transmit default for IPv4 to 1 is not a long-term solution. As hardware and service continue to improve it is feasible that even a single second's delay will be enough to cause a service failure at boot. Services experiencing the issue must be changed to monitor the IP address state prior to attempting a network connection or binding to an IP. Known Issues This is a list of common issues that CSS may face related to DAD and service startup. Service Using a Domain Account Fails to Start Services using a domain account have a special dependency on the network being ready and accessible to perform authentication with the domain controller. The service will not start without being authenticated. When the service starts and times out faster than it takes for the network to be ready, which is typically related to waiting on DAD to complete, then the service will not start. This is commonly seen with SQL Server, but it can happen to any service using a domain account for logon.
This issue can worked around by reducing the number of DAD transmits, disabling DAD, or setting the Recovery option on the service to restart. See the workaround:
Service Cannot Bind to an IP Address on Start This issue happens when the service tries to bind a service to an IP address but times out or errors out before the network is ready. Again, this typically happens because of the DAD wait. The network stack cannot bind a service to an IP address that is not in a Preferred state. This issue is seen often with the spooler (Print Server) service. Issues like this can be worked around by disabling DAD or setting the service startup to "Automatic (Delayed Start)". Other workarounds may not work when the service doesn't fail/stop, it simply continues without a service binding to an IP address. IPv6 Addresses Disappear from DNS Server on Reboot The DHCP client may request DNS registration before IPv6 DAD is complete. When this happens the IPv6 address is deleted/disappears from the DNS server during Dynamic DNS updating by the DNS client.
I hope this will help you and I would like to draw your attention to the fact that at the moment there is no final solution found.