Alle Aktivitäten

Die Ausgabe hier nun: New-PSSession : [hm mhex04 m t •] Processing data from remote server mhex04.kundenurl.de failed with the following error message: [ClientAccessServer=MHEX04, BackEndServer=mhex04.kundenurl.de, RequestId=b03240ad-78d2-4556 -bc7c-442e7eee5bf4, TimeStamp=4/2/2026 6:01:30 PM]| [AuthZRequestId=0ea45bf5-2f26-4744-ae2e-620d7e71be59][FailureCategory=AuthZ-SetupVersionInformationCorruptException]| Unable to determine the installed file version from the registry key "SOFTWARE \Microsoft \PowerShell\'. For more information, see the about_Remote_Troubleshooting Help topic. At line:1 char:1 + New-PSSession -ConnectionURI "SconnectionUri" -ConfigurationName Micr ... + NIUNNNNNNNNNNN/////////////////////////////////////////////n + CategoryInfo : OpenError: (System. Manageme.... RemoteRunspace: RemoteRunspace) [New-PSSession], PSRemotin TransportException + FullyQualifiedErrorId : Ich habe das m.E. passend gemacht

Zukünftig bitte als Text in einen Code-Tag posten, das erleichtert das Lesen ungemein. Bei deinem Bild sind am Anfang der ersten Zeile zwei Semikolon drin, die gehören dort bestimmt nicht rein. So sieht es von einem Windows Client aus: C:\Users\ich>echo %PATH% C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;C:\Users\ich\AppData\Local\Microsoft\WindowsApps;C:\adb;C:\ADB\;C:\Users\ich\AppData\Local\Microsoft\WindowsApps; C:\Users\ich>

Hallo Wie ist das mit dem Jugendschutz bei Nutzung von KI? Ich will da nix loslassen, was später schwer einzufangen ist. Tschüss

wirklich CU5 oder CU15 gemeint?

Ergänzung: ich poste anbei anonymisiert die Powershell Fehlermeldung: Path Ergebnis:

Ergänzend: auch ein Add an der ISE wie von Alith vorgeschlagen klappt nicht Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn Nachtrag - die Pfade stimmen meiner Meinug nach auch

Hallo zusammen, ich habe ein ungewöhnliches Problem: meine Management Shell und die ECP Konsole sind nicht erreichbar. Shell liefert einen Authentifizierungsfehler zurück. ECP wirft HTTP Code 500 geprüft habe ich bereits folgende Dinge: - Registry Einträge der Powershell - IIS Config der Endpunkte Front- und Backend gem. Changelog wurden Windows Patche installiert. Sonst gab es keine Änderungen. System: Win Server 2022 Exchange 2019 CU5 Eine Upgradeinstallation lief reibungslos durch. Die Anwender melden derzeit keine Fehler somit ist die DAG verfügbar. Eine Reperaturinstallation wurde noch nicht ausgeführt. Die Registry Werte der PowerShell sind aus unserer Sicht korrekt. (Vgl. Probleme Exchange 2016 CU6 Update) Ein manueller Import des Exhange Management Moduls war nicht hilfreich. Virenscanner wurde entfernt, Updates wurden deinstalliert Testweise. Kein Erfolg. Dank vorab für euren Support.

Habe einen kleinen Hyper-V Workgroup Cluster, 2 Hosts 2025. Als Storage ein SAN als shared Storage. Läuft seit ca nem dreiviertel Jahr ohne Probleme. Livemigration läuft super 😉

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.)

Cluster: OK. Versuche die jeweils zu vermeiden. Auch separate separate Infrastruktur nur fürs Anmelden. Mal genauer anschauen wie das Workgroup funktioniert. Danke für den Hint. AI: OK. Von der Updategrösse her müsste da schon was reingekommen sein oder? Die Frage ist nur ob es aktiv ist oder "nur" Schnittstellen für später. "Nur" weil die ja dann theoretisch angesprochen werden könnten von z.B. Malware. Oder bin ich falsch? NVMe: Alles was der Latenz hilft, hilft eigentlich direkt sehr spürbar der Performance mit SP. Auch wenn ich da erst Benchmarks gesehen habe (weils eben 2025 ist und mir der Nerv bis jetzt immer noch fehlte, aber ist ja wieder ein Jahr vergangen.)

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.

Zu AD-Less hatten wir hier vor einiger Zeit mal nen Thread. :) So richtig begeistert war niemand ;)

Danke für die Rückmeldung. Also in den letzten Monaten kein Ärger mit den Updates? Wie steht ihr zu den Sicherheitsbedenken bei den Member? KI Gedöhns gefunden, nur bei Desktop Experience oder gar nix da? Netzwerkänderung bin ich auf eine "Ente" reingefallen wo Neuerungen für 2025 in einem Blog-Eintrag angezeigt wurden. War wohl irgend ein KI-Rülpser. Die Änderungen die ich meinte, kamen bereits vorher *hust* Sorry für die Verwirrung. Bleiben für mich die Storage Verbesserungen und die AD-Less Live Migration.

