Weingeist

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

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

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

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

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

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

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

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

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

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

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

Also bei .Net3 muss der Pfad "ausführlicher" angegeben werden. Vielleicht hilft es ja auch in diesem Fall. dism.exe /online /enable-feature /featurename:NetFX3 /all /LimitAccess /source:E:\sources\sxs

Mit zwei Variante mit gleichem Verhalten war ich schon in Kontakt. 1. Fehlendes, zwingendes Update das nicht mehr freigegeben ist auf dem WSUS. Das war mal bei einer Windows 8 Maschine. Warum dieses eine Update und die anderen Updates dann nicht als "fehlend" erscheinen weiss ich nicht. Es verhält sich eventuell auch nicht auf jeder Kiste identisch oder aber das zwingend benötigte war abgelaufen. Abgelehnt war es nicht. Den Update-Client habe ich dann sogar manuell hochgezogen, gleiches Ergebnis. Erst die Online-Update-Suche hatte mir das fehlende Stück präsentiert. Ob es solche Updates bei W10 noch gibt, weiss ich nicht. Bis jetzt ist mir da nichts untergekommen. --> Da WSUS 100% anzeigt, Tippe ich auf ein fehlendes Update in Deinem WSUS. Entweder wie von Gulp genannten fehlendes Häckchen. Prüfen kannstes mal mit der Online-Suche. 2. Eventuell gibt es Malware oder ein Bug die ein solches Verhalten auf irgend eine Weise erzwingen kann. Hatte vor Jahren mal eine Windows 7 Maschine die immer 100% vermeldet hat, sich aber weder von WSUS noch von Windows online Update die Updates gezogen hat. In der WSUS-Konsole wurde aber korrekt die fehlenden Updates angezeigt. sfc vermeldete keine Fehler, rücksetzen der Update-Dienste brachte keine Besserung, manuelles einspielen der neuesten Version ebenfalls nicht, Update-Logs wurden auch nicht erstellt. Die Dienste liefen allesamt und der aktuelle Status ging auch korrekt an den WSUS. Entweder war es also eine Malware welche dem Updatedienste ein 100% alles gut vorgaukeln kann oder ein Bug. Auch wenn ich es etwas seltsam finde, dass ein Bug ein 100% erwirken kann und nicht einen Fehler provoziert. Da ich trotz mehreren Stunden Suche nichts gefunden habe, habe ich die Kiste neu aufgesetzt.

