Weingeist

NVMe-RAID habe ich bis jetzt erst in meiner Testmühle. Noch nicht produktiv, da ich noch keinen für mich optimale Serverbasis gefunden habe. Der nächste wird wohl ein AMD Epyc System von Supermicro, zum Beispiel dieser hier: https://www.supermicro.com/en/Aplus/system/1U/1114/AS-1114S-WN10RT.cfm Vorzüge von AMD: viele PCI-Express lanes und CPU's mit hoher Taktrate zu moderatem Preis verfügbar. Normal nehme ich einen Hardware-Controller für das Local-High-Speed-Backup sowie das Host-OS + wenn Super-Speed gefragt ist, Storage Spaces für die Daten. Braucht aber auch potente CPU's um die Leistung wegzuschaufeln. Stand Heute würde ich wohl alles auf einen bzw. zwei separate RAID-Controller packen mit U.2 Laufwerken. Also einen für Produktivdaten und einen für das Local-High-Speed Backup.

Die Storage-Pools sind schon auch geeignet als RAID-Controller-Ersatz. Ist absolut robust genug. Eigentlich sogar robuster, da ein Gerät weniger in der Kette (!bitte erst alles lesen!). Mittlerweile setze ich Storage Pools doch ca. 7 Jahre in diversen Projekten produktiv ein. Quasi seit es sie gibt. Anfangs nur für VDI mittlerweile für alles. Schlechter oder besser als Hardware-RAID kann man nicht wirklich pauschal beantworten. Hat beides Vorzüge und Nachteile. Es kommt wie bei allem halt sehr stark auf die Implementierung und die Anforderungen an. Hardware-RAID ist halt einstecken, konfigurieren, fertig. Fehlerquelle extrem gering. Aufwand im Fehlerfall auch gering. Mittlerweile hat z.Bsp. Broadcom (LSI) auch vernünftiges NVMe RAID mit U.2-Laufwerken. Insofern kann man es sich schon überlegen wieder nen Hardware-RAID aufzubauen. Die neuen Controller sind sogar ziemlich schnell. Das wurde anfangs total verschlafen. Das Problem ist dann eher, das wirklich gute Zeugs von einem der grossen Herstellern in sinnvoller Gesamt-Austattung unter einen Hut zu bekommen. Meist endet man irgendwann bei Supermicro. Storage Pools sind dagegen definitiv nicht trivial. Weder in der korrekten Erstellung noch dem Unterhalt. Man hat sehr viele Möglichkeiten einen kompletten Schwachsinn zusammenzuzimmern der am Ende sogar läuft und dann plötzlich total versagt. Die Reparatur ist dann sehr aufwendig bis nicht möglich. Man sollte sich schon sehr intensiv mit Storage Pools befassen und dessen Eigenheiten und insbesondere Schwächen kennen bevor man es tatsächlich produktiv einsetzt. Sprich Fehlerszenarien durchgehen, Tests mit Stromausfällen, Plattenausfälle, Sektorfehler, grosse Dateien verschieben, zu gross konfigurierte Thin-Volumes und und und. Mein Fazit für oder gegen Storage Spaces: Storage Pools sind quasi eine bewusste Entscheidung für ein ziemlich mächtiges, flexibles Stück Software welches richtig eingesetzt viel Spass bereitet, falsch aber extrem viel Kummer. Quasi die Eierlegende Wollmilchsau die beim falschen Futter, Bewegung oder Pfleger sofort wegstirbt. ;) Man sollte auch immer einen allfälligen Nachfolger im Hinterkopf haben. Die wenigsten IT-Fachleute sind so mit Storage Spaces vertraut, dass man Ihnen gefahrlos eine Umgebung "überlassen" kann. Als keine sinnvollen Hardware-Controller verfügbar waren, überwiegten die enormen Performance-Vorteile von SP mit SSD's oder NVMe gegenüber Hardware-Controller mit SSD's für mich klar. Heute denke ich, dass es vielleicht auch wieder nen Hardware-Controller sein dürfte. Ist halt viel Schmerzfreier die Umgebung in andere Hände zu übergeben - sofern man sowas wie ein Gewissen hat. ;) Wahl der SSD: Das wichtigste ist bei allen SSD's die für Produktivdaten eingesetz werden die Wahl der Laufwerke. Die müssen über eigene Kondis für das Wegschreiben der ausstehenden Daten verfügen (weil die SSD's in der Regel die Commits rausgeben BEVOR effektiv geschrieben wurde). Dann müssen SSD's welche im RAID-Betrieb eingesetzt werden, über eine regelmässige und tiefe Latenz verfügen (Average und Max Latency müssen tief sein). Bezüglich Speed ob man ihn braucht oder nicht: Ist er vorhanden, reklamiert niemand. Ist er es nicht, wird es mühsam zum ändern. Meine Erfahrung ist, dass in Kleinumgebungen der Speed immer relevant ist für irgend eine Aufgabe. Und sei es nur ein paar komisch programmierte Programme die aber sehr nützlich sind. Die anderen profitieren einfach auch davon, auch wenn es eigentlich unnötig ist. Mehrere Speed-Levels für Produktivdaten machen da selten Sinn. Auch kann man sich oft das teilweise aufwendige optimieren in der Regel schenken, das spart auch Zeit und somit Geld und die Umgebung bleibt einfach aufgebaut. Auch die Taktrate der CPU nehme ich nichts unter 3GHZ. Bringt in Kleinumgebungen normal viel mehr als viele Kerne oder Dualsysteme. Vieles skaliert einfach nicht toll oder ist nach wie vor auf Single-Core ausgelegt. Die gefühlte Performance ist (Latenz) viel wichtiger ist als die effektive über längere Zeit und gesamthaft vefügbare Leistung. Es wird auch selten viel Performance "gemeinsam" benötigt. Es sind die Peaks die relevant sind. Für einen typischen KMU-Chef gibt es nichts schlimmeres als wenn der PC die Sanduhr bringt. Das ist offensichtliche, verlorene Zeit. Also immer frei nach dem Motto viel hilft viel zusammenstellen. ;) OS auf gespiegelte schnelle Platten oder nicht: Würde ich immer machen. Zu schnell gibts nicht und RAID = eine Ausfallvariante weniger. Ich setze immer alles um was mit wenig Aufwand redundant gemacht werden kann und fängt bei der Stromversorgung an. Doppel-Online-USV, separat abgesichert, genügend Batteriekapazität, Strom-Switch für Geräte mit nur einem Netzteil etc. Da ist die Kohle z.B. viel besser aufgehoben als in einem zweiten Server oder einem teuren Dual-CPU-System. Aber wie immer, alles ist irgendwoe Geschmackssache und kommt auf die Anforderungen und auch etwas auf die persönlichen Vorlieben an. Wie so oft.

