Weingeist

Die Aufgabenplanung hat er aber schon als Admin geöffnet? --> Also rechte Maustaste als admin öffnen --> Ist bei der MMC nicht immer gleich, manchmal fragt er sowieso, manchmal eben nicht.

FTP ist nicht wirklich so straight für den normalen User. Klar man kann ihm alles beibringen, aber ist eher lästig. Oft auch gar nicht möglich. In der Industrie-Automation wird gerne mit Transfer-Volumes gearbeitet wo dann verschiedene Maschinen und Leitsysteme ihre Steuerbefehle in Form von Files ablegen. Das Verzeichnis wird dann von allen überwacht und ausgewertet. FTP wurde früher gerne genommen, heute wird es wieder eher stiefmütterlich behandelt. Mir gefällt der Lösungsansatz mit dem Proxy und ansonsten physischen oder per VLAN getrennten Netzen. Wäre allgemein ziemlich positiv für Produktions-Anlagen die z.Bsp. ans ERP müssen. Ist halt eine Station mehr in der Kette die Ärger machen kann, aber in Hinblick auf alte nicht aktualisierte Software und verschiedenster Malware wäre das schon sehr positiv bzw. eigentlich fast schon Pflicht. Könnte und sollte dann zugleich als Firewall fungieren.

Es muss nicht immer nur schlecht sein, wenn "normale" User selber keinen direkten Zugriff auf Tasks wie die vom Backup bekommen. Die Tasks sind dann unter Umständen auch besser vor Manipulationen geschützt weil z.B. nur ein bestimmtes Service-Konto die Änderungen vornimmt. Aber wenigstens Read wäre schon gut. Möglicherweise sind sie aber auch schlicht nicht Regelkonform erfasst worden, dann erscheinen sie im Taskplaner auch nicht in der Auflistung. So wie das MS eben teilweise bei den Telemetrie-Tasks auch macht. Das ist dann entweder Absicht oder eben schlampige Arbeit. ;) Die Tasks kannst Du natürlich in der Registry ändern/löschen wenn das gewollt ist. Bei neueren OS kann auch die Powershell mittlerweile ziemlich viel. Die Parameter direkt in der Registry zu ändern ist aber etwas tricky. Zudem solltest beim händischen löschen in der Registry nach weiteren Ableger des Tasks mittels der GUID suchen.

Dieser Haken ist mittlerweile nur noch die halbe Miete. Wichtig ist ob und welche Art von tatsächlichem Zugriff der aufrufende Benutzer auf die entsprechenden Reg-Hives hat. Aber auch als System/TI ist die Auflistung nicht 100% vollständig und nur in der Registry ersichtlich. Die Aufgabenplanung ist teilweise ziemlich undurchsichtig geworden. Man muss dann selber die Registry durchforsten möchte man die effektiven Tasks haben. Ich würde es als erstes mal versuchen, mit Sysinternals psexec die Aufgabenplanung als System zu starten und schauen ob es in der Auflistung erscheint. (z.Bsp. einfach die mmc.exe) Falls es nicht geht, mit Joakim Tools -RunFromToken- als TI und zu guter letzt eben zu Fuss via Registry.

