Jump to content

Weingeist

Members
  • Content Count

    975
  • Joined

  • Last visited

Everything posted by Weingeist

  1. 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
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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...)
  7. 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
  8. 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.
  9. @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
  10. 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.
  11. Davon muss man ausgehen ja. Wenn man in Englisch danach googelt läufts eigentlich immer darauf hinaus.
  12. 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.
  13. 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.
  14. 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.
  15. Du könntest das Laufwerkmapping auf Scripts umstellen --> Beim anmelden. Dann dürfte das Problem gegegessen sein und die GPO's können ohne Ärger aktualisiert werden.
  16. MS mag Office 2010 eh nicht mehr, dabei ist es noch das letzte ohne die ganze Integration vom Internet-Gedöhns und viel Bling Bling-Animationen die kein Mensch braucht. Im Oktober ist leider eh fertig lustig, dann läuft der Support aus. Evlt. wäre dies ja der Moment für ein Upgrade. =) Ich persönlich würde für reine Sicherheitsupdates von Office 2010 bezahlen bzw. noch lieber für Office 2003 mit ein paar Verbesserungen/Bug Fixes. Ich mag die Ribbons auch nach über 10 Jahren noch nicht wirklich, da einfach langsamer und unnötige Platzverschwendung und äusser mühsam/aufwendig in der Anpassung.
  17. Yep, ist echt mühsam geworden. Dank der Super Duper Patchstrategie von MS eigentlich ein komplettes Desaster. Ist ja bei Office-PC's schon mühsam genug geworden mit den ganzen halpatzigen und fehlerbehafteten Updates und halbgaren Builds. Über 10 Jahre lang hatte ich (fast) komplett Ruhe mit Patch-Problemen, jetzt ist es wieder wie zu alten Zeiten. Bei Industrie-PC's ist es zusammen mit dem LyfeCycle von Pro und den Kombi-Updates der Super Gau. Gleichzeitig immer mehr Integration/Vernetzung.
  18. Nach Möglichkeit würde ich die Dinger draussen lassen und auch möglichst per Dienstkonten und Firewall lösen. 1. weil die Hersteller alle Änderungen ablehnen 2. weil Du immer Schuld bist, wenn mal was ist, egal was passiert, bei anderen gibt es das NIE welche Standard verwenden, auch wenn Du während Monaten/Jahren keinerlei Probleme hattest Soweit die Realität bei der Zusammenarbeit mit den meisten Firmen. Gibt auch Ausnahmen, die sind aber selten. ABER: So einfach wie früher ist die Abgrenzung nicht mehr. - Kommunikation mit ERP, Produktionsplanung etc. - Messysteme von Werkzeugen kommunizieren mit CAD, Maschine, Leitsystem - Simulationssysteme mit CAD, Leitsystem, Maschine etc. - Leitsystem kommuniziert mit Maschinen, ERP, CAD, Überwachung - Prüfmaschinen legen die Protokolle auf Fileserver ab welche wiederum per E-Mail versendet werden müssen - Fernwartung - und und und W10 bzw. die Patchstrategie von MS hat dieses Thema auch nicht gerade vereinfacht. Früher (XP + 7) habe ich die Systeme einfach mit Sicherheitsupdates gepatched. War nie ein Problem. Das geht nicht mehr. Dazu vorher die Festplatte geklont um jederzeit den Auslieferungszustand wieder herstellen zu können. Ich hatte in 15 Jahren seit ich solchen Krempel einbinden muss, einen Fall wo ich dann das Original hervorholen musste um den Fehler zu reproduzieren und zu beweisen, dass es nicht an Systemänderungen, also der Domäneneinbindung sowie Sicherheitsupdates liegt. Bei allen anderen half bei Diskussionen schon der Verweis, das ich eine entsprechende Kopie oder die Originalfestplatte vorliegen habe. Fazit zur Einbindung: Ich würde das nur noch mit Leitsystemen machen welche dann in beiden Netzen hängt. Macht viel weniger Ärger und Diskussionen. Für die Fernwartung die nicht über separatem Hardware-VPN läuft, setze ich mittlerweile eine dedizierte Hopp-Maschine ein, welche in der Domäne hängt aber auch Zugriff auf die Maschine hat. Die meisten setzen zum Glück auf primitive Übertragungstechniken mit eigenen Diensten direkt via IPv4-Adresse oder FTP oder können es zumindest (noch). Den ganzen Windows Kram benötigen sie also normal nicht zwingend. Man kann also fast alles zudrehen und nur die Kommunikation zwischen Hopp und Maschine zulassen, welche für die Fernwartung oder Dateiübertragung notwendig sind. Gleiches gilt bei den Leitsystemen. Wichtig beim Kauf für Leitsysteme oder andere Systeme die zwingend ins Netz müssen: 1. immer auf Windows Server oder W10 LTSC bestehen (Bei Leitsystemen, Prüfmessgeräten etc. klappt das immer. Maschinensteuerung selber erfahrungsgemäss eher nicht) 2. die Maschinen mit Scripts so konfigurieren, dass die Update-Dienste keine Updates ziehen können und auf Knopfdruck eben schon. 2. ist wichtig weil W10 sobald es Updates irgendwie sieht, diese herunterlädt und installiert. Nett wenn Produktionsmaschinen 24h laufen und ihnen das Leitsystem unter den Füssen weggezogen wird. Wirklich abstellen kannst W10 das A mit der Firewall und B indem du die Update-Dienste inkl. Orchestrator + Tasks abstellst. Manches geht nur über den Umweg via Systemrechten + TrustedInstaller. (Gibt Scripts/EXE für die feindliche Übernahme von TI ohne das die effektiven Berechtigungen der Dienste/Tasks/Files geändert werden müssen).
  19. Hi, Die Eigenart wie Excel und Word bzw. allgemein Office mit Druckern und deren Einstellungen umgeht ist eine äusserst mühsame Angelegenheit. Inbesondere bei Automatisierungen. Ist ca. seit 2007 der Fall. 2003 gab es die ganzen Printerprobleme jedenfalls noch nicht. Da griff Office auf das Systemeinstellungen zurück. Seit Office 2007 gibt es alles mögliche an Fehlerbildern. Die eigentliche Problematik ist, dass die (effektiv) modernisierten Office Applikationen sämtliche Einstellungen zu einem Drucker selber im Zwischenspeicher halten. Macht ein User Änderungen daran, sind diese beim nächsten Drucken immer noch getätigt. Soll dem User helfen. Tut es in der Regel aber nicht wirklich, da das ganze eben ziemlich fehleranfällig ist, Applikationsweit gilt und nicht nur für das jeweilige Dokument. Also selbst wenn der Drucker gewechselt und wieder zurück gewechselt wird, werden wieder die geänderten Einstellungen genommen. Excel reagiert nicht zu 100% wie Word. Das macht einmal in Excel und ein anderes mal in Word Probleme. Meist wird das Problem umgangen, wenn Excel komplett geschlossen wird, also keinerlei Prozesse mehr auf Excel.exe zugreifen, also auch nicht von Word aus. Dadurch wird die Office-Applikation gezwungen die Drucker inkl. Einstellungen vollständig neu zu laden. Danach funktioniert es in den meisten Fällen wieder. Manchmal tuts auch nur für einen einzigen Druck. Wie gesagt, es gibt unzählige mögliche Fehlerbilder. Deines ist eines davon. Vor kurzem hatte ich einen Fall, dass Drucken nur ging solange gar nichts an Einstellungen verändert wurde. Sonst kamen nur Hyroglyphen raus. Da es sonst nie andere Applikationen als Office betroffen hat, tippe ich mal darauf, dass Sie enger mit dem neuen Super-Buggy-Druckertreiber-Modell zusammen arbeiten als andere Applikationen. Dummerweise sind die meisten (insbesondere ältere) Treiber eben nur adaptiert und nicht neu entwickelt worden. Der Fehler liegt also nicht nur bei MS obwohl MS das ganze Problem meines erachtens völlig unnötig provoziert hat. Mit W10 wurde das ganze nochmals um gefühlt den Faktor 100 schlimmer. Insbesondere in RDP-Umgebungen. Nur zur Lösung: Die einfachste Lösung ist ein neuer, guter Treiber. Sofern verfügbar. In den allermeisten Fällen hilft es - wenn kein neuer Treiber verfügbar ist oder der nichts hilft -, separate Anschlüsse für jeden Drucker zu erstellen. Das heisst obwohl die Ziel-IP identisch ist, soll jedes mal ein anderer Anschluss für jeden einzelnen Drucker mit eigenen Einstellungen genommen werden. Standardmässig wird immer der gleiche Anschluss genommen sobald die IP identisch ist. Bei "guten" und aktuellen Treiber ist das aber normal nicht mehr notwendig. Vor ein paar Jahren war das quasi noch Standard. Selbst bei den grossen Herstellern wie HP oder Canon. Das ist ein Heidenspass ist, wenn es ein Zentraler Drucker mit vielen unterschiedlichen Einstellungen ist, versteht sich von selbst. Es funktioniert zudem nicht immer, nur den Anschluss zu wechseln, manchmal muss der Drucker zuerst komplett weg. Inkl. aller Einstellungen. Neu verbunden müssen die Drucker auf den Clients auch werden. Oft muss der Drucker auf dem Client gelöscht und komplett neu verbunden werden.
  20. Habe das sporadisch auch immer wieder mal. Hauptsächlich in Verbindung mit Hardware-Extendern wie PCoIP. Vor einigen Jahren auch mit DVI. Lösen lässt es ich meistens indem ich mich einmalig per RDP auf die Maschine verbinde. Dann ist am Hauptschirm immer das gesperrt-Bild wieder da. Ich vermute den Übeltäter bei Fehlern in der Kommunikation zwischen Bildschirm und PC bezüglich Energiesparen und/oder dem Grafikkartentreiber. Mit Energie auf Max + Bildschirm nie ausschalten in Windows habe ich es mittlerweile extremst selten. Wenn ich den Bildschirm selber auch kein Energiesparen erlaube (also am Screen einstellen), meist gar nicht mehr. Finde ich aber etwas naja, daher nehme ich es in Kauf so 1-2x pro Monat per RDP zu verbinden. Bei einer Kiste reichte nicht einmal ein Neustart, da muss wirklich aller Strom weg. Inklusive das bisschen Strom welcher via LAN reinkommt. Sonst gab es kein Bild mehr auf DVI. Oder eben reset per RDP, was auch immer das verbinden bewirkt. Bei anderen Geräten waren wiederum USB-Energiespareinstellungen schuld. Also vor allem die daran angeschlossen Geräte. Die haben teilweise ein aufwecken blockiert. Insbesondere wenn Sie mittels Hub angeschlossen waren. Hat man diese Geräte erst angesteckt wenn der Bildschirm da war und immer ausgesteckt vor dem sperren, dann gab es die Probleme nicht. --> USB-Stromsparen abstellen Alles in allem war am Ende bis jetzt immer irgendwelches Energiesparzeug schuld. Egal ob Pentium D mit XP vor 10 Jahren oder aktuelle Systeme. Das Zeug ist teilweise einfach grässlich programmiert und evtl. auch physisch mies aufgebaut. Sehr oft aber eben nicht immer ist es die Grafikkarte.
  21. Hast es mal mit Diskpart versucht? Damit lässt sich eigentlich ziemlich alles automatisiert machen bis hin zur Scriptbasierten Erstellung von System-Partitionen. Ich meine aber, diskpart schmeckten die ImDisks auch nicht. Scripten mit Diskpart kann aber schnell in die Hose gehen, Diskpart fragt nicht so viel nach. Falsche Disc selektioniert und schon hast das perfekte Chaos. ;) Allerdings könntest auch ein paar Sicherheit wie die Abfrage der GUID einbauen. Ist ebenfalls mit Diskpart oder Powershell (WMI) herauszufinden. Ansonsten: Starwind RAM-Disk ist sehr zuverlässig, allerdings nicht die schnellste. IMDISK ist da deutlich zügiger. Keine Ahnung worans liegt. (Mein Tests sind Jahre her!) Aber IMDISK hat diverse Inkompatibilitäten mit "neueren" Filesystem-Funktionen, läuft daher aber wohl auf dem hinterletzten Windows OS. *hust* die Funktionen sind mittlerweile auch schon ewig alt, aber was solls.
  22. Wenn Die den ComponentStore bzw. die Manipulationen darin zu 100% im Griff haben, brauchts irgendwann theoretisch gar keine Neuinstallation mehr oder in sehr viel längeren Abständen. Dann sind sogar reine Component-Updates und Manipulationen denkbar. Bis das soweit ist, dürfte allerdings noch sehr viel Wasser den Rhein runter gehen. Seit 2012R2 glaube ich daran, dass es zumindest möglich ist, dass es irgendwann tatsächlich klappt. Seither funktioniert die Kapselung von Funktionen und auch deren Entfernung immer besser ohne das - je nach Package natürlich - dies Einfluss auf den Rest hat. Der letzte Schritt wird dann - so vermute ich - Hinzufügen von zuvor entfernten Components oder teilweise Updates ohne Neustart sein.
  23. Für Access Anwendungen zählen eigentlich nur zwei Dinge. Niedrige Latenz und hohe Single Core Leistung. Dann rennts wenn keine Designfehler gemacht worden sind. ;) Sprich: Enterprise SSD mit möglichst tiefer und konstanter Latenz. Intel Optane oder DC's zum Beispiel. Dann kann man noch Code in DLL's auslagern für alles was irgendwie lahm ist und berechnet werden muss (VB6 bzw. C++ ist besser da schneller als .NET --> .NET sind etwas lästig beim Programmstart). Alles in allem sind die Access Lösungen nicht per se schlecht, auch wenn Sie tendenziell anfälliger sind als "richtige" Software. Aber bei grossen Projekten ist das manchmal einfach zu teuer in der Neuentwicklung. Access Lösungen habe ich noch immer portiert, bei neuen .NET ist das nicht immer der Fall. Insofern ist die Portabilität eigentlich sogar eher besser. ;)
  24. Jetzt fehlt nur noch das Primärziel: Admin-Rechte für die tägliche Arbeit unnötig machen.
  25. Ich weiss gar nicht mehr wie ich das mal zum laufen kriegte, aber es war eine schöne Frickelei. Ich musste da mit den Disc-Descriptors sowie der VMX rumspielen. Restore-Szenario war mir aber auf alle Fälle einfach too-much. Nur zum rumspielen OK. Als ich meine Tests machte, hat VmWare gar keine richtige HD Serial vergeben sonderN es gab nur die Volume-ID und die hast nur bei formatierten Drives. Das machte dann die Probleme mit Storage Spaces mit diesen Standard-ID's. Ich meine es waren folgende Flags in der VMDK (nicht der -flat) disk.EnableUUID="true" (sonst wird uuid ignoriert --> obs heute noch so ist, keine ahnung) ddb.uuid = "XXXXXX" ddb.longContentID = "XXXXXXXX" Ich meine die Hardware-ID war die UUID, bin aber nimmer ganz sicher. Paravirtual sollte man eigentlich für alle Storage-Spielereien nehmen. Ist zumindest der allgemeine Tenor. Habe mal noch google angeworfen, vermutlich ist das was unter Rockstor geschrieben ist relevant. Würde aber direkt die VMDK's mutieren. https://github.com/rockstor/rockstor-core/issues/545 https://serverfault.com/questions/304565/edit-hard-disk-serial-number-with-vmware Für die Markierung als SSD (Cache-Simulation) http://www.vcloud-lab.com/entries/general/emulate-hdd-as-ssd-flash-disk-on-esxi-and-vmware-workstation Ansonsten kann ich Dir den Ulli empfehlen, der weiss extrem viel oder kriegt es fast immer raus. Vielleicht steht sogar etwas in seinen Handbüchern. -->http://sanbarrow.com/
×
×
  • Create New...