phatair

Ok, danke euch. So hatte ich das jetzt gar nicht gesehen, macht aber Sinn. Anders wäre es auch irgendwie komisch gewesen, aber bei MS weiß man ja nie

Hallo zusammen, es gibt eine schwerwiegende Sicherheitslücke im WSUS https://www.heise.de/news/Microsoft-WSUS-Notfallupdate-stopft-kritische-Codeschmuggel-Luecke-10845666.html https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-59287 Was mich wundert ist folgende Aussage von MS Heißt das jezt, dass ich die WSUS Rolle vorher deinstallieren muss, dann fix installieren und dann wieder die Rolle installieren? Oder verstehe ich das falsch?

Hallo zusammen, auch wenn der Beitrag hier über die M365 E3 Lizenzen geht, wollte ich noch mal eine Info hier platzieren. Falls ich dafür einen eigenen Beitrag erstellen sollte - sorry dafür. Wir wechseln von Exchange 2016 zu Exchange SE und haben "nur" M365 Business Basic Lizenzen. Diese beinhalten ja keine Zugriffsrechte für einen Exchange SE. Wir haben 220 Mailboxen bzw. Zugriffe die lizensiert werden müssen. Wir müssten also einmal den Server Exchange SE mit SA kaufen und zusätzlich User CALs mit SA für den Exchange SE. Unsere bisherigen Exchange 2016 CALs sind ja für die Tonne. Laut unserem Dienstleister, mit dem wir die MS Lizenzierung machen, enthält aber der eigenständige Exchange Online Plan 1 eine Standard Base CAL die auch den Zugriff auf Exchange SE abdeckt. Der Exchange Online Plan 1 der auch im M365 Business Basic enthalten ist, hat dieses Recht nicht. Der eigenständige Exchange Online Plan 1 kostet 3,89 pro User pro Monat und kommt und ist somit deutlich günstiger als eine eigenständige Exchange SE User CAL. Auf eine Laufzeit von 3 Jahren gerechnet ist das ein ordentlicher Betrag der gespart wird. Ich habe jetzt nur das hier gefunden und das würde diese Aussage ja untermauern. Oder übersehe ich hier etwas? https://learn.microsoft.com/en-us/answers/questions/5558021/microsoft-exchange-server-subscription-edition-(se Grüße, Steffen

Ok, Problem gelöst. Ich musste für das Hinzufügen von der AccessRuntime noch mal eine XML inkl. Office 2024 bauen und den download noch mal neu starten. Danach hat jetzt das Hinzufügen sauber funktioniert. XML sieht dann wie folgt aus. Vielleicht hilft es ja noch jemand anderem

Hallo zusammen, ich verzweifele gerade am Office Click 2 Run Installer. Wir hatten bisher immer die MSI Variante eingesetzt und setzen nun sein ein paar Wochen Office 2024 LTSC Standard ein. Die XML für Office haben wir über das ODT online erstellt und sieht wie folgt aus. Wir haben die Daten mit dem Parameter /download <pfad zur xml> erstmal runtergeladen und die Installation von Office 2024 LTSC Standard funktioniert auch einwandfrei. Nun müssen wir auf einigen Clients auch noch die Office Access Runtime für Office 2024 nachträglich installieren. Die Access Runtime für Office 2024 ist die Access Runtime M365 die hier zu finden ist. Hier lädt man nur eine OfficeSetup.exe runter und mit einem Doppelklick wird die Access Runtime installiert. Dies funktioniert aber nicht, wir erhalten folgende Fehlermeldung. Wir wollen die Runtime aber ja auch silent verteilen, daher haben wir über das ODT eine XML gebaut. Diese sieht wie folgt aus Führen wir dann die ODT setup.exe mit dem Parameter /configure <pfad zur xmls> aus, erhalten wir diese Fehlermeldung Ich bin ratlos. Wie kann ich den das "Feature" Access Runtime nun nachträglich installieren. Früher ging das ganz einfach - es gab eine MSI für die Access Runtime und diese wurde zusätzlich installiert. Fertig. Hat hier jemand eine Idee? Vielen Dank und Grüße