@BOfH_666 Stichwort Tricky Powershell. Bezieht sich auf Task-Scheduler und die aufrundene Syntax. Habe mal Stunden mit dem Kram verbracht der in der Kommandozeile funktioniert hat, im Taskscheduler aber nicht. Der Scheduler hat dann gerne die eingebene Zeile im Fomularfeld beim wiederaufrufen der Einstellungen auf die anderen Felder verteilt. Funktioniert hat es auch nicht. Habe damals leider nichts gefunden im Netz. Daher der Workaround mit dem Batch, der funktioniert immer. =) Ansonsten: Der Input mit den Powershell DataFiles klingt auch vernünftig bzw. ist wohl besser.

Die Aufgabenplanung nimmt immer jenen User den man definiert hat. Powershell-Scripts sind etwas tricky um die Syntax genau zu treffen damit sie direkt funktionieren. Kleine Howto: https://devblogs.microsoft.com/scripting/weekend-scripter-use-the-windows-task-scheduler-to-run-a-windows-powershell-script/ oder auch lesenswert: https://devblogs.microsoft.com/scripting/schedule-powershell-scripts-that-require-input-values/ Insbesondere der zweite Link ist wichtig bei Textargumenten. Umgehen kannst den Ärger mit den Argumenten indem Du einfach ein aufrundes Batchfile nimmst, das funktioniert schmerzfrei. Hat den Vorteil, dass man nicht am Task selbst herummachen muss sondern einfach das aufrufende Script etwas abändert. Mich hat die Testerei mit den Argumenten teilweise wahnsinnig gemacht und habe deshalb einfach standardmässig eine zusätzliche Batch erstellt. Aber das ist wie so vieles geschmackssache und auch etwas verbohrte Gewohnheit. ;)

Das Produkt von Stratus ist grundsätzlich sehr erprobt in der Gebäudetechnik. Wurde früher eigentlich auch ausschliesslich da verwendet, in der IT kam es nie wirklich an. Der Kram funktioniert wirklich. Ist halt relativ kostspielig (wars damals zumindest). VmWare hat das mehr schlecht als recht kopiert und zudem bei weitem nicht vollständig. FT haben die damals +- nur gemacht um eben auch ein solches Feature zu haben. Entwickelt wurde es von Marathon als Aufsatz auf den Xen Hypervisor. Wurde später an Stratus verkauft. Die Fault-Tolerance ist über alle Komponenten gewährleistet. Der Wechsel der aktiven VM geschieht nur, wenn der Host tatsächlich tot ist. Solange also CPU/RAM funktioniert, wird die VM nicht gewechselt, höchsten die Datenbeschaffung/Netzwerkverbindung. Eigentlich sehr durchdacht das Ganze. Ich habe es damals nicht produktiv umgesetzt weil die Community quasi nicht vorhanden ist. Im Fehlerfall bist also wirklich zu 100% auf den Hersteller angewiesen. Die haben leider auf den falschen Hypervisor gesetzt.