Funktionsumfang und Lizenzrechtliche Bedingungen sind aber nicht identisch. Und Lizenzrechte stehen nunmal nicht auf der Marketingseite sondern in den Nutzungsbedingungen. Du begehst nach aktuellem Wissenstand einfach einen Lizenzbruch. Ob und wie der erkennbar ist, sei mal dahingestellt. Aber grundsätzlich ist schon immer eine CAL nur was für den Schrank gewesen, weil der Zugriff auf einen On-Prem Exchange eben KEINE technische Beschränkung hat. Heißt, wenn du keine CALs hast, dann kannst du trotzdem mit Outlook/OWA usw. auf deinen lokalen Exchange zugreifen. Nur eben lizenzrechtlich nicht!

Danke für die bisheringen Antworten, wobei sich zeigt, wie widersprüchlich die Informationen hierzu sind. Festzuhalten ist, dass M365 Standard Busines einen Exchange Online-Plan1 enthält, so wird es zumindest hier angegeben: https://www.microsoft.com/de-de/microsoft-365/exchange/compare-microsoft-exchange-online-plans?market=de Ob dieser Plan1 auch den Zugriff ermöglicht, ist unsicher, denn bei dem von mir anfangs zitierten Beitrag: https://www.mcseboard.de/topic/230981-lizenzierung-von-exchange-server-se-über-m365-e3-lizenzen/page/4/#findComment-1477982 ermöglicht der dortige Plan1 keinen Zugriff. Vermutlich ist Plan1 nicht gleich Plan1 ... Ich werde mal bei Microsoft direkt anfragen und dann berichten. Grüße Clemens

Ich glaube so einfach ist es nicht. Unter https://www.microsoft.com/en-us/microsoft-365/business/microsoft-365-plans-and-pricing?market=de findet sich bei den M365 Business ein Exchange Online Plan 1. Und Exchange Online Plan 1 beinhaltet https://www.microsoft.com/licensing/terms/productoffering/ExchangeServer/MCA#AccessLicenses eine "Base Access License" = CAL.

Soweit wir das hier durchdiskutiert haben, enthalten die Business Lizenzpläne (Basic, Standard und Premium) eben KEINE CAL Äquivalenz. Viel deutlicher kann man es doch gar nicht schreiben. ;) Also wenn sich die Lizenzbedingungen nicht irgendwo geändert haben, gilt das weiterhin. Business Pläne enthalten keine CALs (Cal Äquivalenz).

Laut unseren Ansprechpartner für ms Lizenzen ist in den ms business Paketen keine User cal für exchange se enthalten. Man bräuchte also eine extra exchange se User cal. Bei einer exchange online Plan 1 Lizenz ist aber die Nutzung eines exchange se pro User aber mit dabei. Ich glaube das war das extended User right oder so. Für uns war es günstiger den exchange online pan 1 zu kaufen als die exchange se User cal. Bezieht sich auf den exchange se standard und man muss aufpassen das man nicht enterprise Funktionen nutzt. Hofge ich hatte alles noch right in Kopf. Edit: sorry hatte die Antwort von dukel übersehen

Moin an Board, auf geht’s in den Grün-Donnerstag - ich koche Kaffee Allen einen stressfreien Tag, alles eingekauft? Morgen am Karfreitag haben die Läden zu Hier sonnig bei derzeit 6°C, es zieht sich bald zu und gegen 18:00h Regen erwartet bis etwa 12°C

Lt. https://www.microsoft.com/licensing/terms/productoffering/ExchangeServer/MCA#AccessLicenses müsste die CAL im Exchange Online Plan 1 enthalten sein. Aber ganz so einfach ist das nicht unbedingt wie man in der Diskussion unter https://borncity.com/blog/2025/09/23/lizenzierung-von-exchange-server-se-und-sharepoint-server/ findet.

Guten Morgen, um dieses schon etwas angestaubte Thema noch einmal aufzugreifen: Einige Beiträge weiter oben wird berichtet, dass M365 Business Basic einen Exchange Online-Plan1 enthält, welcher keine User CALs für Exchange SE bietet. Unser Büro verfügt über M365 Business Standard und dank Microsofts undurchsichtiger Lizensierungsstrategien bin ich mir trotz einiger Recherchen immer noch nicht im Klaren, ob hier jetzt User CALs enthalten sind? Hat jemand hierzu Erfahrungen? Danke und Grüße Clemens

