Weingeist

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.

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.

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.

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).

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.

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.

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.

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.

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. ;)

Jetzt fehlt nur noch das Primärziel: Admin-Rechte für die tägliche Arbeit unnötig machen.

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/

Also von irgendwelchen zusätzliche Firewalls würde ich tunlichst abraten. Das bringt in aller Regeln nur Probleme. Eher früher wie später. Windows bringt eine excellente Filter-Engine mit. Man muss sich nur etwas einarbeiten. Schützen kann man theoretisch die Reg-Hives wo die Firewall-Richtlinien abgelegt werden indem die Änderungsberechtigungen für Admins entzogen wird und zbsp. einer speziellen Gruppe zugewiesen wird. Da ist dann die gleiche kriminelle Energie notwendigt wie für das tauschen eines Passwort-Hashes. Die Firewall-Polcies bfinden sich unter: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\SharedAccess Im Subreiter Parameters>FirewallPolicy>FirewallRules liegen die benutzerdefinierten, in der GUI angezeigten Regeln Im Subreiter Parameters>FirewallPolicy>RestrictedServices>Configurable liegen wie der Name schon sagt konfigurierbare Regeln (CMD/Powershell), sind aber in der GUI unsichtbar Im Subreiter Parameters>FirewallPolicy>Static liegen die die statischen Regeln, die weder per GUI noch per CMD verändert noch angezeigt werden können (Nur direkt in der Registry) Ich meine im November Build von 2018 kam dann noch ein spezieller Subkey für APP-Container dazu. Genauer Pfad weiss ich aber nicht grad auswendig. EDIT: Wer genug Zeit hat, kann mal spasseshalber W7/W8.1/W10 in versch. Editionen mit einander Vergleichen. Ziemlich "interessant". Kommt man auf die Idee System/TI die Write-Berechtigungen zu entziehen, muss dazu gesagt werden, das W10 nicht happy damit ist wenn man System und TI die Kontrolle über diese Hives wegnimmt und z.Bsp. einer speziellen Gruppe zuweist. Das Problem: Wenn sich ein Benutzer der noch kein Profil auf diesem Rechner hat anmeldet, schlagen die App-Installationen fehl, weil die Erstellung der Firewall-Freipässe für die Apps fehlschlagen. Das ist zwar ein äusserst wirksames und simples Mittel um sämtliche App-Installationen (Auch System-Apps) zu verhindern, allerdings hat man dann lediglich einen funktionierenden Desktop aber keine Taskleiste, Infobereich, Startmenü, Suche etc. Quasi Windows 3.11 Style =) Aber wie gesagt, schaut, dass gar keine Admin-Rechte zum arbeiten notwendig sind. Windows bietet relativ viele Mittel dafür. Diese Zeit/Geld ist eigentlich sowieso immer gut investiert.

Noch ein paar Ideen: Wenn WLAN nie gebraucht wird, könntest die Geräte auch aufschrauben und die Antenne oder gleich das ganz Modul entfernen. Zumindest wens nicht verklebt/verlötet ist. Da hängt meist Bluetooth noch mit dran. LAN kann man evtl. mit einem Schloss dauerhaft unbrauchbar machen (keine Ahnung obs sowas gibt) oder mit Kunstharz vergiessen, was dann endgültig und eher wenig sinnvoll ist. Gleiches wäre dann übrigens für die USB-Anschlüsse sinnvoll, wenn das in Frage kommt. Da ist das kopieren von Daten am einfachsten auch wenn es erschwerbar ist mit GPO's etc. Aber auf irgend eine Variante müssen die auszuwertenden Daten ja auch auf die Kiste. Im LAN ist dies z.B. dann mit Kommunikationsbeschränkung richtung AD und Fileserver möglich. --> Windows Firewall All das erschwert aber nur den Datenklau und verhindert ihn nicht. Stichwort abfotografieren etc.

