Weingeist

Na klar... Diese Debatte gibts auf Seite 1. Ein richtig oder falsch gibt es in diesem Fall nicht, es gibt Gründe dafür und dagegen. Entscheiden muss das am Ende jeder für sich selbst. Den von MS gewünschte Zustand bekommt man in 30 Sekunden zurück sollte man wirklich Support brauchen/sich das antun wollen und MS ist der Meinung IPv6 bräuchte es für den support.

Bei Type 0x20 to prefer IPv4 over IPv6 by changing entries in the prefix policy table. Bin ich mir nicht zu 100% sicher, dass es auch immer korrekt gesetzt wird bzw. welche Voraussetzungen gegeben sein müssen. Auch schon Probleme gehabt. Besser gleich selbst umschreiben. ;)

Haha kann man so sehen. *grinz* Ich sehe die Beweggründe aus Sicht des Aufwands und den grundsätzlich möglichen Komplikationen und den daraus entstehenden Problemen. Wodurch auch immer sie Verursacht werden. Und das steht nunmal im kleinen nicht wirklich im Verhältnis zu den Vorteilen von mehreren DC's. Klar weder prüfen ob die Sync noch läuft, noch reaktivierung von DFS-Replikation von Sysvol, noch löschen eines DC's der down ist, noch neuerstellen eines DC ist viel Aufwand. All das ist normalerweise kein Akt. Aber in der Summe übers Jahr gesehen eben deutlich mehr Arbeit für sehr wenig Mehrwert. Aber das ist nur meine persönliche Meinung die nicht jeder teilen muss. Der DHCP war nur so ein Beispiel, ich persönlich lasse den nicht mehr auf DC bei Neuinstallation oder Umgebungen die ich aktualisiere laufen. Aber ist oder war halt oft so üblich. Meist ist ja Ärger nach einem Stromausfall, Host BlueScreen, Festplattenausfall, RAID-Probleme oder was auch immer und dann sind auch die Leases weg. Die physische Maschine dürfte ja die gleiche sein. Also ist kaum nur DC oder nur DHCP betroffen. Geteilte DCHP-Bereiche schaffen wiederum mehr Verwaltungsaufwand und die Umgebung ist immer noch down. Also wozu sich das alles antun? Von beidem eine Maschine, im Fehlerfall Wiederherstellen und fertig. Mit lokalen Sicherungen dauert das ein paar Minuten.

Wozu ein AD-Recovery? Man stellt einfach den ganzen Server wieder her. AD-Stand ist quasi egal. Backupprogramm in AD integriert: das meine ich ja, schauen dass man lokale Konten hat für eine Wiederherstellung. Ein DC = Konflikte von vornherein ausgeschlossen. Ich hatte in meiner Laufzeit deutlich mehr Probleme mit mehreren DC als mit einem. Sei es wegen Sync-Problemen, Wiederherstellung, Versionsstände usw. Bedarf einfach insgesamt mehr Pflege bei verhältnissmässig wenig Gewinn in Kleinumgebungen. Mit Cloud sieht das teilweise anders aus. Korrekt. Soweit ich das verstanden habe, sprechen wir hier von On-Premise. Ich und viele KMU im Produktionssektor mögen die Cloud auch nicht. Aber das ist ein anderes Thema. Und wie bereits gesagt, DC mit einem Footprint von 20-25Gb ist in ein paar Minuten wiederhergestellt und wieder Up. Insbesondere wenn man lokal ein Backup vorhält. Egal ob er Imagebasiert, Replikat oder AD-Konform gesichert/wiederhergestellt wurde, man hat nie ein Risiko von Versions-Konflikten wie mit mehreren DC's. Viele nehmen zum Beispiel DHCP mit auf den ersten DC. Was hilft hier also ein zweiter DC wenn DHCP down ist? Nix, es bringt nur Probleme. Ist der DC noch ein Filer (was ich gerne vermeide) wird es noch lästiger. Aber eben, jeder wie er mag. Ich mag es möglichst einfach. Solange eben keine normalen Anwendungen im AD herumschreiben. Dann sieht es logischerweise anders aus. Bei einem DC ist es fast egal WIE wiederhergestellt/gesichert wird, man muss sich schon von vornherein nicht um die korrekten AD-Stände kümmern. Den Client interessiert das nämlich nicht besonders.