Ich finde das Thema enorm schwierig. In letzter Zeit trudeln hier immer mehr perfektere Mails rain. Steuerbehörde, Telekomanbieter, Microsoft, Apple, GMX, Airlines. Echt krass. Sogar teilweise in perfektem Deutsch. Eigentlich müsste man den kompletten internen Verkehr von den Maschinen mit Online-Zugriff trennen. docx/slxs etc. kann wenigstens gleich jeder manipulieren =) Ist ja im Endeffekt nur ein ZIP-Archiv. Würde mich auch brennend interessieren was daran sicherer sein soll. Hätte jetzt - wenn - eher zu weniger sicher tendiert da automatisierte Verarbeitung evtl. erzwungen werden könnte. ZIP ist ja nicht gerade als besonders sicher bekannt und wird eigentlich überall geblockt. Also müssten es grundsätzlich auch alle Word-Files. Das DOCX sicher sein soll ist meiner Meinung nach der gleiche Unsinn wie das W7 im Kern unsicherer sein soll als W10. Der Firewall-Stack is ziemlich identisch bzw. W7 fehlt sogar der ganze App-Quatsch der im FW-Stack völlig undurchsichtig ist. Er ist wesentlich eingeschränkter als in W10. Ich behaupte W7 mit Firewall extern Block war vermutlich sicherer als jedes W10, weil W10 die Firewall wie ein Schweizer Käse löchert und es auch keine funktionierende Abhilfe gibt, weil die Regeln auf Benutzerbasis automatisiert erstellt werden. Da helfen eigentlich auch all die neuen Features nichts.

Olé olé... =)

Auch wenn Du den Ton noch etwas üben solltest, ich tippe auf ein Binäres System. Das heisst die verschiedenen Optionen kannst du summieren. Manche beschriebenen Szenarien sind dagegen bereits summiert, z.B. 72 = 64 + 8. Das heisst die Optionen 8 und 64 werden gesetzt. Bei 8264 ist es wiederum 8192 + 64 + 8 Macht auch soweit eigentlich auch Sinn wenn man sich den Text zu Gemüte führt. Das OS kann dann sehr schnell einen binären Vergleich für die verschiedenen Optionen durchführen um die entsprechenden Massnahmen zu ergreifen. Das geht programmiertechnisch schneller und ist vor allem immer eindeutig und der Einstellungswert beschränkt sich auf eine Zahl mit der die Vergleiche durchgeführt werden. --> Dies in eine eigene GPO zu packen dürfte dagegen schwieriger sein. Da müsste man die einzelnen, gewünschten Summen präsentieren. Erklärung: Eine Summe von Zahlen welche ausschliesslich aus verdoppelten Zahlen bestehen als, 1, 2, 4, 8, 16, 32 etc. ist immer eindeutig und kann somit einfach per binärem Vergleich in die einzelnen Optionen zerlegt werden. Bis zu einem gewissen Grad macht das Sinn, irgendwann gibts nen Überlauf weil die Zahlen ausgehen. Werden die Zahlen binär aufgeschrieben also eine Verkettzung von 0 und 1 in einem String, dann wird vereinfacht gesagt einfach die 0 und 1 vergleichen. Beispiel: 0000001 = 1 0000010 = 2 0000100 = 4 0001000 = 8 0010000 = 16 0100000 = 32 1000000 = 64 1000001 =65 besteht demzufolge aus 1 und 64

Normal kommen Netzwerkpfad-Fehler wenn das Share mit einem anderen Benutzer verbunden wurde als man darauf zugreifen möchte. Habe ich zwar nicht im Context mit WDS aber mit Scripts schon oft genug erlebt. Eventuell verbindest Du mit dem normalen User, es wird aber mit dem privilegierten Admin-Account ausgeführ. Oder anders rum. Dem fehlt dann das Share. Manche Windows-Prozesse laufen auch als Trusted Installer oder System und das Share wird mit Admin verbunden. Weiss nicht ob das hier geht, aber eventuell wäre ein Mount-Point möglich? Der dürfte unabhängig vom User sein. EDIT: mklink oder so war das glaub.

