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.

• Old admin tools using MMC snapins were simple and efficient tools. They were reliable. And users could easily tailor user interface with their favorite tools.


• The Server Manager that appeared in 2012 is huge and inefficient. It's slow (each time you want to do something, you'll have to wait), and the UI is ******. Things are spread in separate buttons or popup menus all over the screen, which is far less efficient than a tree structure.


• The new Admin center is even more terrible : it's a tool for server administration, but it can not be used on a server, because it requires a browser that can not be installed on a server. Moreover, it requires a very huge subsystem (IIS) that lowers overall reliability and provides a far higher exposition surface. If I understand well, it's intended to be installed on a workstation. This means, for every different customer, I need to deploy a remote "workstation" just to be able to manage a single server ! And if this workstation goes down, I can't administer any of the servers. That's just terrible !

What was wrong with the idea of connecting to an individual server with Remote Desktop, and use simple and efficient tools (MMC snapins) to manage it ?

Most of the admin efforts seem to go to Powershell. Sripting may suit the needs of huge companies, but it's not suited at all for tiny companies which manage dozens of independant customers with one or two physical servers...

The power of Windows has always been the GUI, and there are still people which need efficient graphical admin tools, that allow to do things quickly, without having to read several pages of documentation, or having to spend hours to develop and debug a script for every individual situation.

Please revert back to simple and efficient graphical admin tools instead of huge, unreliable and unusable things.

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.

Add Services to the Windows Server WinX menu (right click of start menu / the menu that appears when you press WinKey+x).

As an administrator, one of the first things I do after connecting to a server is open services.msc. The fastest way to do it has always been click Start, type "services.msc" press enter.

What I would prefer to be able to do is right-click start, choose "Services" but inexplicably, that option that admins use EVERY DAY is simply not in the list when obscure things that we rarely use low Power Options are in the list. Please add Services.msc to the list as a default, at least on Windows Server installations.

Windows NT 4 Server era

No feeling, VGA resolution era, especially monitor that connect to server usually run on VGA mode only.

Windows 2000 Server era

Just fine, VGA monitor is major choose too.

Windows Server 2003/2003R2

Little bit small, adjust the window size sometime for rich info/setting situation.

Windows Server 2008/2008R2

Feels window/dialog size small, 720P, 1080i TV boardcasting era.

Windows Server 2012/2012R2

Hey, always require to keep busy on mouse resizing... move...click...drag...release...move...
Full HD is means standard in almost cases in the world, and even space station.

Windows Serve 2016/2019

Sir, Smartphone may come with 4K screen, right?
The monitor inside the server room are all Full HD. Remote Desktop from client PC may enjoying 2K/4K, curve panel monitor. But the GUI inside Windows Server is still similar to Windows NT4 environment. Any additional pack could adopt another era of GUI for people facing to this ... I don't want to say it is an issue/problem, but it is a question every time I am adjusting something on the Windows Server...

Microsoft may release a software pack to let people use modern and comfortable GUI, especially on Dialog/Window size and position remember (Could be auto reset temporary while the resolution is low). The pack could call "Microsoft Server Plus!".

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.