IPv6 ist nicht Mist. Probleme liegen auch nicht an IPv6 selbst. Probleme macht diesbezüglich höchstens der ganze IPv4 to IPv6 Gerümpel (Teredo) oder eben fehlerhaften Einstellungen bzw. die Person vor dem Computer. --> Dieses ganze Teredo-Zeugs habe ich allerdings nie komplett verstanden. Bin ich schlicht zu doof dafür. Insbesondere bei der Fehlersuche. Entweder IPv4 oder IPv6 oder eben beides. Aber eben, jedem wie er mag. Die Conclusion: Sehr viele Netzwerk-Probleme wie RDP, Zugriffe etc. lassen sich direkt oder indirekt auf unbedarftes deaktivieren von IPv6 zurückführen. Der wichtigste Punkt ist dabei die Priorisierung des Verkehrs. Windows befolgt immer eine Reihenfolge wie es kommunzieren möchte, führt die erste nicht zum Erfolg, versucht es die nächste Variante usw. Das führt dann zu Verzögerungen. Teilweise läuft man dan sogar in TimeOuts. Aktuell kenne ich nur ein Problem, dass eventuell auf die Deaktivierung von IPv6 zurückzuführen ist, aber sicher bin ich mir nicht, weil ich es auch schon mit IPv6 oder nach Windows-Updates hatte: Bei manchen Rechnern hängt die Netzwerkerkennung und dreht permanent. Erkent also die Domäne nicht. Viele Windows-Services funktionieren, aber eben nicht alles 100%ig. Abhilfe schafft manchmal ein Rescan oft aber nur ein Aktivieren/Deaktivieren des Adapters. Letzeres dafür 100% zuverlässig Ab W8 lässt sich das easy beim Start automatisieren, W7 ist mühsamer, geht aber auch. Anbei eine kleine Batch-Datei mit ein paar Erklärungen dazu (Detaillierteres findest Du mit der Suchmaschine deiner Wahl). Bitte NICHT einfach ausführen sondern zuerst recherchieren was das alles bewirkt und für auswirkungen hat. Also Basics zu Loopback etc. Baue auch gleich das Gegenscript, welches sämtliche Einstellugen auf Windows-Auslieferungszustand zurücksetzt! --> Grundsatz bei Eingriffen ins System. Natürlich auch das Protokoll auf den Adaptern entfernen. Ab W8 lässt sich das auch einfach automatisieren, W7 wiederum mühsamer. Ich erstelle zudem noch Firewall-Out-Block-Regeln für alles was mit IPv6 zu tun hat wenn ich mich für ein reines IPv4-Netz entscheide. REM ####################################################################### REM # IPv6 deaktivieren REM ####################################################################### REM Grundsätzlich ist es so, dass IPv6 nicht komplett deaktiviert werden jedoch auf sehr vielen Ebenen abgeschaltet werden kann. REM Der Windows Standard ist grundsätzlich zuerst IPv6 und wenn nicht verfügbar IPv4. REM Deshalb sollte man nicht einfach IPv6 Komponenten deaktivieren ohne darauf rücksicht zu nehmen. REM Das wichtigste ist, die Prefix-Policy so abzuändern, dass nach Möglichkeit IPv4 genommen wird und nicht IPv6. REM Tut man das nicht, hat man unter Umständen Probleme mit Systemdiensten wie dem Anmeldevorgang der nach der Deaktivierung einer Komonenten plötzlich sehr lange geht. REM Zusätzlich zu unten genannten Schritten muss das Protokoll in den Netzwerkadaptern deaktiviert werden. Manuell oder auch per Batch/Powershell. REM Mittels Powershell geht das mit Get-NetAdapter-Binding REM Für Batch bzw. Windows 7 wird das Tool nvspbind.exe benötigt. (MS-Tool, meine es war beim Toolkit mit dabei) REM Prefix-Policy auf IPv4 bevorzugen abändern REM ------------------------------------------ REM IPv6 in der Prioritätenliste nach hinten schieben, damit standardmässig (inklusive Lookup) IPv4 genommen wird und nur IPv6 wenn IPv4 nicht verfügbar ist. REM Es werden auch ältere IPv6-Standardadressen berücksichtigt, die grundsätzlich nicht mehr in Betrieb sind, jedoch teilweise noch verwendet werden. netsh int ipv6 set prefixpolicy ::ffff:0:0/96 60 4 netsh int ipv6 set prefixpolicy ::/96 55 3 netsh int ipv6 set prefixpolicy ::1/128 50 0 netsh int ipv6 set prefixpolicy ::/0 40 1 netsh int ipv6 set prefixpolicy 2002::/16 30 2 netsh int ipv6 set prefixpolicy 2001::/32 5 5 netsh int ipv6 set prefixpolicy fc00::/7 3 13 netsh int ipv6 set prefixpolicy 3ffe::/16 1 12 netsh int ipv6 set prefixpolicy fec0::/10 1 11 REM IPv6 deaktivieren inklusive tunnel REM ----------------------------------- netsh interface ipv6 6to4 set state state=disabled undoonstop=disabled netsh interface ipv6 isatap set state state=disabled netsh interface teredo set state disabled REM Ab Windows 8 / Server 2012 würden auch folgende Powershell-Befehle gehen, obige funktionieren überall REM ----------------------------------------------------------------------------------------------------- REM Set-Net6to4configuration -state disabled REM Set-Netisatapconfiguration -state disabled REM Set-NetTeredoConfiguration -type disabled REM IPv6 System-Komponenten komplett deaktivieren REM ---------------------------------------------- reg add "hklm\System\CurrentControlSet\Services\Tcpip6\Parameters" /v DisabledComponents /t REG_DWORD /d 255 /f REM IPv6 Dienst deaktivieren (er ist versteckt, nicht zwingend notwendig, aber der Vollständigkeitshalber) REM ------------------------ REM reg add "hklm\System\CurrentControlSet\services\TCPIP6" /v Start /t REG_DWORD /d 00000004 /f REM IPv6 Tunnel Services in allen Hardward-Profilen deaktivieren REM ------------------------------------------------------------ reg ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TCPIP6" /v Start /t REG_DWORD /d 00000004 /f reg ADD "HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\TCPIP6" /v Start /t REG_DWORD /d 00000004 /f reg ADD "HKEY_LOCAL_MACHINE\SYSTEM\ControlSet002\Services\TCPIP6" /v Start /t REG_DWORD /d 00000004 /f REM Restliche Hives können natürlich auch für ControlSet1 und 2 gesetzt werden. Danach Reboot. REM Auch die Firewall hat massig Freigaben für IPv6 die man abdrehen kann wenn man möchte. Ausgangsverkehr auch blocken damit es wirkungsvoll ist.

