testperson

Microsoft hat gestern ein OOB für den Known Issue veröffentlicht: April 19, 2026—KB5091157 (OS Build 26100.32698) Out-of-band - Microsoft Support

Moin, selbst signiertes Zertifikat erstellen, exportieren, (importieren) und RDP Datei signieren: $cert = New-SelfSignedCertificate -KeyUsage DigitalSignature ` -Subject "My Code Signing Certificate" ` -CertStoreLocation "Cert:\CurrentUser\My" ` -KeySpec Signature ` -KeyAlgorithm RSA ` -KeyLength 2048 ` -Type CodeSigningCert Export-Certificate -Cert $Cert ` -FilePath "C:\tmp\cert.crt" # Ggfs. am Test Rechner auch in die trusted Roots importieren Import-Certificate -FilePath "C:\tmp\cert.crt" ` -CertStoreLocation "Cert:\LocalMachine\Root" rdpsign.exe /sha256 $cert.Thumbprint "C:\tmp\Test.rdp" Das exportierte Zertifikat ("C:\tmp\cert.crt") nehmen und bspw. per Gruppenrichtlinie auf die PCs in die trusted Roots bringen und den Thumbprint ($cert.Thumbprint) bspw. per GPO an diese Stelle (GPS: Specify SHA1 thumbprints of certificates representing trusted .rdp publishers) auf die Clients bringen. Das signierte RDP File natürlich auch noch auf die Clients bringen. Das selbst signierte Zertifikat wäre so ein Jahr gültig. Ggfs. noch mit dem Parameter -NotAfter (New-SelfSignedCertificate (pki) | Microsoft Learn) die Gültigkeit erhöhen. HTH Jan

In dem fett-geschriebenen Part bzw. zweiten Absatz bin ich mir unsicher, ob und welche "Bedingung(en)" aus dem ersten Absatz gelten.

Moin, es gibt einen Known Issue für Windows Server 2025 DCs. Generell gibt es wohl mit dem Update Probleme, wenn man das PAM Feature nutzt. Kann aber wohl auch auftreten, wenn bei neuen / bestehenden DCs "zu früh" Authentifizierungsanfragen gestellt werden: Windows Server 2025 known issues and notifications | Microsoft Learn HTH Jan

Den Part mit dem Timestamp habe ich komplett überlesen. 😅

Hi, ich habe es selber noch nicht getestet, allerdings wird in diesem Link darauf eingegangen: RDP „Unbekannter Herausgeber" Fix — April-Patchday 2026 | HostSpezial HTH Jan

Die erste Meldung lässt sich durch diesen Registry Key beeinflussen: HKEY_LOCAL_MACHINE\Software\Microsoft\Terminal Server Client RdpLaunchConsentAccepted REG_DWORD 1 HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client RdpLaunchConsentAccepted REG_DWORD 1 1 -> Meldung kommt nicht 0 -> Meldung muss bestätigt werden; Nach "Haken" + "Ok" ist der Wert 1 New-ItemProperty -Path "Registry::HKEY_LOCAL_MACHINE\Software\Microsoft\Terminal Server Client\" ` -Name "RdpLaunchConsentAccepted" ` -Type "Dword" ` -Value 1 ` -Force New-ItemProperty -Path "Registry::HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client\" ` -Name "RdpLaunchConsentAccepted" ` -Type "Dword" ` -Value 1 ` -Force Edit: Das funktioniert auch in HKLM!

Ach du liebes Lieschen.. Ich *** 😅 Ich habe das die ganze Zeit nur per "Ausführen" -> "mstsc.exe" getestet und nicht mit einer gespeicherten RDP Datei. Was allerdings zu einem anderen, recht halbgaren Workaround führt: mstsc.exe /v:<Server>

Moin, ich habe gestern Abend drei Clients mit dem April Update versorgt und zwei Server. Bei mir kommt die Meldung nicht. Von einem Windows Server 2022 "JumpHost" auf überwiegend noch nicht gepatchte Server jedoch schon. Einer der Server läuft als VM in Azure und der andere ist ein Azure Virtual Desktop (, wo ich mich testweise auch per plain RDP angemeldet habe). (Der Workaround ist nicht implementiert.) Gruß Jan

