Weingeist

VL alleine reicht strenggenommen für W10 eigentlich auch nicht mehr aus. Weil W10 Enterprise ein Upgrade-Produkt und kein Einzelprodukt mehr. Ein W10 Upgrade braucht ein System welches bereits mit einem qualifizierten OS lizenziert wurde. Sprich Du brauchts die Aufbewahrungs-Kette im Grunde auch. Keine Ahnung wie man das machen soll wenn z.Bsp. ein Notebook entsorgt wurde und ein neues ohne OS ausgeliefert wird. Theoretisch dürfte man ja Lizenzenz übertragen. Aber ohne das alte Notebook wäre dann die Nachweiskette unterbrochen. Ehrlich gesagt kein Plan wie das funktioniert und was genau der Plan von MS hinter dieser abstrusen Regelung ist. --> Lizenzdoc

Leider auch die Hardware selbst. Software so oder so nicht. Ergänzung: Also ich meinte damit 4 physische Server, beide Firmen lizenzieren alle 4 Server mit Datacenter = nicht erlaubt

Es ist nichtmal erlaubt die Hardware zu sharen wenn beide voll lizenziert sind. Wie streng das reine Hardware-Sharing im Endeffekt ausgelegt wird, dürfte von verschiedenen Faktoren wie der Unternehmensgrösse abhängen. Um ein SPLA-Partner zu werden sind die Hürden aber doch etwas grösser als einfach die Hardware zusammen zu sharen.

Dann brauchts halt ein Extra-Gerät + USV. Wobei eigentlich kann das ja auch im Rack stehen. Stimmt.

An anderer Stelle habe ich auch schon eine Linux-Kiste als Proxy empfohlen. Wenn man sich damit auskennt wäre das eigentlich eine recht gute Sache. Linux kann ja ein Mount quasi identisch behandeln wie ein lokales Laufwerk. Auf LAN-Adapter 1 das Laufwerk von XP gemounted (separates phyisches Netz) Auf LAN-Adapter 2 welches im produktiven Netz hängt, wird der gleiche Mount wieder freigegeben. So hängt die XP Maschine kommunikationsmässig nicht direkt im Netz aber die File-Zugriffe erfolgen trotzdem auf die XP-Maschine. Ich versuche es meist mit irgend einer Windows-Lösungen auch wenn es zum einrichten mühsamer ist. Aber nur weil ich mich Linux zu wenig auskenne und daher die Fehlersuche mühsam ist wenn mal was nicht mehr tut.

Ich vermute MS wird wieder dahin zurückkommen für alles was nicht reine Office-Maschinen sind. Die Software-Hersteller mit denen ich zu tun habe fluchen was das Zeug hält mit all den Builds die sie unterstützen müssen. Manch einer verlangt sogar schon LTSC sonst gibts keinen Support. Wieder andere verlangen das abdrehen der Windows-Updates, also ganz wie in alten W95 Zeiten, willkommen zurück im Software-Mittelalter *hmpf*. Wenn die 5 Jahre abgelaufen sind, kriegt man für Geld dann nochmals 5 Jahre. Die Updates werden für IOT ja eh gemacht *rofl* Mir persönlich ist 10 Jahre mehr als recht. All die Laborgeräte, Maschinensteuerungen etc. sind mit 5 Jahren einfach viel zu wenig. Aber selbst 10 Jahre ist nur in sehr schnellebigen Produktionsstrassen wo eh nach ca. 6 Jahren alles ausgetauscht wird möglich. Zumal die Industrie mindestens ca. 5-10 Jahre hinterherhinkt. Sprich wenn ein neues OS implementiert wird, ist es mit einem Lifecycle von 5 Jahren beim Ersteinsatz schon EOL. Danach ist eine Maschine ~10-15 Jahre im Einsatz. Aktuell meist Windows Pro anzutreffen. Super gau quasi. Klar nicht primär ein MS Problem, aber halt trotzdem die Realität

Für Krudes gibt es manchmal auch krude und hässliche, dafür simple Lösungen... Skript/Miniprogramm auf den Desktop welcher die gewünschte IP in die Datenbank einträgt. Wenn was nicht klappt, sollen sie das ausführen. Verschafft einem Zeit. --> Für solchen Kram am besten eine zentrale Liste führen, damit man wenigstens weiss, wo man Würge-Arounds eingebaut hat und diese bei Gelegenheit und Lust sogar abarbeiten könnte.

