Alle Aktivitäten

Seit wann das so ist kann ich nicht genau sagen :-( Bin leider auch nur in die Materie rein geschlittert :-( Replikation des NETLOGN/SYSVOL auf allen beteiligten DCs muss ich noch prüfen lassen...

Moin, zeig mal das Ergebnis von ipconfig /all an einem CMD von so einem Client und den DC

Seit wann ist das so? Was wurde zum Zeitpunkt des ersten Auftretens des Fehlers am System geändert? Funktioniert die Replikation des NETLOGN/SYSVOL auf allen beteiligten DCs? Weißt Du ob ein bestimmtes GPO dafür verantwortlich ist?

Hallo zusammen, siehe Screenshot anbei - ich habe in letzter Zeit immer wieder das Problem, dass beim Logon/Login keine Verarbeitung der Gruppenrichtlinie stattfindet. Erst nach mehrmaligem Neustart des Clients klappt es dann irgendwann. Es tut m. E. nichts zur Sache, welcher Logonserver (wir haben 2) genutzt wird. Grund dafür, dass die GPOs nicht gezogen werden ist, dass der Zugriff aufs Sysvol nicht immer funktioniert. Siehe Screenshot, dieser stammt aus einer RDP-Session, in welcher ich via Domainadmin auf einem Client verbunden bin – wenn ich manuell darauf zugreifen möchte (Namensauflösung funktioniert), dann muss ich die Credentials eingeben – folglich ist klar, dass die GPOs nicht angewendet bzw. gelesen werden können. Starte ich das Laptop neu durch, so kann es sein es funktioniert oder auch nicht – ist ein bisschen ein Glücksspiel.

Moin an Board, so starten wir dann in eine neue, spannende Woche - ich koche Kaffee Allen einen ruhigen Montag, bleibt gesund! Sonnige Grüße aus Leipzig, aktuell 14°C, es wird ein sonniger Tag bis etwa 27°C Heute zurück nach Hause, war schön hier

+1 für eine Welt ohne Public Folder.... Hätten die SharePoint Kollegen ihren Job mal richtig gemacht.

Danke dir, hat sehr geholfen.

Die beschreiben doch alle dasselbe. Wo isn dein Verständnisproblem? Der Link den du gepostet hast ist der von April (da war das das Vorgehen und ist es immer noch, nur war da Exchange SE natürlich noch nicht veröffentlicht). Der den ich gepostet habe ist von vorgestern und natürlich beschreibt der dasselbe Vorgehen, nur eben ein wenig ausführlicher in seinen Erklärungen.

Danke dir. Was ist mit diesem hier: Exchange Server Security Changes for Hybrid Deployments | Microsoft Community Hub Step 1 und 2 bei Exchange Hybrid customers who require rich coexistence must act müsste auch gemacht werden, korrekt?

Ich glaub ich rede chinesisch. Der Healthchecker gibt dir einen schönen Link, den solltest du komplett lesen, verinnerlichen und dann entsprechend abarbeiten. ;) https://microsoft.github.io/CSS-Exchange/Diagnostics/HealthChecker/ Alternativ lies das hier: https://techcommunity.microsoft.com/blog/exchange/dedicated-hybrid-app-temporary-enforcements-new-hcw-and-possible-hybrid-function/4440682 Wichtig der Abschnitt: What you should do

Danke dir. Ich nutze SE mit Hybrid. Was genau muss ich jetzt tun? Konkret muss ich den Hotfix von April installieren auf Exchange SE (obwohl beim Hotfix nur 2019 und 2016 steht und nicht SE), und obwohl das Exchange SE-ISO, welches ich zur Installation nutzte, von Juli ist, verstehe ich das richtig? ??Also ich installiere dann den hier auf dem SE?? Download Hotfix Update for Exchange Server 2019 CU15 HU1 (KB5050672) from Official Microsoft Download Center

Es wird sich in 5 Jahren zeigen. Fakt ist, dass es bereits Firmen gibt, die wieder von Cloud zurück auf On Premise gehen, weil die Großen machen, was sie wollen. Alles Glaskugel

SE beinhaltet den April Patch. Tätig werden musst du trotzdem, falls du eine Exchange Hybridbereitstellung nutzt. Wenn du keine Exchange Hybridbereitstellung nutzt, ist es egal ob du den Patch drauf hast oder nicht und auch unter SE musst du dann nichts tun. ;)

Guten Abend, es gibt dieses CVE und unzählig viele Artikel dazu. Der von Microsoft ist hier: CVE-2025-53786 – Leitfaden für Sicherheitsupdates – Microsoft - Microsoft Exchange Server Hybrid Deployment Elevation of Privilege Vulnerability Wie ich es verstehe, ist das Sicherheitsloch in Exchange SE schon gepatcht, da das unten verlinkte KB5047155 auf das SE-ISO verweist, welches am 1. Juli schon online war, das Problem ist auch vom April, wurde nur eben erst veröffentlicht. Kann das bitte wer von euch bestätigen? Ich frage darum, weil in den unzähligen Artikeln vieles steht. Z.B. dass Exchange SE vom diesem CVE betroffen ist. Laut MS Artikel oben ist das auch so, und der Patch ist dann auch gleich das 1. ISO, welches es von SE überhaupt gab. Da kann ich eigentlich nur davon ableiten, wie ich verstehe, dass SE eigentlich gar nicht betroffen ist. Aber man natürlich CU14 oder CU15 einfach auf SE anheben kann und dann sind diese Versionen dann auch gepatcht. Kann bitte wer bestätigen, dass SE okay ist damit? Grüße Telber

