Startupscript wird nicht ausgeführt

[lahe 0]

Hallo zusammen,

ich habe folgendes Problem und hoffe, dass Ihr mir bei der Lösung helfen könnt.

 

System:

Windows Server 2008 R2 und Windows7 Pro Clients. (Domäne)

 

Problem:

Ich habe ein Startscript, welches lediglich einen netsh-Befehl auf allen Clients ausführen soll um eine vorhandene Firewallregel zu aktivieren.

Das Script funktioniert, wenn ich es mit administrativen Rechten auf einem Client ausführe. Mit runas und den entsprechenden Parametern ebenfalls für nicht administrative Benutzerkonten. Nun möchte ich dieses Script als Startupscript ausführen. Startup von daher, weil laut mehreren Literaturen ein lokales admikonto zum ausführen verwendet wird.

 

Das Script liegt unter .../Machine/Scripts/Startup der entsprechenden GUID vom GPO und hat Lese/Ausführen-Rechte für Domänen-Computer als NTFS- und Freigebeberechtigungen.

Bei der Sicherheitsfilterung des GPO´s habe ich domänen-computer hinzugefügt.

 

Hinweise:

Auf dem AD sind alle Domänen-Computer unter Computers (Windows-Verzeichnis der Domänen-Computer) gelistet.

Benutzerscripte mit Befehlen, die keine administrativen Rechte benötigen funktionieren.

 

Fragen:

• Was muss ich tun, damit das GPO für einen bestimmten Computer (zu Testzwecken) wirksam wird? In eine extra OU verschieben? Spezielle Rechte zuweisen?
• Kann ich das Script irgendwie für Benutzerrichtlinien mit adminrechten verteilen
• Ich habe festgestellt, dass die Softwareverteilung vom AD ebenfalls nicht, funktioniert! kann dies in einem Zusammenhang stehen?
• Kann ich mir gpresult auch Computerrichtlinien abfragen?

Wie ist denn der generelle Umgang mit Computerrichtlinien. Muss ich eine OU haben mit den Computern, damit ich ebenso wie bei Benutzerrichtlinien mit einen GPO verknüpfen kann? Oder regelt man die Zuweisung über den Sicherheitsfilter?

 

Vielen Dank im Vorraus für die Mühen

 

[Sunny61 806]

 

Das Script liegt unter .../Machine/Scripts/Startup der entsprechenden GUID vom GPO und hat Lese/Ausführen-Rechte für Domänen-Computer als NTFS- und Freigebeberechtigungen.

Bei der Sicherheitsfilterung des GPO´s habe ich domänen-computer hinzugefügt.

OK.

 

 

Hinweise:

Auf dem AD sind alle Domänen-Computer unter Computers (Windows-Verzeichnis der Domänen-Computer) gelistet.

Benutzerscripte mit Befehlen, die keine administrativen Rechte benötigen funktionieren.

Erstell am besten eigene OUs, auf den Container Computers kannst Du keine GPOs direkt verlinken, auf einer OU schon. Ist einfacher in der Handhabung. Hier auch der passende Artikel dazu: http://www.gruppenrichtlinien.de/artikel/erstellen-einer-gruppenrichtlinie/

 

 

 

• Was muss ich tun, damit das GPO für einen bestimmten Computer (zu Testzwecken) wirksam wird? In eine extra OU verschieben? Spezielle Rechte zuweisen?

 

 

In eine eigene OU verschieben ist die einfachste Variante.

 

 

• Kann ich das Script irgendwie für Benutzerrichtlinien mit adminrechten verteilen

 

 

Verteilen ja, ausgeführt wird es aber nicht bzw. läuft auf Fehler. Als Computerstartupscript ist es richtig.

 

Welche NETSH Befehle führst Du in dem Script aus? Evtl. gibt es Alternativen die ohne Script benutzt werden können.

 

 

• Ich habe festgestellt, dass die Softwareverteilung vom AD ebenfalls nicht, funktioniert! kann dies in einem Zusammenhang stehen?

 

 

SW-Verteilung mittels Computer-GPO funktioniert. Lies dich doch mal ein: http://www.gruppenrichtlinien.de/artikel/softwarezuweisung-software-im-unternehmen-verteilen/

 

 