https://techcommunity.microsoft.com/t5/windows-it-pro-blog/the-next-windows-10-long-term-servicing-channel-ltsc-release/ba-p/2147232 Ich glaube MS hat erkannt, dass vermehrt Kunden LTSC einsetzen möchten weil sie die Schnautze voll vom Semi Annual Channel haben. Vermutlich sogar mehr als Ihnen lieb ist. Anders kann ich mir das irgendwie nicht vorstellen. 10 Jahre ist MS aber dann wohl zu lang. Schade eigentlich... Aber mit 5 Jahren kann ich wohl auch sehr gut leben, vermutlich finden das dann auch die Softwareentwickler toll und supporten wieder offiziell. IOT bleibt bei 10 Jahrn

Würde ich aber nur für die wirklich notwendigen machen, Erfahrungsgemäss wird es lästig in den ganzen abgelehnten Updates wieder das gewünschte zu finden... Es werden ja auch so viele abgelehnt die ersetzt wurden. Bin da auch eher bei nichtgenehmigt bzw. habe ich dafür eine Untergruppe ohne Computer wo ich es genehmige. Das kann ich von Zeit zu Zeit prüfen und habe sie immer im Blickfeld oder mal für einen bestimmten Client freigeben und wieder testen. ;)

So schwierig? Wenn Du an einem Client per RDP als Admin angemeldet bist, kann kein anderer Nicht-Admin Dich aus der Sitzung werfen. Also die Arbeitstation ist quasi gesperrt. Wenn er es doch kann, dann ist er Admin und das sollte ja nicht sein oder? Edit: Falls doch, weiss eben die Rechte nicht was die linke tut (wenn mehrere Admins) Ansonsten: Da MS den Lockscreen mit Infos füttern kann, muss es da auch irgendwelche API's geben damit man das selber tun kann. Das wäre so mein Ansatz wenn ich das wikrlich für sinnvoll erachten würde. Ich gebe wenn ich auf eine Maschine muss kurz ein Telefon und gut ist. Dafür gibts ja interne Nummern, anmelden kann sich der Client dann eh nicht. =) EDIT: Ob es dann gelesen wird steht auf einem ganz anderen Blatt, vermutlich eher nicht

