Weingeist

Hallo Leute, Jemand eine Ahnung was mit dem Ende des Supports von Windows XP mit den WSUS-Updates geschieht? Wird das ebenfalls abgestellt? Muss man also selber vorsorgen um alle Updates zu haben? Dankeschön

Kleiner Anhang: RunAsSystem geht auch mit nem MS-Tool, dann hat man sicher keine Dubiose Quelle. http://technet.microsoft.com/en-us/sysinternals/bb897553.aspx

@Norbert: Hatte damit bis jetzt nur manuell 'rumgespielt'. Manipulation normal mit Regedit, teilweise mit Owner-Ship übernahme und dann Rechte-Entzug. Man braucht halt die SID des Users wenn man es nicht auf den Current anwendet. Mit der Massenmanpulation von Registry-ACL's habe ich mich aber auch noch nicht wirklich auseinander gesetzt. Schneller gehts mit einschlägigen Tools wie RegOwnIt. Wenn alles nix hilft weil Rechte fehlen, braucht man Systemrechte. Diese bekommt man entweder indem man ein Script im Aufgabenplaner als System ausführt oder indem man sich ein Tool besorgt, das RunAsSystem und nicht nur runasadmin erlaubt. Mit Systemrechten bekommt man eigentlich alles irgendwie geändert. ;) So kriegt man auch in 8.1 den Windows-Store und AppX komplett deaktiviert und wird alle unerwünschten Apps los und muss sich um etwas weniger kümmern. Heute geht das noch, in ein paar Jahren vermutlich nimmer. Eigentlich genau dann, wenn viele Programmierer Apps anstatt Windows-Programm schreiben und man keine Wahl mehr hat. ;) Aber eben, man muss da schon wirklich wissen was man tut und in Testumgebungen ausprobieren und sauber dokumentieren. Sonst beisst sich ein anderer dann die Zähne aus, dies rückgängig zu machen. Rein theoretisch dürfte (angeblich) die Registry-Manipulation auch mit Powershell gehen, wenn auch ziemlich kompliziert wie ich finde. Anbei ne kleine Lektüre: http://technet.microsoft.com/en-us/magazine/2008.02.powershell.aspx EDIT: Zu guter letzt sollte das auch noch irgendwie sicher sein. Ich persönlich würde versuchen möglichst alles in ein Script zu packen, auf welches nur Admins zugriff haben. Dieses Script dann mit System-Rechten z.B. mit dem Taskplaner ausführen lassen. Dazu mit Trigger die man für sinnvoll findet.

Wow, das ist mal wieder ein grandioser technischer Fortschritt. Ein weiterer Punkt auf der grossen Liste der Verbesserungen von MS für die Kundschaft. Warum wird überhaupt noch OEM angeboten. Mal sehen wie lange es noch Office Open zum kaufen gibt. Der Einstiegsbutton ist ja bereits Klitzeklein. Zu deinem Problem: Möglicherweise kann Du die Registrywerte mit Sicherheitsbeschränkungen versehen, dann sollten Sie eigentlich nicht mehr geändert werden können.

Du machst doch sowieso ein Backup vor einem solchen Schritt oder? Viel mehr wird dir auch nicht übrigbleiben. Inplace ist immer mit nem Restrisiko verbunden gegenüber einer Neuinstallation. Ich mache generell neu und nicht wenige tun das auch. Gibt aber auch solche die gerne Inplaces fahren. Jeder wie er mag.

