stevenki

nur eine kurze Rückmeldung - Die Probleme wurden immer umfangreicher und undurchsichtiger ... keine Anmeldung am Client möglich, teilweise kein Zugriff auf Shares (von Client / Server A kein Zugriff, von B wiederrum kein Problem mit gleichen User usw). Auch unser Gast-Cluster (Fileserver) hatte immer wieder Probleme, teilweise am Node ebenso Benutzername / Kennwort falsch usw. Für weiteres Probieren war einfach keine "Zeit" mehr, die Probleme in unserer Produktiv Umgebung wurden ernst. Auch war die AD-Replikation IMMER nach einen Neustart der 2025er DCs kaputt, "RPC Server nicht gefunden" usw... musste manuell angestossen werden und dann lief es wieder bis zum Neustart Wir haben uns dann entschlossen die Domain Controller zu entfernen und neue Domain Controller mit 2022 zu installieren, seit dem sind wir Problemfrei

Also kurze Rückmeldung: nachdem ich mit einem Server den Zugriff nicht mehr auf den Fileserver hinbekommen habe, habe ich diesen aus der Domain genommen. Ein erneuter Beitritt in die Domain war nicht mehr möglich. Ich habe alles probiert, Netzwerkstack zurückgesetzt, manuelle DNS Server, Auflösung getestet, gespeicherte Credentials gelöscht (keine Vorhanden), sogar eine neue SID generiert, nicht möglich. Dann habe ich aus unserem "Grundimage" ein neuen Server 2025 aufgesetzt, Windows Updates gemacht, in die Domain aufgenommen. Zugriff auf SMB Share NICHT möglich -> geht nicht Als Gegentest noch mal aus den gleichen Grundimage (ist ein Windows Server 2025 mit Updates ca. von Mai) installiert, OHNE Updates in die Domain aufgenommen, SMB Share möglich. Ändert nichts daran, dass auch mit dem 2025er DC etwas nicht stimmt. Booten wir die DCs neu, verbleiben die im Modus dann eine Synchronisation nicht möglich ist (RPC Server nicht verfügbar, Server nicht gefunden). Triggere ich eine manuelle Synchronisation an, geht es wieder alles. Vermutlich rühren dort unsere ursprungsprobleme her (Maschinenpasswörter die ggf. auseinander driften) Fakt ist, ich sehe nicht mehr durch ... aber ganz klar ist auch, installiere ich das aktuelle Windows Update auf 2025, bekomm ich ein Zugriff auf den SMB Share unseres Fileserver nicht mehr hin (auch 2025) -> da bekomme ich immer nur noch Netzwerkpfad nicht gefunden.

