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.

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.

Windows search has to be deprecated.
- It is not cluster-aware.
- You cannot automate the rollout and
- Cannot orchestrate a bunch of nodes with the same configuration and
- last but not least you only have the choice between pest or cholera if you want to use an abstract namespace with all the advantages for background migrations by using the distrubuted file system (dfs), cause windows search is still incompatible with dfs - and never was it!

Sharepoint does it!

But sharepoint is still not integrated in windows explorer. You only have the possibility to import an „osdx-File“ with the OpenSearch 1.1 Provider interface. But you do not search on sharepoint and provide a huge I/O utilization on the fileserver node unless you hit the search icon that you created with the „osdx-File“ first.
But there are negative Points for OpenSearch. OpenSearch Provider is an old interface and the sharepoint does not consider the whole bunch of search functions for that small feature set.
Actually we placed an enterprise developing order and closed some advisory cases for that problematic around sharepoint and indexing dfs namespaces.
But you can do it better and professionally in next server releases and for all you customers around the world!

We request with this post

- that you integrate sharepoint search native into the windows explorer as the preferred search engine – no need to import an osdx, the search bar uses directly the sharepoint search cluster address .

- That you provide an set of group policies and the possibility to configure it also with powershell.
f.e. one or several URLs for Search Center Adress on a per user level.

- that you give as soon as possible the ability to hide the search bar in all contexts in the windows explorer unless a registered search provider is chosen (group policy setting).

- That you replace windows search with sharepoint search as the search provider in outlook in order to avoid indexing personal folder files on a network drive.

- Create a „Sharepoint Search Client“ for Desktops and RDS, so the administrators can decide if there has to be a centralized sharepoint search farm or a client can index locally (default).
But also it is important that you can set several parameters in group policies or via powershell – f.e. for setting the indexing database path.

We know that you can develope a professional new search approach for the future and delight your customer.

The new UI design of making the windows white and windows without frames is a poor design decision.
If you try to counteract the white-everwhere look, and select the 'dark' theme, then you have a black title bar on the windows, and then you can't see the 'minimize, restore & close' options.

If you've got multiple 'native' server 2019 applications open, its very difficult to differentiate where the edges of the windows are - so much I've had premier support staff get caught out by it when on remote support calls.

If you run 'older' products such as SCCM, and maybe open the service manager you'll get a window with a frame edge, you know the dimensions where that window is.
There needs to be some sort of middle ground here to fixing this.