Du hast nicht richtig beschrieben was eigentlich Deine Frage/Ziel der Übung ist. Sprich ob es Dir um die Replikation geht oder was Du als Unterbau verwenden sollst. Aktuell scheint es dir um den Unterbau zu gehen. Bezüglich Lizenzen: Nein eigentlich ist das theoretisch fast nicht möglich, dass Du korrekt lizenziert bist wenn unterschiedliche externe Leute auf den Server arbeiten. Du bräuchtes theoretisch für jeden externen MA oder Gerät eine CAL welche du wiederum nur innerhalb bestimmter Zeit neu vergeben darfst. Dass das in so einer Konstellation korrekt gemacht wird, habe ich noch nie gesehen. Daher sind da eigentlich fast alle illegal aber +- geduldet unterwegs. ;) Ich arbeitet gerne mit Storage-Spaces, ich meine auch tatsächlich "Storage Spaces" wenn ich Storage Spaces schreibe. Sonst eben "Storage Spaces Direct". Cluster heisst wiederum nicht zwingend Storage Spaces direct mit shared nothing sondern kann auch einfach ein clustered Storage Spaces mit shared discs sein. Shared Disc braucht kein Datacenter. Storage Spaces kommt sehr auf die Implementation an ob es performant läuft. Das ist standardmässig vor allem auf sehr grosse Umgebungen ausgelegt. Für das kleine Umfeld taugen die Standardwerte nichts, sofern man nicht rein mit All-Flash werkelt. Ein Teil der "Eigenheiten" habe ich oben beschrieben. Deine SSD's werden Dir mit Storage Spaces und sequentiellen Loads so gut wie nichts bringen wenn Du einfach standardmässig konfigurierst. Einfach weil die Loads nie auf den SSDs landen werden. Egal ob dieser Cache 100GB gross ist oder nicht. Ein paar wichtige Stichworte die mir grad einfallen - Journal Flag auf den SSD's damit Write-Cache überhaupt sinnvoll funktioniert, VOR der Erstellung eines Volumes - Nur Parity Random/IO writes werden bei SP gecached, bei Storage Spaces direct alle. (Mirror Volumes kommen NICHT in den genuss des Caches für sequentielle Loads) - Erhöhen des interleave bei Erstellung des Volumes bei sequentillen Loads auf Mirrored Volumes mit Magnetplatten auf SP ohne Cluster auf 4194304 (4MB statt 256KB) damit auch sequentielle Loads performanter laufen - RAM Read Cache funktioniert nur bei Storage Spaces bereitstellung via Cluster - Storage Spaces braucht für Triple Mirror 5 Discs, für dessen Write-Cache 3 discs (ZFS ist mit 2 für ZIL/Write Cache immer happy) - Storage Spaces braucht für korrekten Mirror eigentlich 3 Discs auch wenn zwei funktionieren, für dessen Write-Cache 2 (hängt mit der Art und weise zusammen wie SP funktioniert) - Single Node Cluster/Stager um die besseren Cache-Funktionen für einen einzelnen Server zu nutzen und Standardverhalten von Storage Spaces auszuhebeln (RAM Read Cache ermöglichen, alle writes auch bei Mirrored Volumes cachen etc.) - Loads können theoretisch auch mit Tiering gecached werden. Das funktioniert auch mit sequentiellen Loads. Hier sollte dann der Tier 1 so gross sein, dass alle Writes eines Tages darin landen und über Nacht das ganze auf Tier 2 verschoben werden kann. (unter Tage passiert bei Storage Spaces standardmässig gar nichts). Das Tiering funktioniert das erste mal bis der ganze Tier 1 voll ist performant, nachher erst wenn wieder aufgeräumt wurde Single-Node Cluster - wenn man das möchte wegen dem RAM Read Cache - kann nur mit Powershell erstellt werden indem -FaultDomainAwarenessDefault auf PhysicalDisk gestellt wird. Auch Loadbalancing muss deaktiviert werden. ZFS musst darauf achten, dass Writes auf ein Mirrored SSD Zil gehen und nicht nur in den RAM-Cache. ZFS konfiguriert standardmässig ungepufferten RAM als Write-Cache. Daher wichtig ein Mirror-ZIL konfigurieren. Dafür cached ZFS standardmässig alle writes, egal ob Random oder sequentielle loads. Fazit: Alles in allem wird ZFS mit Magnetplatten vermutlich immer besser rennen wenn man sich nicht intensiv mit Storage Spaces beschäftigt, weil die Standardwerte von SP einfach unbrauchbar sind für kleine Umgebungen wo eher die Spitzenlast/Latenz als die durchschnittliche Auslastung wichtig/relevant ist. Storage Spaces ist dagegen insgesamt flexibler, auch bezüglich Erweiterungen, theoretisch sicherer/besser für rebuilds (slab-Prinzip), erfordert aber etwas mehr Einarbeitung. Die Dokumentation von MS ist mitunter grauenhaft, insbesondere für die Eigenheiten damit es auch mit Magnetplatten rennt (wenn auch deutlich besser geworden als vor knapp 10 Jahren wo man fast alles noch selber raustüfteln musste). Für beide Varianten gilt: Fachpersonal gibt es selten bis nie für typische KMU-Betriebe. Man tut einem allfälligen Nachfolger und der Firma also nicht ubedingt etwas gutes. Ausser man nutzt eine 0814 NAS von QNAP/Synology etc.