Jop, Danke. Genehmigungen scheinen wirklich per Powershell zu gehen. Habe mittlerweile herausgefunden, dass es in der DB bereit eine Sicht gibt welche einem die ganzen Daten ausliest. So hat man nen Anhaltspunkt mit welchen Tabellen man arbeiten muss. Selber eine Liste pflegen habe ich nicht so Lust. Schafft man eh fast nicht mit allen Ablehnungen usw. Denke da eher an sowas wie von meinem WSUS alles auslesen und dann automatisch abarbeiten. Muss dafür natürlich alle definierten Spezial-Gruppen der Kunden auch bei mir vorhalten (Spezielle Maschinensteuerung welche nicht alle Updates erhalten dürfen z.B.). Am Ende sollt es dann quasi so ablaufen: Schau ob das Update in der Liste/Tabelle den gleichen Status hat wie in der DB, falls nein, ändere es. Bissel was gefunden habe ich dazu schon, zumindest zum setzen aufgrund einer CSV-Datei. Mal sehen was da sonst noch auftreiben kann. Was ich mich noch gefragt habe: Die SQL-DB scheint so aufgebaut zu sein, dass man mehrer Übergeordnete Gruppen wie die Gruppe "Alle Computer" haben kann, gibt es dafür eine offizielle Prozedur, kann man die direkt in der DB eintragen oder überwirft sich da die GUI? Bis jetzt konnte ich via GUI nur Untergruppen von "Alle Computer" erstellen. Hätte ich mir schon öfter gewünscht. Gerade für Spezial-Clients wie Industriesteuerungen wo ich gerne einen komplett separaten Stamm hätte, damit für gewöhnlich das "Alle Computer" trotzdem ausgewählt werden kann und nicht aus versehen nicht plötzlich doch was falsches genehmigt wird. Wäre sinnvoller als diese Clients komplett von WSUS und Windows-Updates abzuschotten, damit keiner dumme Sachen machen kann. Ist der interne WSUS zuständig und die Gruppe komplett separat, könnte man das gut steuern und auch ab und wann wieder gezielt Updates einspielen oder ablehnen.

Danke für die Antwort... Jo das ist schon so. Aber alle Kundennetze mit meinem zu verbinden finde ich nach reiflicher Überlegung aber eigentlich auch nicht so prickelnd. Bei einer solchen Verbindung werden aber im Haupt-WSUS immer alle Computer-Konten abgelegt oder? Und die Updates werden doch dann auch von diesem Master-WSUS geholt und nicht von Microsoft. Oder habe ich das falsch verstanden? Ob das lizenztechnisch geht weiss ich auch nicht so wirklich. Aber ich denke ich werde versuchen automatisch ein Script zusammenzustellen aufgrund der Einträge für die jeweiligen Updates in der SQL-Datenbank. Dürfte sicherer und einfacher zu realisieren sein. Muss ich nur herausfinden in welchen Tabellen die ganzen Angaben gespeichert sind. Hat evtl. schon jemand sowas gemacht und hat ne entsprechend SQL-Abfrage am Start?

Frag den Hersteller was für Bibliotheken er von Excel benötigt. Mit etwas Glück sind diese auch in der Runtime enthalten, dann kannst Dir das unter Umständen sparen. Ansonsten: Wenn Dir das alles zuviel ist, dann stelle eine Arbeitsstation hin wo jeder der in Frage kommt, seine Files erstellen kann. Und nur genau von dieser.

Hallo Leute, Gibt es eine Möglichkeit einen WSUS-Server quasi als Master für beliebige WSUS-Server in verschiedenen Domänen zu definieren? Er soll sich dabei nur die Genehmigungen von diesem Master-WSUS holen, nicht jedoch die Daten. Diese sollen nach wie vor via MS kommen. Geht das? Habe leider nix im Netz gefunden. Die entsprechenden Computergruppen müsste der Master-Server auch alle haben. Eine andere Idee wäre ein Script mit jeweils allen genehmigten/abgelehnten Updates mit Hilfe der SQL-Datenbank zu erstellen bzw. erstellen zu lassen und dann jeweils bei den Kunden durchlaufen zu lassen. Entweder direkt als SQL-Script oder über den Powershell-Umweg. Ziel der Übung wäre es, bei Kundensystemen nicht immer alles genehmigen zu müssen. Ansonsten soll aber nix übertragen werden, keine Dateien, keine Computerkonten etc. Jemand ne Idee oder schon gemacht? Vielen Dank