• Kann ich mir gpresult auch Computerrichtlinien abfragen?

 

 

Hast Du es denn schon ausprobiert? Wenn nein, weshalb nicht? Wenn ja, welche Fehlermeldungen bekommst Du bei genau welchen Befehlen angezeigt?

 

Wie ist denn der generelle Umgang mit Computerrichtlinien. Muss ich eine OU haben mit den Computern, damit ich ebenso wie bei Benutzerrichtlinien mit einen GPO verknüpfen kann? Oder regelt man die Zuweisung über den Sicherheitsfilter?

Übersichtlicher ist es IMHO in Computer- und BenutzerOU aufzuteilen. Wenn Du dann innerhalb der OU mit verschiedenen GPOs filtern möchtest, kannst Du immer noch auf Sicherheitsgruppen zurückgreifen.

[lahe 0]

Guten Morgen und erstmal danke für deine Antwort.

 

 

 

 

lahe, am 18 Nov 2013 - 15:59, sagte:

Hinweise:
Auf dem AD sind alle Domänen-Computer unter Computers (Windows-Verzeichnis der Domänen-Computer) gelistet.
Benutzerscripte mit Befehlen, die keine administrativen Rechte benötigen funktionieren.

Erstell am besten eigene OUs, auf den Container Computers kannst Du keine GPOs direkt verlinken, auf einer OU schon. Ist einfacher in der Handhabung. Hier auch der passende Artikel dazu: http://www.gruppenri...ppenrichtlinie/

 

Danke für den Hinweis, das ist ein echt guter Link. Werde mir die Seite mal genauer unter die Lupe nehmen.

 

Ich habe jetzt eine OU "Clients" erstellt in die ich meinen Test-PC aus dem Computers-Verzeichnis hinein geschoben. Ok das Prinzip ist mir klar und nach genauerer Überlegung auch nur logisch.

Habe dann ein GPO mit einem Start-Script erstellt und mit der OU "Clients" verknüpft. Script liegt diesmal unter der NETLOGON-Freigabe!

Bei der Sicherheitsfilterung Domänencomputer hinzugefügt und noch einmal die Freigabeberechtigungen auf der Netlogon Freigabe geprüft.Relevant:

Freigabe: Jeder-Lesen und Administratoren-Vollzugriff.

NTFS: Authentifizierte-Benutzer- Lesen/Ausführen;Standardmäßig kein Domänen-Computer!!!; Administratoren-Lesen/ausführen;Server-Operatoren-Lesen/Ausführen

 

Auf dem Server habe ich gpupdate /force ausgeführt und den Win 7 Client neu gestartet.

Nichts!!!

 

Also ich möchte im ersten Schritte folgenden Befehl ausführen:

 

 

netsh advfirewall firewall set rule group="Windows-Verwaltungsinstrumentation (WMI)" new enable=yes

 

im zweiten Schritt möchte ich das Script durch folgende Zeile erweitern  um eine Übersicht von den Clients zu bekommen, die den ersten Befehl ausgeführt haben:

 

 

echo %COMPUTERNAME%;%DATE%;%TIME%;enable >> \\192.168.XXX.XXX\ScriptReport\report.csv

 

 

Ich habe beide Zeilen in eine .bat gepackt und als admin auf Testclients ausgeführt. Läuft!

 

Normalerweise müsste ich, wenn es funktioniert hat die Gruppenrichtlinienereignisse vom AD aus für den Client abrufen können, aber da ich die Fehlermeldung "der RPC-Server ist nicht verfügbar" bekomme weiß ich, dass die Windows-Firewall auf dem Client den WMI-abruf blockt und mein Scriptabruf versagt hat. Natürlich funktioniert der Remotezugriff  mit gpresult auf dem Client auch nicht.

 

Der gpresult /R aufruf auf dem Client zeigt mir nicht dieses GPO an!!! Weder als angewendet und nicht angewendet. Das sagt mir, dass es nicht am Script liegt, sondern an der Ausführung der Richtlinie oder sehe ich das falsch?