Also es ist wirklich komisch, wochenlang geht es (bis auf einzelne Anmeldeprobleme) und dann kommt wieder Tag X wo quasi nichts mehr geht. Ein repadmin /replsummary hat bei Quell-DSA DC01 als Fehler angezeigt, bei Ziel-DSA DC02 als Fehler. Ein repadmin /showrepl hat immer das ausgegeben: CN=Schema,CN=Configuration,DC=domain,DC=xx Standort\DC01 über RPC DSA-Objekt-GUID: a514d08f-f9c3-4889-93a6-e6f5c4b9573e Letzter Versuch am 2025-09-30 11:46:46 ist fehlgeschlagen, Ergebnis 1908 (0x774): Der Domänencontroller für diese Domäne wurde nicht gefunden. 1 aufeinander folgende Fehler. Letzte Erfolg um 2025-09-30 10:52:07. Ein Repadmin /Syncall /APeD hat ohne Fehler funktioniert und plötzlich waren alle anderen Befehle auch wieder ohne Probleme. Danach konnten manche Server nicht mehr angemeldet werden (Benutzername Passwort falsch) -> da habe ich das MaschinenPasswort zurückgesetzt via Powershell augenscheinlich läuft jetzt alles wieder.. ABER ich kann von einem Server nicht auf einen anderen Server per SMB zugreifen. SMB-Freigabe = Server A SMB-Client Server = Server B irgendein dritter Server = Server C Server B auf Server A, kein Zugriff möglich. Es kommt, dass der Pfad nicht gefunden wurde von Server C kann ich auf Server A und Server B zugreifen, ohne Probleme Ich habe alles probiert... wenn ich den nicht funktionierenden Zugriff von Server B auf A starte, wird im DC folgendes ProtokollierT: Es wurde ein Kerberos-Dienstticket angefordert. Kontoinformationen: Kontoname: Administrator@domain.LOCAL Kontodomäne: domain.LOCAL Anmelde-GUID: {8d65f0ca-0efc-dc10-1223-182bee81e08b} MSDS-SupportedEncryptionTypes: N/A Verfügbare Schlüssel: N/A Dienstinformationen: Dienstname: AG-SRVCLNODE01$ Dienst-ID: domain\AG-SRVCLNODE01$ MSDS-SupportedEncryptionTypes: 0x1C (RC4, AES128-SHA96, AES256-SHA96) Verfügbare Schlüssel: AES-SHA1, RC4 Domänencontrollerinformationen: MSDS-SupportedEncryptionTypes: 0x1F (DES, RC4, AES128-SHA96, AES256-SHA96) Verfügbare Schlüssel: AES-SHA1, RC4 Netzwerkinformationen: Client-Adresse: ::ffff:192.168.1.49 Client-Port: 49778 Beworbene E-Typen: AES256-CTS-HMAC-SHA1-96 AES128-CTS-HMAC-SHA1-96 RC4-HMAC-NT RC4-HMAC-NT-EXP RC4-HMAC-OLD-EXP Zusätzliche Informationen: Ticketoptionen : 0x40810000 Ticketverschlüsselungstyp: 0x12 Sitzungsverschlüsselungstyp: 0x12 Fehlercode: 0x0 Übertragene Dienste: - Ticketinformationen Ticket-Hash anfordern: 032kGYblSyvg1A1USYrE5j9ozeSkarob0xy/zEN6NNk= Antwort Ticket-Hash: WvkSPncrq23CP8RQXMpg8q1714+GGZeBY48Es2cFVGg= Dieses Ereignis wird jedes Mal generiert, wenn Zugriff auf eine Ressource angefordert wird, wie z. B. auf einen Computer oder einen Windows-Dienst. Der Dienstname steht für die Ressource, auf die der Zugriff angefordert wurde. Dieses Ereignis kann mit Windows-Anmeldeereignissen korreliert werden, indem die Anmelde-GUID-Felder in jedem Ereignis verglichen werden. Das Anmeldeereignis findet auf dem Computer statt, auf den zugegriffen wurde, der oft ein anderer Computer ist als der Domänencontroller, der das Dienstticket ausgestellt hat. Vorauthentifizierungstypen, Ticketoptionen, Verschlüsselungstypen und Ergebniscodes sind in RFC 4120 definiert. Server B protokolliert in dem Moment folgendes: Fehler beim Anmelden eines Kontos. Antragsteller: Sicherheits-ID: NULL SID Kontoname: - Kontodomäne: - Anmelde-ID: 0x0 Anmeldetyp: 3 Konto, für das die Anmeldung fehlgeschlagen ist: Sicherheits-ID: NULL SID Kontoname: Administrator Kontodomäne: domain.LOCAL Fehlerinformationen: Fehlerursache: Bei der Anmeldung ist ein Fehler aufgetreten. Status: 0xC000006D Unterstatus:: 0x0 Prozessinformationen: Aufrufprozess-ID: 0x0 Aufrufprozessname: - Netzwerkinformationen: Arbeitsstationsname: - Quellnetzwerkadresse: 192.168.1.49 Quellport: 49775 Detaillierte Authentifizierungsinformationen: Anmeldeprozess: Kerberos Authentifizierungspaket: Kerberos Übertragene Dienste: - Paketname (nur NTLM): - Schlüssellänge: 0 Dieses Ereignis wird beim Erstellen einer Anmeldesitzung generiert. Es wird auf dem Computer generiert, auf den zugegriffen wurde. Die Antragstellerfelder geben das Konto auf dem lokalen System an, von dem die Anmeldung angefordert wurde. Dies ist meistens ein Dienst wie der Serverdienst oder ein lokaler Prozess wie "Winlogon.exe" oder "Services.exe". Das Anmeldetypfeld gibt den jeweiligen Anmeldetyp an. Die häufigsten Typen sind 2 (interaktiv) und 3 (Netzwerk). Die Felder für die Prozessinformationen geben den Prozess und das Konto an, für die die Anmeldung angefordert wurde. Die Netzwerkfelder geben die Quelle einer Remoteanmeldeanforderung an. Der Arbeitsstationsname ist nicht immer verfügbar und kann in manchen Fällen leer bleiben. Die Felder für die Authentifizierungsinformationen enthalten detaillierte Informationen zu dieser speziellen Anmeldeanforderung. - Die übertragenen Dienste geben an, welche Zwischendienste an der Anmeldeanforderung beteiligt waren. - Der Paketname gibt das in den NTLM-Protokollen verwendete Unterprotokoll an. - Die Schlüssellänge gibt die Länge des generierten Sitzungsschlüssels an. Wenn kein Sitzungsschlüssel angefordert wurde, ist dieser Wert 0. Genau die gleichen Logs wie wenn wir die "wir können uns nicht mehr Anmelden" Probleme haben, komisch ist das Sicherheits-ID in dem Moment immer NULL SID steht. Den Artikel von @testperson bin ich durchgegangen, der passt sehr gut zu "unseren Problemen" . Aber wir haben das geprüft, RC4 scheint bei uns nicht deaktiviert zu sein