Ahja, was auf 2012 nicht laufen wird, ist soweit ich mich erinner deren Fernwartungstool. Musst Ihnen Teamviewer oder so schmackhaft machen. ;)

Orgamax verwendet eine eigene Datenbank. Ist alles sehr simpel gestrickt. Gehe mal stark davon aus, dass Du dem lahmen Ding etwas auf die Sprünge helfen willst. Aus eigener Erfahrung kann ich Dir sagen, dass der Server nur die Spitze des Eisbergs bedeutet. Der Client sollte ebenso ziemlich performant sein. Vorgehen: - Vollständiges Backup ziehen, sowohl mit dem Programm als auch per FileCopy (Es werden beim Backup NICHT zwingend sämtliche notwendige Daten gesichert. --> Manche speziell angepasste System-Formulare, die üblicherweise nicht verändert werden) - Datenbank in neuen Server recovern, Mandanten wieder aktivieren (sofern mehrere vorhanden sind, es werden standardmässig nicht zwingend alle mit korrektem Namen eingefügt) - Dateistamm mit Formularen etc. am besten mit CopyPaste komplett ersetzen, dann bist sicher, dass alles identisch ist, hab da leider auch schon anderes erlebt. --> Backupkonzept gleich mit anpassen. - Cients anpassen Bewährt hat sich ausserdem die Daten auf einer Windows-Freigabe bereitzustellen. Ist sogar DFS-tauglich. Hierbei aber bitte nicht wie empfohlen einfach auf alles erlaubt setzen, sonst kann jeder einfach das Rechnungsarchiv ziehen. Musst aber leider ziemlich viel offenbahren, sonst funktioniert es nicht zuverlässig. Performance: Die Software wurde in den letzten Builds immer langsamer. Vor allem die neue Übersicht braucht teilweise ewig zum laden. --> Tippe auf .Net Bibliotheken die zu lange brauchen oder in eine ältere Programmier-Runtime geladen werden. Auch wenn es mittlerweile leicht besser wurde. Problematisch ist vor allem, dass immer jede Menge Daten übertragen werden und nicht nur jene, die tatsächlich für die Anzeige gebraucht werden. Der Tipp das ganze für die Anzeige auf ein paar hundert Datensätze zu begrenzen bringt quasi gar nix. Auch wird das meiste vom Client berechnet und nicht vom Server. Willst Du also wirklich einen Performance-Schub, dann sollte nicht nur der Server sondern auch der Client über einen sehr schnelle CPU verfügen (nicht Kerne, sondern GHZ). Am schnellsten lief das Ding bis jetzt in einer virtualisierten Testumgebung wo der Client sowie der Server auf SSD's auf der selben Maschine lagen (E5 CPU, 3.2 GHZ). Der Netzwerktraffice geschieht dann Hostintern. Geht ab wie Schmitts Katz. Werden halt wieder Dinge wie gute Netzwerk-taugliche USB-Hubs notwendig für die Einbindung der Dokumentenscanner. -->Lizenzierung beachten Bezüglich Server 2012: Orgamax läuft astrei darauf, beachte in einer SBS-Umgebung, dass Du auch 2012 CAL's benötigst.