Also bei uns funktioniert autodiscover problemlos und mapi/http ist aktiviert. Trotzdem müssen wir mit zero Config das Profil automatisch erstellen lassen. Auch zero Config läuft ja über autodiscover. Meinen Verständnis nach kommt dieses Fenster immer bei Outlook. Bei exchange online usw reicht aber der Klick auf den jeweiligen Button. Bei älteren exchange muss man über die "erweiterten Optionen" gehen. Um das komplette Fenster eben gar nicht erscheinen zu lassen und das Profil automatisch erstellen zu lassen nutzt man zero Config. Ist auch hier so beschrieben https://woshub.com/automate-outlook-user-profile-creation/

Hi, dass hatten wir auch und kann mit exchange zero config erledigt werden. https://learn.microsoft.com/de-de/microsoft-365-apps/outlook/profiles-and-accounts/zeroconfigexchange Grüße

Danke euch für die Tipps, Hilfe und den Test. Dann bin ich ja froh das ich nicht komplett doof bin und wir in unsere Umgebung nicht ein Konfig Fehler haben. Bin gespannt ob da was von MS kommt.

Ja, es ist für das korrekte Profil aktiviert Und der test war remote, jap. Es funktioniert auch nicht mit komplett deaktivierter Windows Firewall. Zwischen den beiden clients ist keine andere Firewall. Endpoint protection hatte ich auch testweise deaktiviert. Eigentlich möchte ich nicht noch tiefer forschen, wir benötigen es nicht, ist nur per Zufall aufgefallen und es hätte mich einfach interessiert ob es ein allgemeiner Fehler ist oder nur bei uns auftritt. Vielleicht hat ja jemand Lust einfach mal zu testen ob bei ihm in der Domäne der remote Zugriff auf die Defender Firewall auf einen 24h2 Client geht (wenn die entsprechenden fw Regeln aktiv sind).

Hi Martin, danke für das Script und die Infos. Also beim Win10 22H2 sehe ich ein Remote Fw APIs mit Port 50369:Listening - also wie du schon vermutet hattest. Bei Win11 24H2 sehe ich das auch - Remote Fw APIs mit Port 49749:Listening Ich würde das jetzt so verstehe, dass eigentlich beide für eine Verbindung bereit wären. Win11 24H2 das aber irgendwie nicht macht.

Hallo zusammen, ich bin bei uns per Zufall darauf aufmerksam geworden, dass es bei Win11 24H2 nicht mehr möglich ist sich remote mit der Windows Defender Firewall per MMC zu verbinden. Unter Windows 10 22H2 funktioniert das noch einwandfrei. Auf beiden Clients (Win11 24H2 und Win10 22H2) sind die Firewall Regeln "Windows Defender Firewall Remoteverwaltung" (RPC und RPC-EPMAP) aktiv. Auch läuft der Windows Defender Firewall Dienst. Der IPSec Dienst läuft auch (wird bei der Fehlermeldung genannt) Für den Test sind die beteiligten Clients alle im gleichen VLAN um die zentrale Firewall auszuschließen. Auch wurde auf dem 24H2 Client die Windows Firewall deaktiviert. Trotzdem geht die Verbindung nicht. Die Verbindung per MMC von 24H2 zu 24H2 schlägt mit folgender Fehlermeldung fehl: Die Verbindung per MMC von 24H2 zu Win 10 22H2 funktioniert einwandfrei. Hat jemand eine Idee woran das liegen kann? Ist jetzt nicht so tragisch, aber würde mich interessieren ob wir hier nur irgendwas übersehen oder MS da etwas grundlegendes geändert hat. Viele Grüße

Ha... da ist was wahres dran Danke euch!

Jep, da wird so einiges verschlimmbessert... Wenn ich mir nur die cpl Befehle merken könnte Muss mir doch mal ne Liste machen🙈 Schönen Abend zusammen