Warum sollte das nicht gehen? Der grosse Vorteil von den von daabm genannten Tasks: Du kannst dem Script problemlos alles an benötigten Rechten mitgeben. Also auch Systemrechte. Oder wenn nötig über Umwegen sogar die vom TI ohne jedoch den User entsprechend auszustatten. Bei Verwendung von Powershell-Scripten gibts ein paar Dinge die man beachten muss. --> Suche anwerfen. Wens nur was simples ist, nehme ich in der Regel Batch-Files. Nur für den automatischen Reboot brauchst einen Workaround. Also die Abfrage des Reboots mit /NoRestart beim dism verhindern und anschliessend einen Shutdown bzw. Restart im Script provozieren --> shutdown /r /t 00 /f EDIT: Damit kann man auch gut Windows von mehreren ungewollten Packages automatisiert "erleichtern" und erst anschliessend den Reboot ausführen.

Einstellungen mit Mausklicks tätigen... ist das wirklich notwendig? Normal haben alle Anwendungen eines davon: - Ini-File oder dergleichen mit den Einstellungen - Einen Ordner wo alles abgelegt ist - Registry-Einträge - Eine Datenbank des Programms Mit Tools wie RegShot und Sysinternals kann man herausfinden/aufzeichnen was alles so geändert wird, wenn man die Einstellungen tätigt. Sind das nicht gerade verschlüsselte Files würde ich immer diesen Wege bevorzugen gegeünber Script-Klickerei. Klar dank den vielen Telemetry-Zeugs ist das Filtern der Aufzeichnungen mitunter lästig geworden, aber ich finde es dennoch fast immer den besseren weg.

Zum Hänger-Problem in RDP: Ein fehlerhafte IPv6-Konfiguration/Deaktivierung ist definitiv ein Punkt der bei falscher Konfiguration gerne ein Hänger-Problem jeglicher Art gibt (Verzögerungen in der Session, Disconnects, Anmeldeprobleme). Da er aber nichts davon schreibt das es deaktiviert ist, ist es wohl was anderes. Gibt sehr viele Ursachen für RDP-Probleme - Applikationen die nicht RDP-Tauglich sind --> Hängt ab und wann mit Rückwärts-Kompatbilitätsmassnahmen des OS zusammen (Aufwendig selber zu fixen) - Aufbereitung von Ausdrucken --> Gibt sehr oft Ärger, insbesondere wenn die Aufbereitung auf dem Client und nicht dem Printserver geschieht - Aufbereitung von Grafiken wenn diese spezielle Dinge wie OpenGL und so Spässe nutzen - LAN-Verbindung die nicht stabil ist --> Paketverluste --> Alles mögliche an unerklärlichen Problemen Bei Windows 10/Server 2019 hat sich das ganze nochmals verschärft, weil MS da massiv am ganzen Benutzerstack rumexperimentiert. (Services, Apps und und und). Mein Vorgehen bei unerklärlichen RDP-Problemen während dem Betrieb - Grafikkartentreiber alles aktualisieren - Printertreiber aktualisieren, Druckaufbereitung auf dem Client verbieten wenn der Drucker auf einem Printserver liegt und verbunden wird (in kleinen Netzen eh egal) - Ist IPv6 "deaktiviert", dessen vollständigkeit prüfen - Netzwerk-Verbindung prüfen: Entweder mit einem Prüfgerät des Elektrikers die Leitung checken oder aber Testweise nen 100Mbit/Switch in die Leitung hängen Hilft das alles nicht: VNC, Teamviewer oder ein anderes Fernwartungsprotokoll/Lösung weil die Chance gross ist, das eine Applikation nicht damit klar kommt. @IT-PhiL: Naja, Du deaktivierst IPv6, er jedoch nicht (zumindest hat er nichts dergleichen erwähnt) = Nicht identische Voraussetzung = anderes Thema. Ziemlich oft ist zwar das erscheinen ähnlich, nicht aber unbedingt die Ursache. ;) Bezüglich IPv6 deaktivieren: Bitte nur wens vollständig gemacht bzw. umkonfiguriert ist. Komplett deaktivieren lässt sich der Stack nämlich nicht. Macht man nur die Hälfte, gibts Ärger an allen möglichen und unmöglichen Stellen. Ein paar Stichworte: Protokolle auf Netzadapter, Priorisierungsregeln IPv4 vor IPv6, SubServices, Firewall-Regeln In/Out, Reg-Einträge (aktivierte Bestandteile) etc. Der Krempel muss unter Umständen nach einem grösseren Update wei einer neuen Build erneut gemacht werden. @MurdocX: Naja, ich finde schon. Man muss beides Pflegen in der Firewall und bei der Problemsuche. IPv6 ist auch nicht so wirklich auf Anhieb durchsichtig beim nachverfolgen wer mit wem wohin quaselt. --> Insbesondere in kleinen Netzen ohne die entsprechenden Spielsachen die man in grösseren Firmen zu Verfügung hat. (Aber ist wieder ein anderes Thema...)

