Disconnect error when running update in Azure Automation

Question

Folks,

I am facing lot of my systems showing Disconnect error when schedule update fails in Azure update automation.

Looking at eventlog in SMA, finding this error

Source: Microsoft-SMA
Event: 15105

Error while polling the hybrid notification channel. [AccountId={xxxxx-xxx-xxx-xxxxxxx}] [RunbookWorkerGroup=aaddds.computer_aaaa-aaa-4829-9479-aaaaaaa] [MachineName=aaddds.computer] [MachineId={aaaa-aaa-4829-9479-aaaaaaa}] [Exception=JobRuntimeData.Client.JobRuntimeDataServiceClientException: The remote name could not be resolved: 'xxxxx-xxx-xxx-xxxxxxx.jrds.eus2.azure-automation.net'
 [System.Net.WebException: The remote name could not be resolved: 'xxxxx-xxx-xxx-xxxxxxx.jrds.eus2.azure-automation.net']
   at JobRuntimeData.Client.JobRuntimeDataServiceClient.Get[T](String suffixUri, IDictionary`2 queryParameters, IDictionary`2 headers)
   at JobRuntimeData.Client.Operations.SandboxOperations.GetActions(Guid accountId, String hybridWorkerGroupName, String hybridWorkerVersion)
   at Orchestrator.HybridChannel.HybridJobRuntimeDataServiceClient.Receive()
   at RunbookWorker.Hybrid.CloudNotificationManager.PollAndNotify()

   inner exception -> System.Net.WebException: The remote name could not be resolved: 'xxxxx-xxx-xxx-xxxxxxx.jrds.eus2.azure-automation.net'
   at System.Net.HttpWebRequest.GetResponse()
   at Orchestrator.WebClient.RequestChannel.IssueRequestAndGetResponse[T](HttpWebRequest request, WebHeaderCollection& responseHeaders, String payload)
   at Orchestrator.WebClient.WebClient.Get[T](WebHeaderCollection& responseHeaders)
   at JobRuntimeData.Common.TransientFaultHandling.RetryPolicy.ExecuteAction[TResult](Func`1 func)
   at JobRuntimeData.Client.JobRuntimeDataServiceClient.Get[T](String suffixUri, IDictionary`2 queryParameters, IDictionary`2 headers)

Ran troubleshooting and it passed all of them. It was working perfectly fine till last three weeks....

Thanks in Advance.

Answer 1

@Arif Usman , thank you for posting this question on Microsoft Q&A.

I understand that you have some VMs which are reporting disconnect errors for Azure Automation Update Management. Here are some of the steps that should help you troubleshoot this issue

1. Based on the information provided that you "Ran troubleshooting and it passed all of them", I assume that you ran the offline troubleshooter as mentioned here - Offline Troubleshooter.
   If not, please do use this troubleshooter on the VMs where you are getting errors. Check the CheckResult property of returned output of various tests, to understand where the issue might be.
2. Based on the error below, the error is related to the name resolution, which means that there is an issue with the DNS/Name server. Ensure that the URLs and network requirement as mentioned in the following link is still implemented and was not changed unintentionally - Azure Automation update Management Network Planning

'inner exception -> System.Net.WebException: The remote name could not be resolved: 'xxxxx-xxx-xxx-xxxxxxx.jrds.eus2.azure-automation.net'

I would suggest checking the commonality that you have for these machines where disconnect errors are being reported - are they in the same location OR connected to same VNET/Network etc. You may also check the name resolution to this URL by using nslookup and tracert.

Also, are these machines consistently throwing "Disconnect Error" or was it an only for a while/short time period and not happening anymore - if the disconnect error is not happening anymore, the issue could have been related to network which would have resolved by now.

If you are still facing this issue, detailed troubleshooting might be required which would involve log review and network trace analysis from the system. You may also reach out to Azure Support for 1:1 help.

Hope this helps.

If the answer did not help, please add more context/follow-up question for it, and we will help you out. Else, if the answer helped, please click Accept answer so that it can help others in the community looking for help on similar topics.

Answer 2

I figure it out, Subnet associated with VNET but wasn't peer with. Working fine now.