Bezüglich 2. DC: Mir persönlich verschliesst sich in Zeiten der Virtualisierung wozu ein zweiter DC im KMU-Bereich sinnvoll sein soll. Permanent Änderungen gibt es ja in der Regel nicht und wenn der Server Down ist, läuft der Rest der VM's auch nicht. Gilt natürlich nur wenn man keine Anwendung hat die Permanent mit AD arbeitet bzw. darin rumschreibt. Die ganzen möglichen Probleme die es mit dem Sync geben kann, schliesst man von vornherein aus. EDIT: Und das meiste ist eh vom PDC bzw. der Betriebsmaster-Rolle abhängig und die muss dann erstmal gewechselt werden sonst läuft z.Bsp. ein DFS-Wechsel - manuell oder automatisch - auch nicht wenn das Primärziel auch auf dem gleichen physischen Host war. Was bei AD+Fileserver in der gleichne VM unweigerlich der Fall wäre. Nur ein DC heisst es ist total wie er gesichert/wiederhergestellt wird weil die Versionsstände der DB quasi egal sind. Selbst eine 100% funktionierende Copy im ausgeschalteten Zustand kann verwendet werden für den Desasterfall oder wenn die Veeam oder integrierte Sicherung nicht top funktioniert hat. Ein DC ist ca. 10GB bis max. 20GB gross. Das heisst er ist ratz fatz zurückgespielt und wohl der kleinste Teil der zu wiederherstellenden Daten wenn ein physischer Server Down geht. Schlägt z.Bsp. ein Update/Upgrade fehl, spielt man einfach eine ColdCopy der VM-Discs zurück. Ein zweiter DC's gibts bei mir nur kurze Zeit wenn ich die Server-Version erhöhen möchte Die Lizenz nutze ich persönlich lieber für einen separaten File-Server oder eine separate CA. Aber eben, alles ist Geschmackssache, aber ich nutze seit über 10 Jahren keine Zweit-DC's mehr solange keine Exchange eingesetzt wird und bin damit sehr gut bzw. besser gefahren. Ärger mit AD hatte ich immer nur wenn mehr als einen DC in einer Umgebung war.

Da die Taskbar eine App auf User-Basis ist, könntest Du verhindern, dass diese überhaupt installiert wird. Ausblenden geht meines wissens nicht. Die Installationsverweigerung ist allerdings auch nur mit dem Vorschlaghammer möglich weil MS es leider nicht einfach so ermöglicht. Der Desktop selber ist dagegen im System verankert und funktioniert auch ohne die App. Abmelden etc. kann man auch gut per Link auf dem Desktop umsetzen. Die ganzen Benachrichtigungen etc. funktionieren natürlich ebenfalls nicht, brauchen die Leute aber auch nicht wirklich. Ein paar Ideen dazu: 1. Per dism.exe die entsprechenden Pakete entfernen. Das ist allerdings nicht umkehrbar. 2. Dem System/TrustedInstaller die Zugriffsrechte auf Dateiebene entziehen 3. Die Berechtigungen für das ändern der Firewallregeln in eine eigene Sicherheitsgruppe auslagern und System/TrustedInstaller die Write-Berechtigung verweigern (Registry-Hives) Meine bevorzugte Variante ist aktuell Nummer 3. Die wende ich gern im industriellen Bereich mit LTSB/LTSC oder auch auf Servern an (aktuell bei Server noch im Testbetrieb, bin noch auf 2012R2). Ergibt so quasi eine Minimal GUI ohne Balast. Ausser Komfort-Verlust dest Starmenüs gab es bis jetzt keine Probleme. Sie ist auch problemlos umkehrbar indem System/TI in die Sicherheitsgruppe mit Write-Zugriff aufgenommen wird und dann alle Anmeldungen bis zum entfernen aus der Gruppe die Apps wieder installiert bekommen und installiert bleiben. Den Probleme mit den Nutzerprofilen/Startmenü geht man auch gleich komplett aus dem Weg. Auch die Firewallregeln auf Benutzerebene können dann nicht automatisiert durch Windows oder sonst einem Programm erstellt werden, was mir eh komplett gegen den Strich geht da nicht beinflussbar wohin kommunziert werden darf (z.Bsp. Cortana mit seinen ganzen Indexdaten). In Zukunft kann es aber vielleicht Probleme bei MS-Software geben wenn Sie auf die Indexdaten von Cortana zurückgreifen möchte oder SQL/Exchange auch damit verzahnt wird usw. Aber bis dahin gibt es vielleicht auch von MS wieder bessere Einstellungsmöglichkeiten.