Und auch in Kleinumgebungen ist es sehr viel angenehmer für die Wartung wenn man die Rollen separiert. Lohnt eigentlich immer. Früher mit rein physischen Maschinen sah das etwas anderes aus. Ein paar hundert Euro Lizenzkosten sind viel zu schnell von Stunden aufgefressen wenn was spinnt. Printserver ist so ziemlich der anfälligste Server überhaupt. Ziemlich in jeder Hinsicht. Sicherheit und Ärger. Den würde ich einfach immer separat halten. In Kleinumgebungen wo gerne auch "billig-geräte" vorkommen sowieso, da sind die Treiber ja oft Kernschrott. Gerade mit VM's hat man auch den Vorteil einfach auf Knopfdruck nen Rollback auf einen alten Treiberstand zu machen wenn es Probleme gibt ohne das es Einfluss auf etwas anderes hat. Erster DC: Immer separat ohne weitere Rollen. Sicherheitstechnisch besser und schnell wiederhergestellt. Zweiter DC in Kleinumgebung: Imho ziemlich sinnlos solange man keine Applikation hat, die permanent in AD schreibt. Der Mini-Footrint von 20-25GB ist in ein paar Minuten wiederhergestellt wenn man lokal auf einer separaten Platte eine Kopie/Backup vorhält. Viele Probleme mit AD sind mit einem Server schon von vornherein ausgeschlossen. Replikation, die Chef-Frage, allfälliges Image-Backup usw. Echten Mehrgewinn bringt es selten. Einfach schauen das man ein lokales Konto für den Zugang zum Host hat, welches nicht AD-abhängig ist damit z.Bsp. eine Kopie des Server zurückgespielt werden kann. Und seien wir ehrlich, ist ein physischer Server down, arbeitet man eh nen Moment nicht mehr. Ob dann ein zweiter DC da ist, spielt dann wirklich keine Rolle mehr. Fileserver würde ich auch immer separat halten. Je nach Anzahl und Grösse der Files halte ich sogar deren zwei vor. Bereitgestellt per DFS. Das ist normal der einzige Server der in Kleinumgebungen möglicherweise wirklich eine Ewigkeit braucht bis er wiederhergestellt ist. Insbesondere wenn es über LAN muss. Dann kann man einfach das DFS-Ziel switchen und hat genug Zeit den 1. zu flicken. (Abhängigkeiten PDC und DFS beachten). Also wozu den Server mit anderen Rollen "verunstalten" und Risiko eines Rollbacks auf sich nehmen weil man eine andere Aufgabe etwas falsch installiert/konfiguriert etc. Lizenzserver, WSUS, sonstiger "unwichtiger" Kram kann man gerne konsolidieren. Würde aber schauen, dass der Krempel jeweils auf eigene Platten schreibt. Ein Vollaufen des WSUS auf C bringt z.Bsp. dann nicht gleich alle anderen Rollen bzw. den Server selbst ins Elend. Wenn man sich die Lizenzen gönt, hat mans je nach dem auch hier einfacher wenn Upgrades anstehen. ;) Aber eben, jeder hat so seine Vorgehensweisen und es führen viele Wege nach Rom. Ich separiere mittlerweile immer soviel wie es geht. Egal wie gross die Umgebung ist. Das hat sich bewährt. Und bezüglich GUI habe ich die gleiche Meinung. Tu Dir das nicht an ohne. Auch kannst viele Systeme z.Bsp. für Updates viel einfacher während der Arbeitszeit machen. Bei konsolidierten Rollen ist das viel anspruchsvoller und eben auch die Chance grösser das es schief geht. Ahja, KMU's sind fast immer Inhaber-gesteuert. Die sind selten sehr geduldig. Insbesondere nicht bei der IT. Damit werden ja nicht die Brötchen verdient wie mit einer Maschine und viel dran ist optisch auch nicht. Also sollte man besser zuschauen, dass sie möglichst wenig Ärger macht. Die Kostenrechnung Stunden zu Material/Lizenkosten beherrschen die normal auch. ;)

Wenn man keine spezielle Technolgie nutzt sondern lediglich auf bestimmte bestehende Desktop-VM's direkt per RDP zugreift meines Wissens nicht. Müsste in Enterprise + SA enthalten sein (bis 4 VM's oder so, ähnlich wie bei VDA). Problematisch wird es laut meinem Wissensstand - auch wenn das Gespräch auch wieder ein Moment her ist - erst, wenn spezifische Funktionen von MS für Automatisierung, Loadbalancing, Zugriffsart, Veröffentlichung usw. genutzt werden. Also das was auch bei ServerOS oft genutzt wird. So war zumindest damals die Ansage. Diese Funktionalität wird bei anderen Anbietern wie VmWare meist ebenfalls separat bezahlt, daher möchte wohl MS auch nen Schnippsel davon haben wenn ihr Zeugs genutzt wird.

