What is AzureArcSysTray.exe doing on my Windows Server?

Introduction to AzureArcSysTray.exe

After installing the October 2023 updates for Windows Server 2022, I noticed a new systray icon, AzureArcSysTray.exe.

What is AzureArcSysTray.exe doing on my Windows Server?

It encourages me to launch Azure Arc Setup.

AzureArcSysTray.exe

Which I hope takes a bit more planning than following a systray link. But that’s just me, an old-school IT Pro.

Get rid of the systray entry

Delete the AzureArcSysTray.exe value from the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run registry key. Well, use GPO or another form of automation to get this done whole sales. I used Computer Configuration GPO Preferences in the lab. See the screenshot below from my home lab. It is self-explanatory.

The added benefit of a GPO is that it will deal with it again if Microsoft pushes it again in the next update cycle.

Uninstall the feature

Using DISM or Server Manager, you can uninstall the feature altogether. Do note that this requires a reboot!

Disable-WindowsOptionalFeature -Online -FeatureName AzureArcSetup

Or

Note: This removes the systray exe and Azure Arc Setup. If someone already set it up and configured it, that is still there and needs more attention as the Azure Connect Machine Agent is up and running. Does anyone really onboard servers like this in Azure Arc?

Bad Timing

Well, this was one thing I could have done without on the day I was deploying the October 2023 updates expeditiously. Why expedited? Well, it was about 104 CVEs, of which 12 are critical Remote Code Execution issues, and 3 are ZeroDays) and a Hyper-V RCT fix that we have been waiting for (for the past five – yes, 5 – years). Needless to say, testing + rollout was swift. That AzureArcSysTray.exe delayed us, as we had to explain and mitigate it.

Is it documented?

Yes, it is, right here: https://learn.microsoft.com/en-us/azure/azure-arc/servers/onboard-windows-server. It was incomplete on Tuesday night, but they added to it quickly.

Judging from some social media, Reddit. Slack channels, not too many people were amused with all this. See https://www.reddit.com/r/sysadmin/comments/174ncwy/patch_tuesday_megathread_20231010/k4cdqsj/

https://www.reddit.com/r/sysadmin/comments/1763a7o/azure_arc/https://www.reddit.com/r/sysadmin/comments/1763a7o/azure_arc/

Conclusion

I had to explain what it was and our options to eliminate it, all while we were asked to deploy the updates as soon as possible. Finding AzureArcSysTray.exe Azure Arc Setup installed was not part of the plan late Tuesday night in the lab.

Please, Microsoft, don’t do this. We all know Azure Arc is high on all of Microsoft’s agenda. It is all the local Microsoft employees have been talking about for weeks now. We get it. But nagging us with systray icons is cheesy at best, very annoying, and, for many customers, nearly unacceptable.

November 2019 updates caused Windows Server 2012 reboot loop

Introduction

Some laggards that still have some Windows Server 2012 virtual machines running got a bit of a nasty surprise last weekend. A number of them went into a boot loop. Apparently the November 2019 updates caused Windows Server 2012 reboot loop. Well, we have dealt with update issues before like here in Quick Fix Publish : VM won’t boot after October 2017 Updates for Windows Server 2016 and Windows 10 (KB4041691). No need to panic.

Symptoms

Not all Windows Server 2012 virtual machines were affected. We did not see any issues with Windows Server 2012 R2, 2016 or 2019. Well the symptom is a reboot loop and below I have a sequence of what it looked like visually.

November 2019 updates caused Windows Server 2012 reboot loop
Restarting
Looking good so far …
OK, stage 2 of 4 … stlil seems OK.
November 2019 updates caused Windows Server 2012 reboot loop
Could still be OK … but no, its starts again in an endless loop.

So what caused this Windows Server 2012 reboot loop?

Fix