Es ist einfach viel entspannter. Keine Ahnung wie man es sich antun kann, jeden Client einzeln zu beglücken. Vor allem in Hinblick auf Updates die nicht erwünscht sind. Silverlight, Windows Desktop Search, Search 4.0 und ne Menge anderer Dinge die mehr oder weniger sinnvoll sind aber nicht zwingend gewünscht ist, dass diese generell ausgerollt werden. Nebst dem, dass man dann nie eine Ahnung hat, was genau auf den Clients installiert ist, wie sein Patchlevel ist usw. In WSUS hat man immer direkt den Überblick über alle Clients und Server. Zudem kann pro Computer-Gruppe definiert werden welche Updates sie erhalten sollen. Fragt sich halt, ob du mit 2 VM's tatsächlich bereits glücklich bist. Ich würde eher sagen nein. Folgende Dienste habe ich mittlerweile gerne getrennt: - WSUS - Printer - Kann eine Menge Ärger ersparen wenn mal nen Treiber spinnt und die VM einfach zurück gesetzt werden kann. Habe ich mir auch mit dem SBS angewöhnt da möglichst eine separate Instanz zu haben. - DC - Exchange - Datenbank Betriebssoftware Geht eigentlich mehr darum, dass beim SBS das als ganzes so verkauft wurde und man auch Support erhielt wenn was schief ging. Gewisse Dienste dürfen oder sollten heute nicht zusammen installiert werden. SBS war ein Konstrukt das super funktioniert hat weil sich eben MS die Mühe gemacht hat, alles so zu (ver)konfigurieren, dass es sich nicht oder möglichst wenig gegenseitig beisst. Das hat meiner Meinung nach sehr gut funktioniert. Zum Beispiel Veaam. Das sichert in einen Backup-Server und daraus kann man die Backup-VM grad anstarten wenn man möchte. Mir gefällt die Variante am besten, dass eine virtuelle Platte auf einem iSCSI, NFS oder ... in den Host eingebunden wird auf welchem dann per Hostsicherung oder mit einer zusätzlichen virtuellen Platte direkt aus dem Gast konventionell gesichert wird. - Mit Windows-Boardmitteln möglich - Die Storage Einheit kann bzw. sollte in einem anderen Brandabschnitt stehen - Recovery kann man z.B. nen Restore des Basis-Images machen, z.B. eine Kopie der Backupplatte einbinden und anschliessend den gewünschten Stand zurückspielen - Files halte ich jeweils gleich auf einer anderen Maschine vor was regelmässig Repliziert/Gebackupupt wird (DFS/Robocopy), im Desasterfall kann sobald der DC oben ist, einfach im DFS der Mirror-Pfad eingegeben werden und man hat mal alle Files wieder. --> Sind ja meist viele Daten und nicht so schnell restored Das ist verhältnismässig günstig, gut und die Komplexität ist überschaubar SQL-Server, Exchange, DC, Printserver. Gern geschehen

Hallo Zusammen, Kann mir jemand verraten was dieser Dienst und seine Tasks im Taskplaner genau machen? Nach einiger Recherche komme ich zum Schluss, dass diese Ding für sehr viele unnötige Warnungen verantwortlich sein muss. Es geht vor allem um folgende Events: Warnung 122: Der Zugriff auf Treiber auf Windows Updates wurde durch eine Richtlinie blockiert Warnung 200: Es konnte keine Verbindung mit dem Windows Update Dienst hergestellt werden Warnung 202: Vom Netzwerklisten-Manager wird fehlende Internetkonnektivität gemeldet Was die Warnungen bedeuten ist mir soweit klar. Ist auch gewollt so. Im Detail handelt es sich um die Aufgabe: "Metadata Refresh", sie lässt sich aber ned mal deaktivieren. Fragen: 1. Was tut diese Aufgabe überhaupt? Wozu ist es sinnvoll? 2. Kann man dem Ding irgendwie beibringen den Schnabel zu halten? 3. Fals man es nicht zum schweigen bringt, ist es ein Risiko die Aufgabe einfach zu deaktivieren? Vielen Dank

Da hast Du recht, hatte COPY:DATSOU mit /E und /Purge für MIR im Kopf... Nix für ungut und Danke für die Berichtigung.

@Daniel: MIR überschreibt aber auch alle Benutzerberechtigungen oder? Müsste man nicht die Flags selber zusammenbauen und Security ausklammer oder spielt das keine Rolle?