Storage Spaces Direct ist für unterschiedliche Netze sicher nicht sinnvoll bzw. vermutlich nicht möglich weil eine Voraussetzung ein Cluster ist. Da is alles im gleichen Netz sowie AD. Zudem: Viel zu komplizierter Unterbau wenn man es nicht sowieso möchte. Lizenzierung für sowas simples sowieso jenseits von gut und Böse (Datacenter-Lizenz). Storage Spaces wiederum kann als Basis der Server Sinn machen solange man SSD's nimmt. Mit einem reinen HDD Unterbau wird man mit Storage Spaces nicht glücklich aufgrund des ineffizienten Read und Write Caches. Guten Read-Cache erhält man nur über den Umweg über ein Cluster, selbst wenn es ein Single-Node-Cluster ist. Write-Cache kriegt man für sequentielle Loads (was es hier wohl wäre) so halbwegs sinnvoll hin. Entweder über die Komplexität mit Tiering oder mit Überlistung (Storage Spaces cached keine sequentiellen Loads über 256KB). Ein Hardware-Raid Controller ist oft die bessere Variante mit HDD's. Das Tiering hat dann auch wieder ein paar Eigenheiten. Hat aber mit der eigentlichen Replikation wenig zu tun sondern nur wie die Daten in den jeweiligen Bereichen zu Verfügung gestellt werden. Im Endeffekt ist die Art der Replikation und eigentlich auch der Server welche die Daten bereitstellen aber eine Frage der Anforderung (wie eigentlich genannt wurde): - Reine Einweg oder beidweg Replikation (falls von Untrusted in Richtung Trusted wie beschrieben, wozu dann nicht gleich direkt auf dem Hauptsystem ablegen? Wenn man sich was einfängt, dann landet es ja eh automatisiert im System) - Braucht es die Daten intern oder dient es nur als Kopie/Backup oder Bequemlichkeit (evtl. besser komplett separat halten) - Welche Datenmenge soll repliziert werden (Robocopy ist zbsp. Ressourcenintensiv, wenn aber genügend Bums da ist im LAN sowie Plattenmässig auf beiden Seiten gut machbar) - Wie schnell nach einer Änderung soll repliziert werden (reicht z.Bsp. in der Nacht oder muss es "sofort" sein? Oder auf Abruf oder ....) - etc Ohne solche Eckdaten (Anforderungen) zu definieren kann man unmöglich einen Tipp geben wie es sinnvoll/weniger sinnvoll gemacht werden könnte. Und das kannst nur Du. Also das was Nils bereits gesagt hat. Es könnte z.Bsp. ja auch sinnvoller sein, die Leute mit VM's/RDP arbeiten zu lassen auf die man sich mit einem Fernzugriffstool wie für Home-Office (alle Daten + deren Bearbeitung im internen Netz) Unter Umständen ist aber nichtmal der technische Aspekt der Stolperstein. Windows-Server benötigt für den Zugriff CAL's. Mit wechselnden Kunden-Systemen ist das etwas schwierig bzw. höchstens geduldet umsetzbar. Weil diese können ja nicht wirklich sauber lizenziert werden, also eine ungefähre Anzahl Zusatz-Cals vorhalten und Prinzip "Hoffnung" bei nem Audit. Geduldet weil in der Praxis für diesen Anwendungszweck nicht wirklich sinnvoll umsetzbar. Mit Windows WebServer ging das noch, den bekommt man aber nicht mehr als 0815-Kunde für On-Premise sondern muss über Umwege gemietet werden und steht dann eher im Internet. (Keine Ahnung ob auch sonst möglich).

Naja, solange Du nicht rausrückst was das Ziel der Übung ist, ist es auch schwierig etwas zu empfehlen Für mich klingt der Beschrieb zum Beispiel so, als arbeiten die anderen "Admins" unnötig mit Admin-Rechten weil sie gar keine Admin sind. Weil grundsätzlich können nur andere lokale Admins andere Admins aus der Session kicken. Normale User können das nicht. Sprich ist nur der effektive Admin mit Admin-Rechten unterwegs, sollte sich das Problem eigentlich gar nicht stellen. Ansonsten gibt es ein Zuständigkeitsproblem. Gleiche Konten für Admins/Nicht Admins. Mehrere unnötige Admins wenn diese die Wartung gar nicht machen etc.

Möglicherweise könntest Du den Umweg über NFS statt SMB machen. Guter kleiner NFS-Server bietet z.Bsp. Hanewin wenn der bordeigene nicht deinen Wünschen entspricht. Per Firewall könntest dann auch jegliche sonstige Kommunikation unterbinden.