Moin, es gibt weitere 6 Monate ESU für Exchange 2016/2019 und im April erneut keine SUs. Announcing Period 2 Exchange 2016/2019 Extended Security Update (ESU) program | Microsoft Community Hub No Exchange Server Security Updates for April 2026 | Microsoft Community Hub (Cleveres Geschäftsmodell ;-)) Gruß Jan

Hi, siehe: Microsoft Teams for Virtualized Desktop Infrastructure (VDI) - Microsoft Teams | Microsoft Learn HTH Jan

Und bis ihr jemanden gefunden/geholt habt, passt ihr evtl. schonmal eure Firewall an und lasst LDAP / SMB nicht mehr von außen rein. Option 1) Alles funktioniert weiterhin und das war eine recht grobe Fehlkonfiguration Option 2) Ihr habt schonmal was gefunden, was besprochen werden sollte

Moin, mich irritiert hier gerade der "Tag: eol-product". Ist das der Grund fürs "flaggen"? Wurde für die Prüfung von intern (LAN) oder von extern (WAN) gescannt? Solange Windows Server 2016 / 2019 noch im Support sind, wäre ein FFL/DFL 2008 R2 für mich kein "EOL". Da ihr aber 2019er Domain Controller habt würden mir ad hoc als Vorteil für ein FFL/DFL 2016 einfallen Bei Einsatz von LAPS können die Passwörter verschlüsselt gespeichert werden Die Protected User werden AFAIK auf Kerberos-only / 4h TGT / AES erzwungen (Authentication Silos / Policies oder auch PAM) Ggfs. noch zusätzlich folgende Artikelserie: Active Directory Hardening Series - Part 1 – Disabling NTLMv1 | Microsoft Community Hub Active Directory Hardening Series - Part 2 – Removing SMBv1 | Microsoft Community Hub Active Directory Hardening Series - Part 3 – Enforcing LDAP Signing | Microsoft Community Hub Active Directory Hardening Series - Part 4 – Enforcing AES for Kerberos | Microsoft Community Hub (Bei einem DFL/FFL 2008 R2 evtl. einmal vor dem April Patchday bewerten/prüfen.) Active Directory Hardening Series - Part 5 – Enforcing LDAP Channel Binding | Microsoft Community Hub Active Directory Hardening Series - Part 6 – Enforcing SMB Signing | Microsoft Community Hub Active Directory Hardening Series - Part 7 – Implementing Least Privilege | Microsoft Community Hub Active Directory Hardening Series - Part 8 – Disabling NTLM | Microsoft Community Hub Als Hinweis: Prüft, was ihr davon eh schon umsetzt. Bewertet was ihr einfach umsetzen könnt und evtl. "schnell + viel" hilft. Setzt auf keinen Fall alles gleichzeitig und ohne es zu testen um. Gruß Jan

Jetzt wo du es schreibst, mache ich das doch in einem Intune Script selber mit der reg.exe 😅 Write-Output "Disable Widgets" Copy-Item -Path (Get-Command -Name reg.exe).Source ` -Destination "$env:TEMP\reg1.exe" ` -Confirm:$false ` -Force Invoke-Expression -Command "$env:TEMP\reg1.exe add `"HKLM\DEFAULTUser\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced`" /v TaskbarDa /t REG_DWORD /d 0 /f" Remove-Item -Path "$env:TEMP\reg1.exe" ` -Confirm:$false ` -Force

Moin, du bist dann vermutlich auch über diesen Beitrag gestolpert: UserChoice Protection Driver – UCPD.sys – the kolbicz blog Da wäre eine "Lösung" drin aus der Kategorie "Tricks". Letztlich Dienst und Task deaktivieren. Alternativ müsstest du dir ein Angebot für SetUserFTA – THE file type association utility einholen. Da sollte dann ja auch Support inkludiert sein bzw. fixes, falls MS erneut Anpassungen vornimmt. In dem ersten Link ist ja auch verlinkt, dass der DEM FTA von VMware oder auch Ivanti das gleiche Problem haben. hier wäre die Frage, wie VMware das mit dem "UCPD-fix.cmd" lösen. HTH Jan

Hi, was findet sich auf dem Broker und Terminalserver zu diesem Zeitpunkt im Eventlog unter Anwendungs- und Dienstprotokolle -> Microsoft -> Windows-TerminalServices -> SessionBroker / SessionBroker-Client -> Admin/Client. Generell halte ich gemischte Betriebssysteme der Session Hosts (2022 / 2025) in einer Sammlung für suboptimal. Gruß Jan

