Hello @MatthewHughes-5093

Thanks for the question and apologies for the delayed response. Will try to help get you a solution however I need some clarity on the issue you are seeing.

From reviewing your question, I understand you are unable to view Update History on your on-premise (Non-Azure) servers. Is this a recent issue?
Can you confirm the OS running on your impacted servers i.e. Windows or Linux? Also confirm you followed the OS-specific deployment steps for Windows, Linux,

Assuming you successfully connected your non-azure servers to a log analytics workspace, I recommend running the OS appropriate log query against your linked workspace to verify your non-azure servers have been enabled for update management - sample queries below.

Linux:
Heartbeat
| where OSType == "Linux" | summarize arg_max(TimeGenerated, *) by SourceComputerId | top 500000 by Computer asc | render table

Windows:
Heartbeat
| where OSType == "Windows" | summarize arg_max(TimeGenerated, *) by SourceComputerId | top 500000 by Computer asc | render table

HI @MatthewHughes-5093 - also worth mentioning that issues like the one you are hitting can be caused by incomplete configuration of networking, proxy, firewall settings on the agent.
If the agent is configured to communicate with the internet through a firewall or proxy server, confirm the firewall or proxy server is properly configured.
To learn how to verify the firewall or proxy server is properly configured, review Network configuration for Windows agent or Network configuration for Linux agent.

Hope this helps.
Cheers.

Hello @yasserMohamedAbdelMoneim-0269 - Just in case you haven't seen these, sharing the following docs on how to use Azure Migrate toolkit to:

1. Move SQL Always On to Azure VM.
   This article walks through migration of SQL Server Always On availability group to SQL Server on Azure VMs using the Azure Migrate: Server Migration tool.
   Using the migration tool, you will be able to migrate each replica in the availability group to an Azure VM hosting SQL Server, as well as the cluster metadata, availability group metadata and other
   necessary high availability components

2. Migrate failover cluster instance to SQL Server on Azure VMs
   This article teaches you to migrate your Always On failover cluster instance (FCI) to SQL Server on Azure VMs using the Azure Migrate:
   Server Migration tool. Using the migration tool, you will be able to migrate each node in the failover cluster instance to an Azure VM hosting SQL Server, as well as the cluster and FCI metadata.

Hope this helps but don't hesitate to ping if you have any questions.

Hi @sc2111 - noticed this is related to another post you made on 8/19 - ref here.
is this still an issue? Happy to help if it is. Please review my response on the related post above.

Looking fwd to your reply.

Cheers.

If I understand correctly, you were able to run the script locally with no issues.
Can you confirm there are no firewall/network restrictions or blocked Ports impacting remote-exec to your target?

Check out this post as it may help shed some light on your issue.

Cheers.

Hello @sc2111 , came across this old post without a response in months. Apologies for that.

this is not a scenario I've tried but happy to help troubleshoot assuming this is still an issue.
is there a specific doc/steps you followed for this configuration? if yes, please share so I can review and attempt to recreate.

You also mentioned "It simply fails in the event log". Can you share a screenshot or the verbose error & code that was thrown?
This will help us get things started down the right path.

You can also try to re-install the agent to see if that helps - details here.

Looking fwd to your response.

Cheers.

Sorry for the delay @AmulyaAdapa-6347, this issue has been escalated to the feature owners for further investigation. They will let me know once there's an update on root-cause. Actively working to see if we can get you a workaround in the meantime. Thanks for your patience.

Cheers.

hello @AmulyaAdapa-6347 - thanks for posting. Are you getting any output at all? If yes, can you share the output or screenshot of output you are seeing?

thanks for sharing. will investigate and get back to you soon.

thanks for the detailed response and reference link, @ChrisSanders-0177

Thanks for the post, @oferpld Just in case you haven't seen this yet, please review the steps on migrating VMware VMs to Azure.
You have the option for agentless or agent-based migration. Don't hesitate to ping if you have any follow-up questions.

Cheers.

Thanks for the post and sorry for the delayed response. I am following up on this internally and should have an update sometime this week.

Thanks for the post, @CosminStirbu-1831. Since this is a preview service, checking with the Azure monitor feature team on how to reconcile state-ful custom log alerts.
Please stay tuned. Will share an update early next week.
Have a good weekend.

Hello @ChrisPeacock-1515, If i understand correctly, the TF alert doesn't fire when the alert conditions are met/true?
If this is the case then we may need deeper debugging to get to the root-cause. We have 2 options here:

1. If you have a support plan linked to your Azure Subscription, Create a service request for technical support via the Azure Portal
   

2. If you don't have a support plan, send mail to AzCommunity@microsoft.com, include your Subscription ID and a link to this Q&A thread (for context)
   My team will gladly connect you with the right Azure Monitor support channel. (add Attn:Femi to email subject.)

Looking forward to hearing for you soon.

Have a good weekend.

Hello @RRedgrave-4617 thanks for posting on Q&A and exploring this preview feature.
With this still being in preview, very likely this is still a work in progress. I've reached out to the feature owner to confirm.

Will share an update as soon as I get one.

Cheers.