Ich betreue ja auch ein paar solcher Umgebungen und habe mittlerweile ein paar auf 2012 geswitcht. Meiner Meinung nach gibt es eigentlich nix bequemeres als nen SBS zu administrieren wenn man sich an ein paar Regeln hält sowie ein gscheites, mehrstufiges Backup/Recovery-Konzept hat. Hauptaufgabe ist unter WSUS die ganzen Updates zu checken/freigeben/kontrollieren. Der Rest ist ja ein ziemlicher Selbstläufer. Bis auf wenige Einrichtungs-Wizards oder Datenverschiebungs-Wizards habe ich wenig genutzt. Insbesondere die ganzen Logging-Funktionen habe ich jeweils möglichst abgedreht, weil der Ressourcenverbrauch in jeder Hinsicht jeweils ins unermessliche stieg. Das ist vor allem in VM's deutlich spürbar. Bis und mit 2003 war das Patchmanagement mitunter etwas "trickreich" wenn man zu den ersten gehörte. Seit 2008, VM's, Snapshots, VSS etc. ist das aber auch kein Thema mehr. Meine eher negativen Erfahrungen bis jetzt beim Wechsel - Das Patchmanagement hat deutlich an Aufwand zugenommen wenn Auto-Updated unerwünscht ist --> Mehrere Server - Die Gesamtkomplexität steigt - Für eine zackige Single-Host Umgebung mit schnellem Recovery muss einiges an Hardware aufgefahren werden --> Deutlich mehr OS Daten - Es braucht umfangreichere Reihenfolgen für Shutdowns und Starts (USV) sowie Überprüfungen - Um wirklich Vorteile und nicht nur Nachteile aus der Separierung der Dienste zu ziehen, braucht es eigentlich mehrere Hosts und VM's. -> Kostentreiber, SA etc. - Der Installationsaufwand ist deutlich höher - Desaster-Recovery-Aufwand bzw. die Zeit bis alles wieder oben ist, ist länger (ein paar neuere Backupkonzepte ausgenommen, wo direkt anstarten möglich ist) - Die Kosten sind deutlich höher Es hat natürlich auch einige Vorteile - Fehlersuche mitunter einfacher - Sicherheit sicher deutlich höher - Misratene Patches / Fehlkonfigurationen haben ned zwingend Aufwirkungen auf alles - Man kann nen Dienst einfacher entfernen und neu aufsetzen - Grössere Auswahl an Backupsoftware (Dafür auch deutlich teurer) Fazit: Ich arbeite nicht unbedingt weniger gerne so, eher im Gegenteil. Aber dieser Vorteil muss sich eben ziemlich teuer erkauft werden.

Bei Office gibts kein Reimageing mehr. OEM-Lizenzen sind heute weniger wert wie Volumen-Lizenzen. Der ganze Quatsch mit den KeyCards würde ich mir wie bereits erwähnt wurde in keiner Weise antun wollen. Das ist einfach nur mühsam. Zumal du Office 2013 verwenden musst, was ich persönlich ungefähr genauso gerne hätte. Mit einem Vol-Vertrag hast Downgrade-Rigths auf z.B. 2010... ;)

Wie bereits angetönt wurde ist das schwierig pauschal zu beantworten. Für Server-Workloads spielt es oft nicht so die Rolle. Aber es war schon immer so, viel hilft viel. Ist die CPU schnell, macht sie im Moment wo sie arbeiten soll, die Arbeit eben schneller, auch wenn ihr überspitzt gesagt 80% vom Tag langweilig ist. Das merkt man vor allem in VDI Umgebungen sehr gut. Das Benutzerfeeling ist deutlich spürbar besser wenn z.B. 2.2 GHZ und 3.2 GHZ verglichen wird, auch wenn die Leistung nicht permanent abgerufen wird. Anwendungen die vor allem SingleCore basierend sind oder aufgrund von Lizenzbestimmungen auf eine limitierte Anzahl beschränkt sind profitieren ebenso davon. Oft hat eine CPU die nur leicht höher getaktet ist, aber deulich mehr kostet, auch mehr Cache und/oder nen höheren QPI. Das wirkt sich auch auf die Performance aus. In kleinen Umgebungen oder für spezifische Workloads kann unter Umständen auch mal nen Single-Socket System mit ner dicken CPU eingesetzt werden. Die sind in der gleichen Serie deutlich billiger als jene für die Dual Systeme. Gibt halt nur nicht viele Hersteller die tatsächlich vernünftige Serversysteme mit den grossen E5 CPU's anbieten.