Wenn Software-RAID dann gleich Windows machen lassen. Also den Intel-Onboard umschalten und mit Storage-Spaces eine RAID 1 machen. Zusammen mit ReFs kriegst den Datastore fast nicht kaputt. War da mal sehr kreativ mit Zerstörversuchen. Discs rausziehen, Stromzufuhr trennen, SATA Kabel abziehen, Backplane-Strom abklemmen, Sektoren feindlich überschreiben mit HexEditor etc.) Alles unter voller Auslastung. Das Filesystem war nie kaputt, Sektorfehler wurden selbständig wieder geheilt. Da können die Onboard-Controller komplett abstinken und viele RAID-Controller auch. Nur ein volles Volume ist der Tod von ReFs. (Passiert schneller als man denkt wenn man mit sehr grossen Files hantiert/ändert. Wurde aber massiv verbessert in den letzten Versionen.) Sehr empfehlen kann ich auch einen Extra-HBA. Also ein hochwertiger, nicht der Onboard-Kram wo sehr oft nicht das unbedingt das Beste verbaut ist. Da ist dann evtl. sein Max. Durchsatz die Limite. Noch besser: Gleich NVMe nehmen. Wichtig bei Software-RAID: SSD's mit Kondis als Stromausfallversicherung! Die SSD-Controllen schicken zwecks Speed gerne mal die Commits raus bevor die Daten effektiv geschrieben wurden. Auch ein Hardware-RAID hilft da dann wenig. Deren Controller lassen bei SSD's zudem gerne den Write-Cache aus. Hardware-RAID bringt also oft gar nicht so viel. Zudem ist StorageSpaces viel robuster. Ansonsten: SSD RAID-Leistung steht und fällt mit 1. Latenz, 2. Latenz, 3. Latenz und dann noch mit der CPU-Leistung. ;) --> Sprich: Wichtig ist die Average sowie Max. Latenz, also eine möglichst gleichmässige Latenz ohne Ausreisser mit langen Zugriffszeiten. Je mehr Discs mit von der Party sind, desto wichtiger wirds. Bei zwei nicht vollen Discs sollte das noch nicht dermassen ins Gewicht fallen, ausser eben beiden billigen Teilen. Da trennt sich die Spreu extrem schnell vom Weizen. Sofern die CPU genügend Bums hat, skaliert das mit guten SSDs fast 1:N. Samsung 850 Pro hatte ich eigentlich als relativ gleichmässig in Erinnerung. Müsste also gut gehen. Hatte aber schon lange keine mehr in den Fingern und ob die Kondis als Write-Protection haben, weiss ich auch nicht auswendig.

Wenn die Befehle nicht klappen, könntest Du in der Registry danach suchen und rauslöschen. z.Bsp. hier: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Map Network Drive MRU Alle unerwünschten Einträge löschen und anschliessend die MRU-List anpassen. Also nur die Laufwerks-Buchstaben drin lassen, die du auch verwendest. oder evtl. auch hier hier: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\DOS Devices

Ich finde nur seltsam, dass die m2 in diskpart unter dem installer erkannt wird. Sicher, dass das Ding "leer" ist und nicht so partitioniert, dass sie eben in der Auflistung nicht angezeigt wird? Dell EMC klingt nach eher neuem Modell, eigentlich unlogisch wenn m2 nicht als bootlaufwerk unterstützt wird. Fals noch nicht versucht, leere mal die Partitionstabellen der m2 manuell mit diskpart. Also CleanAll

Naja, das klassische RDP wird MS nach und nach madig machen. Sofern es sich MS nicht anders überlegt. Peu à peu. Ist ja eh alles etwas naja punkto Grafik-Implementierung und Sicherheit. Zudem muss es ja eigentlich einen Grund haben, dass die ganzen Services nach User aufgedröselt werden und als eigene Instanz laufen. Vielleicht gehts am Ende aber auch einfach in Richtung eigener VDI-Instanz. Ich behaupte MS sucht einen Weg um die Kunden möglichst komplett in die Cloud zu bugsieren und schaut nun was am besten geht. Aber das ist alles reine Spekulation meinerseits. ;)

Wenn es ne Einzelplatte ist, würde ich sie noch auf Sektorfehler und den SmartStatus prüfen. Wenn es zudem eine SSD ist, zügig ersetzen. Ist gerne nen erstes Anzeichen für den baldigen Tod.

