[German]Here is a strange observation of a blog reader on Windows Server 2016 systems running as failover clusters (SQL). After the February 2019 updates have been installed, virtual accounts can no longer be registered in the DNS. An error entry with ID 3019* is entered in the event logs.
The issue was reported to me by blog reader Markus S. by mail. I’ll just adjust it here – maybe there are more affected people or an explanation. Markus writes:
I have encountered an issue here in the company where I am interested in whether there have been more reports about this. A [Windows Server 2016] failover cluster (SQL) updated with February 2019 can no longer register virtual accounts in the DNS. Errors 3019* occurred when registering DNS in the cluster event log.
Markus states that they are two cluster nodes 01 and 02 running from Windows Server 2016. Cluster node 01 was updated according to plan. Cluster node 02 was not restarted as planned due to an error in a script. Markus wrote:
Cluster node 01 has thus retained its roles instead of returning them to cluster node 02 via script after the server has been restarted. In addition, it was not possible to install the update for [Cluster node] 02. So this means: [Cluster node] 01 with February  update and [Cluster node] 02 with January  update. Active was the [Cluster node] 01 with February update.
In this environment the DNS entries have an expiration time of ~2 days. And once a week the DNS server cleans the entries. So it was not immediately noticeable that there will be a problem. Markus wrote also:
Now it came to the problem that the application didn’t work anymore, because the DNS entries of the virtual computer accounts were gone, because the [cluster node] 01 couldn’t register them anymore. .
When trying to register DNS entries, according to blog reader Markus, the following occurred:
*: Cluster network name resource ‘SQL Network Name (LV-xx-0000x-v02)’ failed registration of one or more associated DNS name(s) for the following reason:
DNS bad key.
This means that DNS entries can no longer be registered. Markus has tried a repair that and describes the following observation:
When I then moved the “main role” of the failover cluster to the unpatched one and took the name offline and repaired it, it was suddenly inside again. The same was with the SQL cluster resource. When I moved it to the unpatched one and repaired the name, the DNS entry was back.
It’s obvious that the updates are related, isn’t it? Unfortunately, I didn’t realize this until after I started to follow up the February update that wasn’t successfully installed. Let’s see what happens after the reboot.
Markus asks: Were there any reports from other administrators in this direction? Nothing like that came into my eyes – but I’m not on the road in this area either. In addition, the scenario is a bit special. Are there any other people affected, or does anyone have an explanation?
Cookies helps to fund this blog: Cookie settings