Aktuell habe ich wieder das Problem, dass ich auf die c$ Freigabe eines Server nicht zugreifen kann, im Explorer passiert einfach nichts, per cd in Powershell erhalte ich folgende Fehlermeldung: cd : Der Pfad "\\[Servername]\c$" kann nicht gefunden werden, da er nicht vorhanden ist. In Zeile:1 Zeichen:1 Was habe ich geprüft: 1) auf Server und Client (auch ein Server) sind Uhrzeit mit dem DC synchronisiert und identisch 2) Auflösung kein Problem 3) Client sowie Server sagen bei Test-ComputerSecureChannel das alles iO ist 4) wenn ich auf dem Client ein "klist get host/[Servername]" ausführe, bekommt der Client ein Ticket ich bekomme einfach keinen Zugriff hin, nun habe ich den Server neugestartet und alles funktioniert wieder. Ich gehe mal den Artikel von dir durch @testperson, vielen Dank erstmal Wir haben auf einem Server ein dauerhaftes Powershell Skript laufen, welches Daten auf einen Fileshare kopiert. Über eine CSV wird das Share-Ziel ermittelt (unterschiedliche Server) -> auf manche Server klappt es grade, auf andere sagt er Benutzername oder Kennwort falsch. Gleicher Benutzer ... es ist wirklich zum Wahnsinnig werden

Hallo, danke für eure Antworten. War leider krank und das Problem spitzt sich zu ... auch server haben teilweise nun das Problem. Nach einem Neustart ist dann meißt alles wieder iO. @daabm: Wenn ich deinen Befehl an einen betroffenen Client / Server ausführe erhalte ich bei klist get host/%computername% nur folgende Ausgabe: Fehler bei klist. Fehler: 0xc000018b/-1073741429: Die SAM-Datenbank des Windows-Servers enthält kein Computerkonto für diese Arbeitsstationsvertrauensstellung. Die Probleme haben wir aus meiner Sicht seit dem wir den 2025er DC mit integriert haben. Davor gab es diese Problematik nie a) DNS geht ohne Probleme zu der Zeit, ich kann alles ordentlich auflösen am Client / Server b) es betrifft auch relative neue Clients / Server die vor nicht allzu langer Zeit in der Domain aufgenommen wurden

Also das Zurücksetzen des Passworts vom krbtgt hat nichts gebracht ... DNS würde ich an der Stelle eventuell ausschließen?! Weil im Log des Clients steht zb davor, dass er sich die Uhrzeit vom per Name aufgelösten DC geholt hat. Die Auflösung scheint ja also zu klappen und den DC erreicht er ja, sonst würde der DC ja auch nichts Protokollieren oder? Wegen dem RC4 schaue ich mir mal an, dankeschön

Also am Computer Kennwort kann es , aus meiner Laiensicht, nicht liegen, denn sollte dann jeder Computer nicht genau nur 1* betroffen sein? Tatsächlich sind die Clients mehrfach betroffen, hatte erst Freitag einen Notebook mal phyisisch in dem Moment vor mir, wo das Problem auftrat. Keine Anmeldung mit keinem Konto möglich (außer natürlich mit dem lokalen), Neustart, alles wieder iO. Logs genau auf allen Clients gleich

