Jump to content

Weingeist

Members
  • Gesamte Inhalte

    1.566
  • Registriert seit

  • Letzter Besuch

Alle erstellten Inhalte von Weingeist

  1. Im Grunde gibt es ein paar Grundsätze und dann sollte es (wieder) funktionieren. Habe jetzt mehrere Umgebungen aktualisiert und eigentlich spielt es gar nicht so eine Rolle ob es RDS oder andere Maschinen sind. Bei RDS ist nur das Verhalten auffälliger weil ebene deutlich mehr Köche den Brei verderben können und oft auch tun. Das Problem ist übrigens kein reines 2019 oder 2022 Problem, auch 2012R2 oder neuere Windows Clients zeigten dieses Verhalten. Manchmal ist es schlicht Zufall das es tut bzw. sieht man die Logik dahinter nicht oder nicht auf Anhieb warum es tut oder eben nicht. Das wichtigste überhaupt: Verbinden ausschliesslichen über FQDN und nicht über den Computernamen oder gar die IP. Server.domain.suffix\Freigabe Hat man das einmal gemacht, ist das Kind im Grunde in den Brunnen gefallen. Warum ist das ein Problem? Verbindung via der IP-Adresse oder dem Computernamen werden mittels NTLM authentifziert und nicht via Kerberos. Das macht aber nicht nur bei deaktiviertem NTLM Ärger sondern eben auch wenn es noch aktiv ist. bei Netzwerkdruckern/Laufwerken kann das auch sonst reinpfuschen. Es gibt aber auch die andere Variante, trotz deaktiviertem NTLM findet eine Fallback statt und eine Verbindung kann aufgebaut werden. Aber nicht immer zuverlässig und meist grottenlahm. Wieso das geht, verschliesst sich mir. Wie verhindert man das effektiv? Keine Ahnung Was wenn der Ärger schon passiert ist oder die User eben selber verbinden? Mühsam Wie löst man es? Siehe unten =) Prävention: Verknüpfungen auf Printserver / Fileserver in die öffentlichen Dokumente ablegen. Logischerweise als FQDN Sprich ich spekuliere darauf, dass die Leute zu faul sind, selber etwas einzutippen. Das funktioniert hervorragend. Zusätzlich verbinde ich die normalerweise benötigten Drucker per Login-Script. Ob man das pflegen möchte ist jedem selbst überlassen. Meine Umgebungen sind klein, Arbeitsplätze meist fix und die GL jeweils faul, daher automatisiere ich das. Je grösser und je weniger fixe Arbeitsplätze desto aufwendiger. Aber auch mehr Manpower vorhanden. Netzwlaufwerke versuche ich zu vermeiden, ist in der Industrie aber nicht immer möglich weil Software nicht mit UNC klarkommt. Dann sollte man das Rendering dem Printserver überlassen. Ich deaktiviere Client Side Rendering für Netzwerkdrucker. Den Tipp mit den generischen Treiber kann ich bestätigen. Und mit richtigen Business-Druckern hat man generell viel weniger Ärger mit Printern. Angenommen man hat nun also den Ärger: Abhilfe bringt hier alle Druckerverbindungen in der Registry zu löschen. Systemweit wie User-basierte. Wo die Orte sind, findet man per Registry Suche nach einem alten Drucker bzw. dem Printservernamen raus. Manchmal auch via der IP(s). Auch die Anschlüsse der Drucker sollten/müssen auf die FQDN lauten. Diese werden ja oft nur einmalig erstellt, da hilft es dann nicht zwingend wenn man per FQDN verbinden möchte, der Anschluss aber als IP oder Computername hinterlegt ist. Hier liegt manchmal auch der Hund begraben wenn das vermischt wird. Wie auch immer das möglich ist, jede Kreativität konnte ich nicht nachstellen, aber so manches angetroffen und manches wohl auch durch mich verschuldet, insbesondere in älteren Umgebungen wo das FQDN-Thema noch nicht ganz so verbreitet war. Daher nach den IP-Adressen suchen und allfälige Anschlüsse rauswerfen wenn sie nicht schon andersweitig gelöscht wurden. - die Auflistungen unter HKLM\System\CurrentControlSet\Control\DeviceClasses die Einträge enthalten *##?#SWD#PRINTENUM#* - die Auflistungen unter User: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Providers\Client Side Rendering Print Provider\UserSID\Printers\Connections\Printername - die Auflistung unter: HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Print\Providers\Client Side Rendering Print Provider\UserSID\Printers\Connections\ - \HKEY_USERS\.DEFAULT\Printers\ConvertUserDevModesCount - \HKEY_USERS\UserSID\Printers\ConvertUserDevModesCount Und dann gibts noch Herstellerabhängige Einträge. Die müssen manchmal auch möglichst alle raus. Vorgängig Treiber rauswerfen verhindert potentiellen Ärger bzw. stellt sicher, dass die Einträge wieder neu angelegt werden. Was mir mal aufgefallen ist, als alles nichts half (ältere Umgebung): Der Treiber muss wohl via einem Admin-Konto erstmalig auf die Maschine gelangt sein. Ist dem nicht so runterwerfen, Registry cleanen und den Drucker erstmalig mit einem Local-Admin verbinden. Auf alle Fälle habe ich es bis jetzt noch nicht erlebt, das man den Printserver oder das Printing mit V3-Treiber nicht wieder sauber zum laufen bekommen hat. Da meine Umgebungen immer recht überschaubar sind und das ganze sobald man weiss was man beachten muss, normal recht schnell durch ist, habe ich dazu noch kein Clean-Script geschrieben. Ist auch nicht immer ganz trivial wegen der vielen Orte wo das hin kann und GUID's die man allenfalls nicht kennt usw. Vielleicht hat ja mal jemand die Zeit und Musse dazu.
  2. Och, das Netz ist voll von Ärger die NLA betreffen. Entweder schraubt MS da immer dran rum oder das Teil "erarbeitet" sich irgendwelche Werte auf deren Basis es dann zukünftige Reaktion macht. Oder es ändern sich Bedingungen die zu unterschiedlichem Verhalten führen. Ich sage ja, es wäre äusserst hilfreich wenn jemand eine Doku zu NLA besorgen könnte. Die Reihenfolge der Netzwerkadapter inklusive der ausgeblendeten spielt wohl auch irgend eine Rolle. Hatte es vor Jahren in einer Umgebung vollständig im Griff. Ohne jegliche Scripts, verzögerung des NLA-Starts etc. Dann kam das VMXNET3 Adapter Update welche alle Netzadapter gelöscht und neu installiert hat (inklusive neuer MAC's war "interessant"). Danach reagierte die Umgebung identisch wie alle anderen. Überreste vom alten Adapter verblieben damals in der Registry. Auch die Wartungsadapter von z.B. der Intel ME scheinen einen Einfluss zu haben. Wie auch immer, es bleibt für mich zu undurchsichtig. Daher habe ich es aufgegeben. Und das einzig zuverlässig ist das Deaktivieren/aktivieren der Netzadapter oder ein anderweitig angestossenens "Update" des Netztadapters wie das "aufwachen" oder sofern möglich "ipconfig /renew". Schön wärs wenn man ein Update bei fixen IP's anstossen könnte ohne den Adapter zu deaktivieren. Noch schöner wenn man das Verhalten schon vor dem Start beeinflussen könnte. Alle Maschinen die es nämlich von Haus auf können, haben z.B. die Computerrichtlinien-GPO's innerhalb 1-2 Sekunden verarbeitet, bei den anderen dauert es so 5-10 Sekunden. Gleicher Host, gleiche Hardware-Version, gleiche Netzwerkkarte.
  3. Ob ein Cluster wirklicht läuft / funktioniert siehst Du erst, wenn man einen Failover oder geregelten Umzug macht/machen musst. Vorher geht man davon aus, das es so ist. Auf welcher Grundlage auch immer man das entscheidet. Um wie viele VM's gehts den überhaupt? Der VM ist der Unterbau ja grundsätzlich egal solange sie wieder die Ressourcen bekommt die sie benötigt. Warum nicht zwei Maschinen in das neue Cluster und alle VM's migrieren? Allenfalls kalt statt warm? Mit einem Cluster-Spezi? Kleiner Anhaltspunkt: Viele Tools die Maschinenübergreifend agieren funktionieren nicht richtig wenn man Remote-Registrierung oder Remote-Verwaltungsdienste nicht laufen oder entsprechende Firewall-Freigaben fehlen. Natürlich kann man auch pedantisch die Firewall-Regeln/laufende Dienste zwischen den Servern abgleichen. Auch DNS ist immer wieder ein Klassiker für sehr vieles das nicht richtig tut. Ansonsten: Aktiviere mal das Firewall-Auditing und erstelle eine gefilterten Ausgabe für Packet-Block im EventViewer. --> Wird in Security geloggt, dann siehst was nicht ankommt/rausgeht. Relevante Nummern: 5152, 5157 Englisches OS: auditpol.exe /set /category:"Object Access" /subcategory:"Filtering Platform packet drop" /success:enable /failure:enable Deutsches OS: auditpol.exe /set /category:"Objektzugriff" /subcategory:"Filterplattform: verworfene Pakete" /success:enable /failure:enable Sprachübergreifend: auditpol.exe /set /category:"{6997984A-797A-11D9-BED3-505054503030}" /subcategory:"{0CCE9225-69AE-11D9-BED3-505054503030}" /success:enable /failure:enable Die Protokollgrösse würde ich auf mindestens 64MB (65536) hoschrauben eher das Vierfache. Mit - tasklist /svc - netstat -a -b Kann herausgefunden werden welcher Prozess es betrifft der allenfalls Freigaben braucht.
  4. NLA startet man aber nicht (mehr) ohne so weiteres durch. Ist mittlerweile ein geschützter Dienst bei neueren Builds. Den kannst nur mit taskkill und entsprechenden Berechtigungen zur Aufgabe zwingen. Starten tut er wieder selbst. Ob das aktuell immer noch so ist oder ob das wieder geändert wurde, habe ich schon ein weilchen nicht mehr getestet. Ansonsten hilft in der Regel folgendes vorgehen: Fixe IP: Adapter deaktivieren/aktivieren den man zum Update von NLA zwingen will Dynamische IP: ipconfig /renew reicht aus. Also auch für einfache Benutzer machbar. (allenfals Adapterspezifisch) oder eben auch Adapter Aktivieren/Deaktivieren. Letzteres seit geraumer Zeit nicht mehr 100% zuverlässig, warum, keine Ahnung. Meine Scripts mit Aktivieren/Deaktivieren funktionieren jedenfalls nicht mehr zuverlässig. Was wohl nachhaltig gegen NLA-Ärger hilft: Komplette Neuinstallation mit aktueller ISO und integrierten Updates von MS. Meine neueren Installationen machen jedenfalls keinen Ärger. Oder noch nicht Die ganzen Tipps bezüglich passive/active probing sind fast immer für die Tonne bei neueren Builds. Am besten funktionierts mit Werkseinstellungen und allenfalls angpassten Zielen für den Connectionstest etc. Was auf meiner Todo-Liste steht: Auswerten was bei ipconfig /renew oder aktivieren/deaktivieren alles an Registry Werten geändert wird. Allenfalls wird da irgend ein Counter hochgestuft welcher von NLA geprüft wird. Wo wir wieder beim triggern wären. Ich bin mir fast sicher, dass es irgend einen WMI-Befehl geben wird, welcher ein Update eines Netzadapters oder sonstigen Entscheidungsgrundlagen für den NLA anstossen kann. Gibts ja für fast alles. Das wäre dann zuverlässig. Ich selber habe leider zu wenig Ahnung von WMI um mich da durchzuwühlen. Allenfalls hat auch der NLA-service versteckte Befehle mit dem man ihn triggern könnte bis anhin bin ich aber nicht auf entsprechende Quellen gestossen. Vielleicht erbarmt sich ja mal jemand mit Connections zu MS um ein Paper zur genauen Funktionsweise von NLA zu erhalten und allenfals Trigger die man manuell anstossen könnte.
  5. Du könntest auch einfach nen WSUS aufsetzen in dessen Netz Du neue Maschinen hängst. Da wirds dann ebenfalls nur einmal gezogen. Mache ich schon Jahre so für die ISO's die nicht von MS aktualisiert werden weil das für mich einfacher ist als ständig ISO's zu pflegen. Nachbearbeitung dann mit nem Script welches über alle Windows-Versionen hinweg funktioniert. Die Konstellation spart mir ne Menge Zeit, die Anpassung an neue Builds sind meist minimal. Für 1000 Clients sicher zu aufwändig, wenn immer wieder für eine oder auch verschiedene Firmen mit wenig Clients notwendig, ist das ziemlich praktisch. Die Anforderungen an die Kommunikation sind minimal. Allenfalls sogar mit Treibern *hust* (Dann ganz sicher mit richtigem SQL-Server und WAM-Script... Wäre zum testen. Mit Business-Notebooks wäre die Chance am grössten, dass aktuelle Treiber vorhanden sind.) Wäre dann das gewohnte "Gefühl" ohne viel Scripten und Imagepflege (die mich angurkt, es sind einfach zu viele). Ansonsten: Du tust Dir tatsächlich die Hersteller-Loads an? Puuuuh das wäre nichts für mich. Dafür habe ich kein Nerv. Die Kisten sind meist sooooooooo viel schneller ohne die ganze Hersteller-Bloatware. Zumal ich nirgendwo Pro haben möchte.
  6. Mal ein kurzes Feedback zum aktuellen Stand. So theoretisch wurde mit dem Oktober bzw. November Update ja eine Menge "geforced" bezüglich NTLM-Deaktivierung. SMB Der Würg-Around mit einer Remote-Authentifizierung via NTLM gegen lokale Konten funktioniert zum aktuellen Zeitpunkt nach wie vor. Auch mit SMB-Hardening-Features. Theoretisch hätte das nicht mehr funktionieren sollen. Zumindest hat es nicht mehr funktioniert wenn man es selber NTLM deaktiviert hatte. Die GPO scheinen also noch zu ziehen. Aufbau: Zwei Maschinen die sich mit DFS-R einen Transfer-Ordner replizieren Maschine 1 (Filer): Verbindung zu DC, Maschine 2, allgemeines Netzwerk, NTLM durchwegs nicht erlaubt Maschine 2 (Relay): Verbindung auf einer Seite zu DC, Maschine 2 sowie dem Maschinennetz, NTLM erlaubt via GPO Da ich NTLM auf dem DC durchgängig geblockt habe (ohne Ausnahmen), scheitern Authentifizierungsversuche mit Domain-Konten gegen den DC via Relay wie gewünscht. Authentifizierung von lokalen Konten gegen das Relay funktioniert hingegen. Die CA Nun die scheint auch weiter zu funktionieren. Warum und wie auch immer die sich authentifizieren kann ohne das eine Ausnahme definiert werden muss. Ist mir immer noch ein Rätsel. Scheint eine hardcoded Ausnahme zu sein. Fazit: Scheint als sei das enforcement nicht durchgesetzt worden seitens MS. Das legen auch ein paar Internet-Recherchen nahe. Angeblich plant MS NTLM noch mindestens zwei Jahre zu unterstützen. Bis sie ihre eigenen Hardcoded-NTLM-Geschichten gelöst haben. Zu guter letzt soll Kerberos wohl aufgebohrt werden damit eine einseitige NTLM-ähnliche Authentifizierung ermöglicht wird. Wie auch immer das sicher gemacht wird. Habe ich mich noch nicht eingelesen. Auch ist wohl ein lokaler KDC auf jeder Maschine in Planung der NTLM auf lokaler Ebene ablösen soll. Naja, immerhin hat MS genügend Angst gemacht, dass man sich vermutlich endlich darum gekümmert hat das möglichst vollständig aktiv abzuschalten wo möglich. Zumindest mir gings so, auch wenn ich nicht 100% damit gerechnet habe weil Basis-Features wie die CA nicht ohne NTLM funktionieren und ein paar grössere Hersteller noch immer tiefenentspannt waren. Aber böse bin ich nicht... dachte die SMB-Relays seien schon dem Tod geweiht und ich müsste die mühsame - dafür sichere - shared disc Geschichte mit eigenem Lock-File weiter ausbauen.
  7. @zahni hmm seltsam. Ich habe in allen Umgebungen immer max 50 Geräte und die WSUS DB dümpelt sehr oft so um die 9-10GB rum. Ist oft ein Eiertanz, total nervig. Daher viele wieder zurück auf intern gewechselt. Aber eben, ist etwas fragwürdig da nie ein CU gefragt wird und auch manuell keins installierbar ist. Aber oft halt einige Office/Windows Versionen. Clients wie Server. Industrie halt, da gibts meist alles irgendwie und irgendwo. Vielleicht sagt sich MS: Man kann bei internen DB eh nix via LAN abfragen, also unnötig. Wenn jemand auf die Maschine drauf kommt, ists eh gelaufen. Keine Ahnung. Die interne DB lässt sich schon länger mit den Tools administrieren nur sind manche Tweaks nicht machbar, sonst schiesst man die interne DB ab weil eine Überprüfung seitens MS fehlschlägt. In kleinen Umgebungen kann man damit aber leben. Die restlichen Tweaks von WAM reichen da aus.
  8. Performance oder Sicherheitsgründe weil sie nicht wirklich Updates erhält? Die Express-Variante ist schon mit wenigen Clients recht schnell am Anschlag. Ist immer ein Riesentheater mit der DB-Grösse, man bewegt sich quasi immer am Limit wenn man nicht wirklich nur eine OS/Office Version hat. Kam eigentlich davon weg und habe (wieder) interne genommen nachdem ich vorher jahrelang Express genommen habe.
  9. Kannst auch einfach schauen obs läuft... Nur weils noch nicht supported ist, heisst es nicht, dass es nicht läuft. Wenn Du Pech hast, gibts halt irgendwo Ärger. Kommt etwas auf die Anzahl Arbeitsplätze an die betroffen sind und wie sehr es den Betrieb stören würde, wenn es Ärger macht. In einem Callcenter würde ich das nicht machen, im Büro mit 10 Nasen schon. ;)
  10. hahaha, spasseshalber schonmal versucht er weiss es natürlich nicht. Karl Klammer war wenigstens noch etwas lustig und nicht nur unnütz Naja ganz Unnütz ist dieser hier nicht, solange er nicht intelligent werden will. Sprich eigentlich würde ich ja vor allem die Option "Intelligentes Nachschlagen" und das Popup der Hilfe weghaben wollen weil ich das eh nur aus versehen anklicke und dann wieder schliessen muss.
  11. Unabhängig von dem Sinn oder Usinn: Funktionen kann man auch deaktivieren. Das benötigte Stichwort ist: Fluent User Interface Control Identifiers Man erhält einen Download bei MS mit einem Excelfile pro Applikation. Jedes Control hat eine ID, diese kann man in den GPO's eintragen als blockiert. Die meisten sind Programmübergreifend, aber nicht alle. Ist manchmal nur etwas mühselig das Gewünschte zu finden. Hätte z.B. gerne die ID für "Was möchten Sie tun" und konte ihn noch nie auffinden.
  12. @mwiederkehr Naja, im Grunde gibts das alles. Sofern Du dich mit den Prepare-Tools abmühst oder die entsprechenden Reg-Flags zum passenden Zeitpunkt manuell setzen tust... Ist halt immer wieder fällig oder aber du automatisierst es mit dem Wissen, dass es bei der nächsten Build wieder anders sein könnte. Wenn Du kein Bock hast immer die ISO's / XML anzupassen reicht es oft, wenn Du ein Script mit den entsprechenden Einstellungen in die ISO reinkopierst, im richtigen Moment mit Shift+F10 die Konsole öffnest und das Script ausführst. Das ist dann sogar fast immer Build und Server/Client OS übergreifend funktionsfähig. Je nach Option halt. Aber ja ich bin bei Dir, ich gehe davon aus, dass 99.9% aller Admins exakt die gleichen Einstellungen treffen würden was Deine angesprochenen Punkte betrifft. Ungefähr so wie mit der elenden Explorer-Ansicht die man seit gefühlt W95 mühsam in den Default-User bringen muss. Ab einer gewissen Grösse sind solche Scripte sicher zu mühsam. Aber im kleinen ist das oft einfacher als die ISO für jede OS-Art und jeden Kunden jedes mal anzupassen. Aber ja ich bin absolut bei Dir. Ich habe im Industriebereich auch schon Server statt Client OS eingesetzt. Insbesondere seit LTSC nur noch 5 Jahre hat. Die paar hunderter Differenz zwischen Pro+Upgrade mussten sie einfach schlucken. Dafür alles recht flexibel. Mittlerweile aber auch gerne IoT LTSC.
  13. Geht irgendwie in die gleiche Richtung wie mit dem Edge... man drückt es mit Gewalt durch, auch wenn er deinstalliert wurde und stellt es dann so dar als wäre das von allen so gewollt Irgendwie traurig, dass man dies auch im Server-Bereich nötig hat Aber vielleicht waren es ja tatsächlich ein paar Grosskunden die das gewünscht haben damit sie weniger Arbeit haben. Wobei die wiederum die Tools und das Knowhow gehabt hätten das problemlos zu automatisieren. Ich tippe mal auf möglichst viele dazu animieren...
  14. Eine solche Karte wie Du es vorhast einzusetzen würde ich grosse Abstand nehmen. Hat nichts verloren in einem Server. Eigentlich nichtmal in einem Privatsystem. Du hängst quasi Deine ganzen Produktiv-Daten an eine einzelne Karte von einem Günstig-Anbieter. Wenn Du etwas mehr Flexibilität als von HP, Dell etc. willst, kauf einfach von Supermicro. Da gibt es eigentlich alles was man möchte. Auch als Komplettsysteme, mittlerweile sogar mit Wartung. Ich mag deren Systeme weil man hochwertigste, flexible Single-CPU Systeme zusammenstellen kann wie das bei den anderen in der Vergangenheit nicht möglich war. Dazu noch ohne Vendor-Lock. Das Zubehör hat moderate Preise und nicht Faktor 2-3 mit Vendor Lock um es durchzusetzen. Nimm am besten U.2 Systeme mit direkter PCI Express Anbindung.
  15. Nachdem der September einigermassen ruhig war, schiessen die mal wieder den Vogel ab... Mit Feature-Upgrades die jeder ungefragt installiert haben möchte Recht müsant geschriebener Artikel zum Thema (Englisch): https://www.c-amie.co.uk/technical/azure-arc-setup-installs-and-launches-at-log-on-after-october-2023-kb5031364-on-windows-server-2022/ Jemand schon einen Plan wie man die Installation des Features verhindern kann? Habe nix dazu gefunden... Ist irgendwie nervig, Am Ende darf man das jeden Monat machen *grummel* Naja, wenigstens sonst nicht so viel Ärger... Der wird voraussichtlich nächsten Monat kommen wenn die Timelines eingehalten werden =)
  16. Wie so oft gibt es da verschiedene Ansätze. Die Fragen die man sich hier stellen muss sind bei jeglicher Automation immer die gleichen. Egal ob Produktion oder IT. Manchen Aufwand holt man zwar objektiv gesehen nie rein, der Alltag ist aber z.B. für die Mitarbeiter weniger stressig, die Fehlerquote tiefer, weniger Ressourcen werden vergeudet oder man sammelt einfach nur Cookie Points bei den Mitarbeiter (Aus Sicht der IT, des Chefs etc.). Bei statischen Arbeitsplätzen wie Produktion, Lager oder automatisierten/definierten Prozessabläufen lohnt sich eine Automatisierung imho immer. Die Verkäuferin im Supermarkt verbindet ihren Kassenzetteldrucker auch nicht selbst. Der grosse Vorteil ist, dass man Bereinigungen für falsch verbundene Drucker, nicht mehr vorhandene Drucker, Umstellung auf FQDN, verschiedene Standortermittlungsverfahren (Thinclients mit denen sich auf die eigene VM verbunden wird, Zeroclients, Files etc.) mit in ein zentrales Script einfliessen lassen kann. Alles im grunde recht Primitiv aber wirkungsvoll. Die Druckerliste selbst kann ein Textfile sein, welches z.B. jemand aus der Abteilung pflegt. Ein richtig oder falsch gibt es lediglich WIE man die Drucker verbindet und da ist die primitivste Variante auch heute fast immer noch die beste (rundll32). Das Ob hängt von der Umgebung ab. Ein vollautomatisches Beispiel: Eine Betriebssoftware haben wir so angepasst, dass alle Drucker darin gespeichert sind und die ID's der Fächer mit den jeweiligen Papiertypen verküpft werden. Was nicht verknüpft ist, landet auf dem Mehrzweck mit einer Bestätigung am Screen, dass man das Papier eingelegt hat bevor der Druck rausgeht. Pro Abteilung. Die Software ermittelt den Standort des Clients und wählt das Standard-Preset aller Drucker der Abteilung aus. Der User kann die Ziel-Abteilung manuell ändern. Er wählt nie einen Drucker aus, er wechselt nur die Zielabteilung für den Ausdruck wenn das gewünscht ist. Die Drucker werden von der Anwendung verbunden. Wird ein Drucker ersetzt, müssen meistens lediglich die ID's der Fächer und allenfalls der Name angepasst werden, bleibt der Hersteller identisch, nichtmal das. Minimalster Administrationsaufwand. Das ganze war einmal aufwändig und wird nun seit bald 25 Jahren verwendet. Der Aufwand wurde schon längstens reingeholt. Nur die Ermittlung des Standorts musste teilweise modernisiert werden als VM's hinzugekommen sind welche mit dem Mitarbeiter mitgehen. Da haben wir dann die Session-Daten aus der Registry ausgelesen. Andere Software löst das teilweise mit einem zentralen Druck-Management auf einem Server, in diesem Fall war das so einfacher und vor allem ohne eine zusätzliche Software mit einer vergleichsweise einfachen Änderungen möglich. Dann gibt es noch ein ganz praktisches Admin-Problem. Die meisten händisch von Usern verbunden Drucker werden via NetBios Namen und nicht via FQDN verbunden. Das gibt spätestens wenn die ganzen Security Flags der letzten Monate enforced werden viel Spass. Ist einigermassen gruselig das aufzuräumen. Kann natürlich geschult werden, aber es dürften noch sehr viele Drucker falsch verbunden sein. ;) Mal ganz unabhängig von den Druckern, es gibt keinen einzigen vernünftigen Grund, dass man ein Domain-Admin Konto zum verbinden von Druckern hernimmt. Auch nicht für die Administration von Clients. Nicht mal zum testen. Der Domain Admin ist eigentlich rein für die Administration des DC's da. Egal wie gross die Umgebung ist und sollte so weit weg wie möglich von allem sein was mit Druckern zu tun hat. Das hinzufügen von z.B. einer Domänen-Client-Admingruppen zur lokalen Admingruppe der Clients kann man sehr easy mit GPO's steuern. Und gleichzeitig mit GPO's verhindern, dass sich Domain oder andere Server-Admins auf Clients verbinden.
  17. Kannst Du so sehen, ist aber nicht so. 2-Knoten Cluster gibt es vor allem wegen Zweigniederlassungen von Grossfirmen. Ansonsten würde es das Konstrukt vermutlich gar nicht erst geben. Und auch da nur wegen den Kosten. Ein zuverlässiger Cluster-Aufbau funktioniert nur wenn mindestens zwei Parteien gemeinsam entscheiden, dass ein dritter Beteiligter nichts mehr zu melden hat. Wenn es nur zwei Beteiligte gibt, ist das nicht zuverlässig möglich, es könnte sein, dass beide Nodes gar nicht tot sind, sondern einfach die Verbindung zwischen Ihnen. Dann sind beide der Meinung, dass sie zuständig sind. Dann kracht es zuverlässig. Dafür braucht es entweder mindestens ein zusätzliches, vollwertiges Mitglied welcher gemeinsam mit einem anderen Miglied entscheidet wer nun Chef ist bzw. ausgegrenzt wird. Oder eben eine dritte Partei die zwar Stimmrecht hat, selber aber sonst nichts zum Cluster beiträgt. Das ist ein Zeuge. Reine 2-Node können zwar teilweise erstellt werden, technisch sinn voll ist es aber nicht. Dann ist noch ein Single-Node Cluster sinnvoller, wenn man gewisse Funktionen haben möchte, die es Standalone nicht gibt (Read Cache für grössere Dateien zum Beispiel). Der weiss dann immer, dass er der Chef ist. Die meisten denken mit einem Cluster bekommen sie eine höhere Ausfallsicherheit. Sehr oft erreichen sie genau das Gegenteil. Damit ein Cluster in der Realität eine höhere Uptime hat als eine einzelne Maschinen braucht es A Knowhow und B muss die technische Einrichtung dafür stimmen. Ansonsten ist die Ausfallwahrscheinlichkeit immer höher und die effektive Uptime tiefer. Verursacht durch Stromausfälle, fehlgeschlagene Updates, fehlerhafte Manipulation an LAN-Kabel, nicht geplante Reboots usw. die bei Standalone-Systemen wenig bis keine Auswirkungen haben, bei Clustern aber je nach Situation katastrophal sein können und ein Recovery erfordern. Sprich die Infrastruktur muss Top sein, sonst macht das 0,0 Sinn bzw. schadet.
  18. Also wenn es wirklich eine Build vor RTM ist, würde ich zwingend eine aktuellere aus dem VL-Download per Inplace drüber bügeln. Wenn das nicht klappt, tendenziell am ehesten die RTM und danach eine aktuelle Build per Inplace. Das dürfte MS ausführlich getestet haben. Sobald RTM draussen ist, juckt sie die ganzen Pre-RTM eigentlich nicht mehr, die zahlende SA-Kundschaft dürfte aber Update-Support bekommen. 7 Jahre nach Release wirst aber schon zu den zahlkräftigen Kunden gehören müssen =) Dank VM's sind ja solche Übungen easy. Auch wenn ich für so "grobe" Fälle immer auch ein Cold-Clone ziehe und nicht nur einen SnapShot. Ansonsten für kuriose Fälle mal das Online-Update versuchen. Hat schon oft "Wunder" vollbracht wenn die manuelle Installation oder WSUS "überfordert" war. Insbesondere bei älteren Builds wo irgendwelche Update-Abhängigkeiten nicht sauber durch WSUS geschleift werden und somit ein Update bei der Bereinigung aus dem Katalog fliegt. Beim Online-Update passiert das nicht, weil nach dem löschen von SoftwareDistribution der ganze Krempel vollständig neu abgefragt wird. Also allenfalls lokal abgelehnte Updates auch wieder aktiviert sind. Mal ganz unabhängig von den ganzen Reperationslösungen: Warum eigentlich keine sauber Applikations-Migration auf 2022? So nach bald 7 Jahren und zwei neuen Windows Generationen dürfte dieser Zusatz Aufwand akzeptabel sein. Mir ist auch noch keine Applikation untergekommen, die Ärger gemacht hat. (Ausser der Dongle-Kram oder irgendwelche Security-Lösungen, aber das macht auch sonst Ärger) ;) Das ist eine relativ neue Meldung von Windows. Dient als Warnung, dass eben ein solcher Absturz der Applikation das verursachen könnte. Hat aber nix mit einem effektiven Vermutung zu tun, dass ein solcher auch tatsächlich stattfindet. Die tolle neue SystemSettings.exe ist voll mit solchen Abstürzen sobald die User-Dienste mal nicht verfügbar sind. Scheint grässlich programmiert zu sein. Was ein Spass wenn da die Exploits mal kommen. Die Windows-User-Apps kriegen von Windows ja gerne Firewall-Freipässe.
  19. Wenn Du ein wirklich gutes und fortlaufend gepflegtes Script möchtest wäre AJTEK noch eine Überlegung wert. Früher war das Script kostenlos und quasi schon "Gold-Standard" und bügelte auch gewisse MS-Fehler z.B. in den Verkettungen oder OS-Bezeichnungen aus. Heute kostet es einen kleinen Obolus pro Jahr, ist dafür immer sehr up to date. Seither sind meine WSUS-Installationen clean und brauchen im Vergleich sehr viel weniger Platz. Obwohl ich alles an Updates behalte, die mal effektiv gebraucht wurde und nur verwerfe was tatsächlich ersetzt wurde und nicht mehr gebraucht wird. Und das wichtigste, ich muss mich nicht mehr Ärgern Der Pflegaufwand für die WSUS-Server ist quasi gegen 0 geworden und beschränkt sich auf das reine Freigeben/Überwachen. SQL-Express würde ich tunlichst vermeiden. Habe mich selbst Jahrleang damit rumgeärgert. Die DB wächst selbst mit sehr wenigen Clients rasant und mit den guten Scripts recht schnell über 10GB, auch wenn es sich normal immer in der Gegend um die 8-12GB einpendelt wenn man fleissig cleaned. Scheint so das minimum zu sein was es ungefähr braucht. Also entweder Interne DB die - ich weiss es klingt schräg - praktisch keinerlei Sicherheitsupdates seitens MS bekommt oder aber eine Kauf-Version. Zumindest konnte ich noch nie eine SQL-CU über eine interne DB bügeln. SQL-Server hat ein paar Geschwindigkeitsvorteile, auch mit dem AJTEK Script.
  20. Mittlerweile klappt es ja sogar auf Deutsch =) Mal noch eine Frage: Ihr seht das schon auch so, dass die August-Updates lediglich der besseren Protokollierung dienen, wenn man noch nicht enforcen kann oder? Sprich wenn man vorher die Signierung bereits auf 2 (für "immer") stehen hat, braucht es weder die ADMX noch die Protokoll-Flags? Bin etwas faul
  21. Für das nächste Mal, Rechte von Systemprogrammen sollte man im Grundsatz beibehalten und nicht verändern. Sprich CMD oder das Tool deiner Wahl mit den notwendigen Rechten öffnen und dann kopieren damit die korrekten Rechte vorhanden sind. Ausser eben man will sie explizit anders haben. Ansonsten: Mir persönlich gefällt Dein Weg nicht. Windows Defender ist eine Sicherheitskomponente, an der solllte man eigentlich nicht "rumspielen" müssen.
  22. Naja, solange das wirklich so heisst und nicht "%ProgramData%\Microsoft\Windows Defender\Platform\<Version>" bestimmt... Spass beiseite, geht davon aus, dass du Dich vertippselt hast. ;) Wie auch immer, dann weiss ich auch nicht weiter und würde auch nicht ewig dran rummachen. Entweder gibts nen Installer von MS und wenn nicht würde ich einmal neu. Wenn es VM's sind ist es ja easy. Kannst den Kram auch gleich aufteilen. - DC/Filer herunterfahren, Cold Copy der Systemplatte auf die Seite legen (optimalerweise auch die Datenplatte, so für alle Fälle) - Neuer DC, promoten, kontrollieren das alles repliziert wurde, alle FSMO-Rollen übertragen, den alten demoten (allenfalls vorher herunterfahren und schauen ob sich noch alle anmelden können --> Ich mache das jeweils weils eine Sache von ein paar Minuten ist, manche findens unnötig) - Danach vom alten Server die Freigaben exporterieren (Registry) - den alten DC/Filer abschalten - neuen Filer installieren, gleicher Name, gleiche IP, in domäne einbinden - Datenplatte aus dem alten Filer einbinden - Freigaben in die Registry importieren - Reboot Am besten in einem Wartungsfenster machen. Sollte es grässlich in die Hose gehen, könntest immer noch zu Deinem aktuellen Stand zurück indem Du die alten Systemplatte wieder aktivierst. Du könntest natürlich den ehamligen DC auch als Filer ohne die DC-Rolle weiterlaufen lassen und z.B. ein Inplace einer aktuellen Build der gleichen Version drüberbügeln. Dann sollten Freigaben etc. erhalten bleiben und die ganzen Windows-Systemdienste sind wieder zurückgesetzt. Ich persönlich mag es aber nicht, wenn ehemalige DC's weiterlaufen. ;)
  23. Klingt jetzt etwas seltsam aber es gibt ja vieles. Vielleicht ist das Cleanup Script eben nicht so sauber im aufräumen. MS hat beim Defender die glorreiche Idee gehabt, mit jeder Version auch einen neuen Pfad mit der neuen Version zu hinterlegen. Keine Ahnung wozu das gut ist, aber ist so. Die Frage ist, ob das Problem gelöst ist, wenn Du den Pfad des Services einfach manuell auf die neue EXE umschreibt. In der Registry den aktuellen Pfad der EXE eintragen, danach Service starten, allenfalls ein Reboot. Regedit mit erhöhten Rechten starten. HKLM\SYSTEM\CurrentControlSet\Services\WinDefend\ImagePath
  24. Sicher, dass Dir keiner einen Streich spielt? Ich finde es ziemlich schräg weil eine Malware deaktiviert in der Regel nicht die Druckerwarteschlage. Die ist schliesslich ihr Lieblingsziel um auf ein System zu kommen. Ausser dem Updatekram macht der Rest eigentlich ebenso wenig Sinn, dass er durch eine Malware deaktiviert werden soll. Sind jetzt eher die Dienste die man aus Privacy-Gründen deaktiviert. Hast Du allenfalls ein "Privacy-Pseudo-Security-Tuning" Programm installiert? Falls ja bewirkt diese vielleicht so ein verhalten bei Browser oder E-Mail Client Start. Falls nein, klingt das eher nach Schikane-Ware. Bist Du im Bildungswesen tätig oder hast Ärger mit den Lausbuben in der Nachbars***aft? ;) Nur würde ich auch dann platt machen und einmal neu. Ausser Du findest den Verursacher und der steckt Dir, was und wie genau er gemacht hat. Wenn es externe Software war, dann auf alle Fälle platt und neu. Sonstige Vorschläge: - Schau ob Thunderbird nicht per Script statt Verknüpfung geöffnet wird - Deaktiviere mal alle Thunderbird-Dienste und was nicht nach MS aussieht ( Dann Reboot und schauen wie das Verhalten ist) - Überprüfe/Vergleiche die Dienste mit einem anderen PC mit gleichem Patchstand, insbesondere die Triggers und Exe's dahinter - Überprüfe/Vergleiche im Aufgabenplaner die Tasks. Registry oder MMC oder beides, allenfalls gibts da was für Thunderbird - Zur Sicherheit auch das Firewall-Logging aktivieren (auditpol) und Standardmässig Block-Out einstellen, dann schaust wohin alles eine Verbindung aufgebaut wird. Die Überprüfungen kannst auch mit Regshots machen und diese Vergleichen. Vorzugsweise mit System oder TI-Rechten öffnen damit man sicher auf alles Zugriff hat. Das ist alles recht zeitaufwändig und lohnt sich eigentlich nur wenn man wissen will, was da vor sich geht. Auch wenn ich eher zu den Inplace-Gegnern gehöre, könntest eine Iso mit aktuellem Patchstand drüberbügeln. Bei Home/Pro bekommst ja eh immer wieder mal ein neues OS. Also wenn Du bis jetzt keine Probleme hattest, dann wird auch ein weiteres Inplace voraussichtlich keinen Ärger machen. Die Windows-Systemdienste werden damit allesamt zurückgesetzt. Die nachträglich "installierten" müsstest Du selber schauen, dass sie noch in Ordnung sind. Am besten vorgängig alle deaktivieren/deinstallieren. Ebenso die Antiviruslösung.
×
×
  • Neu erstellen...