RHEL In-place upgrades and Azure Update Manager
Following the process in this article will cause a disconnection between the data plane and the control plane of the virtual machine (VM). Azure capabilities such as Auto guest patching, Auto OS image upgrades, Hotpatching, and Azure Update Manager won't be available. To utilize these features, it's recommended to create a new VM using your preferred operating system instead of performing an in-place upgrade. According to https://learn.microsoft.com/en-us/azure/virtual-machines/workloads/redhat/redhat-in-place-upgrade, Azure Update Manager will break if any RHEL in-place upgrades are performed due to data/control plane disconnect. As a Microsoft product, this dilemma seems to defeat the benefits of AUM if you're someone like me who uses Redhat 'pet' VMs (as opposed to 'cattle' VMs) for work, and would frankly like to centralize all operations within the lifecycle of a Linux box inside the Azure tenant (patching, upgrading, rollback, any possible automation/application deployment etc). Unfortunately it would seem that this issue is largely something outside of the Azure customer's control. So, to anyone with esoteric Azure knowledge: what gives? Why and how is there a data disconnect between the control planes? What does the process look like from a bird's eye view? Given that the issue exists in the first place I would imagine that there is some kind of developmental contradiction, otherwise a feature like this probably would have been figured out a while ago (or that it is, as I suspect, simply not high priority enough despite a solution which may already exist in development). Furthermore, for those who may have more intimate info on the matter, does any sort of discussion or planning of a solution for this issue exist? With kindness, MadDogOfShimano
Scaling Smart with Azure: Architecture That Works
Hi Tech Community! I’m Zainab, currently based in Abu Dhabi and serving as Vice President of Finance & HR at Hoddz Trends LLC a global tech solutions company headquartered in Arkansas, USA. While I lead on strategy, people, and financials, I also roll up my sleeves when it comes to tech innovation. In this discussion, I want to explore the real-world challenges of scaling systems with Microsoft Azure. From choosing the right architecture to optimizing performance and cost, I’ll be sharing insights drawn from experience and I’d love to hear yours too. Whether you're building from scratch, migrating legacy systems, or refining deployments, let’s talk about what actually works.
Former Employer Abuse
My former employer, Albert Williams, president of American Security Force Inc., keeps adding my outlook accounts, computers and mobile devices to the company's azure cloud even though I left the company more than a year ago. What can I do to remove myself from his grip? Does Microsoft have a solution against abusive employers?
Conditional access policy or User risk policy set to force password at high risk doesnt work
Hi all, When setting Conditional access policy or User risk policy set to force password at high risk doesn't work instead I get a blocked windows on users. I have set SSPR too and I think this is a requirement What am I doing wrong?
Azure Update management - error HRESULT: 0x80072F8F
Azure Update management not working Environment: Azure Windows based VM Forced Tunnelling Onpremise Firewall supports only IP Addresses Update management error: AssessmentError Exception from HRESULT: 0x80072F8F AssessmentErrorStackTrace System.Runtime.InteropServices.COMException (0x80072F8F): Exception from HRESULT: 0x80072F8F at Microsoft.EnterpriseManagement.Mom.Modules.ChangeTracking.WUA.IUpdateSearcher2.EndSearch(ISearchJob searchJob) at Microsoft.EnterpriseManagement.Advisor.PatchManagement.WindowsUpdateHelper.GetUpdateSnapshot(TimeSpan timeout, Boolean onlineSearch, DateTime lastTimeUpdateApplied, IAutomaticUpdates2 automaticUpdates, UpdateModuleState state) Troubleshooting: Due to Forced Tunnelling the traffic has to go to the onpremise FW. Unfortunately the onpremise FW allows only IP Addresses and as per the following article: https://docs.microsoft.com/en-us/azure/automation/automation-network-configuration#update-management-and-change-tracking-and-inventory It suggest to allow port 443 for url: Azure Public *.ods.opinsights.azure.com *.oms.opinsights.azure.com *.blob.core.windows.net *.azure-automation.net & *.oms.opinsights.azure.com Though, no IP address that I can NSlookup for *.azure-automation.net” Therefore, trying the alternate approach: Tried enabling service Tags via Azure Firewall, but as the traffic still goes to Onpremise FW we either need the IP Address for the URL to be allowed Else, use User Defined Route (UDR) to direct the Traffic for Service TAGS: “Azure Monitor” & “GuestAndHybridManagement“ via UDR and allowed the same using CLI, still no good. Checking for suggestions. Thanks in advance to reading through.