Hallo, danke für eure Antworten. Leider ist mir das entgangen, gab es da einen manuell zu installierenden Hotfix? Also Grundlegend sind alle Updates installiert, die über Windows Update zu beziehen sind.

Hallo zusammen, wir haben aktuell "massive" Probleme mit Anmeldeproblemen, die ich einfach nicht nachvollziehen kann. Ich würde behaupten, dass die Probleme auftreten, seit dem wir einen Windows Server 2025 DC mit im System haben, 12 Jahre davor hatten wir keinerlei diese Probleme. Die Probleme äußern sich wie folgt: Einige Rechner melden bei der Anmeldung "Benutzername oder Kennwort falsch". Wenn wir in dem Moment uns dann lokal Anmelden und Test-SecureComputerChannel machen, bekomme ich ein True. NSLookup hat auch die Domain sowie alle Domaincontroller aufgelöst usw. Zeit passt auch mit den DCs überein. Nach einem Neustart des Clients gehts dann immer wieder. Das Problem haben wir auch im gesperrten Modus, also wenn ein Benutzer seinen Rechner sperrt und wieder entsperren will. Im Log des Clients wird folgendes gemeldet: EventID 4625 MachineName TA-CLPC20005.xxx.local EntryType FailureAudit Fehler beim Anmelden eines Kontos. Antragsteller: Sicherheits-ID: S-1-5-18 Kontoname: TA-CLPC20005$ Kontodomäne: [DOMAINNAME] Anmelde-ID: 0x3e7 Anmeldetyp: 2 Konto, für das die Anmeldung fehlgeschlagen ist: Sicherheits-ID: S-1-0-0 Kontoname: [Anmeldename] Kontodomäne: [DOMAINNAME] Fehlerinformationen: Fehlerursache: %%2304 Status: 0xc000006d Unterstatus:: 0x0 Prozessinformationen: Aufrufprozess-ID: 0x9e8 Aufrufprozessname: C:\Windows\System32\svchost.exe Netzwerkinformationen: Arbeitsstationsname: TA-CLPC20005 Quellnetzwerkadresse: 127.0.0.1 Quellport: 0 Detaillierte Authentifizierungsinformationen: Anmeldeprozess: User32 Authentifizierungspaket: Negotiate ?bertragene Dienste: - Paketname (nur NTLM): - Schl?ssell?nge: 0 zur gleichen Zeit wird auf dem DC folgendes protokolliert: Ein Kerberos-Dienstticket wurde angefordert. Kontoinformationen: Kontoname: [Anmeldename]@[DOMAINNAME] Kontodomäne: [DOMAINNAME] Anmelde- GUID: {8ceb624b-4a79-43d5-9f30-fc3eacf3d33c} MSDS-SupportedEncryptionTypes: 0x0 (N/A) Verfügbare Schlüssel: N/A Dienstinformationen: Dienstname: TA-CLPC20005$ Dienst-ID: [DOMAINNAME]\TA-CLPC20005$ MSDS-SupportedEncryptionTypes: 0x1C (RC4, AES128-SHA96, AES256-SHA96) Verfügbare Schlüssel: DES, RC4, AES128-SHA96, AES256-SHA96 Domaincontrollerinformationen: MSDS-SupportedEncryptionTypes: 0x18 (AES128-SHA96, AES256-SHA96) Verfügbare Schlüssel: DES, RC4, AES128-SHA96, AES256-SHA96 Netzwerkinformationen: Clientadresse: ::ffff:10.1.10.38 Clientport: 53570 Angekündigte ETYPEs: AES256-CTS-HMAC-SHA1-96 AES128-CTS-HMAC-SHA1-96 RC4-HMAC-NT DES-CBC-MD5 DES-CBC-CRC RC4-HMAC-NT-EXP RC4-HMAC-OLD-EXP Zusätzliche Informationen: Ticketoptionen: 0x40810000 Ticketverschlüsselungstyp: 0x12 Sitzungsverschlüsselungstyp: 0x12 Fehlercode: 0x0 Übertragene Dienste: - Ticketinformationen Hash des Anforderungstickets: s5yh1FJP7/QGNfIseWEklJBJwrWgI6rnxxwBYFb82qw= Hash des Antworttickets: Kd0//U3zlF76OWCXt/dK468UjDOx3yRqjxSDZW6014E= Es wurde ein Kerberos-Authentifizierungsticket (TGT) angefordert. Kontoinformationen: Kontoname: [Anmeldename] Bereitgestellter Bereichsname: [DOMAINNAME] Benutzer-ID: [DOMAINNAME]\ [Anmeldename] MSDS-SupportedEncryptionTypes: 0x24 (RC4, AES-SK) Verfügbare Schlüssel: DES, RC4, AES128-SHA96, AES256-SHA96 Dienstinformationen: Dienstname: krbtgt Dienst-ID: [DOMAINNAME]\krbtgt MSDS-SupportedEncryptionTypes: 0x18 (AES128-SHA96, AES256-SHA96) Verfügbare Schlüssel: DES, RC4, AES128-SHA96, AES256-SHA96 Domaincontrollerinformationen: MSDS-SupportedEncryptionTypes: 0x18 (AES128-SHA96, AES256-SHA96) Verfügbare Schlüssel: DES, RC4, AES128-SHA96, AES256-SHA96 Netzwerkinformationen: Clientadresse: ::ffff:10.1.10.38 Clientport: 53569 Angekündigte ETYPEs: AES256-CTS-HMAC-SHA1-96 AES128-CTS-HMAC-SHA1-96 RC4-HMAC-NT DES-CBC-MD5 Zusätzliche Informationen: Ticketoptionen: 0x40810010 Ergebniscode: 0x0 Ticketverschlüsselungstyp: 0x12 Sitzungsverschlüsselungstyp: 0x12 Vorauthentifizierungstyp: 2 Vorauthentifizierungsverschlüsselungstyp: 0x12 Zertifikatinformationen: Name des Zertifikatausstellers: Seriennummer des Zertifikats: Fingerabdruck des Zertifikats: Ticketinformationen Hash des Antworttickets: s5yh1FJP7/QGNfIseWEklJBJwrWgI6rnxxwBYFb82qw= ich weiß leider nicht mehr wo wir ansetzen sollen, es betrifft aktuell nur "wenige" einzelne Rechner, gefühlt werden es aber mehr. Hat jemand Ideen wo ich noch ansetzen könnte? Interessanterweise meldet der Client auch folgendes: 13:15:21 Der Computer konnte eine sichere Sitzung mit einem Domänencontroller in der Domäne DOMAINNAME aufgrund der folgenden Ursache nicht einrichten: Interner Fehler. Was interner Fehler hier bedeutet weiß ich nicht - ABER, dieser Fehler kommt erst eine ganze Weile nach den Meldungen oben. Auch finde ich im Log, dass er erfolgreich die Zeit mit dem DC synchronisiert usw. Ich wäre glücklich, wenn jemand eine Idee hat. Liebe Grüße