We turned of the virtual machines on which the November 2019 updates caused Windows Server 2012 reboot loop. We started them up again in “Safe mode” which completed successfully. Finally, we then did a normal reboot and that completed as well. All updates had been applied bar one. That was the 2019-11 Servicing Stack Update for Windows Server 2012 (KB4523208).

We manually installed it via Windows update and that succeeded.

When reading the information about this update https://www.catalog.update.microsoft.com/ScopedViewInline.aspx?updateid=5fa2a68f-e7cd-43c7-a48a-5e080472cb77 its states it need to be installed exclusively.

Maybe that was the root cause. It got deployed via WSUS with the other updates for November 2019.

Anyway, all is well now. I remind you that we have at least 2 ways of restoring those virtual machines. In case we had not been able to fix them. Have known good backups and a way to restore them people.

Conclusion

We fixed the issue and patched those servers completely. So all is well now. Except for the fact that they now , once more, have been urged to get of this operating system asap. You don’t go more than N-2 behind. It incurs operational overhead and risks. They did not test updates against this old server VM and got bitten. Technology debt without a plan is never worth it.

Microsoft Pulled KB4036479 for Windows Server 2012 R2

Nothing like coming back from a holiday to find out the quality assurance of Windows updates has cause some issues once again. What saved the day here is a great colleague who identified the problem, declined the update in WSUS and removed it from the affected machines. Meanwhile, Microsoft Pulled KB4036479 for Windows Server 2012 R2.

KB4036479 was to eliminated the restart that occurs during initial machine configuration (IMC) with with Windows Server 2012 R2. But after a the “successful” update it does the post install reboot, rolls it back and that process starts all over. This happened to both Windows Server 2012 R2 VMs on premises as well as in Azure IAAS. For now it has been pulled form the Microsoft Update Catalog (https://www.catalog.update.microsoft.com/Search.aspx?q=KB4036479). The issues has been discussed on the forums here.

Again, it pays to deploy and test Windows update to a lab or proving grounds environment that mimics your environment before you let it lose on your production environment. Be practical here and don’t let the desire for a perfect but non existent lab be the enemy of good, existing and usable one!

PS: Some people reported issues with KB4038774 as well, but that does not turn out to be the case. In any way these preview updates have no business being installed on production servers and I wish Microsoft would put them in a separate category so they are not detected / downloaded / approved with other production updates but allow for ease deployment /use in proving ground environments.

July 2016 update rollup for Windows RT 8.1, Windows 8.1, and Windows Server 2012 R2

Microsoft recently released another update rollup (aka cumulative update). The

July 2016 update rollup for Windows RT 8.1, Windows 8.1, and Windows Server 2012 R2.

This rollup includes improvements and fixes but more importantly it also contains ‘improvements’ from June 2016 update rollup KB3161606 and May 2016 update rollup KB3156418. When it comes to the June rollup KB3161606 it’s fixes the bugs that cause concerns with Hyper-V Integration Components (IC) to even serious down time to Scale Out File Server (SOFS) users. My fellow MVP Aidan Finn discuses this in this blog post. Let’s say it caused a wrinkle in the community.

In short with KB3161606 the Integration Components needed an upgrade (to 6.3.9600.18339) but due to a mix up with the manifest files this failed. You could leave them in pace but It’s messy. To make matters worse this cumulative update also messed up SOFS deployments which could only be dealt with by removing it.

Bring in update rollup 3172614. This will install on hosts and guest whether they have  already installed or not and it fixes these issues. I have now deployed it on our infrastructure and the IC’s updated successfully to 6.3.9600.18398. The issues with SOFS are also resolved with this update. We have not seen any issues so far.

image

In short, CU should be gone from Windows Update and WSUS. It it was already installed you don’t need to remove it. CU will install on those servers (hosts and guests) and this time is does things right.

I hope this leads to better QA in Redmond as it really is causing a lot of people grief at the moment. It also feed conspiracy nuts theories that MSFT is sabotaging on-premises to promote Azure usage even more. Let’s not feed the trolls shall we?