Liegt es vielleicht an der fehlenden NTFS-Berechtigung für Domänen-Computer auf der NETLOGON-Freigabe? Welche Rechte werden denn auf der Freigabe benötigt, da ich laut Literaturquellen davon ausgehe, dass Startscripte von den höchstberechtigten lokalen Benutzerkonto auf dem Client ausgeführt werden?!?

[Sunny61 806]

Ich habe jetzt eine OU "Clients" erstellt in die ich meinen Test-PC aus dem Computers-Verzeichnis hinein geschoben. Ok das Prinzip ist mir klar und nach genauerer Überlegung auch nur logisch.

Habe dann ein GPO mit einem Start-Script erstellt und mit der OU "Clients" verknüpft. Script liegt diesmal unter der NETLOGON-Freigabe!

Bei der Sicherheitsfilterung Domänencomputer hinzugefügt und noch einmal die Freigabeberechtigungen auf der Netlogon Freigabe geprüft.Relevant:

Freigabe: Jeder-Lesen und Administratoren-Vollzugriff.

NTFS: Authentifizierte-Benutzer- Lesen/Ausführen;Standardmäßig kein Domänen-Computer!!!; Administratoren-Lesen/ausführen;Server-Operatoren-Lesen/Ausführen

In den Authentifizierten Benutzer sind auch die Computerkonten enthalten. Sorry, das ist Grundlagenwissen, das mußt Du dir schon vorher aneignen.

 

Auf dem Server habe ich gpupdate /force ausgeführt und den Win 7 Client neu gestartet.

Nichts!!!

Überleg doch mal, Du führst auf dem Server gpupdate /force aus. Was genau bewirkt das? Was bringt ein Befehl auf dem Server wenn ein Client der Betroffene sein soll? Genau, nichts bewirkt der Befehl. Grundlagen!

 

Mit Netlogon waren auch Loginscripte gemeint, steht in dem Artikel auch recht deutlich. Du mußt also den Pfad zum Script exakt angeben. Aber achte auf die Verwendung von UNC-Pfaden innerhalb des Scriptes!

 

Also ich möchte im ersten Schritte folgenden Befehl ausführen:

 

 

 

netsh advfirewall firewall set rule group="Windows-Verwaltungsinstrumentation (WMI)" new enable=yes

 

im zweiten Schritt möchte ich das Script durch folgende Zeile erweitern  um eine Übersicht von den Clients zu bekommen, die den ersten Befehl ausgeführt haben:

 

 

echo %COMPUTERNAME%;ÚTE%;%TIME%;enable >> \\192.168.XXX.XXX\ScriptReport\report.csv

 

 

Ich habe beide Zeilen in eine .bat gepackt und als admin auf Testclients ausgeführt. Läuft!

 

 

Gut.

 

Normalerweise müsste ich, wenn es funktioniert hat die Gruppenrichtlinienereignisse vom AD aus für den Client abrufen können, aber da ich die Fehlermeldung "der RPC-Server ist nicht verfügbar" bekomme weiß ich, dass die Windows-Firewall auf dem Client den WMI-abruf blockt und mein Scriptabruf versagt hat. Natürlich funktioniert der Remotezugriff  mit gpresult auf dem Client auch nicht.

Dann melde dich auf dem Client an und schau in das Ereignisprotokoll. Es gibt auch ein spezielles GPO-Log, das muß allerdings erst aktiviert werden. Bis zu einem gewissen Punkt kann man das auch via GPO erledigen. In http://support.microsoft.com/kb/944043/de findest Du weitere Infos dazu.

 

Falls nichts angelegt wird, keine Bange, hier gibt es einen Artikel dazu: http://blogs.technet.com/b/deds/archive/2010/01/12/group-policy-debug-logging-gpsvc-log-in-windows-7-und-server-2008-r2.aspx

 

Der gpresult /R aufruf auf dem Client zeigt mir nicht dieses GPO an!!! Weder als angewendet und nicht angewendet. Das sagt mir, dass es nicht am Script liegt, sondern an der Ausführung der Richtlinie oder sehe ich das falsch?