Fehler gefunden - es tut mir leid für die Verwirrung. Aufgrund unserer ganzen Core Installationen (fast alles mittlerweile bei uns unter Core) ist es nicht direkt aufgefallen - für den 1 DC wurde versehentlich das falsche ISO verwendet, es ist also eine 2022 VM. Das erklärt das unterschiedliche Verhalten der 2 DCs, warum es bei einem geht und beim anderen nicht. Außerdem habe ich mich noch mal in diesen Artikel eingearbeitet: https://www.windowspro.de/philip-lorenz/domain-controller-ldap-channel-binding-ldap-signing-absichern Offensichtlich verhält sich Server 2025 da nicht mehr wie 2022, denn selbst wenn ich alles "optional" einschalte, Channel-Binding und Signierung ist immer aktiv. Deswegen schlägt das ganze auf dem 2025er DC fehl. Ich konnte nun das ganze erfolgreich auf LDAPS umbauen und es funktioniert mit beiden DCs Sorry für die Verwirrung und danke an alle Beteilgten

Port ist natürlich offen, ein Telnet auf den Port zeigt auch eine Verbindung ... das gepostete war etwas überhastet, habe es natürlich auch mit DNS Namen probiert, keine Änderung :-( Allerdings steht die GPO noch wie oben geschrieben, ist damit TLS gänzlich deaktiviert?

Hallo, danke für deine Antwort. Also beide DCs haben ein Zertifikat mit der Vorlage Domänencontroller , sonst kein weiteres. Bei der einen Anwendungen (es betrifft aber wie gesagt alle Anwendungen bei uns) kann ich auch extra "keine Verschlüsselung" oder "SSL verwenden" einstelle. Wenn ich SSL verwenden aktiviere funktioniert weder DC1 noch DC2, da lautet die Fehlermeldung Could not connect to Ldap Server: 0x51 (Can't contact LDAP server; (unknown error code)): ldaps://192.168.1.10:636 Ich stehe total auf dem Schlauch aber danke für deine Hilfe

Hallo, wir sind derzeit dabei, sämtliche VMs von Server 2012 R2 / 2016 und 2019 zu 2025 zu migrieren. Die DC sind dabei bereits erfolgt, beide auf 2025. Leider haben wir jetzt mit externen Programmen Probleme, die vorher immer per LDAP die DCs abgefragt haben. Ein Fehlermeldung unseres MDM Systems lautet: Could not connect to Ldap Server: 0x8 (Strong(er) authentication required; 00002028: LdapErr: DSID-0C0903CC, comment: The server requires binds to turn on integrity checking if SSL\TLS are not already active on the connection, data Ich habe folgende GPO (Default Domain Controller Policy) bereits folgendermaßen angepasst: Domänencontroller: Signaturanforderungen für LDAP-Server -> Keine Es funktioniert trotzdem nicht. Das wirklich merkwürdige an der Sache ist jedoch, es funktioniert nur auf 1! DC nicht. Auf dem anderem DC funktioniert es problemlos. Wir haben nun - als temporäre Lösung - in sämtlichen Programmen einfach den LDAP Server auf den funktionierenden DC gelenkt und alles funktioniert erstmal. Trotzdem würde ich das Problem gern lösen und verstehen, was der 2. DC für ein Problem hat. Habt ihr Lösungsansätze für mich?

das ist mir bewusst ... mit "VM-Netz" meinte ich ja auch nur den vSwitch, an welchen die VMs angebunden sind. Vielen Dank für eure Antworten, wie gesagt, es ist klar, dass es eine Mini Umgebung ist. Trotzdessen wollte ich hier mal nachfragen, ob es Empfehlungen gibt, die ich bei der Netzwerkplannung unbedingt beachten sollte. Danke für eure Antworten

Danke für die Antworten, tatsächlich war meine FRage weniger der Performance geschuldet , da wird die Umgebung kaum große Notwendigkeiten ans Netzwerk stellen. Mir ging es nur um die Best Practise bei Hyper-V, da ich wie gesagt, in der Richtung eher aus dem VMWare Umfeld komme und mir die aktuellen Best Practises einfach so nicht bekannt sind. Warum nicht stacken? Ich habe sehr viele Uplinks, die via LACPs Links auf jeweils ein Switch des Switch-Stacks gehen, um Redundanz zu gewährleisten. Ja, ich könnte stattdessen auch mit RSTP arbeiten, aber was spricht denn gegen Stacks? Als Shared-SAS hatte ich eine DELL ME5024 geplant - relativ günstig für ein, für diese Umgebung, sehr performantes shared Storage. Dieser Xaler ist doch ein S2D korrekt? Hatte ich auch überlegt, aber mMn steigert es die komplexität unnötig für gleiche Kosten und unwesentlich, nicht benötigter, mehr performance (wenn überhaupt). Aber kannst mich auch gern korrigieren...

danke für eure Antworten, wie ich bereits im Eingangs-Post schrieb, ich bin bei den pNICs noch flexibel, abhängig von der Best-Practice vom Hyper-V. Ports im Switch-Stack habe ich genügend übrig, und die pNICs kann ich, da die Server noch in der Bestellphase sind, noch beliebig anpassen. Die Umgebung wird eher eine relativ kleine Umgebung, wenig Last (8-10 VMs, darunter 1 Exchange, 1 Datev Server, 2 RDS, 15 User) Für Backup-Traffic wollte ich saperate NICs verwenden, um den Backupserver auch komplett zu trennen. Also vom Prinzip her: - Livemigration - Cluster / CSV (zusammen via vNIC oder getrennte pNICs?) - Backup-Traffic - VM - Mgmt Alle Karten werden 10Gbit haben

Hallo zusammen, bisher war ich immer in der VMWare Schiene unterwegs, aufgrund der aktuellen Lizenzproblematik und nur noch ABO-Modellen möchte ich im nächsten Projekt daher ein Hyper-V Cluster verwenden. Hier bin ich allerdings die ganze Zeit auf der Suche nach den Best Practises bzgl. Networking und finde immer sehr unterschiedliche Aussagen. Auf manchen Seiten wird geraten, ein SET Team zu erstellen und vNIC daran zu hängen für die verschiedenen Dienste. Auf anderen Seiten wird wiederrum sämtlicher Traffic weiterhin getrennt. Aktuell bin ich noch frei in der Netzwerkkonfiguration der Server , es soll ein Cluster aus 2 Hosts werden. Storage wird über shared SAS angebunden, also keine Netzwerkbetrachtung notwendig. Außerdem werden 2 Switches, welche gestackt werden, verwendet, um die Hosts ans Netzwerk zu bringen. Für Live-Migration wollte ich die Hosts direkt miteinander verbinden (10 Gbit). Hier die 1. Frage: - eine Verbindung für Live-Migration (1* 10 Gbit) - 2 Verbindungen für Live-Migration (2* 10 Gbit) - 1 SET Team mit 2 Verbindungen für Live-Migration Da es nur ein 2 Host-Cluster wird stellt sich auch die Frage für Cluster / CSV Traffic. Oder reicht 1* SET Team mit 2*10 Gbit und dann verschiedene vNIC für die Dienste Livemigration, Clustertraffic,..? Wie sieht es mit dem Mgmt des Hypervisors aus? - eigene Verbindung via LFBO Team - eigene Verbindung via SET Team? - vNIC im Set-Team gemeinsam mit VM Traffic? Wäre schön, wenn ich von euch ein paar Anregungen bekomme, welche Konstellation am besten und sinnvoll ist. Vielen Dank

Hallo, ja funktioniert in beide Richtungen mit OWA und Outlook.

Hallo, wir befinden uns in der Migration von Exchange 2016 zu Exchange Online. Die Hybridstellung (Klassisch voll) funktioniert, ich habe einige User auch erfolgreich zu ExO verschieben können. In Verbindung mit Teams habe ich neue Ressourcenpostfächer (Räume) auf dem Exchange Online angelegt (also natürlich vom lokalen Exchange mit enable-remotemailbox). Der Raum ist von ExO Usern sichtbar und wird in der lokal erstellten, synchronisierten Raumliste auch angezeigt. ExO User sehen auch die Exchange on-prem Räume, nur andersrum nicht. Ein Exchange on-prem User sieht zwar die Raumliste (in der die eigentlichen Exchange Online Räume liegen), diese ist jedoch leer. Wie kann ich das Problem lösen? Alles was ich bisher gesucht habe hat immer vom umgedrehten Szenario gehandelt (Exchange on-prem Räume und Exchange Online User) Ich würde mich freuen wenn Ihr mir helfen könnt. Lieben Dank

Hallo zusammen, vielleicht ist ja jemand im Forum an Board, der sich mit den oben genannten Switchen auskennt (Aruba OS 16.10) Ich habe ein Device-Profil angelegt: device-identity name "Voip-Phone" lldp oui 0012bb sub-type 2 exit device-profile name "Voip-Phone" untagged-vlan 10 tagged-vlan 20 exit device-profile device-type "Voip-Phone" associate "Voip-Phone" enable exit Ziel ist, dass sobald an einem Port ein Voip-Phone erkannt wird, der Port die VLANs entsprechend erhält (Tagged 20, untagged 10) Grundlegend funktioniert das auch, der Port erhält dynmisch die VLANs. Ich habe aber das Problem, dass der Bootvorgang des Telefons vermutlich diese Prozedur stört, denn das Telefon startet während des Boot-Prozesses 3* neu, wo es ganz kurz den LAN-Port deaktiviert. Meine Vermutung ist, dass aufgrund dieses kurzen deaktiverens das Konstrukt nicht funktioniert, da das Telefon am Ende die TK-Anlage im VLAN 20 nicht erreicht und sich in einer Dauerschleife befindet und immer wieder mit "No Ethernet" neustartet - no Ethernet bedeutet in dem Fall aber nicht "kein Netzwerk" sondern keine Verbindung zur Anlage ... das Telefon hat in dem Moment eine falsche IP Konfiguration (die des 10er VLANs). In meiner Theorie ist das Problem das kurze Port-Deaktivieren beim Booten, sodass das Profil, welches der Port bekommt, immer wieder zurückgesetzt wird. Ich müsste also die dynamische Zuweisung der VLANs für eine gewisse Zeit auch beibehalten, auch wenn der Port deaktiviert wird. Ggf. mit irgendwelchen LLDP Timern? Leider bin ich auf dem Gebiet LLDP noch relativ frisch, sodass ich hier mal um Hilfe frage. PS: Ja, die Variante VLAN 20 als Voice VLAN zu kennzeichnen und auf den Ports das untagged 10 und tagged 20 VLAN festzulegen, funktioniert einwandfrei (VLAN 10, um PCs, welche am Telefon hängen, im entsprechenden VLAN zu haben). Allerdings müssen so sämtliche Ports manuell mit VLANs konfiguriert werden, sodass ich gern die Thematik über die device-profile versucht hätte, zu lösen

Hat sich erledigt, man muss beim set-mailbox den Parameter -publicfolder mit angeben, dann funktioniert es. korrekt, Outlook verbindet sich ja aber trotzdem auf dessen "Emailadresse" ... Problem somit gelöst

na das die Adresse [Domain].local ist, welche natürlich nicht im Zertifikat enthalten ist und somit ein Zertifikatsfehler im Outlook erscheint

Nein, ich kann da leider nichts einstellen außer Kontingente

Hallo, wir haben unsere Migration von Exchange 2010 zu 2016 erfolgreich und problemlos durchgeführt. Leider habe ich noch ein Problem mit den öffentlichen Ordnern bzw. mit dem Postfach für öffentliche Ordner. Beim erstellen hat dieser sich leider die Emailadresse mit der internen Domain gezogen ... diese ist natürlich nicht im Zertifikat enthalten. Wie bekomme ich diese Mailadresse geändert? über Get-mailbox -PublicFolder bekomme ich das Postfach angezeigt, über Get-mailbox -PublicFolder | Select-Object displayname,EmailAddresses, PrimarySmtpAddress,WindowsEmailAddress bekomme ich das Postfach aufgeführt und in allen Spalten steht @domain.local Aber wie bekomme ich die Werte angepasst? Wenn ich über Get-mailbox -PublicFolder | Set-Mailbox -PrimarySmtpAddress PF_master@domain.de versuche, die Adresse anzupassen, sagt er mir folgenden Fehler: Das Objekt ist natürlich vorhanden und sämtliche andere Vorgänge (neuer Mailbox / neuer User, Mailbox / User ändern) funktionieren einwandfrei über die Powershell. Das Problem betrifft tatsächlich nur das Konto für die öffentliche Ordner. Vielen Dank für eure Hilfe

Hallo, vielen Dank erstmal für eure Antworten. Leider kann ich die Kritik teilweise nicht ganz verstehen - warum eine Umgebung nachbauen, die nicht aussagekräftig ist? Es ist doch ein 1:1 Abbild der original Umgebung, wenn diese Testumgebung nicht aussagekräftig ist, welche dann? Warum wir das selber machen steht leider in der Form nicht zur Diskussion, auch wenn ich eure Argumente verstehe. Aber das entscheide ja nicht ich. Und an sich finde ich unsere Exchange Umgebung ja auch nicht wirklich komplex, es ist keine DAG vorhanden oder die Rollen auf unterschiedlichen Servern verteilt sondern ein Single-Server. Und es ist auch nicht so , dass ich Exchange vorher noch nie gesehen habe, es ist halt meine erste Migration, die ihr ja auch irgendwann mal als erstes gemacht habt. Könnt ihr mir den Tips geben, wo ich ansätzen könnte? Die DNS Einträge (Split-DNS) sehen folgend aus: autodiscover.domain1.de -> interne IP Exchange 2010 autodiscover.domain2.de -> interne IP Exchange 2010 autodiscover.domain3.de -> interne IP Exchange 2010 usw. mail.hauptdomain.de -> sämtliche URLs auf dem Exchange 2010 sowie auf dem 2016. -> zeigt auf den 2010er. Je nachdem, wo ich diese Einträge hinlenke, dieser Exchange funktioniert dann in Bezug auf Outlook Konnektivität ... Die Proxyfunktion fürs OWA funktioniert wiederrum ohne Probleme wenn die DNS Einträge auf den 2016er zeigen und ich mich im "neuen" OWA anmelde