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

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

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!

Running Windows Server 2016 Standard with Desktop Experience on a server with two network cards.

• the 1st network card is connected to the internet and receives the configuration via DHCP server on the network 193.136../24


• the 2nd card is manually configured as a private network with a fixed IP 192.168.1.254 and netmask 255.255.255.0 without gateway or DNS, this card is connected only to a network switch that is not connected to anything else.

Configured another machine with a fixed IP 192.168.1.1 that is connected to the switch, the server and client can ping each other just fine.

On the server a tracert 192.168.1.1 works fine but if I do a tracert to a non-existing machine like 192.168.1.10 instead of getting "reports: Destination host unreachable." or something like that tracert shows that packages are sent to the gateway of the first network interface!!!

The exact same setup on older Windows servers didn't to that, I did several searches and coudn't find anything saying that this is a new behavior so i think this is a BUG!

C:\Users\Administrator>tracert 192.168.1.10

Tracing route to 192.168.1.10 over a maximum of 30 hops

1 1 ms <1 ms 1 ms router.domain.com [193.136..]
2 <1 ms <1 ms <1 ms router-world.domain.com [193.137.xx.xx]
3 3 ms 3 ms 3 ms Router13.ispdomain.domain2.com [193.***.x.x]