Filelocks können unterschiedlichste Ursachen haben. In der Regel hat tatsächlich einer die Datei offen. Entweder bewusst oder unbewusst. Des weiteren können instablie LAN-Verbindungen hängende Locks verursachen. Insbesondere wenn viele Pakete verworfen werden --> prüfen mit z.Bsp. Wireshark. Das betrifft insbesondere grosse Excel oder Word-Dateien. Läuft dann wohl in irgendwelche Timeouts. Das gab früher öfter wenn von 100Mbit auf 1Gbit Switches gewechselt wurde ohne die Leitungen auszutauschen. Abhilfe hat dann das aktive Verringern des Ports-Speeds gebracht oder wenn kein Managed Switch vorhanden war, das testweise dazwischenklemmen eines 100mbit Switches. Dann gibt es noch die Varianten das zwar Excel einen Lock aufrecht erhält aber nicht der direkte Auslöser ist. Habe mich vor kurzem mit einer CAD-Software abgemüht die auf Excel und Word-Funktionen zugreift für irgendwelche Exports. Wenn nun der gleiche User eine andere Exceltabelle geöffnet hatte, dann wird Excel unter Umständen nicht immer komplett entladen und seine Locks auf die normal geöffnete Files nicht entsperrt wenn er Excel schliesst. Excel bzw. Teile davon schwirren dann irgendwo im Hintergrund rum und behalten die Locks auf die Datei obwohl sie vom User eigentlich geschlossen wurde. Abhilfe schafft dann oft nur ein Neustart des verursachenden Clients. Manchmal hilft auch ein manuelles abschiessen des Excel-Prozesses oder ein neuanmelden. Die Probleme auf Applikationsseite kamen, seit MS mit Office 2007 die grandiose Idee gehabt hat, Excel und Word-Instanzen nicht vollständig isoliert auszuführen sondern irgendwie zu verhängen. Die einzelnen Instanzen werden dann bei Automatisierungen mit externen Programmen oft nicht komplett sauber entladen. Viele dieser Probleme haben den Printerstack als Ursache welcher in Excel/Word Parallel zum System geführt wird und alle Instanzen gemeinsam darauf zugreifen. Total bescheuert. Ich habe noch keine Möglichkeit gefunden, dieses extrem mühsame Verhalten auf Office 2003-Standard zurückzusetzen. (Extrem mühsam z.Bsp. für automatisierte Ausdrucke und per Code gesetze Printereinstellungen)

Du könntest Ihm auch nen kleinen Script schreiben. Ich mach das jeweils so wenn etwas zwingend Admin-Rechte benötigt. 1. Script welches die Funktion ein- oder ausschaltet (i.d.R. gibts Powershell-Befehl oder eben den Reg-Entry dafür --> RegEntry muss allerdings selbständig durchs OS überwacht werden damits ohne Neuanmelden/Neustart klappt) 2. Im Task-Scheduler das Script als System/Admin oder eine Managed Service Account mit entsprechendem Recht hinterlegen 3. Das Ausführen dieses Tasks für normalen User erlauben 4. Link/Script erstellen welche den Task anstösst (damit User nicht in der Aufgabenplanung rumhampeln müssen) So kannst dem User den Umständen entsprechend relativ bequem Tasks mit erhöhten Rechten ausführen lassen ohne ihm selbst Admin-Rechte zu geben. Halt auf die gleiche Weise wie das Windows im Hintergrund auch macht.

Wieso nicht einfach eine kleine NAS mit RAID 1/5/10? Kostet doch wirklich nicht die Welt. Falls das noch zu teuer ist, sind die Daten einfach nicht wichtig genug. Schon oft genug erlebt, das eine einzelne Platte Sektorfehler hatte. Die bemerkst Du nichtmal zwingend, aber deine Files sind nachher korrupt. Daher sind Einzelplatten eigentlich nie so wirklich gut für wichtige Daten.

Solche verschlüsselten Scripts sind oft auch eine Selbstschutz damit man nachher keine fehlgeschlagene Manipulationen wieder flicken muss. So nach dem Motto, wieso bieten Sie das überhaupt an wenn nachher so viel kaputt gehen kann usw. Ein verschlüsseltes Script gibt da auch eine gewisse Sicherheit, das es eben unverändert ausgeführt wurde. Weil eben nicht der 0815 Büroawender drin rumwuseln kann. Das ist mal die Grundidee dahinter. Später kommt erfahrungsgemäss dann schnell der Geld-Gedanke hinzu. =) Zu Deinem Problem: Danze ganze sieht für mich auch nach Java aus. Nach Microsoft Java. Darauf lässt das Statement New ActiveXObject schliessen. Meines wisses gibts dieses genau so nur in Microsoft Javascript. Normal wird ActiveX nicht direkt in Java supported und muss etwas aufwendig erstellt werden. Die Helper-Function (bzw. sowas wie nen eigenes Object ) VBHelper bringt dir nun die verwendeten VB-Functions relative easy nach Java. Ich vermute den Sinn darin, dass es entweder Altlasten sind oder das es der Tatsache geschuldet ist, dass mit vbs relativ easy Textfile-Manipulationen vorgenommen werden können. Die verwendeten UCase sind allesamt unterhalb der definierten vbs Objects in den einzelnen Funktionen zu finden. Nicht jedoch im Code selbst. Imho ziemlich schwachsinnig gelöst, aber es funktioniert. ;) Meiner Ansicht ist die Helper-Function UCase innerhalb der VbHelper aber falsch: return vbs.eval('UCase' + ParamsToString([string]) + ')'); Nach mir fehlt hier schlicht eine Klammer: return vbs.eval('UCase(' + ParamsToString([string]) + ')'); Dann sollte eigentlich auch der Zugriff auf die Helper Function Ucase in der oberen Funktion funktionieren. Upper Case bescherrscht aber eigentlich jede noch so dumme Sprache, für sowas nen Wrapper zu bauen... Naja man muss nicht alles verstehen. Solange nicht unglaublich viele Statements abgesetzt werden müssen, ist auch der Speed erträglich, bei Grossmanipulation sind solche Konstrukte tödlich. ;) Weiterer Vorschlag: In Java müsste die Methode toUpperCase deinen String umwandlen. Ich bin nicht wirklich fit in JavaScript, Google meint aber das UpperCase eine Methode des String-Objects ist. Das heisst ein simples toUpperCase müsste funktionieren. Also: Produkt.toUpperCase Die ganzen Änderungen sind sehr simple SQL-Statements. Ein paar Where und einfache Update-Statements. Das Upper Case kannst auch mit SQL totschlagen. Dafür musst allerdings die SQL-Sprache wissen. Schätze mal MS-SQL. Normal läuft das ungefähr so. UPDATE VERTRAG SET Produkt = '"+Produkt+"', BEARBEITER=..... ersetzen mit sowas Update UPDATE VERTRAG SET Produkt = UPPER('"+Produkt+"'), BEARBEITER=..... Damit bewirkst du das Grossschreiben direkt im Update-Statement. Ich bevorzuge aber obiges, weil es nur einmal geschieht. Wenn Du solchen Krempel öfter machen musst, würde ich mir ne kleine Anwendung schreiben wo dann statt der Input-Boxes entsprechend Formular-Felder vorhanden sind. Ist mit Express ziemlich schnell gemacht. Gibt dann auch die Möglichkeit von SQL-Rolllbacks wenn was schiefgeht usw.

