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.

Hi! Gibt es eine Möglichkeit einen WSUS Server so zu konfigurieren, dass er keine BDC-Updates (Binary-Delta-Compression) mehr verwendet, sondern nur noch "selfcontained" (old-style) Upates? Diese Delta-Updates machen den ganzen vor einem Update stattfindenden Security-Audit unmöglich, weil man vor dem Update nie sagen kann, wie das Binary nach dem Update genau aussehen wird. Beim alten selfcontained update war das anders, da war die neue Datei einfach in dem Patch, das Ding konnte man untersuchen und wusste was man hatte. BDC ist in dieser Hinsicht scheinbar ein K.O. Kriterium, außer mir sagt hier jemand, was ich übersehen habe. Thx, T.

Ich habe mal alles Mögliche abgeschaltet (siehe Screenshot in meinem Posting von oben), vermutlich mehr als ich gemusst hätte, was aber an sich kein Risiko darstellt, da die GPO nicht permanent gilt, sondern nur kurzzeitig während der Prüfung / Installation der Software. Ist das erfolgreich durchgelaufen, wird der Rechner wieder aus der Gruppe rausgenommen und damit gilt die GPO nicht mehr und alles ist wie vorher. Gruß, T.

Alles toll! Klappt jetzt! Da ist der Papa aber froh! ;-)

Ich probiere noch mal rum und melde mich hier noch mal.

Hi! Ich habe ein kleines Tool geschrieben, das wie "runas" Software unter einem bestimmten (admin) Benutzer startet. So ähnlich wie "runasspc", das hier vielleicht bekannt ist. Ich verwende das zur Softwareverteilung, indem ich im Ad ein GPO Computerkonfiguration/Administrative Vorlagen/System/Diese Programme bei der Benutzeranmeldung ausführen anlege, was bisher (Win2k, XP) korrekt dazu geführt hat, dass, immer wenn ein Benutzer sich eingeloggt hat, mein Tool startet und mit Admin-Rechten prüft, ob die Software, die der Computer haben soll, auch installiert ist und falls nötig ein unattended setup nachzieht. Dabei habe ich die GPO außerdem per Sicherheitsfilterung an die Mitgliedschaft einer bestimmten Gruppe gebunden, was dazu führt, dass ich einen Rechner in die Gruppe aufnehmen kann, dadurch wird die GPO angewendet und die Software installiert. So eine Art Software-Verteilung für Arme. Dies funktioniert nun unter Vista nicht mehr. Beim Aufruf des runas-ähnlichen Tools zur Privilegieneskalation bekomme ich die Meldung "Der Vorgang erfordert erhöhte Rechte". Nun vermute ich, dass ich dies der UAC verdanke. Bleibt die Frage, wie ich das wieder zum Laufen bekommen kann, und zwar, ohne dass ich jeden Rechner von Hand anfassen muss, sondern über eine Gruppenrichtlinie oder (temporäre) Änderung eines Registry-Keys. Mein Versuch unter "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System\ConsentPromptBehaviorAdmin " auf 0 zu stellen hat auch nichts gebracht. Über Hilfe würde ich mich echt freuen! Gruß, T. ----------------- Nur als Anmerkung, um Hinweise wie "mach das doch ganz anders, indem du ..." oder so zu vermeiden: Beim Ausrollen mancher Software-Pakete wird zwingend sofort ein Reboot benötigt. Da ich dem Benutzer den Rechner nicht während der Arbeit an seinen Dokumenten wegreißen kann, muss der automatisch durch die Installation angestoßene Reboot zu einem Zeitpunkt erfolgen, bei dem der Benutzer noch nichts Wichtiges gemacht haben kann. Daher habe ich "Diese Programme bei der Benutzeranmeldung ausführen" gewählt, denn das ist immer zu einem Zeitpunkt, bei dem der Benutzer den Reboot problemlos verkraften kann.