AI: Auf einem (in diesem Bereich) unbehandelten Windows Server findet Get-AppxPackage -AllUsers *cop* | select Name Get-AppxPackage *cop* | select Name nichts. Auf einem aktuellen Win11 Client, wo mir gerade die Admin-Rechte fehlen findet ein Get-AppxPackage *cop* | select Name Name ---- Microsoft.Copilot "immerhin" die Copiltot App. NVMe ist AFAIK seit Oktober 2025 GA in Windows Server 2025. Hier ein Beitrag von MS dazu: Announcing Native NVMe in Windows Server 2025: Ushering in a New Era of Storage Performance | Microsoft Community Hub Evtl. noch zur Vollständigkeit die App Pakete auf (m)einem Server 2025 (Terminalserver mit M365 Apps): Get-AppxProvisionedPackage -Online | select DisplayName DisplayName ----------- aimgr Microsoft.DesktopAppInstaller Microsoft.MicrosoftEdge.Stable Microsoft.Office.ActionsServer Microsoft.OfficePushNotificationUtility Microsoft.OutlookForWindows Microsoft.SecHealthUI Microsoft.UI.Xaml.2.2 Microsoft.UI.Xaml.2.4 Microsoft.VCLibs.140.00 Microsoft.WindowsFeedbackHub Microsoft.WindowsTerminal MicrosoftCorporationII.WinAppRuntime.Main.1.8 MSTeams Get-AppxPackage | select Name Name ---- Windows.CBSPreview Microsoft.Windows.NarratorQuickStart Microsoft.Windows.CapturePicker Microsoft.CredDialogHost E2A4F912-2574-4A75-9BB0-0D023378592B 1527c705-839a-4832-9118-54d4Bd6a0c89 c5e2524a-ea46-4f67-841f-6a9465d9d515 F46D4000-FD22-4DB4-AC8E-4E1DDDE828FE Microsoft.AccountsControl Microsoft.AsyncTextService Microsoft.BioEnrollment Microsoft.Win32WebViewHost Microsoft.Windows.Apprep.ChxApp Microsoft.Windows.CloudExperienceHost Microsoft.Windows.PeopleExperienceHost Microsoft.Windows.PinningConfirmationDialog Microsoft.Windows.XGpuEjectDialog MicrosoftWindows.UndockedDevKit windows.immersivecontrolpanel Windows.PrintDialog Microsoft.MicrosoftEdgeDevToolsClient Microsoft.Windows.ContentDeliveryManager Microsoft.UI.Xaml.2.8 Microsoft.UI.Xaml.2.8 Microsoft.VCLibs.140.00 Microsoft.NET.Native.Runtime.2.2 Microsoft.NET.Native.Runtime.2.2 Microsoft.NET.Native.Framework.2.2 Microsoft.NET.Native.Framework.2.2 Microsoft.VCLibs.140.00.UWPDesktop Microsoft.VCLibs.140.00.UWPDesktop Microsoft.VCLibs.140.00 Microsoft.AAD.BrokerPlugin MicrosoftWindows.Speech.de-DE.1 Microsoft.ECApp Microsoft.Windows.StartMenuExperienceHost MicrosoftWindows.56978801.Voiess MicrosoftWindows.57058570.Speion MicrosoftWindows.57074904.InpApp MicrosoftWindows.57074914.Livtop MicrosoftWindows.Client.FileExp MicrosoftWindows.Client.Photon Microsoft.UI.Xaml.CBS Microsoft.WindowsAppRuntime.CBS.1.8 MicrosoftWindows.Client.Core Microsoft.OutlookForWindows Microsoft.Windows.OOBENetworkCaptivePortal Microsoft.Windows.OOBENetworkConnectionFlow Microsoft.Windows.ShellExperienceHost Microsoft.WindowsAppRuntime.CBS.1.6 MicrosoftWindows.Client.CBS MicrosoftWindows.Client.OOBE Microsoft.SecHealthUI Microsoft.WindowsFeedbackHub Microsoft.WindowsAppRuntime.1.8 Microsoft.WindowsAppRuntime.1.8 Microsoft.Winget.Source Microsoft.MicrosoftEdge.Stable 40174MouriNaruto.NanaZip Microsoft.WindowsTerminal MicrosoftWindows.57242383.Tasbar MicrosoftWindows.59336768.Speion MicrosoftWindows.59337133.Voiess MicrosoftWindows.59337145.Livtop MicrosoftWindows.59379618.InpApp Microsoft.LockApp Microsoft.DesktopAppInstaller MicrosoftCorporationII.WinAppRuntime.Main.1.8 aimgr MSTeams Microsoft.OfficePushNotificationUtility Microsoft.Office.ActionsServer (Der aimgr ist AFAIK von Office.)