Hi Jan, danke für die Info. Wie erwähnt gibt es kein Problem. Die Anzeige in Windows 11 ist einfach nur verwirrend. Das sagt wohl nichts über das Netzwerkprofil aus. Aber trotzdem gut zu wissen, dass es da Bugs in Windows gibt, die dann mit einem deaktivierten IPv6 auftreten können. In dieser Einstellung ist alles korrekt, nur hatte ich diese nicht auf Anhieb gefunden Danke Dir! Das schaue ich mir dann in Ruhe mal an. Jeder Client wird bei uns neu mit einem Base Image installiert und die meisten Treiber eben genau per INF Files installiert. Bloatware haben wir da so gut wie keine auf den Systemen.

Ein paar Dienste haben wir abgeschaltet, aber hier bin ich dann doch immer etwas vorsichtig, da ich oft die Abhängigkeiten nicht so ganz nachvollziehen kann. Aber über Tipps, welche Dienste man abschalten könnte, wäre ich natürlich dankbar Selbstredend dass man die noch mal gegenprüft, ob diese in der eigenen Umgebung auch wirklich nicht benötigt werden.

Weil wir es nicht benötigen und ich unnötige Funktionen gerne abschalte :) Außerdem hat der Mark dazu einen guten Beitrag geschrieben und daran haben wir uns orientiert https://www.gruppenrichtlinien.de/artikel/ipv6-deaktivieren-das-protokoll-nicht-die-bindung

Hi Norbert, habe mein Beitrag schon editiert. Der Fehler ist wohl kein Fehler, da wie in meinem "Edit" geschrieben die Einstellung in Win11 etwas versteckt ist. Für was dieser Punkt "Eigenschaften Privates Netzwerk" steht weiß ich noch nicht. Das Netzwerkprofil passt aber bei uns. Laut MS ist ab Win 11 nicht mehr NLA für das erkennen des Domain Profils zuständig, sondern der Network List Manager 24H2 hatte uns noch zu viele Kinderkrankheiten Auf Netzwerkwarten ist per GPO gesetzt. IPv6 haben wir komplett über die Regedit deaktiviert (nicht nur die Bindung in der NIC entfernt).

Hallo zusammen, wir rollen im Moment Windows 11 23H2 aus und dabei ist uns folgendes aufgefallen In der Netzwerkübersicht wird hier als Netzwerkprofil (so verstehe ich zumindest die Info "Eigenschaften" als "privates Netzwerk" angezeigt. Das Gerät ist aber ein Domänen Client und alle anderen Indikatoren zeigen auch an, dass er als Netzwerkprofil "Domäne" verwendet Firewall nutzt das Domänen Profil In der Registry ist der Adapter als "Domain" gekennzeichnet Per Powershell mit Get-NetConnectionProfile erhalte ich ein "Domain authenticated" zurück Wird hier in der GUI einfach nur das falsche Profil angezeigt oder steht "Eigenschaften" gar nicht für das Netzwerkprofil, wie man es aus Win 10 kannte? Ist das bei euch auch so? Vielen Dank im Voraus. Grüße EDIT: Ok, ich glaube ich habe gerade selber rausgefunden, dass diese Info "Eigenschaften" wohl irgendwas anderes ist. Wenn man in den Win 11 Einstellungen -> Netzwerk und Internet -> Erweiterte Netzwerkeinstellungen -> Erweiterte Freigabeeinstellungen geht, dann ist dort die Info zum Netzwerkprofil zu finden

Also die Org-Admin Rechte werden für den KMS nicht benötigt. Der "Fehler" war ein einfacher. Der Server Manager wird als Admin gestartet, startet man das Volumenaktivierungstool aus dem Startmenü passiert das nicht automatisch Das Tool muss also mit rechter Maustaste "als Administrator ausführen" gestartet werden, dann kann die KMS Rolle hinzugefügt werden und es werden eben nur lokale Admin Rechte benötigt. Umzug der Clients auf den neuen hat dann problemlos gelappt.

Hatte die Docs bei MS auch schon geprüft und nichts gefunden. Keine Ahnung. Aber wie im "Edit" geschrieben, hat es auch ohne Org Admin Rechte funktioniert, wenn man das Volumenaktivierungstool aus dem Server Manager gestartet hat. Ich könnte mir vorstellen, dass man die Org Admin Rechte auch nur braucht wenn man die active directory based activation nutzt. Werde berichten ob es am Ende geklappt hat :)

