torstenv

Hi! Aus Gründen, die ich hier nicht diskutieren kann und hinnehmen muss, habe ich die Anforderung umzusetzen, dass WSUS Updates auf den Clients erst x Tage nach dem Eintreffen des Patches auf dem WSUS Server (also Sync) installiert werden. Zur Verdeutlichung mit x=3: Di - Microsoft veröffentlicht neuen Patch Mi - WSUS Server synct mit Microsoft, lädt Patch herunter Do - Patch wird nicht auf Clients ausgerollt Fr - Patch wird nicht auf Clients ausgerollt Sa - Patch wird nicht auf Clients ausgerollt So - (Client wird nicht gestartet, es ist schließlich Sonntag) Mo - Patch wird auf Client ausgerollt Mit Windows Bordmitteln (WSUS Config oder GPOs) habe ich da keine Möglichkeit gefunden. Mein Frage zielt auf eventuell vorhandene APIs, mit denen man das vielleicht über PowerShell Scripte regeln könnte. Ist eine API zum Analysieren des Patches (wann eingetroffen, Genehmigugnsstatus) oder so bekannt? Gruß, T.

Hi! Ich kanns nicht diskutieren, ich muss mich mit den Vorgaben abfinden: Gegeben sind viele Systeme (egal, 100 oder 1.000), die nicht kb943729 installiert haben, auf denen regedit nicht per Script gestartet werden kann, und auf denen ein bestimmter Registry Key unter HKLM geändert werden muss. Hat jemand eine bessere Idee, als ein autoit oder autohotkey Script, das die jeweiligen Registrys auf einem Management Rechner über die Netzwerkregistrierung einbindet, den Key ändert, und wieder entfernt? Danke! T.

Danke! Das habe ich jetzt auf meinem Test PC ausprobiert, und, ja, das hat das Problem gelöst. Leider löst es das Problem nicht für die 100 PCs, auf denen ich die Registry Keys ändern muss. Fällt jemandem noch irgend ein Weg ein, wie auf 100+ Rechnern einen Reg-Key ändern kann, sofern KB943729 nicht installiert ist, und auch über ein Script kein regedit gestartet werden kann? Ich denke, diese Frage ist so weit weg von der original-Frage, dass ich diesen Thread besser schließe und die Frage noch mal neu stelle. Hab ich schon Danke gesagt? Egal: DAAAANKE!

Hi! Ich versuche per GPO einen Registry Key auf bestimmten Rechnern zu ändern. Hierzu habe ich ein neues GPO auf meinem DC (w2k8r2) angelegt, ans Domain-root verlinkt, dann eine Sicherheitsfilterung auf die Mitgliedschaft einer Gruppe eingerichtet (und authenticated Users aus der Filterung entfernt). Die betreffenden Rechner sind Mitglied der Gruppe, auf die der Filter zeigt. Dann die Gruppenrichtlinie editiert: Computer Konfiguration -> Preferences -> Windows Settings -> Registry Rechtsklick -> New -> Regitry Item Action: Replace Hive: HKLM Key Path: Eingegeben (und mindestens 10 mal geprüft) Value Name: Eingegeben (und mindestens 10 mal geprüft) Value Type: Reg_SZ Value Data: Eingegeben Fehler: Die Änderung wird nicht angewandt. Der Key bleibt unverändert. Zum Test habe ich die GPO um ein Startup Script erweitert, das C:\test.txt anlegt. Die Datei wird erzeugt, also die Gruppenrichtlinie wird angewandt. Nur meine Registry Keys werden nicht verändert (Test-Client ist ein XP SP3). Ich kann leider nicht regedit oder reg.exe in das Startup Script einbauen, da eine auf den 100 PCs laufende Sicherheitslösung den Start dieser Programm unterbindet. Damit ist das keine Option. Tipps? Danke im voraus! T.

Ich habe zwar außer Cygwin kein Tool gefunden, das die gesuchte Zeit her gibt, aber eine API, mit der ich was coden kann: pinvoke.net: ntqueryinformationfile (ntdll)

