OMS Update Management Solution - Not Configured Message

[Deleted]

I have configured the Update Management solution in my OMS workspace. Everything seems to be working fine for most, but not all VMs I manage.

When I navigate to the Automation Account > Update Management pane in the Azure portal, the VMs with issues show the following (seemingly conflicted) parameters:

Compliance: Compliant (with green checkmark)

Update Agent Readiness: Not configured

I have checked the Application and Services Logs\Operations Manager Event Logs on the VM, and found 4502 errors but not referencing 'HybridAgent' as the Microsoft technical documentation instructs. No Windows or network based firewalls are blocking the path outbound over port 443, and we receive consistent heartbeats in OMS from the machine.

Two questions

1. How is it possible that the solution assesses that the VM is compliant, but also says the "Update Agent Readiness" is not configured? Does this mean Update Management is getting the proper update status from the VM, but it cannot perform any updates if it finds needed updates?
2. What other troubleshooting steps should I take to address the "Not configured" message?

Thank you in advance!

[#2 · Accepted solution]

Hi, Azure Update Managament is using the OMS agent to do the assessnent of the server. The actual patching happens via a feature called Hybrid Worker. The OMS Agent distributes the bits for Hybrid Worker and the server is automatically configured for Hybrid Worker by Update Management. In this case seems that your server cannot be configured as Hybrid Worker. This Hybrid Worker is also reffered as Update Worker when it is configured by Update Management. In case the same computer was previously connected to another workspace there is the possibility that some old configuration was left on the computer and blocking the new registration. This is because only one Update Worker is allowed. The article is located here: https://cloudadministrator.wordpress.com/2017/05/24/moving-update-worker-server-between-oms-workspac... Registered Update workers can be seen in Azure Automation -> Hybrid Worker Groups -> System Hybrid Worker Groups. There you should all the servers that are onboarded to Update Management and they should report every 30 minutes. Keep in mind that you cannot reigster Update Worker manually. If you perform the manual operation you are registering Hybrid Worker that is used to run your own custom runbooks on a server. Let us know if you see any other errors. Also sometimes the server might be assessed before it is registered as Update Worker.

[#3]

@Stanislav_Zhelyazkov 

even if the topic is a little bit older, I have a very similar problem:

When looking at the automation account in the blade "hybrid worker groups" there are not groups in "system hybrid worker groups".

I know that this has been working earlier: Every time i installed the oms agent and configured it a system hybrid worker group was generated. (non azure machines)

Because of a misspelled automation account i deleted it and created a new one.

After this i reinstalled all the OMS agents and connected the machines again to the workspace.

The machines appear in the inventory and in the update update management, but they are marked as "not configured". I think this is because of the missing hybrid worker groups".

What can i do to make this work again as expected? (New OMS agent installation should result in a new worker group automatically).

I already tried the steps mentioned above (cleaning cache, deleting regkey if present,..) and also tried reinstalling the whole agent including restarts of the machine .

Thank you very much in advance.

edit: i created for testing purposes a new automation account with new ressource group and new log analytics workspace. Then i installed an agent to a machine and everything was okay. (Also a system hybrid worker group was created autoamtically for this machine).

What could be wrong in my first environment? 😕

[#4]

Hi@PatrickF11 Unfortunately the only thing I could think of is those registry keys but you have cleaned them already. Another thing you can do is check in the logs if there is some hint what is going on. You can check Operations Manager even log. Best is to stop the agent, clear the cache, start it and see what is being generated as warnings and errors. Other thing you can check is Operations table (I think that was the name) if there are any records there. Sometimes for some problems with the agent or specific solution data is written in that table to show what is the problem.

I hope this will help you!

[#5]

@Stanislav_Zhelyazkov  Thank you for your answer.

Luckily things were resolved by themselves about 48h after my posting.

Azure.... 😄

[#6]

@PatrickF11 I'm having the same issues.  Your servers just started working correctly on their own?

[#7]

Yes, everyhting worked as expected about 48h afterwards.

[#8]

@PatrickF11 thanks for the response.  Turns out after contacting their support they actually had a DNS issue that was preventing new servers from enrolling in the update platform.  After around 3-4 days for me they finally started working as expected.