Das steht im Wizard direkt auf der ersten Seite. Ist uns nur aufgefallen, da der User mit dem wir den Host aktivieren wollten eben nur lokaler Admin ist. Da aber ganz am Anfang steht "Das verwendete Konto muss über Folgendes verfügen, um die Volumenlizenzierungsdienste installieren und aktivieren zu können:", würde ich jetzt vermuten das es nur für den Install gilt. EDIT: allerdings kam jetzt gerade mein Kollege um die Ecke und meinte, dass er den KMS auch nur mit lokalen Adminrechten aktivieren kann. Dazu muss er die KMS Konfig über den Server Manager starten. Wenn er die Volumenaktivierungstool direkte aus dem Startmenü startet, dann klappt die Aktivierung nicht, da er nicht die notwendigen Rechte hat. Verstehe das jemand...

Jetzt habe ich doch noch eine Frage, vielleicht kann die auch noch beantwortet werden Zur Aktivierung vom KMS muss der Account über bestimmte Rechte verfügen. Diese kann man delegieren oder er muss in der Gruppe der Organisation Admins sein. Nun stellt sich noch die Frage, wird dieser Account dann dauerhaft genutzt oder nur temporär für die Installation und Aktivierung des KMS? Wenn es dauerhaft genutzt wird (z.b. um irgendwelche Daten zu schreiben), müsste ich einen dedizierten Account dafür erstellen. Wenn es nur temporär ist, reicht es aus dem entsprechenden Account kurzzeitig in die Organisation Admins Gruppe aufzunehmen. Vielen Dank schon mal. VG

Das hab ich total falsch verstanden bzw stand auf dem Schlauch Damit ist alles geklärt Danke für deine Hilfe und ein schönes Wochenende!

Sicher das man für Win 11 Pro einen eigenen KMS Key benötigt? Aktuell aktiviert unser 2012R2 Server auch Windows 11 und der hat nie einen extra Win 11 KMS Key erhalten. Der hat nur den Win 10 KMS Key bekommen und es musste ein Update installiert werden. Werde aus der MS Seite auch nicht so richtig schlau - In der Tabelle "Activation versions" steht bei Windows Server 2019 kein Win 11 - In der Tabelle "KMS host required updates" steht bei Windows Server 2019 nur, dass für Server 2025 und 2022 extra Updates benötigt werden. Über Windows 11 wird gar nichts gesagt. Heißt für mich, damit ich Server 2022 und 2025 aktivieren kann, brauch ich die genannten Updates. Aber was ist mit Win 11? Dafür brauche ich wohl kein Update, aber warum wird es dann nicht in der ersten Tabelle bei "Activation versions" aufgelistet? Das klingt ja so, als könnte ich gar kein Win 11 mit Server 2019 aktivieren. Aber unser 2012R2 macht das ja auch schon, ohne jegliches separates Update. Daher meine Vermutung, dass Windows 11 auch mit dem Windows 10 KMS Key aktiviert werden. Windows 10 Pro und Windows 11 Pro haben ja auch den gleichen generischen KMS Key zum aktivieren https://learn.microsoft.com/de-de/windows-server/get-started/kms-client-activation-keys?tabs=server2025%2Cwindows1110ltsc%2Cversion1803%2Cwindows81#windows-11-and-windows-10-semi-annual-channel Aber vielleicht stehe ich auch nur auf dem Schlauch. Nächste Woche werden wir das dann mal testen. Schönes Wochenende zusammen.

Ha ... ok Ich dachte immer es gibt einen KMS Key und einen KMS Host Activation Key. Da wir beim 2012 für Windows 10 und Server 2019 auch Keys installieren mussten, damit der 2012R2 Server diese Server/Clients aktivieren konnte. Aber verstanden, dass ist ein und dasselbe . Wenn ich jetzt einen Server 2019 als KMS Server habe, kann dieser ja direkt 2019er Server aktivieren und Win 10/11 auch, richtig? Für Office 2016 brauche ich dann das Activation Pack. Kann der KMS dann damit direkt auch Office 2016 aktivieren oder brauche ich da noch einen separaten Key?