How to Install WSL 2 on Windows Server
A couple of months ago Microsoft announced the Windows Subsystem for Linux 2 (WSL 2), which is a successor of the Windows Subsytem for Linux shipped a couple of years ago. WSL 2 is currently available for Windows Insiders running Windows 10 Insider Preview Build 18917 or higher and with the Docker Tech Preview, you can now even run Docker Linux Container directly on WSL 2. With the latest Windows Server Insider Preview build 18945, you are also able to run WSL 2 on Windows Server. In this blog post, I am going to show you how you can install the Windows Subsystem for Linux 2 (WSL 2) on Windows Server. The Windows Subsystem for Linux was already available in earlier versions of Windows Server; however, WSL 2 brings a lot of new advantages. Read more here: https://www.thomasmaurer.ch/2019/08/how-to-install-wsl-2-on-windows-server/Server 2025 Domain Join Error ASN.1
hallo we wanna join an appliance (cisco ISE) to our domain/forest and get an error. Domain Controllers was updated from Server 2022 to Server 2025 preview it was ok with the appliance in ad. With Server 2025 final we get this error: Test Name :Kerberos test obtaining join point TGT Description :Tests TGT Obtaining in joint point Instance :CCLOUD-AD Status :Failed Start Time :10:13:54 22.11.2024 MET End Time :10:13:54 22.11.2024 MET Duration :<1 sec Result and Remedy... Could not obtain TGT : ASN.1 failed call to system time library. Check Kerberos related AD configuration What we done in troubleshooting, yet: DNS Resoluion works. domain is resolvable NTP is ok and correct time from pdc and synced to all other DCs and Clients/Servers domain join user credentials and permission are correct We tested also with an Domain Admin User/Cred Container/OU and Computer Object Permissions/Owner rights are set to the join account. Delete and let the Appliance create a new Object did not work can anyone help with ideas?Documentation on "Microsoft.OSConfig" PowerShell Module
Hi Server Insiders, is there any documentation available on the PowerShell Module "Microsoft.OSConfig"? https://learn.microsoft.com/en-us/powershell/module/osconfiguration/?view=windowsserver2025-ps does not help that much and also "Get-Help" is not that helpfull on most of the Commands. 🙂 Thanks! Best regards, Jan
Will Windows Server 2025 kernel be resilient to Croudstrike-like failures?
I know that Windows Server 2025 will soon be ready for GA, but I'm also thinking that last week's events happened still on time to do something from MS side in order for kernel of Windows Server 2025 to be more resilient to third party (or its own Defender) influence. Can Microsoft introduce something easy, like automatic last known good kernel configuration if BSOD is detected, which would automatically restart Windows without human intervention with the previous version of antivirus, and just signal in System Event Viewer, that last antivirus update had something crashing the system?
26080 and 26063: Cloud features (like copilot) should bis disabled by default.
There are many cloud features, which are activated by default. This includes copilot, prominently visible in the lower right corner, prominently placed in Edge. In other places it includes OneDrive. Or Azure Arc (which has been rolled out and activated on Server 2019 and 2022 too without consent). Probably countless other places which I just have not yet stumbled upon. Luckily the Weather, Widgets and some other cloud AppxPackages are not there, so I have to give credit in that regard. But all those cloud-components should NOT be active by default on a sever OS. This is, from my point of view, a very serious security concern. For companies it is already difficult to trust Windows 11, and enterprises invest a huge amount of time and money to disable as many of those features as possible. Now they have to fight the same data protection and security concerns for the Server OS as well, which is not good for Microsoft. A suggestion would be a "cloud-features" collection on the "Add Features" pane within the GUI, similar to "Message Queuing" or "Remote Server Administration tools". And none of them installed. They can be listed as "available" in the Get-WindowsFeature list, but not "Installed". Pushing that responsibility to the Admins, which then will create "Server 2025 cleanup for improved security" scripts. Which pose a problem themselves. Instead Microsoft should act responsible to make the Server secure by default, which includes having all those cloud-connected tools not installed by default. The only exception where such a connection to a cloud backend, by default on, if fine is the virus protection. Thank you for reading.
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.Windows Server vNext - TLS improvements, make TLS 1.2 the minimum standard for different areas.
Hi Server Team, it is great to see that Server vNext has enabled only TLS 1.2 and TLS 1.3 left experimental state in Internet Options (Windows System / IE) However the remark from AriaUpdated Changes to improve security for Windows devices scanning WSUS - Microsoft Tech Community does not yet match completely / consistently in Server vNext (not even speaking about productive release as 1607 and later) I would like to plea for following changes: 1. Server vNext should enable TLS 1.2 for PowerShell 5.1. Currently it is not enabled by default an so blocking access to repositories as github, PSget, nuGet etc 2. Upgrading WSUS to Server 2022 should enable TLS for WSUS by default (I know there are no GUI or wizard changes) 3. Server vNext should enable TLS 1.2 for SQL and .net by default 4. Server vNext should use TLS 1.2 for SChannel. Every supported OS (including domain controllers) support this. You should consider to disable TLS 1.0 / 1.1 for each of these Mary Hoffman Currently I am deploying actively these changes in mixed custmer enviroments using script / GPOs ranging from Server 2008-2019, SQL 2012-2019, Exchange 2013-2019, and do not face issues that cannot mitigated. However I would expect the standards to be higher with Server 2022 in compliance with what Aria stated. Thanks for your feedback