BOOL WINAPI GetFileTime( __in HANDLE hFile, __out_opt LPFILETIME lpCreationTime, __out_opt LPFILETIME lpLastAccessTime, __out_opt LPFILETIME lpLastWriteTime ); Das sind alles die "falschen" Zeiten.

Wikipedia hat mich darauf hingewiesen, dass NTFS 4 Zeiten liefert: Erzeugung Änderung Änderung nach POSIX letzter Zugriff Meine Vermutung ist, dass ich mit Windows Bordmitteln den Zeitstempel "Änderung nach Posix" nicht auslesen kann. Bleibt die Frage: Weiß jemand, wie man an diesen Zeitstempel kommt?

Weil ich das erst später gemerkt habe, dass ich die infos mit Cygwin auslesen kann. Aber danke für den Hinweis, ich werde es da nachtragen.

Hi! Windows lügt mir die falsche CTime für manche Dateien vor. Wie kann ich die korrekten Werte für die CTime unter Windows auslesen? Auf meinem WSUS Server kam am 14.3. ein neues Update an, das ich mir genauer angesehen habe. WSUS teilt in seiner Konsole korrekt mit, dass die Datei am 14.3. gespeichert wurde (Arrival Date). Suche ich den Patch im Filesystem, finde ich in den Eigenschaften der Datei alle Zeiten (Erstellt, Geändert, Letzter Zugriff) auf 22.2.12 23:42 Uhr. Das ist aber definitiv nicht korrekt, denn die Datei ist erst am 14.3. auf meinem WSUS Server gespeichert worden. Mir ist unter Windows nicht gelungen, den "echten" Zeitstempel herauszufinden, zu dem die Datei dort gespeichert wurde. Dennoch, es ist sicher, dass die Datei erst am 14.3. auf unserem FS abgelegt wurde. Das sieht man in der Arrival-Time in der WSUS Update Tabelle. Aber mir ist es nicht gelungen, dieses Datum dem "normalen" FileSystem für den entsprechenden Patch zu entlocken. Weder über Windows Explorer Dialoge, noch über Power-Shell. Man könnte denken, dass die Daten nunmal so da stehen, daher kann Windows nichts anderes anzeigen, aber das ist nicht so. Ich habe Cygwin auf einer Maschine und siehe da: ------------------------------------------------------------------- $ cd //fs/WSUSContent/61 $ ls -lc D3AD47874138837ED935FA6A93EF431F9D1D6C61.cab -rw-r--r-- 1 torsten mkpasswd 139489 Mar 14 02:04 D3AD47874138837ED935FA6A93EF431F9D1D6C61.cab ------------------------------------------------------------------- -lc ist unter Unix (Cywin eben) die Creation Time. Die Eigenschaften der Datei zeigen im Windows Explorer den 22. Feb (falsch), unter Cygwin den 14.3. (korrekt). Also ist die Info im Filesystem ja doch vorhanden und auch auslesbar!!! Aber wie kriege ich die da mit Windows Bordmitteln raus, anstatt Cygwin? Und warum zeigt mir Windows mit allen Bordmitteln (die ich bisher gefunden habe) die falsche CTime an? T.

Gelöst. S.o.

Hi! Ein per GPO beim Login eines Benutzers gestartetes Programm, das ich selbst geschrieben habe, muss u.A. bestimmte Werte aus HKLM/Software/Hersteller/SubKey auslesen. Bis Windows XP ging das immer einfach so. Mit Windows 7 gibt es nun auch eine Rechteverwaltung für Reg-Keys. Meine Applikation läuft mit eingeschränkten Benutzerrechten, muss aber Lesezugriff auf diese Reg-Keys erhalten. Kann ich das irgendwie über eine Gruppenrichtlinie machen? Da die GPO, die mein Programm anstößt nicht permanent für alle gilt, sondern nur temporär ein und wieder ausgeschaltet wird, wäre auch eine Lösung, die den User in dieser Zeit weniger einschränkt (z.B. UAC aus), akzeptabel. UAC kommt als Lösungsansatz für mich nicht so richtig in Frage, weil mein Programm ein VB6 Programm ist und ich keinen Schimmer habe, ob man eine Elevation überhaupt über ein VB6 Programm anfordern können wird. Über Tipps würde ich mich freuen! Gruß, T. EDIT: Hat sich erledigt. Der Fehler war, dass ich zum Zugriff auf die Registry Code verwendet habe, den ich ohne weiter zu prüfen aus einem Beispiel übernommen habe. Der Fehler lag darin, dass der Programmierer, der das Beispiel geschrieben hat, folgende Deklaration verwendet hat: Nach Recherche bin ich dann darauf gekommen, dass das "Access Denied" korrekt ist, denn ALL_ACCESS ist nicht READ!!! Aufs Notwendigste reduziert funktioniert das Lesen dann auch und damit brauche ich das im OP angegebene Einrichten der Leseberechtigung nicht, denn die hatte ich immer.

