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.

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 !

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.

It would appears I'm not the only one experiencing the issue, I did a fresh install promote it to a Windows Server 2016 Forest and Domain AD. After the reboot I realize the Start Menu settings cannot be changed, next I found that whole load of permission error whenever I try to launch anything that requires Administrator privilege including Server Manager, Settings and Control Panel. After that I went to check the permission settings of the C drive and Windows folder as compared to previous version of Windows Server, "Authenticated Users" is no longer part of the default permissions. This is a fresh install of various edition from VLSC to MSDN to retail to trial download every version media and edition use present the same issue.

If you use Hyper V Live Migration from Server 2012 R2 (not sure if any other OS) to migrate to Server 2019. The migration works but as soon as you shut down the VM and try to start it again, will no longer boot. It turns on/off 3 times and remains off.

I also did cluster to cluster migration in VMM and this is the same behaviour.

It looks like it is due the migrated MAC address, if I set the VM to get a new dynamic mac address it seems to work. If I set it to it's original mac address as a static it will no longer boot.