Puh, nimm missbrauche in dem Fall doch einfach "%userdnsdomain%\<deine Freigabe/n>". (Solange es definitiv immer nur bei diesem einen DC bleibt). Virtualisieren und eine VM als DC bereitstellen und mit der zweiten einen Fileserver (ggfs. mit DFS-N) ist keine Option?

Ich weiß nicht. PF sind ja so ein bisschen wie File Shares. Der "moderne Weg" scheint zu sein, jeder speichert Zeugs bei sich und "teilt" es mit anderen. In einer Cloud-Welt, wo jeder Zugriff durch Purview gejagt wird, mag das funktionieren, aber sonst?

Das ist ja schön und gut, und kann auch so sein, aber wer um Himmels Willen macht das von einem DC aus?

Es gibt einige Kollegen die über den Explorer Freigaben über den ALIAS Namen ansteuern. Grund dieser Einrichtung war ein Serverwechsel und GPO basierte Netzlaufwerkverbindungen. Es musste dann nur der ALIAS im DNS angepasst werden. Danke Jan!

Hi, warum muss/soll das denn so sein? Gruß Jan

Danke Evgenij für Deine schnelle Antwort. Folgendes habe ich am DC geprüft: netdom verify COMPUTERNAMEDC /domain:DOMAINNAME Als Ergebnis erhalte ich: Die angegebene Domäne ist nicht vorhanden, oder es konnte keine Verbindung hergestellt werden. Der Befehl wurde nicht ordnungsgemäß ausgeführt. Prüfe ich auf dem DC mit diesem Befehl einen anderen Computernamen, erhalte ich folgendes: Der sichere Kanal von GEPRÜFTERCOMPUTERNAME zur Domäne DOMAINNAME wurde überprüft. Die Verbindung besteht mit Computer \\GEPRÜFTERCOMPUTERNAME .DOMAINNAME. Der Befehl wurde ausgeführt. Ping auf die Domäne lös die IPv4 des DC auf. Wenn das ein HOST Eintrag sein sollte, dann nein. Geprüft habe ich mit setspn.exe -L COMPUTERNAMEDC Nein, ist er nicht. Nein, ist er nicht.

Eher ohne Public Folder…

Also von dem DC aus auf sich selbst zugreifen? Existiert der Alias nur im DNS oder korrekt mit NETDOM hinzugefügt? Hat der Server den SPN für diesen Aliasnamen im AD? Ist der Registry-Eintrag für disableStrictNameChecking evtl. gesetzt? Ist der Registry-Eintrag für disableLoopbackCheck evtl. gesetzt?

Hallo zusammen, ich habe ein kurioses Phänomen und hoffe, dass Ihr Rat wisst. Kleines Netzwerk mit Windows Server 2022 und paar Clients im selben Netzwerk. Sobald ich mich auf dem einzigen DC mit einer Netzwerk-Freigabe, die auf dem DC erstellt ist, über einen ALIAS HOST-Namen, der nicht dem Computernamen entsprechen darf, verbinden will, erscheint das Fenster Netzwerkanmeldung. Nach Eingabe der korrekten Daten, erhalte ich trotzdem keinen Zugriff. Verwende ich die IP-Adresse oder den HOSTNAMEN des DC, dann funktioniert es. Getestet habe ich PING und NSLOOKUP auf den ALIAS HOST-Namen. Beide Tests haben als Ergebnis die korrekte IPv4-Adresse des HOSTS. Ebenfalls getestet habe ich die Anmeldung eines zweiten Admin-Benutzers auf dem DC, was dasselbe Fehlerbild zeigt. Von allen anderen Rechnern in diesem Netzwerk funktioniert der Zugriff tadellos. Grüße Mario

Das ist nicht richtig. Deine Aufgabenstellung war ja... "der aus einem 30,5 * 3 cm großen Papierstreifen mit 0,5 cm Überlappung gebastelt wird" somit, da das Papier nicht dehnbar ist und nicht angeschnitten wird (was z.B. bei einer Sphäre zwingend notwendig wäre) gilt für das Möbiusband das gleiche wie für einen Zylinder, den man ohne Verdrehung geklebt bekäme. Das mit der Parameterdarstellung ist eine andere Fläche. Die ließe sich nicht ohne weiteres aus Papier basteln, hätte aber auch bei gleicher Kantenlänge und Streifenbreite einen anderen Flächeninhalt. Die könntest Du aber nicht flach auslegen, wenn Du das Band einmal quer durchschneidest.

Pop Connector!!1!11!eins!!elf!11! *duckundweg* :-P