Set "DNS Search Suffix List" via GPO leads to (webclient) connectivity loss

%3CLINGO-SUB%20id%3D%22lingo-sub-1268992%22%20slang%3D%22en-US%22%3ERe%3A%20Set%20%22DNS%20Search%20Suffix%20List%22%20via%20GPO%20leads%20to%20(webclient)%20connectivity%20loss%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1268992%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F105904%22%20target%3D%22_blank%22%3E%40Peter%20Richardt%3C%2FA%3E%26nbsp%3BSo%20changing%20the%20default%20DNS%20search%20suffix%20can%20stop%20communication%20to%20Azure%20services.%20You%20normally%20need%20to%20reboot%20the%20server%20for%20DNS%20to%20apply%20correctly.%20So%20even%20if%20DNS%20GPO's%20apply%2C%20you%20would%20most%20likely%20need%20to%20reboot%20afterwards.%20you%20should%20also%20check%20vnet%20dns%20setting%20and%20vm%20dns%20settings.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3BWhat%20is%20the%20RDSH%20host%20status%20via%20powershell%20%3CA%20href%3D%22https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fpowershell%2Fmodule%2Fremotedesktop%2Fget-rdsessionhost%3Fview%3Dwin10-ps%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%22%3Ehttps%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fpowershell%2Fmodule%2Fremotedesktop%2Fget-rdsessionhost%3Fview%3Dwin10-ps%3C%2FA%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EDoes%20it%20state%20no%20heartbeat%20or%20unavailable.%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3Elet%20me%20know%20how%20you%20get%20on.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1268127%22%20slang%3D%22en-US%22%3ESet%20%22DNS%20Search%20Suffix%20List%22%20via%20GPO%20leads%20to%20(webclient)%20connectivity%20loss%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1268127%22%20slang%3D%22en-US%22%3E%3CP%3EHi%20together%2C%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3Eif%20we%20set%20the%26nbsp%3B%22DNS%20Search%20Suffix%20List%22%20via%20GPO%20(and%20also%20manually)%2C%20it%20leads%20to%20a%20(webclient)%20connectivity%20loss.%20The%20Webclient%20doesn't%20find%20it's%20virtual%20machines%20anymore.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EIf%20we%20disable%20or%20remove%20the%20GPO%20(or%20remove%20manual%20entries)%2C%20everything%20works%20fine%20after%20an%20gpupdate.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EWe%20even%20added%20reddog.microsoft.com%20to%20the%20list%20as%20first%20entry%2C%20that%20doesnt't%20matter.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EAny%20advice%20here%3F%20Maybe%26nbsp%3B%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F524325%22%20target%3D%22_blank%22%3E%40Ryanmangan%3C%2FA%3E%26nbsp%3B%3F%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E(We%20have%20configured%20two%20own%20DNS%20servers%20on%20and%208.8.8.8%2C%201.1.1.1%20for%20this%20WVD-VNET%20the%20name%20resolution%20is%20working.)%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1270509%22%20slang%3D%22en-US%22%3ERe%3A%20Set%20%22DNS%20Search%20Suffix%20List%22%20via%20GPO%20leads%20to%20(webclient)%20connectivity%20loss%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1270509%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F524325%22%20target%3D%22_blank%22%3E%40Ryanmangan%3C%2FA%3E%26nbsp%3BThanks%20for%20your%20answer.%20It%20currently%20states%20%22available%22%20when%20the%20webclient%20connection%20is%20already%20not%20working%20anymore.%20Last%20heartbeat%20was%203%20minutes%20before%20now%20with%20an%20reboot%20of%20the%20WVD%20machine.%20I%20rebooted%20the%20machine%201%20hour%20later%20and%20again%2C%20last%20heartbeat%20%3D%20boot%20time%20%3D%20Available.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EWhat%20could%20go%20wrong%20here%20and%20were%20could%20we%20start%20debugging%3F%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E(We%20have%20configured%20two%20own%20DNS%20servers%20on%20and%208.8.8.8%2C%201.1.1.1%20for%20this%20VNET%20the%20name%20resolution%20is%20working.)%3C%2FP%3E%3C%2FLINGO-BODY%3E
Highlighted
New Contributor

Hi together,

 

if we set the "DNS Search Suffix List" via GPO (and also manually), it leads to a (webclient) connectivity loss. The Webclient doesn't find it's virtual machines anymore.

 

If we disable or remove the GPO (or remove manual entries), everything works fine after an gpupdate.

 

We even added reddog.microsoft.com to the list as first entry, that doesnt't matter.

 

Any advice here? Maybe @Ryanmangan ?

 

(We have configured two own DNS servers on and 8.8.8.8, 1.1.1.1 for this WVD-VNET the name resolution is working.)

2 Replies
Highlighted

@Peter Richardt So changing the default DNS search suffix can stop communication to Azure services. You normally need to reboot the server for DNS to apply correctly. So even if DNS GPO's apply, you would most likely need to reboot afterwards. you should also check vnet dns setting and vm dns settings.

 

 What is the RDSH host status via powershell https://docs.microsoft.com/en-us/powershell/module/remotedesktop/get-rdsessionhost?view=win10-ps 

 

Does it state no heartbeat or unavailable. 

 

let me know how you get on.

Highlighted

@Ryanmangan Thanks for your answer. It currently states "available" when the webclient connection is already not working anymore. Last heartbeat was 3 minutes before now with an reboot of the WVD machine. I rebooted the machine 1 hour later and again, last heartbeat = boot time = Available.

 

What could go wrong here and were could we start debugging? 

 

(We have configured two own DNS servers on and 8.8.8.8, 1.1.1.1 for this VNET the name resolution is working.)