Server 2025 Core ADDS DC, Network Profile Showing as "Public" and not as "DomainAuthenticated"
OS: Windows Server 20225 Standard Core (no GUI), build 26085.1 Role: ADDS, DNS ForestMode: Windows2025Forest DomainMode: Windows2025Domain Platform: Hyper-V guest When standing up a clean Windows Server 2025 using server core and configuring it as a domain controller, the network category (profile) always shows as "public." A clean load of Windows Server 2022 with server core as a domain controller has the same behavior. However, in Server 2022, the fix is to add DNS as a required service to the nlasvc (Network Location Awareness) service. Once that is done, the network category reflects "DomainAuthenticed" and persists between reboots. In Server 2025, the nlasvc service does not have the same requiredservices as Windows Server 2022, and it does not start automatically. Even after configuring the nlasvc service the same way it is in Server 2022 and adding DNS as a required service, the network category still reflects "public." The only way to get the network category to properly reflect the "DomainAuthenticated" status is to disable and reenable the network adapter after each reboot.Upgrading from Windows Server 2016 to 2019
Is Windows Server 2019 considered a safe upgrade from Windows Server 2016? Is it like installing a new build in Windows 10 (e.g. going from 1703 to 1709)? or is it more substantial than that? traditionally we haven't done in-place upgrades of Server OS, but wondered if 2019 is different, and more like a build upgrade than an OS upgrade? And is there instructions for doing an upgrade of 2016 to 2019?
Server 2022 Preview missing Let's Encrypt Root certificate
First posted to LetsEncrypt.org and was advised to post this issue here. https://community.letsencrypt.org/t/fyi-windows-server-2022-does-not-have-root-certificate/157208 At the time I'm writing this, Microsoft Windows Server 2022 has not been released and is only available in "Preview". Having said that I've installed the "Preview", installed all patches, and experienced the following errors when connecting to resources that use LE certificate. This happened when using Edge and Chrome. Your connection isn't private Attackers might be trying to steal your information from website.domain.com (for example, passwords, messages, or credit cards). NET::ERR_CERT_AUTHORITY_INVALID Firefox worked fine since it uses its own certificate store. After adding the root certificate to the root store, all was fine. The following output shows the certs currently in the root store by default as well as the PowerShell & OS version: PS C:\> gci Cert:\LocalMachine\Root PSParentPath: Microsoft.PowerShell.Security\Certificate::LocalMachine\Root Thumbprint Subject ---------- ------- CDD4EEAE6000AC7F40C3802C171E30148030C072 CN=Microsoft Root Certificate Authority, DC=microsoft, DC=com BE36A4562FB2EE05DBB3D32323ADF445084ED656 CN=Thawte Timestamping CA, OU=Thawte Certification, O=Thawte, L=Durbanville, S=Western Cape, C=ZA A43489159A520F0D93D032CCAF37E7FE20A8B419 CN=Microsoft Root Authority, OU=Microsoft Corporation, OU=Copyright (c) 1997 Microsoft Corp. 92B46C76E13054E104F230517E6E504D43AB10B5 CN=Symantec Enterprise Mobile Root for Microsoft, O=Symantec Corporation, C=US 8F43288AD272F3103B6FB1428485EA3014C0BCFE CN=Microsoft Root Certificate Authority 2011, O=Microsoft Corporation, L=Redmond, S=Washington, C=US 7F88CD7223F3C813818C994614A89C99FA3B5247 CN=Microsoft Authenticode(tm) Root Authority, O=MSFT, C=US 3B1EFD3A66EA28B16697394703A72CA340A05BD5 CN=Microsoft Root Certificate Authority 2010, O=Microsoft Corporation, L=Redmond, S=Washington, C=US 31F9FC8BA3805986B721EA7295C65B3A44534274 CN=Microsoft ECC TS Root Certificate Authority 2018, O=Microsoft Corporation, L=Redmond, S=Washington, C=US 245C97DF7514E7CF2DF8BE72AE957B9E04741E85 OU=Copyright (c) 1997 Microsoft Corp., OU=Microsoft Time Stamping Service Root, OU=Microsoft Corporation, O=Microsoft Trust Network 18F7C1FCC3090203FD5BAA2F861A754976C8DD25 OU="NO LIABILITY ACCEPTED, (c)97 VeriSign, Inc.", OU=VeriSign Time Stamping Service Root, OU="VeriSign, Inc.", O=VeriSign Trust Network 06F1AA330B927B753A40E68CDF22E34BCBEF3352 CN=Microsoft ECC Product Root Certificate Authority 2018, O=Microsoft Corporation, L=Redmond, S=Washington, C=US 0119E81BE9A14CD8E22F40AC118C687ECBA3F4D8 CN=Microsoft Time Stamp Root Certificate Authority 2014, O=Microsoft Corporation, L=Redmond, S=Washington, C=US DF3C24F9BFD666761B268073FE06D1CC8D4F82A4 CN=DigiCert Global Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US D4DE20D05E66FC53FE1A50882C78DB2852CAE474 CN=Baltimore CyberTrust Root, OU=CyberTrust, O=Baltimore, C=IE B1BC968BD4F49D622AA89A81F2150152A41D829C CN=GlobalSign Root CA, OU=Root CA, O=GlobalSign nv-sa, C=BE A8985D3A65E5E5C4B2D7D66D40C6DD2FB19C5436 CN=DigiCert Global Root CA, OU=www.digicert.com, O=DigiCert Inc, C=US 75E0ABB6138512271C04F85FDDDE38E4B7242EFE CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA - R2 742C3192E607E424EB4549542BE1BBC53E6174E2 OU=Class 3 Public Primary Certification Authority, O="VeriSign, Inc.", C=US 0563B8630D62D75ABBC8AB1E4BDFB5A899B24D43 CN=DigiCert Assured ID Root CA, OU=www.digicert.com, O=DigiCert Inc, C=US PS C:\> $PSVersionTable Name Value ---- ----- PSVersion 5.1.20348.1 PSEdition Desktop PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...} BuildVersion 10.0.20348.1 CLRVersion 4.0.30319.42000 WSManStackVersion 3.0 PSRemotingProtocolVersion 2.3 SerializationVersion 1.1.0.1 PS C:\> gwmi win32_operatingsystem | fl Caption, Version, BuildNumber Caption : Microsoft Windows Server 2022 Datacenter Evaluation Version : 10.0.20348 BuildNumber : 20348 EDIT @petercooperjr in the previously mentioned Let's Encrypt thread offered this feedback. Thanks. I don't know if it'd help whomever looks at it, but if you look at the Microsoft Trusted Root Program's page of their current trusted roots, you can see that ISRG Root X1 is there. (And it looks like ISRG Root X2 is there too!) https://docs.microsoft.com/en-us/security/trusted-root/participants-list https://docs.microsoft.com/en-us/security/trusted-root/participants-list This document provides details about the participating Certificate Authorities in the Microsoft Trusted Root Program.
Use DDA to pass GPU to container
Dear community, I want to pass a Quadro GPU to a container on a Windows Server host. What I want to change in our build infrastructure are idleing machines. We got Linux machines and Windows machines. Different Linux distributions. Some of them are idleing most of the time. So I thought about moving everything, Linux and Windows, in a container and run the GPU tests (CUDA and OpenGL) there. Since Linux containers don’t have access to the GPU I was wondering if I can make use of and assign the GPU to any of my containers at runtime? If this is possible, can you please explain how this is done? I also asked in the docker forums: https://forums.docker.com/t/gpu-in-container/54058
