legacy systems needs to go to cloud

.NET and Win32 softwares will be around for long time, for sure..

why container? 1nd

Large systems with decades of code written, composed by 3rd party components can not be changed right away. So containerizing monoliths, are one important step on the jorney to the cloud

why container? 2st

I'm newbie, but as far as I know, the whole thing about containers is ship it as image once and run it everywhere, with environment isolation and integrity.. right?!

the issue

There is no way to properly set globalization settings like Time Zone, Language, or Windows-Location on Server Core containers. Once I can not control the container host, I don't know where my software will run: Azure AKS, AWS, On-Prem, data centers, Windows Desktops,..
So, I need to ensure some container environment settings..

the feeling

I'm very sad.. Microsoft should realize that globalization settings like language and time zone are fundamental to keep the world running..

Otherwise, Windows Server on container is useless, and if you have an OS useless for containers, what do you have?!

I want to go to cloud, I want to go with Windows platform, please don't stop me...

more details and context

https://github.com/moby/moby/issues/40284

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!

Hello,

on a fresh installed and fully patched Windows Server 2019 Std if I enable RDSH role the Windows Search stops working.

Windows Search service looks good and eventlog shows no errors but Indexing Options shows no locations enabled for indexing and I am unable to add them

Things I have already tried

1 - Windows Search service restart

2 - Server restart

3 - Rebuild Index

4 - Enable Windows Search feature

5 - DISM ad SFC

6 - Windows Troubleshoot - shows incorrect permission on C:\ProgramData\Microsoft\Search\Data folder but is unable to fix them. If I manually fix those permissions, search still not works adn permission are automatically reset to previous not working ones

Thank you in advance for help

UPDATE:

Uninstalling RDSH role fix the issue. Unfortunatelly I need both RDSH and Windows Search

BUG confirmed by other users here:

https://social.technet.microsoft.com/Forums/en-US/4c200f89-5905-42b3-ab27-0d7771c0ecb7/rdsh-role-breaks-windows-search?forum=ws2019&prof=required

it is quite annoying that going through a folder redirection step-by-step instruction found on Microsoft websites it turns out that Windows 2019 does not apply this policy correctly, it keeps me signing in with a temporary profile. Using a Windows 2016 server the policy is applied. Wasted two working days becuase I thought I made it wrong. My AD is nearly untouched AD in 2016 level, the folder redirection is the only GPO object that exists apart from the default domain policy and that has only three settings to stop the screensaver from appearing and weakening the password rules. When going through the gpresult I saw that the policy was not applied on Server 2019 without any result and without event protocol entry being provided as it should be. Windows 2016 reported to me "processed but cannot be applied" in gpresult pls look into event log - and in event protocol of Windows 2016 the information about the missing folder structure. That this structure wasn't created automatically is a bug by itself in 2016 but with reasonalbe error reporting I was abel to fix the root casue. Other redirected folders do create automatically, so why the appdata / roaming folder doesn't?

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.