Softwareverteilung via GPO funktioniert bei Win 7; bei XP nicht

[ITasv]

Hallo zusammen,

ich habe eine Computer-GPO erstellt, welche den Foxitreader installieren soll. Bei den Windows-7-Clients funktioniert das einwandfrei. XP behauptet jedoch, keinen Zugriff auf das Verzeichnis zu haben.

Ereignistyp: Fehler

Ereignisquelle: Application Management

Ereigniskategorie: Keine

Ereigniskennung: 102

Datum: 17.10.2011

Zeit: 14:35:15

Benutzer: NT-AUTORITÄT\SYSTEM

Computer: TESTXP

Beschreibung:

Die Installation der Anwendung Foxit Reader der Richtlinie Softwareverteilung ist fehlgeschlagen. Fehler: Die Installationsquelle für dieses Produkt ist nicht verfügbar. Stellen Sie sicher, dass die Quelle vorhanden ist und Sie Zugriff darauf haben.

Weitere Informationen über die Hilfe- und Supportdienste erhalten Sie unter http://go.microsoft.com/fwlink/events.asp.

Verschiedenes:

- die Software läuft auf 32-Bit-Clients

- die Spracheinstellung in der GPO steht auf ‚ignorieren‘

- die GPO wird ausgeführt (es steht kurz da ‚Foxit.. wird installiert und so steht es auch nach einem gpresult da)

- DNS-Problem kann es nicht sein; habe die IP des Servers verwendet

- die MSI funktioniert bei manueller Installation auch bei XP – habe aber auch schon zwei, drei andere Pakete getestet, die bei 7 immer funktionierten und bei XP nicht

Berechtigungen (zu Testzwecken vollständig) haben auf NTFS-Basis:

Authenticated Users

Domain Computers (alle Testrechner sind dort definitiv drin)

Network Service (das hat schon mal geholfen, weiß aber nicht mehr, wobei)

Everyone

System

Admins

Berechtigungen auf Share-Basis haben:

Domain Computers

Everyone

Admin

Wenn ich die Shareberechtigungen um ‚Authenticated Users‘ und/oder ‚Network Service‘ erweitern möchte, so kann man die Schritte ohne Fehlermeldung durchführen, allerdings sind die beim nochmaligen Prüfen sofort wieder weg. Vielleicht liegt hier der Fehler? Wieso funktioniert es dann bei Windows 7?

Ich hab‘ die Schnauze voll und mache gleich Feierabend; vielleicht hat ja bis morgen schon jemand was hilfreiches geschrieben.

Vielen Dank

[Nikomania]

Spontan fällt mir da nur ein, dass der XP Client nicht mit der GPO umgehen kann, weil die erweitere Gruppenrichtlinien verwaltung fehlt - die bei Windows 7 immer vorhanden ist. --> Download Details - Microsoft Download Center - Group Policy Preference Client Side Extensions for Windows XP (KB943729)

Auf was für einen Server läuft der DC? Und auf welches Domänen-Funktionslevel ist der eingestellt?

[ITasv]

domainControllerFunctionality: 4 = ( WIN2008R2 );

domainFunctionality: 4 = ( WIN2008R2 );

forestFunctionality: 4 = ( WIN2008R2 );

Auf was für einen Server läuft der DC?

Wie meinst du das genau? Als Hardware kommt ein Xeon X5650 2,67 GHz zum Einsatz.

Die GPO-Extension hat übrigens nichts gebracht.

---------

Was ist denn mit meinen Fragen aus dem ursprünglichen Post? Es ist ja dann doch recht naheliegend, dass es an den Shareoptionen liegt.

[DDoS]

Hi ITasv !

Ja liegt definitiv an den Rechten. Deine Test-Maschine hat keinen Zugriff auf den Share versuch mal bitte den Computer Account direkt mit "Lesen" Rechten einzubinden.

Alternativ bau dir doch ne Security Group pack den Test-XP da rein und gib der Gruppe die "Lesen" rechte auf dem Share.

Gruß DDoS

[ITasv]

Spontan fällt mir da nur ein, dass der XP Client nicht mit der GPO umgehen kann, weil die erweitere Gruppenrichtlinien verwaltung fehlt - die bei Windows 7 immer vorhanden ist. --> Download Details - Microsoft Download Center - Group Policy Preference Client Side Extensions for Windows XP (KB943729)

Auf was für einen Server läuft der DC? Und auf welches Domänen-Funktionslevel ist der eingestellt?

