Alwayson Secondary replica DISCONNECTED State Issue

We had a strange issue with the Always on 3-Node replica today.

I got onto the server to Implement a change, which was to apply a SQL Patch to SQL Server 2016 SP2.

I’ve discovered that my AG’s health isn’t looking well though, and the databases in that secondary replica’s state are in RESTORING mode.

I also don’t notice any folders inside the AVAILABILITY GROUPS Folder in the problematic secondary replica, as indicated in the clip below.

When I RDP to the problematic Secondary replica and connect all three replica sql instances from SSMS, I am unable to access the PRIMARY AG, as demonstrated in the screenshot below:

For a brief moment, I was concerned about what had happened to PRIMARY, where the Primary AG is located, but then I opened cluadmin and noticed that the AG’s Owner was present on the DR server… So, I connected the SQL Instance to the DR server to see the PRIMARY AG, and it was there. The PRIMARY replica is in good health, as is one of the secondary replicas, however the other problematic secondary replica is in the DISCONNECTED state.

I looked through the SQL Error Logs to see if there were any problems linked to our problem. I discovered the following error.

Besides from that, I couldn’t find any additional errors that would help me troubleshoot the problem.

So, googled for below two errors :

Error Message 35201:

When attempting to connect to availability replica ‘Myreplica’ with id [availability group id], a connection timeout occurred. Either a network or firewall problem, or the replica’s endpoint address is not the DB mirroring endpoint of the host server instance.
There is no connection between this secondary replica and the primary replica. DISCONNECTED is the connected state.
I found the following KB article on support.miscrosoft.com.

https://support.microsoft.com/en-us/topic/kb3213703-fix-an-always-on-secondary-replica-goes-into-a-disconnecting-state-10131118-b63a-f49f-b140-907f77774dc2

However, because the SQL instances version is SQL 2016 SP2, it was not useful for my present organisation.
We also noticed that some Cluster difficulties were logged in Cluster Events on Windows Server Failover Cluster Manager, thus we notified the Windows Team, who are looking into it.
Meanwhile, we’re getting disc space alerts since the data isn’t being migrated to one of the secondary replicas.
So, as indicated by the Microsoft page above, we obtained authorization from the Client to reboot the problematic secondary replica and see whether the problem is resolved.
Because the secondary replica isn’t used in any way, the customer gave his approval, and we rebooted the replica, but the problem persists.

However, because the SQL instances version is SQL 2016 SP2, it was not useful for my present organization.
We also noticed that some Cluster difficulties were logged in Cluster Events on Windows Server Failover Cluster Manager, thus we notified the Windows Team, who are looking into it.
Meanwhile, we’re getting disc space alerts since the data isn’t being migrated to one of the secondary replicas.
So, as indicated by the Microsoft page above, we obtained authorization from the Client to reboot the problematic secondary replica and see whether the problem is resolved.
Because the secondary replica isn’t used in any way, the customer gave his approval, and we rebooted the replica, but the problem persists.