Naja, nicht ganz. Es gibt ja noch die Hauptuser-Klausel. Nur korreliert das mit dem Konsolidierungskonzept das man mit VDI verfolgt weil es den Hauptuser nur in Verbindung mit "persönlich" zugeteilter Hardware gibt. Eigentlich geht folgendes. Immer aus Arbeiter, nicht Admin-Sicht - User hat Windows PC und greift auf Server OS zum arbeiten zu: mindestens RDS-CAL - User hat Windows PC und greift auf Desktop OS auf Server zu (Typisch VDI): Windows Client der zugreift muss Enterprise + SA haben, RDS CAL nicht notwendig - User hat ThinClient oder sonstiges und greift auf Server OS zu: RDS CAL und manche behaupten auch VDA (wurde mir so nicht bestätigt) - User hat ThinClient oder sonstiges und greift auf Desktop OS zu: VDA - User hat ThinClient oder sonstige und greift auf Desktop OS zu und von da baut er eine TS-Session zu einem Server OS auf: VDA + RDS - User greift irgendwie auf seinen persönliche Hardware zu: Keine zusätzlichen Kosten (Hauptuser-Recht), egal wie der Zugriff erfolgt - Hardware ist eine reproduzierbare, definierte Kette mit mehreren, abwechselden, nicht gleichzeitigen Benutzern (z.Bsp. Workstation im Rack, Extender für Bildschirm etc., kein Verteiler) : Keine RDS CAL notwendig, keine SA notwendig, sobald der Kram flexibel auf Endpunkte verteilt wird, wird eine RDS CAL notwendig (sa bin ich nicht sicher, habe den zustand bis dato nirgends) Für Office als Kauflizenz gilt: Jedes End-Gerät von welchem aus der Zugriff erfolgt, muss lizenziert sein. Es gibt wiederum ein Hauptuser-Recht, das zählt aber wie bei Windows nur bei persönlicher Hardware! Sprich es ist mit VDI fast unmöglich das sinnvoll mit Kauflizenzen zu lizenzieren wenn die User X Endgeräte haben. Und auch das nur mit den VL-Lizenzen. Es sei denn, sie haben ihre persönliche Hardware auf welche sie zugreifen und durchlizenziert ist. Bei Miete kann man das einfach pro User bezahlen und hat eine gewisse Anzahl Gerät zugute kann also auch +- bereitstellen wie man möchte. lizenzdoc möge mich zbsp. korrigieren wenn dem nicht so ist, aber auf diese Zusammenfassung kam ich mal mit einem MS-Mitarbeiter sowie einem Lizenzspezi nach gefühlt stundenlangem Gespräch. Schriftlich wollte er mir leider gar nichts geben. Die User-Cal (ich würde immer UserCAL nehmen statt Device CAL in der heutigen Zeit) die immer notwendig ist für Serverzugriffe jeglicher Art, ist natürlich auch quasi immer notwendig. Irgend ein Server mit dem man direkt oder indirekt zu tun hat ist ja immer da. Lästig wird es, wenn die Zugriffe eben unterschiedlicher Natur sind oder von unterschiedlichen Geräten. Manchmal auf Server OS und manchmal auf Desktop OS. Da heisst es dann doppelt lizenzieren, VDA + RDS oder Enterprise+SA+RDS je nach Gerät. Irgendwann ist dann die persönliche Hardware halt vielleicht doch günstiger als Konsolidieren und selbst wenn diese im Rack steht. MS scheint zumindest gewillt zu sein, mit den Mietlizenzen Ordnung schaffen zu wollen und das ganze für die heutigen Umgebungen zu vereinfachen indem einfach Office und Windows pro User gelöst werden kann. Schade ist nur, dass alles mit Preisaufschlägen einhergeht.