Liegt es vielleicht an der fehlenden NTFS-Berechtigung für Domänen-Computer auf der NETLOGON-Freigabe? Welche Rechte werden denn auf der Freigabe benötigt, da ich laut Literaturquellen davon ausgehe, dass Startscripte von den höchstberechtigten lokalen Benutzerkonto auf dem Client ausgeführt werden?!?

Warum fangst Du nicht mit einfachen Dingen an? Spiel doch zuerst die Beispiele von http://www.gruppenrichtlinien.de/artikel/erstellen-einer-gruppenrichtlinie/ durch. Benutzer-GPO erstellen, Bildschirmschoner rein, Computer-GPO erstellen, eine Einstellung vornehmen die man gleich nach einem Neustart sieht.

 

Und auf alle Fälle immer diese beiden Einstellungen aktivieren: http://www.gruppenrichtlinien.de/artikel/fast-logon-schnelles-anmelden-asynchrones-startverhalten-ehemals-faq-36/

[lahe 0]

Also:

 

Warum fangst Du nicht mit einfachen Dingen an? Spiel doch zuerst die Beispiele von http://www.gruppenri...ppenrichtlinie/ durch. Benutzer-GPO erstellen, Bildschirmschoner rein, Computer-GPO erstellen, eine Einstellung vornehmen die man gleich nach einem Neustart sieht.

Nett gemeinter Hinweis aber ich habe bereits divesre Gruppenrichtlinien (Benutzer), die laufen von Ordnerumleitungen, Verknüpfungen, Wechseldatenträgermanagement usw.

Es hatte nur an diesen verflixten Computerrichtlinien gescheitert.

Erledigt durch die eigene OU für die Clients. Danke für den Tipp

 

 

Dann melde dich auf dem Client an und schau in das Ereignisprotokoll. Es gibt auch ein spezielles GPO-Log, das muß allerdings erst aktiviert werden.

gut zu wissen. Schaue ich mir auf jedenfall mal an. Danke

 

 

In den Authentifizierten Benutzer sind auch die Computerkonten enthalten. Sorry, das ist Grundlagenwissen, das mußt Du dir schon vorher aneignen.

Kann sein... weder im Studium, noch beim MS-Kurs oder im MS-Press/Galileobook angesprochen. Also eher insidergrundlagen... wie auch immer. Danke

 

Überleg doch mal, Du führst auf dem Server gpupdate /force aus. Was genau bewirkt das? Was bringt ein Befehl auf dem Server wenn ein Client der Betroffene sein soll? Genau, nichts bewirkt der Befehl. Grundlagen!

habe es aber in der Praxis schon das eine oder andere mal erlebt, dass Richtlinien erst sofort an den Client übermittelt wurden als ich gpupdate /force auf dem server und gpupdate /target:user /force /wait:0  auf dem Client ausgeführt habe. Wird auch im Studium gelehrt

 

Grundlagen!

Ausnahmen bestätigen die Regel

 

 

Mit Netlogon waren auch Loginscripte gemeint, steht in dem Artikel auch recht deutlich. Du mußt also den Pfad zum Script exakt angeben. Aber achte auf die Verwendung von UNC-Pfaden innerhalb des Scriptes!

 

Komisch... Ich habe meinen Fehler im UNC-Pfad ausfindig gemacht und siehe da. Es funktioniert. Steht dort recht deutlich, hast recht :-)

 

Zitat http://www.gruppenrichtlinien.de/artikel/anmelde-skripte/:

Besserer Speicherort der Gruppenrichtlinien Skripte, empfohlen:
Man speichert die Skripte im NETLOGON der Domäne, ein alternativer selbstdefinierter Speicherort ist schon wie bei den alten NT4 Skripten nicht erlaubt. Entweder das NETLOGON oder der Pfad innerhalb der Richtlinie im SYSVOL. Jetzt muss das Skript aber komplett inklusive Pfad im Skripnamen des GP Editors angegeben werden.

 

Vielen Dank für deine Hinweise. Im Endeffekt lag es der Fehlenden OU für die Clients

bearbeitet 19. November 2013 von lahe

[Sunny61 806]

Nett gemeinter Hinweis aber ich habe bereits divesre Gruppenrichtlinien (Benutzer), die laufen von Ordnerumleitungen, Verknüpfungen, Wechseldatenträgermanagement usw.

