Overview: We have recently discovered an error in Covetrus’ "requirements" for AviMark that creates a fragility and is based on a misunderstanding of network name discover in Windows and Windows-based networks by the vendor. Systems can be impacted by this somewhat at random, or never, but it is an unnecessarily risky configuration and less performant than an ideal one. The vendor requirement of using hostnames in URIs for the shortcuts can be workable but only in an environment that runs a full, management DNS server that is correctly configured. Covetrus often does not recommend this configuration, however, and the majority of their deployments do not have this safety measure and even those that do have unnecessary levels of complexity and dependencies that can be avoided.
Details: Covetrus has mistakenly relied on a guessed outcome of a race condition in DHCP name assignments within automated DNS configurations that are a common configuration in small businesses. Their assumption is that the identity of the Avimark server operating system will be detected consistently by a DHCP server which will then automatically populate a DNS entry that will be used to point services to the server. This works the majority of the time, but it is not deterministic and can fail at random. If such a system does not exist (either because there is no DHCP or because auto-populating DNS is not configured) then DNS lookups of the hostname will fail and Windows will fall back to a WINS name resolution system which will pull the nbtname of the system via unconfigured WINS and attempt to rectify the name resolution in that way. This works the majority of the time, as well. But DNS hostnames and nbtnames are not actually tied together and will not necessarily work. Each piece of this assumes something will “just work” without actually being configured to do so.
Three common flaws exist in this process. The first being simply when no DNS or WINS is available at all, the system simply does not function. The second is when DNS and WINS are not configured the same and WINS is required (This one is preventable by the system administrators.) The third and most common is when DHCP and auto-populating DNS do work, but the race condition gives them a different entry in the DNS table as primary than the one expected by the Avimark configuration thus pointing the Avimark shortcuts to the wrong location. Because the Covetrus documented process is non-deterministic, this presents a sizeable risk and the race condition is actually expected to fail in cases where certain enterprise class devices are used and configured. The Avimark documentation assumption is that the race condition is uncommon in consumer devices, which is likely the only type they have tested on.
The fix is simple, instead of using Covetrus’ documentation which is demonstrably incorrect under standard conditions, CCW is manually configuring to follow standard best practices instead and using IP address entries which are static and deterministic removing the entire need for name lookups altogether. This removes many layers of fragility, removes the need for complex DNS management to overcome a gap in Avimark design, improves performance, and improves security.
Importantly, moving to static IPs in the shortcuts allows for IT departments of any skill level to reliably provide server discovery for Avimark. And it removes the need for clinics to implement and maintain additional servers and complexity only for the purpose of avoiding the use of a best practice.