Network Location Awareness is very useful feature on desktops. Particularly in the current climate of people taking machines home, having them detect "Public" networks is useful.

However, it is nearly unheard of for a Windows Server to be picked up and taken to an untrusted network. Instead of the benefits of this feature, there are many reasons wherein a server may decide it's in a public network and firewall itself from access. This will, for example, prevent a file server sharing files, or an Exchange server accepting email. If this occurs to Domain Controllers, it will trigger all other servers to consider themselves on a public network and generate effectively an "all servers down" scenario.

A Google search for "network location awareness" leads to no discussion about the feature, and pages and pages of workarounds for a problem that is clearly quite common.

There is a commonly described workaround involving restarting, or delaying the start of the Network Location Awareness service. But thinking about this logically, it's a "workaround" to a problem that should not occur.

This is particularly relevant to a Server Core installation that would never be taken home for use as a desktop, and can be quite difficult to troubleshoot without a UI.

If a Powershell command or registry edit would allow us to just set a server to "always use domain profile", we could improve resilience and remove these sort of issues from occurring, whilst avoiding workarounds of dubious quality.

To reproduce:

1) Run Disk Management as a user that both:
- is a local admin, and
- has domain credentials to access some network share

2) "Attach VHD", choose a .vhdx file stored on a network share.

3) Run Disk Management as a user that both:
- is a local admin, and
- does not have domain credentials

4) Right-click the VHD's item in the Disk list, click "Detach VHD"

Observe that a dialog pops up reporting the UNC path to the VHD file, which is of course already a bad sign.
Click OK.
Observe that an dialog pops up reporting "The user name or password is incorrect."

Note: This command does still succeed if run as a user with domain credentials. So, it appears maybe the method of detaching was changed under the hood, and this usage scenario was not tested.

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

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.