Aber der Benutzer macht nur nen Doppelklick auf dem Desktop und es läuft wieder, Du kriegst weniger Telefonate und vor allem: Es wird so neu verbunden wie es eigentlich sollte, via DSF und nicht direkt via Serverfreigabe. Wie gesagt, Netzlaufwerke sind Diven, die werden quasi nicht einfach so aktualisiert. Die sollte man immer trennen und neu verbinden. Zum Beispiel beim anmelden. Die GPO soll auch trennen und neu verbinden und nicht einfach nur schauen ob da und wenn nicht, neu verbinden (ich wiederhole mich). Oder VPN-verbinden im gleichen Script wie Trennen/verbinden, oder auf nen Trigger mit nem Task wenn Verbindung steht. Deren Möglichkeiten gibt es viele. Ich mag die 0815 Variante, User hat auf Desktop nen Link zum Script der ihm das Laufwerk auf Wunsch neu verbindet. Simpel und Effizient.

Wie gesagt, erstelle ein Script unter C:\Scripts oder so welches das was per GPO ankommt neu macht. Sprich Netzlaufwerk trennen + wieder neu verbinden. Oder auch unter dem Netlogon-Share. Wenn etwas falsches zwischengespeichert ist, bekommst ein Netzlaufwerk selten wieder einfach so geradegebogen. Zumal immer noch die Frage ist, ob es nur neu erstellt wird per GPO wenn nicht bereits vorhanden (auch wenn falsch) oder komplett ersetzt wird. Wird es nicht ersetzt, dann gibt genau der eigene Work-Around nachher probleme wenn sie einen spezifischen Fileserver angeben jedoch nicht immer der gleiche verfügbar ist. --> Daher mache ich das normal per Script (auch wenn per GPO ausgelöst oder Startup), dann bin ich sicher das es getrennt und neu verbunden wird und so mancher Ärger erspart wird.

Einfach mal alle möglichen Varianten durchtesten, was anderes bleibt dir nicht übrig. Dazu mit Wireshark analysieren. 1. Laufwerk eben nicht per GPO verbinden sondern wirklich erst wenn VPN voll da ist und Im Netzwerkadapter das Netzwerk angezeigt wird die Verbindung erstellen. 2. Eine Stufe retour, also Laufwerk nicht trennen, neu starten und schauen ob es nach VPN Aufbau wieder tut 3. Wieder eine Stufe retour, Laufwerk trennen, neu starten, manuell verbinden (versuchen), VPN aufbauen schauen obs tut 4. manuell trennen, manuell neu verbinden entweder direkt per Kommandozeile oder testweise erst im Explorer So kriegst evtl. einen Work-Around hin der möglichst ohne Adminrecht und Neustart tut. Damit erstellst ein Script (sofern möglich und das Problem behebt), damit es der User selbst tun kann. Link auf das batch auf den Desktop. (Also Trennen und neu verbinden) Falscher Namespace: Nun da kommen wir der Sache schon etwas näher ;) Schuss ins blaue: Ihr habt zwei aktive DFS-Ziele aber nur eines ist per VPN erreichbar. Arbeitet er am anderen Standort, bekommt er entweder Zugriff auf beide Ziele oder auf genau ein anderes. Im Cache ist aber der Pfad zum "falschen" hinterlegt. Da verbundene Netzlaufwerke so gut wie nie - oder mir nicht erkennbaren System - aktualisiert werden, funktioniert der Zugriff nicht. Ich denke der Workaround mit einem Script welches das Laufwerk trennt und neu verbindet, sollte funktionieren. Aber von unterschiedlichen Sites und Standorten habe ich ehrlich gesagt keine Ahnung. Da ich nur kleine Umgebungen habe, versuche ich auch mehrere Standorte unter einen AD-Standort zu kriegen und die Leute per Fernzugriff auf das Hauptsystem arbeiten zu lassen. Sprich Jumphost Prinzip und möglichst Keep-it-simple. Ansonsten muss dann ein anderer ran.

