Weingeist

Etwas lästig ist die falsche Zeit aber schon. Und zwar deshalb weil die Ereignislogs in Windows erst korrekt datiert sind sobald die VM sich mit dem DC synchronisiert hat. Bei der Fehlersuche ist das hinderlich, finde ich. Daher wäre eine funktionierende Zeit schon "nett". --> Ich setze sie auf dem Host jeweils manuell bei Fehlersuche, aber so prickelnd ist das auch wieder nicht. Ob es mit einem eigenen phyischen Zeitserver funktioniert, kann ich noch nicht sagen. Mir war das Geld dafür bis jetzt immer etwas zu schade.

Serial-To-Lan: Moxa-Adapter funktionieren immer, schon unzählige verbaut. Lassen sich auf fast jede mögliche Art parametrisieren USB-To-Lan: Hier bevorzuge ich Silex

Dann fehlt irgendwas. Berechtigung oder Beschreibung des Tasks. Löschen und neu erstellen, flicken oder damit leben. ;)

Naja, Linux ist beim mounten und freigeben ja sehr flexibel. Wenn beide Seiten im Endeffekt auf die gleichen Daten zugreifen, sollte das auch für alle transparent und direkt nutzbar sein. Aber wie genau man es umsetzt, kann ich Dir auch nicht sagen. Die Idee eines Linux-Proxy finde ich aber echt klasse, kam mir so noch nicht und ich habe mir schon einige Stunden den Kopf darüber zerbrochen. =) Könnte mir vorstellen, dass nicht mal das Share an sich auf der Linux Kiste liegen muss sondern auf dem Fileserver/DFS liegen könnte zwecks Flexibilität. Wäre für Zugriff auf Freigaben seitens der Maschinen von Vorteil. Wäre eigentlich cool da einen kleinen einfachen Baukasten zu haben. Das Thema mit der Integration der Produktion ist ja mit XP/W7 richtig aufgekommen und jetzt sind diese Systeme alle veraltet. Dann noch einen Tipp um Ärger mit den Herstellern zu umgehen: Original Festplatte ausbauen, klonen, auf die Seite legen. Dann mit dem Klon und den eigenen Einstellungen sowie Einspielung der reinen Sicherheitsupdates weiterarbeiten (Ich nehme dan meist gleiche eine Enterprise SSD, das freut auch die Leute und die Startup-Time der Maschine). Wenn etwas nicht geht und der Support verweigert wird: Originalfestplatte einbauen. Hilft eigentlich immer, ist einfach etwas mühsamer. Aber so habe ich die Sicherheitsupdates immer eingespielt auf den XP/7 Maschinen. Wurde erst mühsamer als MS alle Updates gekoppelt hat.

Drucker löschen ist mit con2prt.exe schon viel schicker. Ein Reverse-Engineering was dieses Teil für Apis aufruft wäre da mal Klasse. Ist das einzige mir bekannte Tool welches ziemlich ordentlich selber aufräumt. Da ich nur kleinere Umgebungen habe, packe ich die alten Drucker auch mal gerne komplett in ein Batchfile welches alle alten Printer einzeln löscht. Das läuft dann auch bei 50 Drucker die theoretisch mal da waren und in einzelnen Profilen noch rumschwirren könnten in ein paar Sek durch. Für grössere Umgebung ist das natürlich unbrauchbar. Bezüglich verbinden: Ich persönlich mag die GPP Zuweisungen nicht wirklich. Die Scripts sind irgenwie "direkter" und zuverlässiger. Letzeres weiss ich allerdings nicht ob es besser geworden ist in den letzten Jahren. Habe das ca. 2011/2012 das letzte mal "versucht" =)

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.