henryy

Moin Norbert, bisher hatten wir bei den Servern eine feste IPv6 vergeben und keine Probleme damit, aber so ganz glücklich bin ich damit nicht mehr wirklich. Ich würde eigentlich gerne auf Stateless umstellen bei Zeiten. Grüße aus Bremen nach Bremen

Moin, stimmt wir haben nur den Haken entfernt und zumindest über ipconfig zeigt er dann auch keine ipv6 Adresse mehr an. Wenn wir den haken wieder reinnehmen dann kommt das Problem nach unbestimmter Zeit wieder. Haken wieder raus, Problem wieder weg. Macht eigentlich wenig Sinn das es Jahrelang mit IPv6 aktiv funktioniert hat und plötzlich nicht mehr. Einziger Grund den ich mir noch vorstellen könnte ist irgendein update, aber dann kann es auch nur ein DC/DNS update sein, weil ein frischer RDS 2019 Broker ohne updates zeigt das gleiche verhalten.

Nach einem Tipp haben wir auf dem Broker IPv6 deaktiviert und schwubs war alles wieder zu sehen im Broker, aber das kann ja nicht die Lösung sein auf Dauer IPv6 zu deaktivieren.

Was genau war das für ein Update Problem? Hast du da vielleicht einen Link zu und betraf das nur 2019er RDS?

Moin, danke für die Rückmeldung. Was genau meinst du damit? Ich habe bei der Installation der RDS Rollen im Assistenten auch einen RDS Host und einen Lizenz Server hinzugefügt und diese müssen dann ja auch über den Servermanager vorher hinzugefügt worden sein, denn sonst kann man die ja gar nicht auswählen. Im Servermanager des neuen TestBrokers sind also er selber, ein RDS Hosts und ein Lizenzserver vorhanden.

Moin und frohes Neues, leider bringt das neue Jahr merkwürdige Probleme mit sich. Wir haben eine 2019er RDS Farm (1x Broker, 6x RDS Hosts, kein Gateway). Die Farm läuft schon seit Jahren ohne größere Probleme. Letzte Woche wollten wir über den Broker Support machen und die RDS Konsole über den Servermanager konnte nichts anzeigen außer folgendes Bild Zugriff über powershell auch nicht möglich: Ereignissanzeige: zeigt auch keine besonderen Fehler bis auf ID 2056 Datenbankfehler aber der wird weiter oben durch ID 2080 wieder "aufgehoben" und Verbindung zur Datenbank angeblich wiederhergestellt. Es scheint so als ob gar kein Broker vorhanden ist, obwohl er natürlich die Rolle hat und grundsätzlich funktioniert die Farm auch und user können sich anmelden und auf den RDS Hosts arbeiten. Nur können wir(Admins) nicht auf die Farm zugreifen, für zb user Support oder auch neue RDS Hosts hinzufügen oder entfernen. Da ich schon recht viel recherchiert habe und keine befriedigende Lösung gefunden hatte, haben wir den Server aus einem Backup geholt und dann lief er ca. 1 Stunde und danach wieder das gleiche Bild. Nächste Maßnahme war paralel eine neue RDS Umgebung am Freitag hochgezogen. Funktionierte am Freitag alles und heute ins Büro gekommen und auch der völlig neu aufgesetzte RDS Broker hat das gleiche Problem. Hat vielleicht jemand eine Idee?

Moin, ich würde gerne eine virtualisierte RDS 2012r2 Farm (5 TS,1 Broker, 1 Gateway und Lizenz Server) auf eine neue OS Plattform bringen. Einer der Gründe ist zb fehlende Programm Kompatibilität mit 2012 R2 zu Adobe Suite CC2019 und ggf erhoffe ich mir kleine Performance Verbesserungen bei Leitungen mit kleinen Bandbreiten wie 2-10Mb (zb You Tube Videos schauen etc). Würdet ihr da 2016 oder 2019 empfehlen? Nach bisheriger Internetrecherche scheint 2016 sogar etwas performanter als 2019 zu sein. Da finde ich aber durchaus widersprüchliches im Netz zu. Den Nachteil das Office 365 Plus nicht unter 2019 läuft fällt für diese Umgebung flach, da wir dieses Office nicht nutzen. Zweite frage wäre die Art der Migration. Zur zeit sehe ich da zwei Möglichkeiten. 2012R2 ließe sich ja wohl ohne Neuinstallation auf 2016 upgraden. Somit wären alle Einstellungen etc dann noch vorhanden. Ich tue mich mit diesen "in place" Upgrades allerdings immer etwas schwer, weil man nie weiss was man da an Problemen "erbt". Neuinstallation einer 2019er Farm und Parallelbetrieb (2012R2 und 2019). Ist so ein Parallelbetrieb von zwei RDS Umgebungen möglich und was wäre zu beachten um die existierende 2012R2 nicht zu stören"? Sieht für mich möglich aus und momentan die attraktivste Umsetzung weil dann einiges schon im laufenden Betrieb getestet werden kann ohne wirklich produktiv zu gehen. Wie habt ihr eure RDS Umgebungen erneuert? Lg Henry