Soeben mal eine gute Nachricht gelesen, Ribbons verschwinden vielleicht wieder. https://medium.com/microsoft-design/m365future-815cf30a8be Man glaubt es kaum, aber die haben endlich auch bemerkt, dass die Produktivität massiv gelitten hat seit der Einführung dieser Ribbons. Schwarzer Schnee im Sommer... Warum die nicht einfach richtig Back to the Roots gehen und simple, gleiche Menüs wie zu Zeiten von Office 2003 verwenden verschliesst sich mir allerdings. Zwar vielleicht nicht identisch hübsch, dafür Straight-Forward und mit der Zeit hat man die täglichen Abläufe per Tastur evtl. in Kombi mit der Maus völlig automatisiert verinnerlicht statt dem ewigen rumgeklickere. Aber mal sehen, vielleicht wird ja die adaptive Menüführung sogar ganz gut oder es dauert weitere 10 Jahre bis der Office 2003 Standard wieder aktiviert wird und als Neuheit verkauft wird. =)

So habe das mal heruntergeladen und testweise installiert. Das File hat MS tatsächlich falsch benamselt. Die Build ist immer noch 1809 und nicht wie das file suggeriert 1909.

Danke für die Antworten. @zahni: Jahr klar, die Unterschiede zwischen SAC und LTSC sind mir schon bewusst. Von SAC halte ich möglichst immer die Finger fern. Egal ob Client oder Server. Bei Server bin ich produktiv noch überall bei 2012R2. Mich stört immer noch das komplette Desktop-Experience und Core finde ich zu mühsam, aber das ist ein anderes Thema. Nun heisst im LTSC-Bereich - also jenem mit der Jahreszahl 2019 - das eine File eben 1909 (April 2020) und nicht 1809 (April 2020). Das vom Juni heisst 1809. Normal wird hier so alle paar Monate die aktuellsten Updates eingespielt und neu veröffentlicht. Zwei Versionen sind meist online, auf die älteren hat man keinen Zugriff mehr. Vermutlich muss ich einfach mal downloaden, den Installer starten und schauen ob als Build dann wirklich 1909 hinkommt oder ob einfach der Filename ein Flüchtigkeitsfehler war und es ganz normal 1809 ist.

Hallo Zusammen, Eigentlich sollte ja 1809 der aktuelle "Windows Server 2019" als LTSC release verfügbar sein. Wenn ich aber aktuell im Downloadbereich naschaue, bekomme ich bei "Windows Server 2019" eine 1909 (Stand April 20) und eine 1809 (Stand Juni 20) Version präsentiert. Ist das ein Schreibfehler seitens MS und es wäre beides 1809 oder haben die tatsächlich eine 1909er zusätzlich als LTSC Version freigegeben? Unter "Windows Server" als SAC release ohne Jahr kommen wie üblich die verschiedenen Versionen. Grüsse und Danke für eine Info

Das ist nicht ganz trivial, auch z.Bsp. in Thunderbird nicht =) 1. Es hat damit zu tun wie das E-Mail daherkomm (Outlook bzw. RTF, HTML, Reintext) 2. Was eingestellt ist als Standard-Erfassungstyp (Outlook bzw. RTF, HTML, Reintext) 3. Wie geändert wird, also wo man zbsp. den Zeilenwechsel einfügt. Am Anfang, am Schluss oder mitten in der Zeile. Teilweise auch wie viele man einfügt. Grundsätzlich ist es empfehlenswert HTML oder Reintext als Erfassungsstandard zu nehmen, weil dann alle Mailclients damit klar kommen. RTF kann meines Wissens ausschliesslich Outlook. Blöderweise nimmt Outlook das als Standard. Ist ja auch quasi-Standard. =) Wenn aber eine E-Mail als Outlook-RTF daherkommt, ist eben die Basis der Message (nicht die Formatierung) Outlook-Standard und somit reagiert es nicht mehr identisch. Was genau wann in welchem Programm auslöst wird habe ich zwar mal aufgeschrieben, aber das habe ich verloren und dann die Mühe nicht mehr gemacht. 100% beeinflussen kann man es nicht. Viel geholfen ist schon, wenn der Standard-Erfassungstyp vorgeben wird (HTLM oder Reintext), dann reagieren wenigstens alle gleich beim gleichen Nachrichtenformat.