Theoretisch sollte das ja bei 2012 nicht mehr vorkommen. Aber Zahnis Tipp hilft normal bei dieser Fehlermeldung. Erweitere mal nur um 18 oder 19 GB.

DoubleTake machte seine Arbeit in der Vergangenheit sehr gut. Wie gut Sie heute sind, kann ich nicht sagen. War früher aber eine verhältnissmässig einfache Variante um nen SBS mit all seinen Diensten einigermassen schnell wieder bereitzustellen, Upgrades und Updates zu testen (einfach Syncro unterbrechen) usw. In der heutigen Zeit mit sehr gutem VSS sowie Snapshots mit VM's hat es aber arg an Bedeutung verloren bzw. kann man das gleiche günstiger und einfacher machen. Günstig war DT übrigens noch nie, Du brauchst für Basissystem und Endsystem ne Lizenz. Sowohl Windows und seinen Applikationen als auch von DT. Ob das ganze heute supported ist, weiss ich nicht. Ich würde in einer Kleinumgebung das Basissystem möglichst performant auslegen. Auch was Festplattengeschwindigkeit angeht. Dann sind Restores nach einem Defekt oder Austausch von Komponenten ratzfatz gemacht. Wenn Du viele Files hast, ist es in Kleinumgebungen ratsam, die ganze Filegeschichte auf zwei unterschiedlichen Systemen vorzuhalten. Replikation der beiden Systeme mit z.B. Robocopy oder DFS. Freigabe der Files mit DFS. Ein System ist dann in sehr kurzer Zeit wieder oben wenn nur das OS wiederhergestellt werden muss. Im DFS kann man dann einfach den Alternativort für die Files eintragen. Man kann das auch vorbereiten und das zweite Ziel einfach ind DFS deaktivieren. Dann haben die Leute keinen Zugriff darauf und bekommen das Ziel auch nicht zugewiesen. (Replikationskonflikte) Die Leute können jedoch sehr schnell wieder weiterarbeiten, weil die Files nicht erst wiederhergestellt werden müssen.

Hi Daniel, Vielen Dank für die ausführliche Antwort. Beste Grüsse ins MS-Land Weingeist

Du schlägst aber ziemlich aggressive Töne an, dafür dass Du nicht zu wissen scheinst was Du tust und Dich - wenn massig Warnungen kommen - immer noch keine Lust hast Dich zu informieren. Wie Du es machen sollst wurde genannt. Such halt im Netz, da findest Du massig Seiten die sich mit Backup und Recovery von Domainen-Controller befassen und was passieren kann, wenn Du Domänencontroller von einem Image wieder einspielst wenn noch andere DC's rumschwirren. Du kannst Dir sehr wohl einigen Ärger einhandeln. Mit meiner genannten Methode sind die Drucker innerhalb kürzester Zeit auf einen neuen Server umgezogen. Geht auch ohne Downtime wenn der Druckserver anders heissen darf wie vorher. Kommt auf die Anwendungsautomatisierung an. Mit kleiner Downtime von gehts auch mit dem gleichen Servernamen. Aufwendiger wirds wenn die Plattform von 32bit auf 64bit gewechselt wird. Sowohl Treiber und Einstellungen für Papierfächer, Briefköpfe usw. werden übernommen. Mit ner virtuellen Maschine ja sogar noch einfacher. Je nach dem ob Du den gleichen Servernamen verwenden willst oder nicht, halt etwas mehr Vorbereitungszeit nötig und direkter Erfolg zentraler oder auch nicht. Gleichen Namen empfiehlt sich, wenn eure Software automatisierte Druckabläufe mit einzelnen Drucker hinterlegt hat, die nicht so einfach zentral zu wechseln sind. Das meiste davon kannst Du vorbereiten, vorgängig in VM's testen. 1. Aufsetzen eines neuen Druckservers mit irgend nem namen, durchpatchen 2. Exportieren der Druckereinstellungen gemäss meinem Vorschlag (wie gesagt mit einem modernen OS auf den Server verbinden) 3. Import der Einstellungen auf den neuen Server (Ebenso via einem modernen Server oder Client, wenn nicht gleich ein neuer verwendet wird) 4. Herausnehmen des alten Druckservers aus der Domäne, kontrolle ob computerkonto gelöscht ist 5. Anpassen des neuen Servernamens auf den alten 6. Aufnahme in die Domäne 7. Anmelden der Clients mit nem LoginScript welches die verbundenen Drucker trennt und wieder verbindet. Zu 7. Entweder gibt es dafür bereits ein solches Script, es sollte erstellt werden oder Du hast Glück und es tut weiterhin wenn der Name identisch bleibt (was ich aber eher bezweifle). Bei neuem Druckserver-Namen eben Scripte vorbereiten. Wenn gar keine Scripte vorhanden sind und alles zu Fuss gemacht wurde für jeden Arbeitsplatz: Eben ein Script schreiben welches alle verbundenen Druckernamen erst ausliest, dann alle trennt und anschliessend wieder verbindet.