Halt stopp! Mir gefällt der Workgroup Cluster (eigentlich) recht gut. ;) AD-Less Live Migration aber (AFAIK) nur im Workgroup Cluster und nicht zwischen zwei einzelnen Hosts. Bzw. müsste man das einfach mal testen, ob sich die Zertifikate erstellen lassen bzw. eher, ob sich die Migrationseinstellungen ohne Cluster passend konfigurieren lassen. Set-VMHost lässt als "VirtualMachineMigrationAuthenticationType" nur CredSSP und Kerberos zu. Die Eigenschaft ist auf Hosts im Workgroup Cluster allerdings "4" KI ist mir nur in einer der Preview Builds damals untergekommen. Habe aber auch noch nicht danach gesucht ab RTM. Network ATC* ist "cool" insbesondere mit S2D. Die meisten, die S2D oder Hyper-V machen, werden das aber schon irgendwie gescriptet haben. Da wäre dann jetzt "nur noch" eine Drift Control, die Network ATC mitbringt. Desto dynamischer / größer die Umgebung ist, desto spannender könnte NetworkATC sein. Falls man mit dem Windows Admin Center vMode liebäugelt, sollte man evtl. schon auf Network ATC setzen, da es (AFAIK) Voraussetzung ist. Möglicherweise ist Accelerated Network noch interessant, was aber wieder Azure Arc (Network HUD) benötigt sowie (AFAIK) eine aktive Software Assurance bedingt. Der neue native NVMe Treiber soll wohl flott(er) sein. *) Wird wohl wegem dem WAC vMode in Server 2022 backported.

Hi, evtl. hilft es dir (und uns), wenn du "das Chaos" einmal beschreibst. Gruß Jan

Zumindest hat der Exchange Team Blog gerade den Beitrag dazu veröffentlicht: https://techcommunity.microsoft.com/blog/exchange/celebrating-30-years-of-microsoft-exchange/4503439 In diesem Sinne, alles Gute Exchange Server und auf die nächsten 30 😅

Moin, du wirst den/die Dienst/e finden müssen, die das durch den Starttyp "Automatisch" verursachen. Sobald der/die auf "Automatisch (verzögert)" stehen, funktioniert alles wieder. Hier bin ich da kurz im Rahmen von massenhaft In-Place Upgrades gegen Ende kurz drauf eingegangen: In-Place Upgrade auf Windows Server 2025 - Jans Cloud HTH Jan P.S.:

Hi, mache doch alles "nahe am Stamm" per GPP und ITIL. Dann hast du die komplette Verwaltung der lokalen Gruppen in einem GPO. Evtl. dann noch mit diesem Ansatz: What you can do, should do and should NOT do with GPOs: Wer bin ich und was darf ich - Gruppenmitgliedschaften und Benutzerrechte Gruß Jan

Hi, kommen die Netzlaufwerke per GPP Mapping und stehen evtl. auf "Ersetzen"? Gruß Jan

Man kann es neuerdings in den lokalen Richtlinien aktivieren. Und ja, der zweite Artikel packt ein wenig aus dem Debug Log ins Eventlog und der dritte Artikel fügt ins GPSVCLog / Eventlog ein, warum, wer, welcher Prozess ein GP Refresh veranlasst hat. So wirklich bahnbrechend ist es halt wirklich nicht.

Moin, in den letzten knapp zwei Wochen so viel Neues zu "Gruppenrichtlinien": What’s New in Windows Group Policy Preferences Debug Logging | Microsoft Community Hub From Guesswork to Clarity: GPP Diagnostics Improve in Windows Server 2025 and Windows 11 24H2 | Microsoft Community Hub Assigning Process Accountability to Group Policy Refreshes | Microsoft Community Hub RSAT für Arm Devices: RSAT capabilities arrive on Arm-based Windows 11 PCs - Windows IT Pro Blog (Oder fängt da eine KI gerade an die Uservoice zu implementieren? ;-)) Gruß Jan