Es hatte nur an diesen verflixten Computerrichtlinien gescheitert.

Was ist daran anders? Nichts, nur der Zweig ist ein anderer. ;)

 

 

Erledigt durch die eigene OU für die Clients. Danke für den Tipp

 

Bitte, gern geschehen. ;)

 

 

 

 

 

 

Kann sein... weder im Studium, noch beim MS-Kurs oder im MS-Press/Galileobook angesprochen. Also eher insidergrundlagen... wie auch immer. Danke

Kein Insiderwissen, reines Grundlagenwissen!

 

 

habe es aber in der Praxis schon das eine oder andere mal erlebt, dass Richtlinien erst sofort an den Client übermittelt wurden als ich gpupdate /force auf dem server und gpupdate /target:user /force /wait:0  auf dem Client ausgeführt habe. Wird auch im Studium gelehrt

Es wird kein GPO bzw. keine Einstellung an den Client 'übermittelt'. Das ist ein Prozess der vom Client aus initiiert wird, ab Start des Client für die Computer und beim Anmelden für den Benutzer. Lies bitte selbst: http://www.gruppenrichtlinien.de/artikel/was-sind-gruppenrichtlinien/ Der Client holt ~90 +-30 Minuten die GPO-Einstellungen vom DC ab, du hattest möglicherweise Glück dass Du den richtigen Zeitpunkt erwischt hast.

 

Nicht alles was im Studium gelehrt wird, ist scheinbar richtig.

 

 

 

Vielen Dank für deine Hinweise. Im Endeffekt lag es der Fehlenden OU für die Clients

Und das sind schon wieder Grundlagen gewesen. ;)

bearbeitet 19. November 2013 von Sunny61

[lahe 0]

Was ist daran anders? Nichts, nur der Zweig ist ein anderer.

Ach was. Flüchtigkeitsfehler... kommt in den besten Familien vor, dass man neu in ein Unternehmen kommt. Den Laden erst einmal "aufräumen" und dabei für "Kleinigkeiten" blind wird

Es wird kein GPO bzw. keine Einstellung an den Client 'übermittelt'. Das ist ein Prozess der vom Client aus initiiert wird, ab Start des Client für die Computer und beim Anmelden für den Benutzer. Lies bitte selbst: http://www.gruppenri...penrichtlinien/ Der Client holt ~90 +-30 Minuten die GPO-Einstellungen vom DC ab, du hattest möglicherweise Glück dass Du den richtigen Zeitpunkt erwischt hast.

Nenne es initieren oder übermittel von adm/admx daten aus denen auf den Clients Registryschlüssel gesetzt werden. Das ist jetzt Haarspalterei. Das 90-30 Prinzip ist mir wohl geläufig. Egal

 

Nicht alles was im Studium gelehrt wird, ist scheinbar richtig.

Die Bücher werden neu geschrieben

 

Und das sind schon wieder Grundlagen gewesen

Klar... wie eben gesagt kann man irgendwann auch mal einen Fehler machen. Es ist nur nicht eine korrekte Form jemanden zuverbessern und dabei auf eine Quelle zu verweisen, im unrecht zu sein bei eigenen Quellverweis und es als mangelde Grundlagen anderer abzustempeln. Wirkt sehr unqualifiziert. Nochmals Vielen Dank. Thema beendet

[Sunny61 806]

Nenne es initieren oder übermittel von adm/admx daten aus denen auf den Clients Registryschlüssel gesetzt werden. Das ist jetzt Haarspalterei. Das 90-30 Prinzip ist mir wohl geläufig. Egal

Der Client saugt, nicht der Server schiebt. Der Unterschied ist klein, aber doch sehr wichtig.

 

 

Klar... wie eben gesagt kann man irgendwann auch mal einen Fehler machen. Es ist nur nicht eine korrekte Form jemanden zuverbessern und dabei auf eine Quelle zu verweisen, im unrecht zu sein bei eigenen Quellverweis und es als mangelde Grundlagen anderer abzustempeln. Wirkt sehr unqualifiziert. Nochmals Vielen Dank. Thema beendet

Und wo war ich im Unrecht?