Hallo Leute, Hat jemand Erfahrungen mit diesem Produkt? Oder etwas vergleichbares? Klingt irgendwie ganz nett, Websites werden auf der dedizierten VM/Appliance geladen und ausgeführt nicht jedoch auf dem Client. An die Rechner geht hauptsächlich der Video-Stream via html5. Habe das zwar teilweise schon mit separaten, zugedrehten VM's gemacht + Fernwartungsprotokoll, aber das hier klingt irgendwie einfacher zum umsetzen. Theoretisch ist das sicherer, ist es dies aber auch praktisch? Gibt ja fast nix was schneller gepatched wird als die lieben Browser. Ist ja auch bei SSL Inspection/Interception bei der Firewall immer eine Krux. Mit dem Zertifikat auf der Wall kann ja dann eigentlich jeder Traffic gefaked werden. Geht irgendwie ins gleiche. Gruss und Danke

Punkto Dedupe: So gut wie alle Windows-Versionen seit XP gehen +- ineinander auf. Die jeweils vorherige ist zu sehr grossen Teilen blockmässig in den neueren vorhanden. Das heisst: Es wird durch 2019 etwas mehr, aber kaum wesentlich mehr Platz hinzukommen als mit 2016. Rein auf die OS-Daten bezogen.

@DocData: Hat sehr wohl auch mit MS zu tun. 1. haut MS nur noch umfassende Updates und nicht sicherheitsrelevante Updates separat raus (kann, muss aber nicht Probleme bei den Steuerungen geben. So meine Erfahrungen.) 2. kann man den Installationszeitpunkt der Updates nicht zuverlässig selber bestimmen (Ging früher 1A, Maschine hat Updates gezogen, der Mitarbeiter hat bei einer Produktionspause die Updates eingespielt. Fertig.) 3. Zieht W10 seine Updates irgendwie von irgendwoher, das zuverlässig abzustellen ist nicht trivial und schon gar nicht von MS vorgesehen. Dazu gibt es automatische ReArms. Also simple Fernwartung reicht schon aus wenn nicht Firewall, Tasks, Dienste etc. entsprechend durchkonfiguriert sind um den Updatediensten die Kommunikatiosmöglichkeiten zu entziehen. Dazu hat MS ständig neue Ideen wie es wieder aktiviert wird. (Automatische Firewall-Regeln im Hintergrund, Task welche Dienste reaktivieren, GPO welche nicht greifen und und und) 4. erschwert MS den Zugang zum Long Term Service Channel für vollständige Vorinstallationen völlig unnötig. Pro war Jahrzehnte das was verwendet wurd 5. MS missbraucht den Namen der Edition anstatt was neues zu nehmen. Pro ist im Grund nur noch eine Home-Edition mit Domänen-Einbinde-Rechten. 6. wurden die Lieferanten nicht informiert das ihr jahrelang verwendetes Pro nun plötzlich völlig ungeeignet ist für jegliche Art von Steuerungen Meines erachtens trägt MS daher eine ziemlich grosse Mitschuld am Dilemma. Klar, kann alles anderweitig geregelt werden, aber A ist es definitiv nicht Standard bei 99% aller Lieferanten. Ich hatte bis jetzt einen einzigen der von sich aus auf LTSC gesetzt hat. B. Ich hatte noch keinen welcher die Updatedienste selber zuverlässig abgeschaltet hat C. Brauchen alle diese Dinger irgendwann Internet und zuguter Letzt: Muss der ganze Krempel mit ERP, Arbeitsmaschinen, Messtationen etc. kommunzieren. Protokolle müssen per E-Mail verschickt werden und und und. Werd das noch sauber trennen kann, Hut ab! Sorry, das ist einfach ein abartige Einstellung. Da hängt zuviel Leid dran. 1. kennen sich die meisten nicht selber damit aus, also wie sowas effektiv umgesetzt werden muss 2. wird es von den Dienstleistern selten so umgesetz wie man sollte, auch wenn sehr viel Geld in die IT investiert wurde 3. ist wie gesagt die saubere Trennung heute ein Ding der Unmöglichkeit