Also ich habe es noch nie erlebt, dass man den Usern den Admin für die tägliche Arbeit nicht abgewöhnen konnte. ;) Problemlösung durch Windows: Dann schaltet man eben den ganzen Diagnose-Krempel auch komplett ab. Ohne Adminrechte ist der dann auch nicht mehr einzuschalten. Dann kann man noch Proxies verbiegen damit keine Kommunikation nach aussen möglich ist, Windows Firewall konfigurieren und und und. Firewall von Windows kann man z.B. auch konfigurieren für Standard-Block-Out und alles selber Regeln erstellen. Braucht einfach Zeit. Auch dem Admin die Rechte entziehen kann man in den entsprechenden Reg-Hives. (er kann sie mit know How einfach wieder holen) Die Regeln einzeln aktivieren/deaktivieren kann man auch wieder Scripten. Dass Manche Prozesse/Software dann als Admin laufen kann/muss und man damit auch ausbrechen kann, steht auf einem anderen Blatt. Dann gibt es noch den Programmkompatibilitäts-Modus den man auch manuell konfigurieren kann um Software die nötigen Berechtigungen zu verschaffen. Wie gesagt, ich habe es fast noch nie erlebt, das man mit entsprechendem Aufwand die Admin-Rechte nicht direkt braucht. Es gibt der Möglichkeiten viele, aber um das beurteilen zu können was sinnvoll ist, muss man die Prozesse kennen. Daher ist eine externe Beratung von einem Spezi hier wohl sinnvoller ;) Ansonsten ist es einfach so, dass ihr das falsche Produkt gekauft habt bzw. eigentlich pro User zwei Produkte bräuchtet. Wenn ein Bereich dermassen sensibel ist, gehört das sowieso nicht auf die gleiche Maschine wie der Rest. Und schon gar nicht auf einen LapTop. Just my 2 cents. ;)

Mittlerweile lässt sich sehr vieles mit Powershell scripten. Also auch deaktivieren und aktivieren der Netzadapter. Ohne grossartige Krücken wie früher. Da kannst ein paar Scripts schreiben für die jeweiligen Situationen welche das System so einstellen wie für die Situation gewünscht. Bezüglich Admin-Rechte: Wenn es um Dinge geht die Wiederkehrend sind, mache ich das immer mit Scripten die per Task aufgerufen werden. Die notwendigen Rechte hat der Task, derjenige welcher auf Ausführen drückt oder mit einem anderen Script das ausführen anstösst, muss diese aber nicht haben. Der muss nur den Task ausführen dürfen. Dann gibt es natürlich noch die Möglichkeit selber Dienste oder Programme zu programmieren welche die jeweilige Funktionalität haben. Oft ist das aber etwas Overkill. So bekommt man fast alles ohne Admin-Recht der Benutzer hin. Selbst auf Maschinen der Admins. Zu guter letzt kann man natürlich gewisse Rechte auch den Admins entziehen. Das ist zwar für jemanden der wirklich Zugriff will kein so grosses Hinderniss, aber mühsamer wird es. Die Änderungs-Rechte kann man dann wahlweise auf System oder TrustedInstaller (mühsam den zu kapern) schieben. Ist aber eher als zusätzliche Hürde für Malware von aussen als wirklich von innen. Weil die gehen meist von Standard-Situationen aus. Nützt ntürlich alles nichts bei einem gezielten Angriff. ;)

Yeah... Absolut korrekt Yep, bei solchen Sachen ist das definitiv von Vorteil.

@daabm: *lololol* Stimmt das ist widersprüchlich, ist mir erst jetzt aufgefallen wo dus sagst. Doofe Wortwahl. Auch wenn ich sonst überall geschrieben habe, dass modifizieren geht. Inklusive im Titel. Sysvol-Berechtigungen wurde - zumindest in der Theorie - nix dran rumgeschraubt. Allerdings olé olé, war da doch was im Argen. Und zwar waren die Write-Berechtigungen für Zugriff der Admins auf policies lediglich für Unterordner und Dateien nicht aber für den Ordner Policies an sich vergeben. Gefühlt 100x die Berechtigungen angeschaut und trotzdem nicht gesehen. Ich glaubs echt nicht. Wie dies dahin bzw. weg kam, ist nicht mehr nachzuvollziehen. *hmpf* Danke für die Geduld!

