Hi I'm trying to do disaster recovery testing on a CVAD 2402 CU1, testing outage of both license server and/or SQL server. I added a dummy entry in the hosts file for license server: works fine, server no longer reachable, goes into grace mode, everything keeps working. However, when I do the same for SQL, I get weird behavior.I would expect LHC to kick in, but it doesn't. I know about the forced outage mode for LHC and that does work I do a continuous ping to the SQL DNS name: shows my dummy address and a continuous time out. (as expected) In event log, I get event 1201 from Citrix Broker Service: "The connection between the Citrix Broker Service and the database has been lost. Error details: Exception 'A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: TCP Provider, error: 0 - The wait operation timed out.)' of type 'System.Data.SqlClient.SqlException'. Ensure that the database is correctly configured and accessible." > Well, that's exactly what I'm testing... It's NOT accessible, so I want LHC to kick in... But seconds (max 30) later, I get event 1200: "The connection between the Citrix Broker Service and the database has been restored." If I do netstat -aon, I see a connection to the SQL server 'real IP' Established. How is that possible?

DNS is probably in the mix here. For this test, blocking via Firewall would be more efficient and real.

Hi @jvitech Thx for your feedback. If DNS was in the mix, then ping would reply too? I'm aware of firewall but that is set to disabled via GPO and to overrule that I needed to process a bunch of administration, so I tried to avoid that :) Either way, we contacted the Citrix team responsible for LHC via a colleague who's CTP and it might be some kind of SQL client caching of the IP. Will update here once it's all been validated.

Not really, ping is using the hosts file, Netbios legacy stuff. If you do a nslookup of your SQL, it will return the correct IP, not the one in the host file. So if your app uses DNS for the resolution then the hosts file is ignored. I've seen that happening. That's why I don't trust the hosts file for this. But yeah I hear you about the change process involved ... Cheers, Julien

Thanks again. Before I saw your reply we decided to go ahead and do the firewall way anyway and we got LHC triggered doing so. To be validated, our thought was that the 'established' connection we saw when running netstat -aon was the cause. Any new connection to that address got blackholed, but the existing connection was used so DDC was still able to communicate with SQL.

+2 for using windows firewall. A few years back, I was testing out LHC that was re-introduced in 7.1x, and found windows firewall outbound blocks on port 1433 was the best means to test it