Jump to content

Weingeist

Members
  • Gesamte Inhalte

    1.566
  • Registriert seit

  • Letzter Besuch

Letzte Besucher des Profils

Der "Letzte Profil-Besucher"-Block ist deaktiviert und wird anderen Benutzern nicht angezeit.

Fortschritt von Weingeist

Mentor

Mentor (12/14)

  • 20 Jahre dabei! Rare
  • Positiver Einfluss Rare
  • Passioniert Rare
  • Immens engagiert Rare
  • Engagiert

Neueste Abzeichen

157

Reputation in der Community

7

Beste Lösungen

  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 =)
×
×
  • Neu erstellen...