Ich bevorzuge immer ein AD. Egal ob Einman-Betrieb oder mehr. Ein paar Gründe: - Schlicht weil es einfacher zu verwalten und vor allem nachvollziehbarer ist, zudem gleiche bzw. ähnliche Bedinungen wie andernorts - Voraussetzung für Fehlersuche oder Hilfestellung anderer Leute im Problemfall deutlich besser, weil eben 99.9% AD verwenden. - Wächst das unternehmen nur minimal, also kommt z.B. ein PC für die Sekretärin dazu welche nicht auf ganz alles zugriff haben soll, muss nicht alles neu gemacht werden sondern es ist schon vorbereitet, spätestens ab hier wird ein PC mehr mühsam (Pflege Passwörter auf beiden Maschinen etc.) - Arbeitet man von Anfang an mit DFS, müssen später nicht Verknüpfungen in Dokumenten neu gemacht werden - und sicher noch einige mehr Essentials habe ich aber auch schon genommen, auch wenn ich Standard deutlich bevorzuge. --> Print-Server mache ich nach Möglichkeit konsequent separat als VM, Für overdressed halte ich - unter normalen Umständen dagegen einen zweiten DC im kleinen Umfeld. Den braucht es meines erachtens schlicht nicht. Das warum und wieso ich das so sehe habe ich erst kürzlich relativ ausführlich in einem anderen Thread beschrieben.

DWPD: Nun, ich hatte da andere Erfahrungen gemacht und mich seither auf die minimal 3 DWPD beschränkt. Mir ist jede Disc die ich wechseln muss eine zu viel. Ich bin happy wenn ich so wenig wie möglich an die Systeme ran muss. Bei mir ist das aber auch schon einige Jahre her seit ich das letzte mal ne 1 DWPD verbaut habe, möglich das die Qualität hier generell auch besser wurde. Wie genau die Angriffe auf die Veeam-Repositorys erfolgten, ist mir (noch) nicht bekannt. Keine Ahnung ob das Implementierungs-Fehler, Designfehler oder Bugs in der Backupsoftware waren. Muss ich mich auch erstmal schlau machen. NAS: Da wäre ich mir nicht so sicher das die Daten da drauf gut geschützt sind. Die handelsüblichen 0815 NAS sind gespickt mit Sicherheitslöcher. Alleine schon aufgrund ihrer Funktionsvielfalt die weit über die Speicherbereitstellung hinausgeht. Sobald die mal auf dem Radar sind, wird es vermutlich für viele ungemütlich.

Die Reporting-Tools sind auch bei WSUS das bzw. eines der Probleme wenn die Builds nicht gscheit zusammen passen. Die Chance ist also gross, dass es hier auch so ist. Nimmt mal die ältesten Images die Du bekommen kannst. Insbesondere von Windows-Server. .Net 3.5 von der Festplatte installieren mit getrenntem Netzwerk. Danach SCCM. --> Also so: dism.exe /online /enable-feature /featurename:NetFX3 /all /LimitAccess /source:E:\sources\sxs (E: logischerweise für den LW-Buchstaben ;) ) Der SQL 12 ist übrigens (Vorerst) noch bis 22 supported. Aber das weisst vermutlich. Ich meine nur für die Menge Energie die Du noch reinstecken möchtest. ;)