Dein Vorgehe ist extrem übel. Glück für Deinen Betrieb wenn das funktioniert hat. Keine Ahnung wie man alle Warnungen in den Wind schlagen kann und trotzdem so migriert. So wie Du das machst, kann man das bei einem einzigen vorhandenen DC tun, sonst gibt es kein Szenario und auch kein Zwang das so zu lösen. Bezüglich Printer-Sicherung: Da finde ich die beste Lösung der neue Druckservermanager von Vista/Server 2008 aufwärts. Damit kannst auch Konfigurationen von entfernen Server sichern (Alle Einstellungen + Treiber) und auf einem entfernten Server (also 2003) wieder einspielen.

@NeMix: Bei einem Datenverlust steht man grundsätzlich immer alleine da. Da nützt aller Support nix. Support hilft in der Regel nur um die Backups - sofern vorhanden - zurückzuspielen und die Hardware wieder zum laufen zu kriegen. ;) @LK: Lizenztechnisch dürfte es im Grunde kein Problem geben. Ich persönlich würde denoch eine Standardlizenz nehmen. Die ist dann wenigstens voll nutzbar, auch wenn mal was am Design geändert wird. Würde zwar auch eher auf nen zweiten ESXi setzen, aber die von Dir genannte Variante geht auch, wenn der Rest der Umgebung wirklich egal ist. Allerdings würde ich der Kiste wenigstens nen Hardware-RAID spendieren. Bei kleinen Umgebungen bitte immer alle Recovery-Szenarien auch auf Fremdsystem durchspielen. Ist zwar mit virtuellen Systemen in der Regel deutlich entspannter als früher, aber sinnvoll planen sollte man trotzdem.

Erwarte bessere 1. Performance, da HD-Köpfe weniger springen müssen (Fragmentierte Files, sowohl für das Log als auch die anderen Files die so automatisch fragmentiert werden) 2. Bessere, schnellere oder weniger Rechenintensives Dedupe, dabei dürften wenig fragmentierte Files auch eher vorteilhaft sein 3. Bessere Recovery-Voraussetzungen schaffen (versehentlich gelöschte Files z.B.) Vor allem bei letzterem habe ich die Erfahrung gemacht, dass dies deutlich einfacher ist mit einem defragmentierten System. Eine auf eine grosse Fläche verteiltes USN-Journal verhindert eine einfache und saubere Defragmentierung. Zudem ist die Defragmentierung deutlich zeitaufwendiger und braucht mehr Schreiboperation. Wenn das mit verhältnissmässig einfachem Aufwand möglich ist, dann wären diese Dinge quasi umsonst zu haben, ohne dass man irgendwas beachten muss.