Test-XP gehört 'Domain Computers' an und hatte dementsprechend auf beiden Ebenen die Berechtigungen. Ich habe irgendwie trotzdem das Gefühl, dass es an den Shareberechtigungen liegt, da das Verhalten da - wie oben beschrieben - so merkwürdig ist.

[DDoS]

Pack mal SYSTEM beim Share mit "READ" rein. Und starte deine Test-XP Kiste mal neu. Die Distribution Policy sollte ja ne Computer Richtlinie sein die werden unter System ausgeführt, sind ja User unabhängig. Und mach auf jeden fall mal nen reboot anstatt gpupdate /force.

[DDoS]

Schon seltsam hast ja Everyone bei NTFS und SMB drin..... Vllt nochmal die XP - Maschine raus aus der Domain den Computer Acoount löschen und danach wieder reinpacken. Und vllt die .msi Datei nochmal neu in die Policy einbinden. Wenn das nicht hilft müsste ich selber Dr.Google fragen...

Ich hoffe ich konnte dir helfen.

Gruß DDoS

[ITasv]

Danke schonmal für deine Hilfe.

Die Idee hatte ich auch schon und habe den Rechner aus der Domain geworfen und wieder eingebunden; das hat auch nichts gebracht. Ich habe das auch mit dem identischen Ergebnis an anderen Computern getestet.

Wenn ich SYSTEM unter SMB einfüge, dann ist es wie gesagt beim nächsten Mal sofort wieder weg. Den Rechner starte ich übrigens jedes Mal neu, da die Installation sonst sowieso nicht ausgelöst würde.

Ich habe testweise mal eine Userpolicy angelegt und die funktioniert erwartungsgemäß sofort. Das ist doch Murks, muss schlussendlich ja aber an den Berechtigungen liegen. Aber auch das macht in meinen Augen nur sehr bedingt Sinn, denn sonst würde es bei Windows 7 ja auch nicht funktionieren.

Ich könnte so heftig rumfluchen...

[DDoS]

War eben Kaffe holen und da ist es mir wie Schuppen von den Augen gefallen ^^. Bei XP war da ja was mit den Computerrichtlinen bim Booten

Quelle: Gruppenrichtlinien.de FAQ 36