Du weisst aber, dass viele Updates während der Installation automatisch abgerufen werden solange du es nicht aktiv verhinderst? Dann würde ich noch schauen welche Build des SQL-Servers aktuell war als der SCCM rauskam. Dann den SQL-Server mit dieser Build installieren und erst nachher hochziehen. Die Reporting Services benötigen zudem oft .Net 3.5 (weiss nicht auswendig ob diese hier auch) Diese solltest vorgängig installieren. Wiederum ohne Updates.

Eventuell die gleiche Problematik wie wenn manchmal WSUS installiert wird. Da war jeweils die Lösung: Zuerst WSUS und vor allem SQL installieren und erst dann Updates einspielen. Versuchs mal damit. ;)

@noobi: Bis jetzt hatte ich den Mut für nen Epyc System nicht. Wäre aber genau die CPU die ich wählen würde. Wird sie auch für mein nächstes Test-System in der eigenen Umgebung welches ich in der Regel produktiv für die VDI verwende. Preis-Leistung ist unverschämt gut. (Chipsatz, CPU-Takt, RAM-Takt, anz. RAM-Channel, anz. PCI-Express-Lanes --> NVME-Discs). Im Netz liest man nichts Negatives über die 2. Serie. Bei Intel wäre meine Wahl entweder z.B. beim alten E5 16XX v3 (günstig) oder dann beim neuen W-3245. Letzteres ist aber bereits ziemlich teuer (inkl. Chipsatz). Tipp bezüglich SSD: - Tiefe average Latenz --> Wichtig im RAID-Betrieb! Sonst läuft der Krempel immer mit dem Speed des aktuell langsamsten Zugriffs! --> Die Spreu wird vom Weizen getrennt. - Kondensator-Pufferung --> Wichtig bei SystemCrash/Stromausfall (Cache wird noch weggeschrieben). SSD's senden gerne/normal das Commit bevor effektiv weggeschrieben wurde. Write-Cache von RAID-Controllern wird mit SSD's normal ausgelassen - mind. 3DWPD (drive writes per day) --> Je mehr desto besser, ab 3 sind sie in der Regel deutlich robuster, ab 10 kriegt man sie eigentlich nicht mehr kaputt im 0815 KMU-Betrieb, auch mit Dedupe nicht, da wirklich nur beste Chips verwendet werden und die Produktionsabläufe auch deutlich besser sind. Preis natürlich entsprechend. --> Die 10er gibts leider so gut wie gar nicht als Option bei "kleinen" Server der grossen Hersteller. Und wenn dann zu völlig utopischen Preisen. DER Hauptgrund warum ich mittlerweile fast nur noch Supermicro-Barbones im Eigenbau kaufe sobald SSD's im Spiel sind. Fremdfabrikate (und wens nur die eigene Firmware bzw. der Herstellerflag darin ist) werden ja von den anderen aktiv "vergrault". (Musste noch kein einziges mal ne Intel 540er, X-25, DC3700 oder P4800X tauschen--> letztere noch wenig aussagekräftig, da noch wenig verbaut). Bei den QNAP-NAS: Hier könnte man evtl. mit nem kleinen Zwischen-Switch für die separate LAN-Anbindung arbeiten welcher beim Backupjob eingeschaltet wird und danach wieder getrennt. --> zwecks Ransomware-Schutz könnte eine z.Bsp. nur immer am Week-End aktiviert werden, die andere täglich. Auch würde ich bei vielen File-Daten ein zweites Daten-Laufwerk auf dem Fileserver vorhalten welches auf einem NAS liegt. Einfach eine virtuelle Disc zusätzlich einbinden und ausser einem Dienstkonto/Dienstgruppe allen den Zugriff verwehren. Sync per Robocopy. Das Laufwerk deaktivieren, dann trennen. Besser noch anschliessend die LAN-Verbindung zur NAS kappen indem z.Bsp. die Stromversorung des Switches abgedreht wird. (Geht alles ziemlich easy mit Powershell). Entweder mit aktiviertem Dedupe und nem Fullbackup pro Datum (jeweils ein Ordner zbsp. mit Schema yyyy-mm-dd-TimeStamp) oder aber einfach eine Verzeichnis-Synchronisation. So muss im Fehlerfall bei wenig Zeit in der Regel erstmal nur die Systemdisc des Fileservers hochgezogen werden und die DFS-Ziele auf die vDisc welche auf dem NAS liegt umgebogen werden. So gewinnt man viel Zeit. --> Stromverbindung kappen gibts PDU's mit Power-Funktion. Zbsp. mit diversen Protokollen von NetIO (PowerPDU) @daabm: Stimmt, davon gehe ich (fälschlicherweise) eh immer aus. Irgend eine Form von externem Backup oder mindestens separater Brandabschnittt würde ich für den Desaster-Fall immer machen. Immer noch keine Garantie für Ransomware - das Zeug wird immer anpassungsfähiger - aber die Latte wird höher gesetzt. Wegen Ransomware bin ich aktuell auch grad am überarbeiten meiner Standard-Vorgehensweise seit ja angeblich bereits ganze Veeam-Repositorys gelöscht wurden. Aber selbst auf Cloud-Speicher sollte man sich nicht ausschliesslich verlassen. In der Firma eines Kollgen wurden z.Bsp. alle Cloud-Daten aufgrund eine Manipulationsfehlers der Mitarbeiter des Rechen-Zentrums gelöscht. Inkl. der Backups. Die Backups waren mehr Hardware-Snapshot-Syncs auf eine zweite SAN als ein richtiges Backup. (Eigentlich sind solche Syncs ja SEHR positiv zu sehen!). Diese wurden mit dem definitiven Löschflag versehen, ähnlich wie wenn man den Löschbefehl für aufgzeichneten Nutzerdaten gibt. Halt wie bei den grossen üblich, ein vollautomatisierter Vorgang. War dann komplett restlos alles unwiederbringbar weg. Jegliche (konkrete) Haftung wurde in den AGB's ausbedungen, er war also der Esel am Berg. So richtig. Gab zwar ein Kulanzangebot, aber die Daten waren futsch. Glücklicherweise hatte er wenigstens die unbezahlten Debitoren in Papierform sowie ne Kundenliste (alte Schule halt). Ebenso wichtige Aufzeichnungen. Der Anbieter war ein nahmhafter Grosskonzern den ich hier nicht nenne. Auch nicht per PN. Mittlerweile hat er seine Daten wieder lokal und sichert nur noch in die Cloud. Klar diese Fälle sind vermutlich sehr selten, aber es gibt sie genau wie es die lokalen Verluste gibt. Nur werden diese garantiert allesamt unter den Teppich gekehrt mit einer entsprechenden Vereinbarung und Abfindung ;)