Eigentlich ist das ganz easy: Kurzfristig viel Last mit Random-Iops (also kleine Datenblöcke) geschrieben auf ein verhältnissmässig langsames Storage-System ist die Domäne der Write-Caches. Also write-back wenn es gegen Stromausfall gesichert sein soll. Also insbesondere bei Spindeln. Die Iops werden quasi gebündelt und als Pseudo-sequentiell zusammengefasst und weggeschrieben (Gaaaaanz grob gesagt). Sobald die Blöcke im Cache des Controllers landen, geht der Commit für den erfolgreichen Write an das OS und es kann neue Daten schicken. Bei SSD's bringt es das nicht weil der commit von der Platte sowieso kommt bevor der Write tatsächlich gemacht wurde und vernünftige SSD's darin insgesamt zügiger sind als das hin und her zwischen Controller/Platte. Hier muss für einen Sicherheitsgewinn im Raid-Betrieb die SSD selbst gegen Stromausfälle gesichert sein, sonst würde auch der bestens gepufferte Write-Cache des Controllers nix helfen. Ist die Platte selbst abgesichert (Kondensatoren), bringt auch der Controller nix mehr und steht nur im Weg (grob gesagt). Der Cache bringt daher nur etwas, wenn der Zeitgewinn durch die zusammengefassten writes eine ausreichende Entlastung bringt. Bei Magnetplatten und Random-IO ist das normalerweise der Fall. Bei SSD's nicht. Deshalb ist er auch standardmässig deaktiviert auf SSD-Raid-Volumes (z.Bsp. LSI-Controller). Write Back ohne gepufferten Cache = möglicher bis sicherer Datenverlust bei Stromausfall. Ausser den Platten war zufälligerweise gerade langweilig. (Egal ob durch Netzteil, System-Absturz oder den Stromanbieter verursacht). Sequentielle Workloads wie grosse Dateien kopieren: Write-Through ist immer schneller sobald der Cache voll ist. Weil der Write-Cache bringt nur zusätzlicher Overhead sobald er voll ist. Das ist bei sequentiellen Loads ziemlich schnell der Fall. Selbst grosse SAN's haben daher sehr selten grosse Write-Caches. Wenn wirklich viel Write-Performance gefragt ist und verhältnissmässig wenig Read, läuft es dann auf Tiered Storage raus oder das Subsystem selbst muss halt für Read und Write entsprechend Performant sein. Manche Storage-Systeme schreiben auch erst in RAID 10 und wandeln dann zbsp. in RAID 6 um wens ihnen langeweiliger ist. --> Windows Storage Spaces puffert z.Bsp. nur die Random-IO's (Std bis 256KB), sequentielle Loads gehen direkt auf die Platten. Egal ob man einen riesigen Write-Cache von X-GB zu Verfügung hätte.

Ich hätte als Kunde gewisse Fragezeichen, wenn eine Fremdfirma ohne Wissen an der Umgebung arbeitet, ohne dass ich informiert bin... Nur mal so zum nachdenken ;)

Wenn es mit Neustart des Dienstes für mindestens einen Tag gelöst ist, würde ich den Neustart in eine Windows Aufgabe/Tasks packen und jede Nacht ausführen lassen. Mir war das bei einer Applikation irgendwan zu b***d zum nachhaken zumal dann immer die Ausrede kam, dass das Problem die Virtualisierung sei. Problem trat sporadisch ca. 1x pro Woche auf. Jetzt starte ich jede Nacht den Dienst durch und das Problem ist gelöst. Den Task kann man auch als User remote ausführen wenn er die Ausführungs-Berechtigung hat. Sprich 0815 User darf die Aufgabe ausführen und der restart kann z.Bsp. mit anderen Credentials erfolgen sofern erforderlich. --> Kann man sich die Admin-Rechte oder ähnliches ersparen sofern die nötig wären. Hier wurde das mal besprochen:

Wie stabil ist den überhaupt die Unternehmensstruktur? Sprich ist geplant die verschiedenen Firmen - separat zu halten - einzeln wieder zu verkaufen, aufzulösen Ohne jetzt die Tatsachen effektiv zu kennen tippe ich darauf, dass die Anzahl Personen die tatsächlich in allen/mehreren Bereichen arbeiten müssen, ziemlich überschaubar sein dürfte. Ich persönlich finde es nicht wirklich sinnvoll bestehende Strukturen ohne grossartige Not gröber anzupassen und die Gesamt-Komplexität für eine handvoll Leute deutlich zu erhöhen. Es ist ja schon im kleinen Umfeld mühsam wenn sich Pfade zu Dokumenten etc. ändern, im grösseren Umfeld ist es eine gute Möglichkeite um es sich mit jenen Leuten zu verscherzen, die nicht einfach nur die Zeit absitzt. Nur meine Meinung dazu. ;) Klar wenn wirklich konsolidiert werden muss, sieht das wieder anders aus, aber solange es nur darum geht das einzelne Leute ihren SSO-Arbeitsplatz haben... naja... Getoppt wird das nur noch, wenn man auf die Idee kommt auch die Leute Remote arbeiten zu lassen ohne die Bandbreite an den Standorten zu haben. Passiert sogar grossen Unternehmen. Die guten Leute laufen and diesen Standorten dann davon. Neue Technik sollte immer mindestens so gut/schnell sein wie die alte. =) Zumindest würde ich es eingehend prüfen ob die jeweiligen Personen nicht besser Arbeitsplätze - z.Bsp. eine VM - in jeder Filiale haben. Die Passwörter/Benutzernamen kann man ja dennoch identisch halten.