So wie es aussieht scheitert er schon ziemlich früh. Ohne den Rest gesehen zu haben würde ich sagen, er findet den Pfad im Cache, will auf diesen zugreifen, kann aber den Domänen-Namen nicht auflösen. Mögliches Problem: - Keine saubere DNS-Auflösung in jenem Moment wo die Verbindung aufgebaut werden soll. - Noch keine aktive Domänenzugehörigkeit (Sichtbar beim Netzadapter) - Anderes Sicherheitstoken das nicht mehr gültig ist sobald er sich mit VPN einklinkt, die Verbindung hat er eventuell mit einem alten versucht aufzubauen, was dann scheitert. -->laufwerke trennen und neu verbinden nachdem ein manueller Zugriff geklappt hat. Das gleiche auch mal nach einem Neustart und erst verbinden wenn VPN aufgebaut ist (das meinte ich mit alles rauskicken) - Netzwerkprobleme --> Zu viel Paketloss --> Sicherheitstoken macht Ärger bzw. der Client verliert das Vertrauen des AD, dabei wird es bei verbundenen Netzlaufwerken gar nicht oder nicht sofort wiederhergstellt. Manueller Zugriff funktioniert dann meistens trotzdem, aber nicht zwingend stabil. (Hier hier es mal funktioniert indem ich die Geschwindigkeit gedrosselt habe, ist aber via VPN wohl eher tricky) - Möglicherweise gibt es auch Ärger wenn das Netzlaufwerk via einem anderen Adapter aufgebaut wird, also einmal WLAN und dann LAN oder VPN-Adapter. Dann könnte es sein, dass irgendwo eine definierte Route gecached ist, die dann fehlschlägt. EDIT: Hier findest den Ablauf einen DFS-Requests: https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-dfsc/1ff7d611-ba19-49fb-95f4-7c5358b86834 Aber eben, hier hilft vermutlich am Ende nur systematischen vorgehen, ausprobieren...

Technisch gesehen ist die erste Windows 10 ein 6.4. Also 4. Version von Vista. Das war sogar lange in den Build-Nummern erkennbar. Bis TP3 oder 4. Das stimmte nicht mit dem gigantischen Marketingen-Brimborium überein also hat man kuzerhand 10.0 für den Release daraus gemacht. Mittlerweile wäre die Zahl nach dem Komma aber deutlich höher. Nun macht man das Gegeteil und änderte während X Jahren die erste Nummer nach dem Komma gar nicht obwohl es immer ein neues Windows und nicht nur ein Update war. Wie Windows heisst und wie es vermarktet wird, dafür ist hauptsächlich das Marketing sowie die Strategie-Abteilung von MS zuständig. Bis 2012R2 war dem Marketing egal was die technische Version war. Jetzt fliesst sogar das mit ein. Was diese entscheiden ist wiederum abhängig davon, wo man am meisten Potential für Einnahmen sieht. Deren Ansichten können sich deshalb ändern. ;)

Das ist eben nicht wirklich korrekt. Windows spricht standardmässig priorisiert IPv6 und IPv4 wenn IPv6 nicht funktioniert. Nimmt man die Prio weg, spricht es priorisiert IPv4, solange es verfügbar ist. Wenn nicht versucht es die Kommunikation mit IPv6. Ist das eingeschränkt (Komponenten deaktiviert etc.) dann versucht es Windows meistens gar nicht erst. Das Chaos verursacht dann 6to4/Teredo. Deine Aussage beweist es ja: Ein Level X kann IPv6 durch MS supprted abschalten, auch wenn es dadurch grundsätzlich auch nicht zu 100% aus ist. Welches Level aktuell dafür benötigt wird, ist mir nicht bekannt. Aber es ist wohl immer noch supported möglich. Meist dürfte MS aber den support ablehnen wenn man keine triftigen Gründe hat. Ich blocke IPv6 meist auch in der Windows-Firwall. In der Filter-Engine sieht man nach korrekter IPv4 Priorisierung/IPv6 Deaktivierung dann sehr gut wo Windows tatsächlich noch versucht hat trotz allem per IPv6 zu kommunzieren. Das ist ab und wann mal ein Loopback, mehr nicht. Und auch diese sind sehr selten. Wird die Priorisierung nicht gemacht, dann massenhaft geblockten Traffic und lausige Performance. Mit dem Gegenteil, IPv4 abzuschalten hatte ich dagegen Massenhaft Ärger, mehr Verwaltungsaufwand und und und. Irgendwann dreht das vielleicht, solange das aber anders rum ist, schalte ich IPv6 ab weil ich keine Lust auf doppelte Arbeit habe.