Moin, die Ausschlüsse waren gesetzt. Wir hatten bis Anfang des Jahres Mc Afee im Einsatz und sind dann gewechselt zu GData. Kein Plan warum trotz Ausschlüsse dann G Data wohl doch noch auf die CSVs eingewirkt hat. Erstmal gut, dass es nichts mit dem SAN und dem Cluster zu tun hatte. Lg

Moin, kurze Rückmeldung. Die Probleme bei der Live Migration wurden durch den AV Scanner (GData) ausgelöst. Nach Deinstallation des Scanners lief auch die Live Migration wieder einwandfrei. Lg

Hi Nils, danke für den Hinweis. Was genau bringt dich zu der Vermutung? Müssten da dann nicht noch andere Probleme auftauchen bei einem Kommunikationsproblem mit dem SAN? Lg

Moin, in einem HP 2k12R2 zwei Nodes mit HP SAN Cluster schlägt die Live Migration "unregelmäßig" fehl. Manchmal klappt sie 1 oder auch mehrere male zwischen den Hosts hin und her, aber irgendwann schlägt sie fehl und die VM bleibt in einem Fehlerhaften zustand offline. Wenn ich dann die betreffende (auf der die VM Liegt) CSV "verschiebe" also den Besitzer des CSV ändere, dann kann ich die VM wieder starten. Ereignis ID 3080 Hyper-V-Worker sagt "Fehler beim Erstellen oder zugreifen auf die .vsv Datei....." + ID 1069 FailoverClustering " Fehler in Clusterressource ....Fehlercode 0x5 Zugriff verweigert" Wenn ich die Dateien beim Livemigrieren beobachte dann kann ich nach einer gescheiterten live Migration die NTFS Rechte dieser beiden Dateien auch nicht mehr einsehen. Nach dem verschieben des CSVs zum anderen Host und dem starten der VM werden diese beiden Dateien dann neu erstellt mit einsehbaren NTFS Rechten. Jemand eine Idee? Hintergrundinfo: einer der Host wurde vor einigen Wochen neu zum Cluster hinzugefügt. ich kann nicht genau sagen ob der Fehler da schon vorhanden war und er mir nicht aufgefallen ist. Lg

Moin, wenn ich den Host aus dem backup einspiele, inklusive zurücksetzen des Computerkontos, muss ich ihn dann vorher aus dem Cluster entfernen oder reicht es den Knoten anzuhalten, runterfahren, Backup (Bare-Metal) einspielen , starten und in die Domäne aufnehmen. Sollte ja eigentlich reichen Wird er dann wieder normal vom Cluster erkannt oder doch lieber vorher entfernen und neu in den Cluster aufnehmen?

Moin, danke für die Antworten. Naja ein Host neu hochzuziehen dauert deutlich länger (Treiber, Netzwerkkonfig etc), als ein Backup einzuspielen. @Nobby warum Bauchschmerzen? @Dunkelmann Host aus Cluster entfernen Host aus Backup wiederherstellen Computerkonto zurücksetzen Host in Domäne aufnehmen Host zum Cluster hinzufügen Sollte doch eigentlich so funktionieren oder habe ich was übersehen?

Moin, ich würde gerne einen "fehlerhaften" Host aus einem Server 2012 R2 Cluster aus dem Windows Serverbackup wiederherstellen. Momentan läuft der Host noch im Cluster. Wie wäre hier die Vorgehensweise? Host erstmal aus Cluster und Domäne entfernen oder reicht es in den Wartungsmodus versetzen und dann Backup wieder einspielen? Problem ist ja wahrscheinlich das ich den Host nach dem recovery eh einmal aus der Domäne raus und wieder reinnehmen muss, weil dann ja dieses Problem mit der "Vertrauensstellung" kommt und man sich zb nicht mit einem Domänen user am Host anmelden kann.

Moin, was genau meinst du mit alles? Momentan läuft es so: 2x10Gb Team für die VMs 2x1Gb Team für den Heartbeat 2x1Gb Team fürs Management 1x10Gb für Livemigration Die 1x10Gb für Livemigration möchte ich jetzt aber fürs Mangement nutzen, weil Veeam standardmässig die Mangementkarte des Hosts für die Backups nutzt und es nett wäre wenn das Backup 10GB zur verfügung hätte Der 10Gb "Engpass" kommt auf Switch Seite Zustande, weil dort nur 8x10Gb vorhanden sind und der Backupserver jetzt auch einen dieser Ports nutzten soll