Bei Click to Run musst Du das Paket händisch bereitstellen. Also nichts mit schick automatisiert wie mit WSUS. Sprich manuell jeden Monat das Image bei MS holen. Soweit ich mich erinnere, konnte man aber den Pfad zu den Installfiles via GPO verteilen. Ein Problem ist auch das Logging weil man eben keine Oberfläche hat wem was fehlt wie in WSUS. Du hast also keinen wirklichen Plan über die Update-Stände. Habe das selber nur mal im LAB durchgespielt, kann also keine Details über allfällig Stolpersteine sagen und andere Widrigkeiten sagen.

Schau, am Ende kann man viel machen. Sinnvoll ist das meiste nicht und alles was seltsam daherkommt in der Regel auch illegal. Verwende einfach offizielle Vertriebskanäle und fertig. Weder abkratzen von Keys noch der Erwerb von reinen Keys gehört dabei zu den sinnvollen Varianten. Pro Lizenzen sind aber sowieso so billig das sich keinerlei Ärger lohnt. Allerdings reichen die eben je nach gewünschtem Szenario nicht aus. Eigentlich möchte man gar keine Pro-Versionen im Unternehmensbereich einsetzen sondern eben Enterprise. Also wird eh eine Upgrade-Lizenz für einen physischen Computer fällig oder aber eine der mittlerweile zahlreichen Mietvarianten für Windows und/oder Office. Am besten sagst Du was Du vorhast und jemand wird Dir erklären wie Du es lizenzieren musst. Zu 7: Dafür gibts die Tesversionen bei MS direkt

Für Einzelplatten muss bei richtigen Controllern eigentlich immer ein Volume oder eben RAID 0 mit Einzeplatte (im Endeffekt +-das gleiche) erstellt oder aber eine HBA Firmware geflasht werden. letzeres geht nicht bei allen.

Die W10 2004 kam ja gerade raus, ist aber noch nicht für alle freigegeben. Die Stable-Releases kommen tendenziell aber eher im Herbst. Bezüglich Office: Immerhin ist Office Pro Plus 16 noch ~5 Jahre im Support. So lange dürfte man +- Ruhe habe (gleich lang wie 19).

Die ganze Update-Geschichte ist mittlerweile extrem undurchsitig geworden. Manche Hardware-Konfigurationen von PC's verhindern gewisse Updates. Bei manchen wohl auch einfach nur ein falscher Treiber. Dann wird nicht alles komplett gemeinsam an alle ausgerollt sondern gestuft. Das gibt dann im Endeffekt noch viel mehr Wildwuchs als man mit dem ganzen Update-Zwängerei mal verhindern wollte. Kombiniert mit der hundsmiserablen, quasi nichtvorhandenen internen Updateprüfung gibt das wahrlich erstklassige Ergebnisse. Ich könnte teilweise echt nur noch kotzen mit den ganzen Eigenheiten. Aber wir waren ja auch fast 15 Jahre verwöhnt mit WSUS. Jetzt ist es wieder ganz wie in alten Zeiten mit W95 und NT 3.5. Irgendwann - vielleicht in 10 Jahren - kommen die dann wieder zur Erkenntnis, das Updates vielleicht besser geprüft werden sollten und neue Releases vielleicht auch wieder länger dauern könnten und den Business-Usern vielleicht etwas mehr Freiheiten gegeben werden soll und der Fokus eher auf die Stabilität gelegt werden sollte. Privat-User können ja demnächst nichtmal mehr Updates aufschieben. *kopfschüttel* Ich freue mich demnächst die ersten Workstations mit CPU's der Generation 10 mit LTSC zu füttern. Habe mich ja lange gesträubt, aber jetzt steht so ein Ding hier das ich demnächst ausliefern muss. Hatte noch keinen Nerv dafür. Keinerlei Treiber für Chipsatz und Grafik als Download-verfügbar, nur über den unsäglichen Store den ich normal überall abschalte und bei LTSC gar nicht vorhanden ist. Sprich die Treiber gar nicht ins System kommen können. Weltklasse. Wieder irgendwas zusammenfrickeln. *kopfschüttel*