Ich habe ebenfalls keine Probleme mit Hyper-V 2025 im Cluster beobachtet. Aber auch bei meinen Kunden sind die Cluster in der Domain. Neu beim Netzwerk ist Network ATC, sonst ist mir nichts aufgefallen. Mit DCs habe ich noch zugewartet. Ebenso wäre ich mit Terminalservern vorsichtig. Da soll sich Windows Server 2025 hakelig anfühlen und wesentlich mehr Leistung benötigen als 2022. Seit ich in jungen Jahren nahezu am Erscheinungstag von Windows Server 2012 eine RDS-Farm installiert und in den Produktivbetrieb übergeben habe, bin ich diesbezüglich jedoch ein gebranntes Kind.

Hi, ich hab bisher 2 Hyper-V 2025 Cluster mit 3-4 Knoten bei Kunden in Betrieb und kann keine größeren Probleme erkennen. Allerdings sind die Mitglied der Domain und nicht außerhalb. Netzwerkseitig hat sich da denn was geändert gegenüber 2022? Hab jetzt nicht geschaut/geforscht. :) Diverse VMs bei den Kunden laufen auch mit 2025 und ja, ich hab auch auf die DCs bisher verzichtet, weil es anfangs Probleme gab mit dem Firewallprofil und u.a. unserer ISE (soll inzwischen gefixt sein, hatte aber noch keine Gelegenheit das zu testen). Für Memberserver sehe ich jetzt keine wirklichen technischen Hinderungsgründe. Aber YMMV ;)

Hallo Leute, Habe drei Anliegen zu Server 2025 1. Mich würde interessieren ob 2025 insbesondere im Zusammenhang mit Updates - tatsächlich so schwierig im täglichen Betrieb ist oder ob das einfach überproportional in Blogs und Foren aufschlägt. AD ist mir soweit klar (auch wenn ich mich noch nicht eingelesen habe warum). Sprich hat schon jemand hier geswitched und gut Erfahrungen gemacht? 2. Dann würde mich interessieren inwiefern KI eingezogen hat obwohl es das eigentlich nicht hat. 3. Wie sieht es mit HyperV aus? Laufen die Änderungen im Netzwerkstack vernünftig? Livemigration mit unabhängigen, nicht AD-gekoppelten Hosts? Hintergrund (wen es interessiert, sonst ignorieren) Zu 1: Bei 2022 waren meine Probleme der letzten Jahre eigentlich nur Eigenverschulden und nicht jene von MS. Hatte seit 2022 nie Ärger mit Updates. Exchange habe ich nicht. Nur mit der Vorbereitung auf die Updates. Das ist aber nur teilweise die Schuld von MS, weil deren Standardeinstellungen einfach seit Jahrzehnten Schrott sind. Sprich allen Ärger hätte ich vermieden, wenn ich so manches von Anfang an umgesetzt hätte wie man es seit 20 Jahren könnte. Insbesondere bezüglich FQDN statt Namen bei Printer, Netzwerkshares, Isnt. von Druckertreiber durch User. Da ich alles lange vor dem Force durch die Updates umgesetzt habe, dadurch alles gut mit Downtimes planbar war, Testläufe machen konnte etc., liefen die Umgebungen alle munter weiter als gefühlt das ganze Netz während Monaten auf MS rumhackte. Worauf ich hinaus will: Liegt der Ärger mit 2025 wirklich an MS oder einfach an Fehlkonfiguration, nichtumsetzen von Empfehlungen und nach wie vor grottigen Standardeinstellungen die einem dann beim Hardening/forcen von Sicherheitseinstellungen durch die Updates von MS auf die Füsse fallen oder sind die Updates bei 2025 Schrott? Zu 2: Trotz der Abkopplung der Updates vom Client OS sind die Updates immer noch sehr gross. 2022 hat nach nun 4.5 Jahren ~500MB. 2025 nach 1.5 Jahren schon knapp 2GB obwohl MS eigentlich sagt, dass kein KI im System ist. Ich gehe daher davon aus, dass die Systemkomponenten die ganzen notwendigen Änderungen für KI-Systeme aber durchaus bekommen haben, wozu sonst gäbe es so viele Änderungen nach dem Release. Nur einfach nicht alles für die tatsächliche Nutzung. Zusatzfrage: Ist das deswegen ein zusätzliches Sicherheitsrisiko gegenüber 2022? Zu 3: Die Änderungen im Netzwerkstack waren für mich ein Lichtblick. Fand Teaming/Failover oder iSCSI im Windows-Netzwerkstack schon immer grauselig/mühsam in der Konfig und der Fehlersuche. Darauf habe ich bewusst verzichtet und VmWare eingesetzt. Windows selbst habe ich damit nie (mehr) belästigt, weil VmWare das super gelöst hat. Grüsse und Danke

Moin Sagte der Tag und fing neu an. VG Damian