Sage ich ja auch, plump deaktivieren gibt Ärger. Entweder richtig mit allem Pipapo oder eben bleiben lassen. Entweder IPv6 korrekt durchkonfigurieren und alles doppelspurig fahren oder eben soweit möglich abschalten. Hauptproblematik ist die Priorisierung. Insbesondere des Loopbacks. Ist auch der häufigste Fehler den viele machen. Da werden meist nur die Komponenten und die Protokolle der Adapter deaktiviert. MS testet durchaus auch mit reinen IPv4. Auch wenn mein aktuelles Interna ein paar Jahr her ist, denke ich, dass das noch immer gültig ist. Bei Grossfirmen war es sogar möglich, reines IPv4 als supported absegnen zu lassen. Es muss im Grunde auch total wurscht sein, weil die Kommunikation gemäss dem Schwerpukt bzw. Prefixpolicy des IP-Stacks von Windows erfolgt. Die Programme selbst benutzen den Stack nur. Am Stack vorbei geht meines wissens nach nichts. Standardmässig ist einfach IPv6 priorisiert, wodurch es zu massenhaft Verzögerungen kommt, wenn es nicht richtig deaktiviert wird. (Auch wenn es nicht zu 100% inaktiv ist) Bei Problemen ist es einfach so, das MS eventuell das aktivieren von IPv6 erforderlich macht. Egal ob es Hand und Fuss hat oder nicht. Das erreicht man z.Bsp. mittels Script + Reboot.

Obwohl MurdocX grundsätzlich Recht hat - insbesondere auch wegen dem Mangel an Know-How - gibt es wenig sinnvolle Argumente für IPv6 UND Ipv4 in einem internen Netz. Für den Umsetzungsdienst Teredo schon gar nicht. Da man intern selten einen Mangel an IPv4 Adressen haben dürfte, gibt es eigentlich auch keinen Grund zwei Infrastrukturen zu pflegen. Insbesondere Firewall-Technisch ist das mühsam, da gibt eine doch schon genug zu tun. Windows kann aktuell immer noch beides. Dürfte auch noch lange so bleiben, weil einfach viel zu viele reine IPv4 Geräte unterwegs sind. Insbesondere in der Industrie. IPv4 wird also dringend gebraucht. Aber wozu beides pflegen? Wozu intern überhaupt IPv6 wenn IPv4 insgesamt pflegeleichter und weniger komplex ist? Ich persönlich sehe das nicht ein. Gibt mehr Arbeit, mehr Fehlerpotential und ist mühsamer in der Fehlersuche und mehr tippseln muss ich meistens auch. Zumal es eine gewisse Tendenz zum Wildwuchs mit zusätzlichen IPs auf Adaptern zu geben scheint. Ausser man "soll" und es ist die Zukunft, konnte mir auf alle Fälle noch niemand stichhaltige Gründe nennen warum ich mir tatsächlich den Mehraufwand mit IPv6 antun sollte. Sobald Cloud-Services von MS genutzt werden, könnte das unter Umständen notwendig werden. Sofern eben die Umsetzung z.Bsp. via Router nicht genügt. =) Aber eben, jeder hat da seine eigene Sichtweise drauf. Manchmal ist das alte für manche einfach gut genug und man schlägt sich erst damit rum wenn es eben notwendig wird. Aber: Die Deaktivierung muss auch "durchgängig" sein. Registry-Deaktivierung, Netzadapter-Protokoll Deaktivierung, Loopbackkonfiguration, IPv4 Priorisierung, evtl. aktiv IPv6 in Firewall blocken, evtl. Subdienst IPv6 deaktivieren usw. Ansonsten gibt es sehr schnell Performance-Probleme oder es tut nix mehr.