OK, ich habe inzwischen herausgefunden, dass Windows 7 die GPMC tatsächlich nicht mehr unterstützt. Meine Frage ist daher jetzt die: Gibt es ein Pendant? Ich will GPOs scripten.

Hi! Ich habe bisher für die Verwaltung von Gruppenrichtlinienobjekten die Scripte der GPMC genutzt. Mit der GPMC auf Windows 7 Clients klappt das nicht mehr. Beispiel: cscript FindGPOsBySecurityGroup.wsf "Domain Admins" /Permission:Read Microsoft (R) Windows Script Host, Version 5.8 Copyright (C) Microsoft Corporation 1996-2001. Alle Rechte vorbehalten. Searching for all GPOs with Read and Apply permissions for Domain Admins Attempt to query for group Domain Admins failed. The group may not exist. Das ist das Problem. Unter XP klappt das. Die Gruppe ist da, also die Aussage, dass die Gruppe vielleicht nicht da sein könnte, ist nicht zutreffend. Gibt es für Windows 7 neue GPMC Scripte? Kennt jemand die Ursache des Problems (und dann auch noch einen Lösungsansatz)? Oder soll ich mich lieber ans Windows 7 Forum wenden? T.

Hmm. OK, du kennst BDC noch nicht. Dann zweifle ich an, dass du mir helfen kannst. Aber du kannst dich hier schlau machen: Binary delta compression - Wikipedia, the free encyclopedia und: Delta Compression Application Programming Interface Und um das mal selbst zu sehen, dass da in dem Patchfile kein Executable drin ist, schaust du dir einfach mal einen Patch für Vista im Detail an, z.B. windows6.0-kb958690-x86-rc_7e745ae6a0604c0f88afc74bbb63f55b5e9b976d.cab Aber vielleicht kannst du mir helfen, indem du mir sagst, an wen ich mich wenden könnte.

Nee, grundsätzlich hast du mich eigentlich richtig verstanden, aber was du schreibst, gilt imho nur für die alten selfcontained Patches. Das gilt nicht für die neuen BDC-Patches. Darum geht es aber gerade. Ich muss in die Patche reinschauen und den Content analysieren, bevor die Patche ausgerollt werden. Aber bei den neuen Updates von MS wird die BinaryDeltaCompression verwendet, das heißt, das endgültig gepatchte Binary gibt es da gar nicht innerhalb des Patches, sondern es wird mit Hilfe des Patches aus dem alten Binary über das Delta das neue Binary. Und das funktioniert natürlich nur auf dem eigentlichen Zielsystem. Habe ich z.B. den WSUS 3 auf einem W2k3Srv laufen, kann ich ein Vista-Patch nicht in seiner finalen Form sehen, weil ich ja im WSUS Content nur das Delta habe, nicht aber das finale Resultat, weil das ja beim Patchen erst gebildet wird. Und auf dem WSUS Server habe ich dann keine Chance, das Patchen zur Analyse selbst zu machen, weil ich ja das originale File (das Vista File, das gepatcht werden soll) nicht habe. Ich hatte gehofft, MS würde beides anbieten, BDC-Updates und Selfcontained Updates, und man könnte den WSUS so konfigurieren, dass er nur noch die Selfcontained verwendet. Dann wäre es einfach.