Etwas seltsam ist das schon. Deaktiviere die Kommunikation von und zu Akamai sowie Amazon auch standardmässig. Da sind ja einige Services (unter anderem der Spooler) sehr Kommunikationsfreudig. Bis jetzt noch keine Probleme damit gehabt. Bezüglich Updates sind es ja auch eine Reihe GPO's die man konfigurieren kann. Z.Bsp. das ein Client nicht selber zum Internet kommunizieren darf. Übermittlungsoptimierung auf Umgehung (evtl. Komplettdeaktivierung der Optimierung, mache ich bei allen Pro so). Dann fragt er normal ausschliesslich WSUS an, wo man die Treiber wiederum deaktivieren kann. Allerdings habe ich den Build 1903 noch nirgends ausgerollt und das wird vorläufig auch so bleiben. Bin auch total rückständig und nutze wo immer irgendwie möglich die LTSC-Version weil ich kein Bock habe im Halbjahresrhytmus neue Bedingungen anzutreffen. ;)

Wie und was genau? Bis jetzt hatte ich Probleme dieser Art noch nie, bzw. beschränkten sie sich auf das verabeiten auf den Zielmaschinen, das replizieren oder unterschiedliche Varianten der GPO's. =) --> Suche wohl falsch einfach falsch. Fand nix dazu.l @xrated2: Besitzverhältnisse liegen auch bei den Domain-Admins. Aber das problem sind ja auch nicht die existierenden GPO's. Da läuft alles rund. Sobald ich auf den Button neu erstellen drücke, kann ich noch den gewünschten Namen eingenben und sobald ich das bestätige, ist fertig.

@daabm: Nochmals mit anderen Worten: Der Fehler: es lässt sich keine neue GPO auf dem DC erstellen, ändern ist aber kein Problem, löschen auch nicht. Anzeigen auch nicht. Wie er sich äussert: Es erscheint nur eine Meldung: "Zugriff verweigert" wenn eine GPO erstellt wird. 0815 Msgbox ohne Symbol, nur ein OK Button, ohne sonstige Erklärung oder Err. Nummer. Kein Log-Eintrag, weder im administrativen Teil, noch bei Group Policy noch bei der FilterEngine (wo Zugriffsverletzung aller Art normal geloggt werden, sofern aktiv). Der Server ist weder abgestürzt (dass AD beschädig sein könnte) noch sonstwas. Es wurdne lediglich Updates eingespielt. Einträge im AD unter Computer/Benutzer erstellen ist auch kein Problem. Alles was ich den letzten Monaten gemacht wurde, ist die Windows Updates einzuspielen. Werde mal versuchen den Policies-Ordner neu zu erstellen und die Berechtigungen frisch zuzuweisen. Gefällt mir zwar nicht so richtig, aber mir fehlt sonst grad eine zündende Idee.

Jeweils Bearbeiten, löschen, sicherheit ändern für die Admins und Besitzer sind sie auch. Das alles geht auch. Scheint irgendwo ein Neuerstellungsrecht zu fehlen, fragt sich wo.

Hallo Leute, Habe in einer Umgebung das Problem, dass ich die GPO's nicht mehr verändern kann. Ist relativ schwierig nachzuvollziehen seit wann das Problem besteht, weil ich da schon eine halbe Ewigkeit keine neuen GPO's mehr erstellt habe. In den letzten Monaten ja fast Jahre habe ich da lediglich Windows-Updates eingespielt oder GPO's verändert. Was ich schon versucht habe: - Prüfung der Event-Logs --> Keinerlei Einträge, auch nicht bei der FilterEngine wo normal etwas auftaucht wenn irgendwo Zugriff verweigert erscheint (habe umfangreiches Logging aktiviert) - Check der Berechtigung von SYSVOL auf dem Server, keine sichtbare Beeinschränkung, Admins haben Vollzugriff Was ich nicht mehr sicher bin: Ob ich in dieser Umgebung seit der Umstellung auf einen Central Store schonmal Policies neu erstellt habe oder nicht. Jemand eine Idee was das sein könnte? GPO's werden auch sauber angewant ohne Kniffe wie force update oder ähnliches. Grüsse und vielen Dank