Einen "Klassiker" bei XP Clients stellt das geänderte Bootverhalten von XP gegenüber zu W2K dar. Damit der Benutzer das Gefühl bekommt, daß System würde wesentlich schneller starten, wird die Explorerschnittstelle schon gestartet, obwohl noch nicht alle Dienste zur Verfügung stehen. Diese werden nachgeladen. Dummerweise gilt das auch für die Netzwerktreiber :-(

Zum Anmeldezeitpunkt ist das Netzwerk noch nicht bereit. Was dann zur Ursache hat, daß der Client mit "Cached Logon Credentials" arbeitet und effektiven Richtlinien nicht gelesen hat, obwohl im Startbildschirm "Sicherheitsrichtlinien werden übernommen ..." angezeigt wurde.

Damit diese Richtlinie auch wirklich beim nächsten Mal aktiv ist, empfehle ich eine erzwungene Übernahme der Richtlinie in der Kommandozeile.

gpupdate /target:computer /force

Würde erklären warum der Share zu dieser Zeit nicht verfügbar ist.

Gruß DDoS

[ITasv]

Da hatte ich jetzt große Hoffnung und eine noch größere Enttäuschung.

Habe da direkt Nägel mit Köpfen gemacht und diese beiden Einstellungen gesetzt:

Computerkonfiguration/Administrative Vorlagen/System/Skripts\Anmeldeskripts gleichzeitig ausführen

Computerkonfiguration/Administrative Vorlagen/System/Anmeldung\Beim Neustart des Computers und bei der Anmeldung immer auf das Netzwerk warten

siehe: LDAP://Yusufs.Directory.Blog/ - Asynchrones Startverhalten beim Windows XP

Interessiert die Maschine aber natürlich nicht...

WAS SOLL DAS ... FUNKTIONIER!!!!!!

Edit: Habe die übrigens über die GPO gesetzt und 'enforced' eingestellt...

[SilentDemise]

Könnte Information about new Group Policy preferences in Windows Server 2008 auf dich zutreffen?

[Tiro]

schau dir mal die Ausgabe von rsop.msc an. Das ist normalerweise recht aufschlußreich.

[DDoS]

@ Tiro:

Die Policy schien ja zu greifen aber der Share ist zum Zeitpunkt an dem die Softwareverteilung nach dem Paket sucht (noch) nicht verfügbar zu sein.

@ ITasv:

Schon was erreicht kannst ja mal schreiben was gpresult und RSOP sagen. Denke aber nicht das es generell an der Policy liegt. Wenn's gar nicht geht muss es halt ne User-Policy werden. Da ist der Share dann auf jeden Fall da wenn die Policy greift.

[Tiro]

@ Tiro:

Die Policy schien ja zu greifen aber der Share ist zum Zeitpunkt an dem die Softwareverteilung nach dem Paket sucht (noch) nicht verfügbar zu sein.

Gibt es uU die EventID 1054?

Ich verweise mal auf http://www.fachinformatiker.de/windows-betriebssysteme/149117-domaenencontrollername-fuer-computernetzwerk-konnte-ermittelt.html#post1337054

[ITasv]

Könnte Information about new Group Policy preferences in Windows Server 2008 auf dich zutreffen?

Den Vorschlag hat Nikomania schon gemacht; hat nichts gebracht.

schau dir mal die Ausgabe von rsop.msc an. Das ist normalerweise recht aufschlußreich.

Die Informationen entsprechen denen aus gpresult und dem Eventviewer. Leider hilft das nicht weiter. Den relevanten Teil habe ich auch schon in diesem Thread gepostet.

Schon was erreicht kannst ja mal schreiben was gpresult und RSOP sagen. Denke aber nicht das es generell an der Policy liegt. Wenn's gar nicht geht muss es halt ne User-Policy werden. Da ist der Share dann auf jeden Fall da wenn die Policy greift.

Nein, bin auch noch nicht groß dazu gekommen, daran weiterzuarbeiten. Die Policy wird ausgeführt, das ist nicht das Problem. Eine Userpolicy hilft mir leider gar nicht.

Gibt es uU die EventID 1054?

Ich verweise mal auf http://www.fachinformatiker.de/windo...ml#post1337054

Der Fehler steht ein paarmal im Eventlog, allerdings sind die Meldungen schon sehr alt. Sicherlich zustande gekommen, wenn die VBox-Netzwerkbrücke nicht aktiviert war.

COMPUTEREINSTELLUNGEN

----------------------

CN=TESTXP,OU=Computer,OU=zensiert,DC=win,DC=zensiert,DC=zensiert,DC=bla

Zeit der letzten Gruppenrichtlinienanwendung: 25.10.2011 at 08:44:17

Gruppenrichtlinie wurde angewendet von: zensiert.bla

Gruppenrichtlinienschwellenwert für langsame Verbindung: 500 kbps

Angewendete Gruppenrichtlinienobjekte

--------------------------------------

Windows Update (automatischen Neustart deaktivieren)

Foxit-Reader

Bla Default Policy

Default Domain Policy

Richtlinien der lokalen Gruppe

Hat vielleicht jemand eine Idee, bei welchen sonstigen GPOs während des Startvorgangs auch ein Share für die Computer zur Verfügung stehen muss? Dann kann ich die Suchbegriffe mal ändern, denn so komme ich scheinbar nicht weiter.

Vielen Dank für eure Hilfe

[ITasv]

Ich habe jetzt auch mal probiert, die MSI-Datei im sysvol...scripts-Verzeichnis abzulegen und habe dort die entsprechenden Berechtigungen vergeben: kein Erfolg. Es liegt also auch nicht daran, dass die Datei auf dem Fileserver liegt.

Aber um nochmal darauf aufmerksam zu machen: Der Krempel funktioniert mit Windows 7 einwandfrei. Das _muss_ doch ein enorm merkwürdiger Fehler sein...

[ITasv]

"Olaf Engelke [MVP Windows Server]" wrote:

Als Workaround wurde dann in einem KB-Artikel empfohlen, den Mediasense der

Netzwerkkarte abzustellen.

Dafuer reicht eine .reg-Datei mit folgendem Inhalt:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]

"DisableDHCPMediaSense"=dword:00000001

Das habe ich auch probiert: bringt nix.

[ITasv]

Das ist doch unfassbar...es geht jetzt!

Man darf für XP keine IP in den UNC-Pfad bringen sondern man muss den zugewiesenen Namen verwenden.

Der installiert jetzt zwar seit fast 10 Minuten den Foxit-Reader, aber das Problem kann man sicher leichter in den Griff bekommen....