Bei uns in der Nähe gingen grad zwei grössere KMU deswegen Hops. Mindestens einer davon hatte eine ziemlich aufwendige IT, angeblich auch sicherheitstechnisch auf ziemlich hohem Niveau. Einen dritten etwas grösseren Betrieb hat es mehrere Millionen gekostet. Komplette Service-Abteilung ca. 1 Monat vollständig stillgelegt. Ging rein gar nichts mehr. Die Leute völlig überfordert weil sich keiner mehr gewohnt war mit Papier und Stift zu arbeiten. Ersatzteile hat das Lager keine Ausgespuckt da ebenfalls tot usw. Der eine grössere KMU hat ordentlich Geld für IT-Sicherheit dafür ausgegeben. Klar, nur Geld ausgeben ist keine Sicherheit das die Firma welches das umgesetzt hat auch ihr Handwerk verstanden hat, aber der Wille war mit Sicherheit da. Ein Monat kompletter Produktionsstillstand da alles modern, hochvernetzt und durchautomatisiert. Firma pleite, fast 200 Mitarbeiter auf der Strasse. Die ganze Produktion hing mit der IT zusammen. Perfekter moderner Betrieb quasi. War wohl das totale Chaos. Potentielle Investoren welche die Firma retten wollten, sind abgesprungen weil massenhaft Strafzahlungen wegen verspäteter Lieferung angestanden wären. Ich frage mich wirklich wohin das ganze führt. Insbesondere bei der Digitalisierung von Produktionsbetrieben. Da wird noch einiges kommen. Büro PC's kriegt man ja irgendwie noch in den Griff aber integrierte Produktionslinien sind der Super-Gau schlechthin. Insbesondere für kleinere Betriebe. Steuerungen bis runter zu W95 und solche Spässe für aktuell 10 jährige Maschinen sind gar nicht so selten. XP noch sehr weit verbreitet. (Lieferant war nahmhafter deutscher Grosskonzern). Die Update und Produkt-Strategie von MS macht es auch nicht gerade einfacher.

Davon muss man ausgehen ja. Wenn man in Englisch danach googelt läufts eigentlich immer darauf hinaus.

Klingt super, also GPP nicht sauber umgesetzt in W10. Naja, es ist schon sinnvoll das GPO's auch im laufenden Betrieb aktualisiert werden. Ist ja grundsätzlich auch Sicherheitsrelevant. (Remotedesktop-Richtlinien und und und). Mit Windows 10 wird die Einstellung wohl ignoriert. Weiss nicht genau ab welchem Build. Ganz genau habe ich es noch nicht analysiert, ich habe es aber auch noch nie deaktiviert, da eben grundsätzlich sinnvoll. Manche PC's werden ja eine halbe Ewigkeit nicht neu gestartet, da will ich nicht, dass die GPO's nicht verteilt werden. Könnte mir auch vorstellen, dass mittlerweile gewisse andere Dinge auch mit Pushs über die GPO-Infrastruktur laufen. Da eben bereits vorhanden. Ist aber auch nur Mutmassung, wäre aber ein Grund warum die Aktualisierung eventuell deaktiviert worden ist. Aber eben, ich vermeide GPP's soweit es geht. Für Reg-Einträge benutze ich es auch gerne, aber sonst nehme ich nach Möglichkeit Scripts.

Also auch GPP. GPP ist allgemein etwas "spezieller" als die administrativen Vorlagen. Ist eigentlich kein MS Produkt sondern war ein privater Anbieter der von MS gekauft wurde. Auch die Modernisierung dieser Erweiterungen wird immer etwas stiefmütterlich behandelt. Hat für mich immer etwas den Touch von "gekauft, implementiert, vergessen". Gut möglich dass da irgendwelche "Würgs" nie behoben wurden. Ist aber reine Spekulation. Naja, dann nimmst alle GPP's für eine OU raus und testest mal obs danach nimmer flackert. Falls es das nimmer tut, kannst ja nach und nach aktivieren und schauen welche Einstellungen das flackern bewirken oder ob es allgemein alle GPP's sind.

Nope, dann nicht wirklich... Dann liegts aber auch nicht unbedingt nur an den Mappings oder Du hast noch ein anderes Prob. Wäre interessant was Du/Ihr alles an Einstellungen getätigt habt.