Als erstes: Es ist für User A meines erachtens nicht möglich zu erkennen ob ein User B die gleichen Daten auf einem anderen DFS-Ziel bearbeitet. Mehrere DFS-Ziele + mehrere Leute die auf gleichen Zielen die gleichen Daten bearbeiten = Immer Ärger. Das sind eigentlich Szenarien die es nicht geben dürfte. =) Mir kommt bis jetzt kein sinnvoller Anwendungszweck für mehrere aktive Ziele - wo auch aktiv darauf gearbeitet wird - in den Sinn der weniger Probleme macht als er löst. Je nach dem muss man sich überlegen: 1. Warum bearbeiten überhaupt mehrere Leute die gleichen Dokumente? Zuständigkeitsprobleme? Irgendwelche Samme-Excel-Files oder ähnliches? Wird einfach von jedem grad bearbeitet was er für gut hält? 2. Gibt es bessere Ansätze für 1. --> Kommunikation, eine Datenbank, Dokumentenmanagementsystem, Aktive Freigabe zur Bearbeitung, Einführung von Versionierung, Zuständigkeit definieren (ein DMS kann auch "manuell" sein bei einer kleinen Firma) etc. 3. Wozu überhaupt mehrere aktive DFS-Ziele auf denen gearbeitet wird? Performancegründe? Kann man das ersetzen mit z.Bsp. Ordnerstrukturen die an Standort A aktiv sind und andere Standort B sofern benötigt. Zugriffe auf das "falsche" Ziel - weil an einem anderen Ort - sind dann halt langsamer. 4. Bei der heutigen Verfügbarkeit von guten Ferzugriffstools kann man auch überlegen ob man überhaupt zwei Standorte mit wichtigen aktiven Infrastrukturen braucht. Eventuell ist es sinnvoller auf einen Desktop am Hauptstandort zu arbeiten. 5. Will man wirklich DC + Files auf der gleichen Maschine haben? Ein DC mit 20-30GB ist Ratz Fatz wiederhergestellt, ein ganzer Fileserver nicht. Der Vorteil von DFS ist ja gerade, dass man z.Bsp. den DC im Fehlerfall schnell wiederherstellen kann und die Files dann über eine weitere Quelle direkt zu Verfügung hat. Ohne DC läuft nix, ohne Fileserver schon. Bei DFS ist auch immer zu bedenken das es immer drei Parteien gibt. Der DC der die Rolle des PDC hat (Der Korrekheit halber er ist nur Emulator) + die jeweiligen Ordnerziele. Fällt der PDC + das aktive DFS-Ziel aus, kann nicht mehr umgeschaltet werden. Ist also der PDC die gleiche Maschine, wie das aktive Ziel, kann auf die Freigabe nicht zugegriffen und auch nicht auf ein vielleicht noch verfügbares Ziel zugegriffen werden. Die Freigabe ist weg und das DFS-Konstrukt erfüllt nicht mehr seinen Zweck. Deshalb sollte der DC mit der PDC-Rolle auch nicht aktive DFS-Ziele haben.

Ich sage ja, schmeiss alles mal raus - auch alles was du in der Registry findest - und starte neu. Sicherstellen das es nicht mehr da ist. Dann verbinde es neu mit der FQDN und schau ob es dann Neustart-Fest ist oder nicht. Oder eben allfällige Logon-Scripts und/oder GPO's anpassen oder deaktivieren. Dann gibts noch den hübschen Bug mit der Netzwerkerkennung. Sprich wenn er das Netz nicht erkennt (Sanduhr dreht und dreht und ....). Da hilft dann Netzadapter aktivieren/ deaktivieren bzw. neustart des Dienstes nla. (Oft hilft es ihn auf Automatisch verzögert einzustellen) Ahja, ob Du was mit den Firewalllogs und Wireshark versucht hast, hast noch nicht beschrieben.

Das war bis vor kurzem auch mit den Veeam-Repos so... Plätzlich kamen Meldungen rein das da alles automatisiert geleert wurde. Im Grunde dürfte es eine Frage der (neuerlichen) Verbreitung von LTO-Loadern sein ob das zum Risiko wird oder nicht. Macht das wieder Schule, dürften auch die kriminellen sich darauf einschiessen.

Tach, sind die Teile nur in der Geräte-Auflistung weg oder aber auch in den Druck-Dialogen der Programme? Bei letzterem fällt mir auch nix ein, hatte ich so noch nicht bzw. nur bei Netzwerkdruckern und nicht inkl. Systemdrucker. Ersteres ist fast schon "üblich", auch wenn es die letzten 2-3 Jahre besser wurde. Ist zwar nicht Windows direkt schuld, aber mässige Treiber verursachen gerne mal ein "Schnupfen" die dann die saubere Auflistung grad ganz oder teilweise verhindern. Ich habe zwar keine Ahnung was an der "richtigen" Auflistung nicht gut sein soll, aber MS ist da ziemlich am herummischeln und doppelspurig fahren. Drucker kann man über das mmc.exe Plugin "Druckverwaltung" exportieren und importieren. Funktioniert prinzipiell sehr gut. Inklusive Treiber etc.

@Nobbyaushb Veeam kann ja auch Software WORM. Allerdings bleibt eben das Problem, das Tapes im Loader dann nicht von der untersten Firmware des Tap-Loaders sondern eben von der Software Veeam vor Überschreibung geschützt ist. Ein physikalisch gelocktes Band wir nicht mehr beschrieben, sprich das wird von der Firmware des Loaders verhindert. Zwecks gutem Ransomware-Schutz wäre es nun eben Vorteilhaft, das mit dem Lock leerer Platz doch beschrieben werden könnte. Vielleicht bin ich da etwas paranoid, aber eben, geleerte Archive gibts ja wohl öfter als man denkt, also wieso auch nicht geleerte Bänder-Archive in Loadern wenn sich Tape wieder vermehrt durchsetzt.