Alternativ: Vorher nacher ein RegShot und vergleichen. Dann siehst wohin was geschrieben wurde. Vorteilhaft ist dafür eine Maschine welcher man möglichst viel des Trackings abgewöhnt hat. ;)

Kenne das aus dem Industriebereich. Viele Hersteller wollen in erster Linie Ihren eigenen Kram haben weil es so definierte Bedingungen gibt und möglichst wenig "Reinfunkt-Potential" gibt. Einige sind aber in solchen Punkten einigermassen flexibel, wenn man darlegen kann, dass man es auf andere Weise vielleicht besser machen kann. Bei manchen gibts halt schlicht keinen Support wenn die Bedingungen nicht exakt so sind wie vorgegeben. Erfahrungsemäss liegt aber bei vielen - auch wenn sie einsichtig waren - jedes Problem erstmal immer daran, dass eben nicht ihre Standardbedingungen herrschen. Egal wie absurd es ist. Dein Kunde wird dann immer erst hören, dass Du das Problem bist. Die erste 30-60min Support gehen dann für die Beweisführung drauf. Mittlerweile bin ich soweit, dass ich nach Möglichkeit abgeschottete Inselsysteme nach Ihren Vorgaben erstelle wenn einer für mich unerklärliche Bedingungen hat und diese auch nicht erklären kann. Spart viel Ärger. Also soweit möglich vollständig abgeschottet und ein System als Bindeglied. Kostet halt etwas mehr, dafür ist Ruhe im Karton. Wird nur immer mühsamer und aufwendiger mit den ganzen Integrationen andere Systeme, Fernzugriff etc. Dazu dann Firewall-Logging der Windows-Firewall um zu sehen wie die Kommunikation effektiv abläuft. In allen Variationen. Also Fernzugriff, Kommunikation untereinander etc. abläuft. Dann schotte ich die Systeme per Script ab (Firewall) und erstelle gleichzeitig ein Gegenscript um alles rückgängig zu machen. Gleichzeitig Scripts um Fernzugriff zu aktivieren/deaktivieren --> Firewall-Regeln In/Out. So gibts dann wenigstens minimale Sicherheit.

Die Frage dürfte lauten wie man mit dem neuen Zeugs sinnvoll Einstellungen treffen kann. Zu gegebenen Zeitpunkt ist das nicht möglich. Es ist einfach völlig bescheiden gelöst. Dazu langsam und ineffizient. Eine excellente GUI mit ein paar Schwächen - auch grundlegenden - wird abgelöst durch immer mehr Schwachsinn und Bling Bling die kein Mensch zum arbeiten braucht.

Die sicherste Variante wo alles weg ist? --> Dism.exe und die Pakete von Cortana etc. entfernen. Etwas weniger martialisch und Reversibel: Firewall-Ordner der Registry sperren bzw. System/TI etc. den Schreibzugriff in der Registry entziehen und einer speziellen Firewall-Admin-Gruppe erteilen. Die Folge davon ist, dass die vorinstallierten Apps auf Benutzerebene nicht installiert werden, da das Fehlschlagen der Installation der (imho) unsäglichen, automatisierten Firewall-Regeln auf Benutzerebe zu einer Exception führt und die Apps nicht installiert werden bzw. vermutlich ein Rollback passiert. Der Desktop selber funktioniert nach wie vor einwandfrei, aber Startmenü, Taskleiste, Reminder etc. ist Geschichte. Dafür werden viele Write-IO's eingespart und viel weniger Daten gesammelt. =) EDIT: Um es wieder zu aktivieren Schreibzugriff wieder erlauben und die betroffenen Profile löschen. Dann werden Sie neu erstellt und alles funktioniert wieder wie gehabt.

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.