Ist zwar ketzerisch, aber will man sich in Kleinstumgebungen zwei DC's wirklich antun? Ich mache das schon lange nicht mehr solange keine wichtigen Anwendungen regelmässig Daten in AD schreiben. Gründe: - Die paar Passwörter die vielleicht falsch sind, interessiert kein Mensch. - Wiederherstellungsart bei nur einem DC total egal und eh super schnell da kleine VM (selbst eine Cold-Copy tuts die man ab und wann auf die Seite legt + evtl. gleich auch auf dem System vorhält) - Dadurch automatisch nie Ärger mit den Versionständen - Kein Ärger mit Replikation (das überwachen/fehler beheben können die Leute vor Ort eh nicht, müsste man selber) - Fehlersuche aller Art ist einfacher (DNS, AD, GPO) da nur eine einzige Maschine betroffen - Wenn die PDC bzw. Betriebsmaster-Rolle wegknickt ist eh für vieles Essig, umschalten für die paar GB Restore lohnt nicht wirklich - Jegliches Aufräumen im AD dauert immer länger als ein sauberer Restore (wenn eben mal in die Situation des aufräumens kommt) - usw. Alles in allem habe ich den zweiten DC seit es Virtualisierung gibt noch nie vermisst. Nen zweiter kommt bei mir nur bei einem Server-Upgrade rein, danach wird der alte rausgekickt. VM-Aufteilung - 1 VM mit DC - 1 VM mit Fileserver, veröffentlicht mit DFS - 1 VM für DB des Buchhaltungsprogramm, auch Zusatztools wie Zeiterfassung und sonstigen Betriebsspezifischen Kram (Backup eh meist aus Applikationen raus) - 1 VM nur für Printserver (mache ich immer separat, Druckertreiber sind gerne Problemkind Nr. 1, ich war schon oft froh das ich ohne Auswirkungen einfach die VM rückspielen konnte oder den Printserver noch auf einer alten Server-Version belassen konnte weil die Treiber noch nicht gscheit auf den neuen funktionierten. Mache ich selbst bei simpelsten Systemen für 1 Mann-Betriebe so wo lokal auf dem Host gearbeitet wird) - Restliche VM's wie gebraucht, möglichst separat und wenn dann nur 1 Funktion welche Aktuell sein muss (einfachere Rollbacks wenn nötig) Hardware: Lieber 1 Sockelsysteme und max. 16 Kernen (Lizenzkosten, CPU und Chipsatzkosten, mehr GHZ fürs Geld etc.), SSD's nur Enterprise-Ware etc. Dafür aber Geld für Infrastruktur (2xOnline-USV, Umschalter für Geräte mit nur einem Netzteil usw. aufwenden). Bei schnellen SSD's als Primärspeicher kannst alles ins gleiche Disc-Set werfen, auch sonst in der Regel zügiger mit entsprechend Cache auf dem Controller. Zweites Disc-Set, evtl. separatem Controller, für Local-Backup. Bei wunsch nach mehr Infos melden oder Diensleister ins Boot nehmen (je nach Grad deiner Selbstverwirklichungslust).