Kommen Sie in der "klassischen" Liste? Am schnellsten kommst so dahin: Ordner erstellen mit dem Namen (wichtig ist nur die GUID nach dem dem Punkt): Drucker Erweitert.{2227A280-3AEA-1069-A2DE-08002B30309D} --> Wenn Sie da kommen, funktioniert das Drucken meistens trotzdem, da klassische Desktop-Anwendungen auch auf die klassische Liste zugreifen und nicht diese Pseudo-vollständige Auflistung unter Drucker und Geräte. Insbesondere das Abstürzen von luafv deutet aber darauf hin, dass die Treiber eben nicht sauber progrommiert sind und Windows hier "unschuldig" ist. Abhilfe schafft man teilweise, wenn man den Dienst deaktiviert. Am besten vor der Installation der Drucker. Kann aber eigentlich nicht das Ziel sein. Seit W8 wurde ziemlich viel am Printer-Stack rumgeschraubt, was die Treiberentwicklung nicht unbedingt vereinfacht hat. Beziehungsweise theoretisch vereinfacht, praktisch aber eben nicht wirklich weil die alten Treiber irgendwie zurecht gebogen werden anstatt neu entwickelt. Auch würde ich das Client-Side-Rendering per GPO abschalten, macht mit manchen Treibern auch massive Probleme. Ohne wird einfach der Druckserver wieder mehr belastet bzw. nicht entlastet. In kleineren Umgebungen dürfte das allerdings nicht zum Flaschenhals werden. Ich weiss nicht mehr seit wann das ClientSideRendering standardmässig aktiviert wurde, früher war das mal standardmässig aus soweit ich mich erinnere. Auf alle Fälle schaffst du damit gleiche Voraussetzungen bei allen Clients. --> Administrative Vorlagen>Drucker>Druckaufträge auf dem Server wiedergeben --> aktivieren Für die Consumer-Modelle würde ich - sofern vorhanden - auch auf einen Generic-Treiber des Herstellers umstellen und nicht einen druckerspezifischen Treiber. Diese würde ich eigentlich nur noch bei den grossen Arbeitsgruppendrucker nehmen. Auf billige Multifunktionsgeräte möglichst gänzlich verzichten, die machen am meisten Ärger. --> Bei billigen Multifunktionsgeräten mache ich nie lange rum. Geht es nicht auf Anhieb, wird das Teil entsorgt und es kommt entweder ein gebrauchtes "grösseres" Gerät oder eben ein neues professionelles Gerät hin. Die Treiber dazu sind sehr oft unterirdisch.

Du könntest herausfinden welche DLL/Active-X oder was auch immer die Probleme verursachen. Diese nach dem Update dann ersetzen. Andere Möglichkeit ist manchmal auch ein spezifische Anpassung mittels Programmkompatibilität. Ist halt ziemlich aufwendig, muss man schon wollen. Für kleinere Programme ist das meist recht easy, bei MS-Office würde ich das mal bezweifeln. ;) Allerdings habe ich es noch nicht erlebt, dass ein Programm welches auf Server 2003 lief, nicht auch auf Server 2008 portiert werden konnte. Halt teilweise mit etwas Arbeit verbunden. Selbst mit 2012R2 hatte ichs bis jetzt eigentlich immer auf die Reihe bekommen wenn keine 16bit Krücken nötig waren. Da ist dann eben 2008 ohne R2 fällig. bei 2016/2019 habe ich noch zu wenig Erfahrung mit der Erhaltung von Altlasten. Dürfte aber eher schwieriger geworden sein.

Das geht auch mit diversen Registry-Anpassungen. Ist halt Super-Aufwendig. Ungefähres Vorgehen: - Deaktivieren von Tasks welche den Defender einschalten - Deaktivieren von Defender-Diensten - auch Teildienste die nicht in der GUI erscheinen - in der Registry (sind eine ganze Menge) Würde ich gegenüber dem entfernen aktuell noch tendenziell bevorzugen. Entfernen von Komponenten ist halt immer so endgültig, auch wenn es mit (fast) jedem Build besser und zuverlässiger funktioniert. Im Moment gibt es aber für Komponenten noch keine "wieder hinzufügen" Funktion. Hast Du ein Problem, stehst da wie der Esel am Berg weil das System unter Umständen nicht supported ist. Deaktivierst Du per Script, kannst auch per Script wieder aktivieren und den Ursprungszustand herstellen. Dafür sind teilweise Systemrechte oder auch der Benutzer TrustedInstaller erforderlich die man aber beide "erzwingen" kann. Würde die Änderungen auch immer mit diesen User vornehmen, damit die Rechtestruktur identisch bleibt und nicht die Rechte an den Schlüsseln übernehmen.