Establish a two-way forest trust.

Try to establish Remote Desktop Connection from a computer in one forest to a computer in another forest, with an account that is a member of “Protected Users” security group. The connection will fail if the computer (from where you’re trying to establish RDP connection) does not have “RC4HMACMD5” kerberos encryption type enabled (i.e. it only has “AES256HMACSHA1” enabled).

On the other hand, if the user that is trying to establish Remote Desktop Connection is using an account that is NOT a member of “Protected Users” security group, and only AES kerberos encryption types are enabled on the computer from where the connection is initiated (i.e. “RC4HMACMD5” is not enabled), the connection would be established because after kerberos authentication would fail, the account would be authenticated using NTLM, which is even worse.

Please fix this!

We must be able to authenticate and connect to another forest (of course, it the trust exist) with Kerberos using AES. Using RC4 is not acceptable, and NTLM is even worse.

We have two-way forest trust established and would like to manage group policy for both forests from one server.

On a member server where Group Policy Management console is installed, these encryption types are enabled in “Network security: Configure encryption types allowed for Kerberos“:
AES256HMACSHA1
Future encryption types

When I try to add another forest to Group Policy Management console (open “Group Policy Management” console, right click on “Group Policy Management”, click on “Add forest…”, enter domain name and then click “OK”), a message “Access is denied.” pops up.

If I enable “RC4HMACMD5” on the server where Group Policy Management console is installed, I can add a forest in Group Policy Management console without any errors.

Please fix this. I don't like having legacy cypher (RC4) enabled just to be able to manage group policy from two different forests.

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

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.

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

I have been fighting task scheduler for a while and have determined that there is most definitely an issue with task scheduler

we have a batch file that calls an executable.
We can run that batch file from the file explorer and we can watch with a ui and see all the different actions being taken, typically about 120 lines of actions. and this typically takes about a minute and a half to run.

When we put that same batch file in task scheduler and run it on maybe a reocurrance of every 10 minutes, task scheduler starts the task, the task completes 20 actions prior to prematurely ending the task at 5 minutes with no error log, no logs in even viewer, no errors in history, no nothing, but we can clearly see that for one reason or another task scheduler slows down the batch files execution from like 120 actions in a minute and a half to 20 actions in 5 minutes. and then doesn't even complete the task before ending.

This is a horrendous problem, imagine a backup job... and it slows the backup then kills it after 5 min. That would be very detrimental.

we also decided that since it's a batch file calling an executable that we can simply just call the executable instead, so we did... with the exact same result. Running the executable from file explorer ran all 120 actions in about a minute and a half, running it from task scheduler ran about 20 actions in 5 minutes and died at 5 minutes saying the task was complete even though it was not complete.

This absolutely needs to be fixed.

Currently the GPOs provided by MS SCT (https://docs.microsoft.com/en-us/windows/security/threat-protection/security-compliance-toolkit-10) have differents approaches how to install them.
e.g.
Windows 10 Version 1507 Security Baseline\LocalScript\10ClientInstall.cmd
Windows 10 Version 1809 and Windows Server 2019 Security Baseline\LocalScript\BaselineLocalInstall.ps1
Windows 10 Version 1909 and Windows Server Version 1909 Security Baseline\Scripts{Baseline-LocalInstall.ps1, Baseline-ADImport.ps1, Remove-EPBaselineSettings.ps1}

It would be nice to have common/generic approach how those GPOs can be applied. For example one powershell script that can be used to install any GPO regardless of the Windows patch level or AD status (joind to AD or standalone/local GPO) and specify the details with parameters. Otherwise it every time such GPOs are rolled out it is necessary to follow a different approach on how to install them.
My wish would be to have a generic "entrypoint" that can be used for all GPOs (also GPOs which will be released in the future).

Cheers

Make Windows Server to be able to check, download, install updates while the server is running.

like Android project Mainline.

so at first there will be 2 OS drives instead of 1, they'll be clones of each other. when an updates pops up, the OS will download and install it on the other drive that is not used to run the OS. the updates can be installed and completely finished on that drive. the next time a system admin restarts the server, OS will boot up from the other updated drive without ANY downtime for installing or finishing updates. once the system boots up, the OS will update the first drive as well to make it ready for the next update cycle and this same procedure can happen again and again.

this greatly reduces server downtimes and will be a great feature to compete against Linux servers.

technically EVERYTHING that can be done in Linux servers CAN be done in Windows Servers too. the only difference is the time it takes to do it.

for example installing a server role on Windows server can take as little as 5 to 10 minutes but on Linux it can take up to 2 hours to get the same result. and it brings No benefits whatsoever.

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.

With the old Remote Desktop Connection app, there was a display setting to "Use all my monitors for the remote session." This still works in that app, but I have been unable to find such a setting in this Windows Remote Desktop. I prefer to use this app because there are multiple machines I need to remote into and it's nice to be able to logically group them and whatnot, but there are times when I want to remote in and have that be my whole computer screen, and for that I have to use the older app, which sometimes has connectivity problems more than I've had with this one.