We have several users under this scenario where they were working in a remote location with no wifi access and they connect through 4G, then a driver download for the Mobile broadband device kicks in and as it normally happens with network related device driver updates, once Windows starts the process of upgrading it, it will briefly disconnect the device, leaving the user with no connectivity.

Currently, we only have an option to allow/block the entire Windows Updates on metered networks from Windows perspective
https://docs.microsoft.com/en-us/windows/client-management/mdm/policy-csp-update#update-allowautowindowsupdatedownloadovermeterednetwork

It would be great if we can have a granular setting which lets us decide to allow/block Windows driver updates over metered networks.

Default servercore:1809 image came with en-US.

- At this moment, for Server Core 2019, you have to install language pack by yourself: https://docs.microsoft.com/pt-br/windows-server/get-started-19/rel-notes-19.
- The way to do it, is using lpksetup: https://support.microsoft.com/en-us/help/4466511/cannot-configure-language-pack-for-windows-server-2019
- But lpksetup.exe crashes when running on container

I've described step by step how to reproduce lpksetup.exe error on container, **producing crash report logs** that I've extracted from container.
All here: https://github.com/sanguedemonstro/docker-playground/issues/1#issuecomment-453078549

With extra details here: https://github.com/sanguedemonstro/docker-playground/blob/master/langpack-on-servercore2019.md#why-am-i-playing-around-this-subject

But I'm not able to understand logs or fix windows base image. And I can't open support ticket once I'm not MS partner.

So if anyone could help I'm here to support.

Thanks!

Today's Windows Updates are horrible and very unreliable and Windows Updates are one of the most riskiest operations. Microsoft should take the inspiration from Linux environment as Linux implementation of OS updates is informative, transparent to administrators, it's very nice to work with and administrators have all relevant info in case of any issue or update management. And Linux updates are very reliable.

But in case of Windows Server updates they are a nightmare. Using sconfig provides only very basic information, when updates are downloaded with no information is provided about progress, about downloading process, details about downloaded packages etc. The installation is the same issue - black box hiding all info about the prrocess and it is very hard to work with as nobody knows if the system is stucked or what is happening inside and administrators must just guess what to do. No information is provided by Windows Server and admins can do just wait and pray.

And finally admins must pray if the updates will install correctly and not harming their production OSes as this is happening in Windows world frequently.

Microsoft must put Windows Updates as one of the top priorities as this is crucial functionality for every OS from point view as security, maintenance, reliability etc. Now this is a nightmare and one of the most unreliable services in Windows OS which makes Windows Server very risky environment to work with.

When I attempt to automate the provisioning of the Azure Automation Run As account using the attached script, the RunAs Certificate and RunAs Connection assets are created successfully, however the RunAs account does not import the thumbprint, name and expiration dates for the RunAs certificate in it's properties. As a workaround, I have to manually create the RunAs account in the portal. This is ok as a manual process, but I was hoping to automate the deployment of a lab or dev/test environment, then immediately provision a run as account for the automation account so that I can schedule startup and shutdown runbooks.

Also, this is how I'm calling the function:
New-RunAsServicePrincipal -rgName $resourceGroupName `
-AutomationAccountName $AutomationAccountName `
-ApplicationDisplayName $ApplicationDisplayName `
-SubscriptionId $subscriptionId `
-SelfSignedCertPlainPassword $SelfSignedCertPlainPassword `
-AzureEnvironment $AzureEnvironment

I've also attached the screenshots showing the RunAs Account and the certificate asset.

Thanks in advance. Microsoft rules!

Currently volume licensing and most other MS portals don't provide (SHA, MD5 or any) filehashes.
I learned that later this year MS is planning to update the VLSC portal to support this. That's good news.

It would be a bonus to see the hashes on a true public part of the portals or otherwise on www.microsoft.com without any form of subscription.
Reason is that only a limited number of persons have an account that can actually download ISO’s from VLSC. On the other hand, a lot of IT admins cannot download themselves but use these ISO’s and have to rely on the hashes provided by the first group.

Could be done for all types of downloads (.ISO, setup.exe, msi etc).

Hash access without an account would enable everyone to directly verify with the source at MS which enhances integrity and security !

Make Windows Server to be able to check, download, install updates while the server is running.

like Android project Mainline.

so at first there will be 2 OS drives instead of 1, they'll be clones of each other. when an updates pops up, the OS will download and install it on the other drive that is not used to run the OS. the updates can be installed and completely finished on that drive. the next time a system admin restarts the server, OS will boot up from the other updated drive without ANY downtime for installing or finishing updates. once the system boots up, the OS will update the first drive as well to make it ready for the next update cycle and this same procedure can happen again and again.

this greatly reduces server downtimes and will be a great feature to compete against Linux servers.

technically EVERYTHING that can be done in Linux servers CAN be done in Windows Servers too. the only difference is the time it takes to do it.

for example installing a server role on Windows server can take as little as 5 to 10 minutes but on Linux it can take up to 2 hours to get the same result. and it brings No benefits whatsoever.

Historically, ALT-F4 will close out your windows...and if you were at the desktop, it would nicely bring up a dialog box asking if you'd like to sign-out or shutdown/reboot, etc. That is gone it seems...except for the built-in administrator. This leads to accidental logouts and closing of sessions that may have been active, etc. From what I've seen, MS has stated this is "by design" and needs to go to the forum to restore sanity. Seems odd it exists for one type of account and not able to be enabled for others. Regardless....bring back the logoff/shutdown dialog box please, or provide the necessary registry entry or GPO entry to re-enable it. Thanks.