Gibts schon, aber eben nicht mehr für den "normalen" Endkunden sondern wohl nur noch für Hostinganbieter. Und ja da hast Du recht, teuer ist rleativ. Aber im Vergleich zu nem Web-SQL ists halt SEHR teuer. ;)

Dafür gabs früher die Web-Edition. Gibts wohl gar nicht mehr (nicht mitbekommen, da nie gebraucht). Die ist aber wohl nur noch über spezielle Kanäle verfügbar und nicht mehr "einfach" so. Ich schätze mal, es dürfte fast mehr Sinn machen den SQL-Server für die Webdienste über einen Hosting-Anbieter zu ordern. Intern ist die Core Version eigentlich viel zu teuer wenn man nicht gerade riesig ist.

Ist das in einer Kleinumgebung nicht wesentlich billiger einfach den oder die Server komplett zu lizenzieren statt die Cores? --> Soweit ich das mal verstanden habe, ist das lizenzrechtlich auch in Ordnung selbst wenn der SQL-Server dann virtuell läuft. Muss einfach auf diesem Host verbleiben. Bitte aber nochmals abklären.

Willkürliche Netzwerkprobleme haben sehr oft die Leitungsqualität als Verursacher. Auch heute gibts noch viele Installationen die nicht sauber Gigabit tauglich sind. Einfach testweise die betroffenen Clients auf 100Mbits runtersetzen wenn der Switch managebar ist. Ansonsten zum Test einen kleinen 100er Switch in die Leitung hängen. Endet in der Regel in massenhaft Packetloss und die unmöglichsten Fehlerbilder. Auch im Kreis verbundenen Switches machen ähnliche Probleme. Oder manchmal doppelte Kabel. Zu viel wechselnde IP-Adressen auf dem gleichen Port gibt auch Ärger wenn der Switch das als feindlich einstuft. Ist das Neuverbinden jeweils beim Neustart nötig damit er die Domäne findet und das Ührchen nicht im Kreis dreht, dann liegts an Windows. Da muss ein Dienst verzögert werden oder automtatisiert Netzwerkadapter getrennt und neu verbunden werden (in Einzelfällen notwendig).

Ich bin ich jetzt nicht sicher ob ich das richtig verstanden habe, aber hast Du die Probleme nur mit den Netzlaufwerken? Du sprichst von "X:\", das habe ich erst etwas überlesen. Oder kommst Du nun auch mit "\\dom.loc\DFS-Root\Folder" auf diesen Maschinen nicht drauf. Hab da ein Knopf. =) Gleicher PC, anderer User (z.Bsp. neues Profil schon getestet?) Bei Netzlaufwerken: Einfach mal alles rauschmeissen. Also Registry manuell bearbeiten damit restlos alles weg ist wenn einfaches trennen nicht reicht. User-Basis + Computerbasis. Dann neu starten. Dann neu verbinden. Und wie daabm bemerkt hat, unbedingt mit vollständiger fqdn verbinden. Wenn etwas mit dem Anmelde-Token nicht stimmt, gibts manchmal auch Ärger. Sprich die Authentifizierung für die Domäne fehlt/verloren geht. Ursachen gibts da diverse. DFS reagiert hier auch ziemlich heikel. AD Sync wäre auch eine theoretische Möglichkeit, also wenn der DFS-Stamm nicht korrekt repliziert wurde. Das müsste aber eigentlich bei allen zu Problemen führen. Ausser es gehen nicht alle über die gleichen AD-Server. Aber eben ich würde auch mal Wireshark oder so anschmeissen und analysieren was da abgeht. Eventuell auch das Firewall-Journaling aktivieren. Deutsch: auditpol.exe /set /category:"Objektzugriff" /subcategory:"Filterplattform: verworfene Pakete" /success:enable /failure:enable International: auditpol.exe /set /category:"{6997984A-797A-11D9-BED3-505054503030}" /subcategory:"{0CCE9225-69AE-11D9-BED3-505054503030}" /success:enable /failure:enable Ansonsten: Hast mal versucht alles an IPv6 Helper Geschmäus rauszukicken um IPv4 zu erzwingen? Macht die Fehlersuche oft einfacher, auch per Wireshark. (Protokoll auf Netzadapter entfernen, Helper Services deaktivieren, IPv6 in Firewall Out explizit blocken, Priorität auf IPv4 einstellen, Komponenten deaktivieren evtl. auch SubService blockieren.)