Ja sicher. Aber das Beste ist: Das AD macht der Kunde gar nicht selbst, sondern ein ziemlich großes Rechenzentrum. Also der Kunde hat nur einen Tree im Forest des RZ. Und das RZ ist sehr arrogant und schmettert alle "Das ist nicht OK so!"-Hinweise mit einem lapidaren "Wir haben Experten, die sagen, dass das gut so ist, also fassen wir das nicht an." ab. Da kann man nix machen. Wichtig war mir nur, dass der Kunde glücklich ist. Mit meiner Software ist er es jedenfalls, weil auch er sieht, dass die Ursachen wohl eher im RZ zu suchen sind und ich mir trotzdem Mühe gegeben habe, sein Problem zu lösen. Ich kann diese ganzen Fans des Outsourcing nicht wirklich verstehen. Naja.

ADInsight stürzt immer während des Zugriffs ab. Auf einem Vista und einem XP Rechner mehrfach reproduziert. Hier in meiner Testumgebung läuft das Tool prima, beim betreffenden Kunden nicht. Es ist zum ****en. Ich komme bei dem Kunden nicht weiter. Ich habe jetzt einen Workaround gemacht, indem ich die Gruppe einfach überspringe. Ich hasse sowas, es ist schlechter Stil, macht meine Software "schlecht". Aber ich kann den Kunden nicht noch weiter mit meinen Versuchen nerven. Ich danke euch trotzdem für die netten Hilfestellungen!

Ohne zu verstehen, wieso du das fragst, habe ich es einfach mal ausprobiert: "error nr. 13, Type mismatch" Ich werde jetzt mal ADInsight ausprobieren. Mal sehen, das Tool klingt jedenfalls nicht schlecht.

So, ich habe jetzt beim Kunden ins AD schauen dürfen und die Aktion mit ADFind.exe versucht nachzuvollziehen. Doch zunächst einmal zu dem, was ich in meinem Code genau mache. In meinem Tool frage ich nach der Primärgruppen-ID: strDN = strADSPath Set objGroup = GetObject("LDAP://" & strDN) objGroup.GetInfoEx Array("primaryGroupToken"), 0 intGroupToken = objGroup.Get("primaryGroupToken") Ich bekomme bei der betroffenen Gruppe einen Token zurück, nämlich "1433". Dann frage ich das AD nach der Primärgruppe: <LDAP://DC=XX,DC=de>;(primaryGroupID=1433);sAMAccountName,objectCategory;subtree Das bleibt in diesem Falle leer, das heißt, ich bekomme keinen Datensatz zurück (was durchaus OK sein kann, denke ich). Um dann noch die anderen (nicht-primären) Gruppen auszulesen, frage ich noch die .Members ab: For Each objMember In objGroup.Members Da hängt dann mein Programm. Jetzt, was ich ausprobiert habe: adfind -b "DC=XXDomainXX,DC=de" -f "primaryGroupID=1433" Returnt nichts, also NULL. ADFind auf das konkrete Objekt bezogen adfind -b "CN=Exchange Enterprise Servers,CN=Users,DC=XX,DC=de" -f "objectclass=group" liefert aber durchaus Members. Also ADFind ist in der Lage, Mitglieder auszulesen. Die Frage ist: was sagt mir das nun?

Nee, nicht wirklich: CN=Exchange Enterprise Servers,CN=Users,DC=Domainname,DC=de Klar, Leerzeichen kann man auch Sonderzeichen nennen, aber das hat auch bei anderen Gruppen problemlos funktioniert (z.B. "Gruppe 34"). – Nils, Danke für deine Geduld und Erklärung. Ich werde mal versuchen das rauszubekommen. Dazu muss ich aber erst wieder Zugriff auf das betreffende AD haben, und das kann noch etwas dauern. Ich melde mich, sobald ich Neuigkeiten habe, darauf kannst du dich verlassen! ;) Gruß, T.