Ich meine bei normalen, wiederverwendbaren Bändern. Die lassen sich ja weder löschen noch ändern wenn der Schreibschutz gesetzt ist. Auch nicht der leere Platz. Sprich es ist nicht WORM auf "Wunsch" möglich. Entweder ist alles möglich oder nichts wenn der Lock gesetzt oder nicht gesetzt ist.

Haha, das ist klar =) Cool wäre wenn der Schreibschutz eines Bandes nur das Löschen/Überschreiben/ändern verhindert, nicht jedoch das beschreiben von leerem Platz.

Naja, die Zahlen gehen ja stark in die Höhe und die Angriffe werden immer ausgefeilter/automatisierter. Ich kenn das halt von früher. Das mit dem Tape-Wechseln ist einfach ka**e wenn das nicht ein Admin macht und der ist im kleinen nunmal selten vor Ort. Bezüglich Worm: Ich stellte mir halt etwas "Halb-Wormiges" vor. Also ein Änderungs und Lösschutz auf Hardwareebene aber ohne Neuschreibschutz auf leerem Platz. Weiss nicht wie das aktuell gehandhabt wird wenn das normale Band gelockt wird. Habe schon länger keine Bänder mehr im Einsatz, aber aus aktuellem Anlass halt wieder in den Vordergrund gerückt. Wäre total easy so Full + Increments vorzuhalten bzw. am liebsten nur jeweils ein aktuelles Delta zum Full. Quasi perfekt für kleine Umgebungen 8er oder 24er loader, 1-2 Tapes pro Wochentag und gut ist. Nach dem Patchday oder wenn viele Daten geändert werden halt nen neues Full auf neue Sätze.

@NorbertFe Bezüglich Tape attackieren: Naja, ich meine jetzt weniger die Tapes die nicht mehr im Wechsler sind, sondern jene die noch drinn sind. Ist ja mühsam das Zeug jeden Tag aus dem Loader zu nehmen. Lässt man sie drinn, können die Tapes ja theoretisch geleert werden. Es werden ja bereits Veeam-Repos automatisiert geleert... Die Linux-Hardened Repos bis dato noch nicht. @mwiederkehr Das meine ich ja, möglichst komplett abschotten. Ist halt wirklich die Frage ob ein Backupserver wirklich per SMB komplett abgeschottet werden kann. Irgendwie müssen ja die Daten geschrieben werden. Keine Ahnung ob das ohne Hin und her Kommunikation möglich ist. Zudem spricht ESXi NFS und NFS ist tendenziell dümmer als SMB. Sonst kann ja theoretisch ein Löschvorgang passieren sobald ein Host kompromitiert wurde.

hach, fixe IPs haben schon ein paar angenehme Side-Effects. Gerade wenn man nicht vor Ort ist. Insbesondere bei Geräten und nach Stromausfällen. Bei Clients hats auch einen Vorzug: Wenn man gerne mit der internen Firewall arbeitet, kann man so auch easy mit expliziten IP-basierten Regeln arbeiten weil Adapter-basiert in Windows nicht möglich ist. Das konnte nur ISA/TMG. Die Pflege der fixen IP's ist in kleinen Netzten schlicht zu easy als darauf zu verzichten. Neue Clients/Geräte lasse ich erst nen Lease ziehen, dann wird umgestellt auf fix und die Reservierung eingetragen. Doppelt gemoppelt. Hat sich bewährt. Dauert nur ne Minute die beim ersten Stromausfall wieder drinn ist. Nur bei Windows selbst bin ich meist zu faul neben der Res auch fix einzutragen. Aber windows kann das meist auch ab wenn kein dhcp da ist. Aber eben, das ist nur für kleine Netze gut. Bei grösseren ist eh alles etwas aufwändiger und teilweise auch nicht mehr relevant. Das Leben ist mit Windows in vielerlei Hinsicht sehr viel einfacher als mit anderen Systemen. Manches halt auch komplizierter. Irgend einen Tod muss man immer sterben. Auch in Windows ist das meiste mit einem Reboot der jeweiligen Dienste zu lösen. Manchmal ist ein Server-Reboot der bei entsprechender Hardware in 1-2min durch ist auch einfach schneller als grossartig zu suchen. Völlig unnötig sich darüber aufzuregen =) Edit: Und sehr sehr oft liegt das Problem eh nicht bei Windows selbst sondern bei grottigen Treibern und Software die den Arbeitsspeicher nicht sauber leerräumt.