Remotezugriff auf Server OS ist mit RDS Cals OK. Ob nun VDI via VDA oder Enterprise auf dem zugreifenden Client oder eben Server OS mit RDS-Cals besser für Dich ist, musst Du selber entscheiden.

Muss es denn ohne Downtime sein? Falls nicht, kann man sich ein grosses rumkonfigurieren auch einfach sparen. Alle Clients runterfahren, DHCP-Dienst auf alten DC's deaktivieren. Neuen DHCP aktivieren. Upgrade der Umgebung starten. Wenn die Clients hochfahren, ziehen sie sich automatisch die IP vom neuen. Bei gröberen Änderungen mache ich das immer mit Downtime. Bei Produktionsumgebungen mit Integration halt am Abend/Week-End. Ist einfach schmerzfreier und weniger nervig wenn etwas nicht haut. Nach den Fragen die Du stellst, machst Du das nicht alle Tage und somit ist das bestimmt schmerzfreier und mit weniger Ärger mit Deinen Kollegen verbunden ;) Ist es eine grössere Umgebung und Downtime nicht möglich (erwünscht zählt nicht): Besser einen Dienstleister hinzuziehen =) Dann ebenfalls zu beachten: Waren die DC's auch Fileserver bzw. lief der Zugriff über Server oder über DFS? Falls direkt über Server-Freigabe: Migration so machen, dass die DC's wieder identisch heissen. Also sowieso mit Downtime. Sonst hast nachher garantiert Feuer im Dach. Oder noch besser wenn es so war: Neue Fileserver unabhängig von den DC's erstellen mit dem Namen der alten DC's.=) Stichwort Verknüpfungen in Word, Excel, Dateien usw. Bei der Gelegenheit und wenn Lizenzen vorhanden, eventuell DHCP und DC trennen. Und auch grad den/die Fileserver. Macht das Leben auf lange Sicht einfacher und insbesondere Dienstleister die mit eher grösseren Umgebungen zu tun haben finden sich mit Standard-Bedingungen besser und vor allem schneller zurecht --> spart auf lange Sicht Kohle für den Betrieb. Bei DFS musst eh 3 Parteien haben damit es tatsächlich ausfallsicher ist. Sonst bringts nix (1x DC mit Betriebsmaster (PDC), 2x Fileserver mit DFS). Oder wenn die DC's auch Fileserver sind, muss auf dem PDC - bzw. der mit dem Betriebsmaster-Rolle - die DFS-Ziele deaktiviert sein, sonst kannst bei einem Ausfall des PDC die DFS-Ziele gar nicht umschalten, das kann nur PDC. Also alle die auf den Shares des PDC arbeiten, gucken in die Röhre. Wird im kleinen eigentlich fast immer falsch konfiguriert. (Ich persönlich lasse eh immer nur ein Ziel aktiv, schliesst Replikationsprobleme bei der täglichen Arbeit aus, das zweite Ziel halte ich nur für den Totalausfall vor, weils oft einfach zu lang dauert den Filer wiederherzustellen, Rest normal schnell gemacht) Ob es heute noch einen zweiten DC in kleinen Umgebungen braucht, kann man sich übrigens auch überlegen. Die paar GB sind in ein paar Minuten wiederhergstellt und mit nur einem DC hast nie Ärger mit Versionsständen, Replikation etc. Auch beim Recovery, völlig egal wie Du ihn sicherst. Ausser alles andere ist auch komplett und sauber redundant ausgelegt oder es werden laufend AD-Daten geschrieben (zbsp. Exchange). Nur den Fileserver halte ich doppelt vor und schalte wenn nötig um. Lieber das Augenmerk auf High-Speed Recovery USV etc.