ITasv Geschrieben 17. Oktober 2011 Geschrieben 17. Oktober 2011 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 Zitieren
Nikomania Geschrieben 17. Oktober 2011 Geschrieben 17. Oktober 2011 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? Zitieren
ITasv Geschrieben 18. Oktober 2011 Autor Geschrieben 18. Oktober 2011 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. Zitieren
DDoS Geschrieben 18. Oktober 2011 Geschrieben 18. Oktober 2011 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 Zitieren
ITasv Geschrieben 18. Oktober 2011 Autor Geschrieben 18. Oktober 2011 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. Zitieren
DDoS Geschrieben 18. Oktober 2011 Geschrieben 18. Oktober 2011 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. Zitieren
DDoS Geschrieben 18. Oktober 2011 Geschrieben 18. Oktober 2011 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 Zitieren
ITasv Geschrieben 18. Oktober 2011 Autor Geschrieben 18. Oktober 2011 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... Zitieren
DDoS Geschrieben 18. Oktober 2011 Geschrieben 18. Oktober 2011 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 Zitieren
ITasv Geschrieben 18. Oktober 2011 Autor Geschrieben 18. Oktober 2011 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... Zitieren
SilentDemise Geschrieben 18. Oktober 2011 Geschrieben 18. Oktober 2011 Könnte Information about new Group Policy preferences in Windows Server 2008 auf dich zutreffen? Zitieren
Tiro Geschrieben 20. Oktober 2011 Geschrieben 20. Oktober 2011 schau dir mal die Ausgabe von rsop.msc an. Das ist normalerweise recht aufschlußreich. Zitieren
DDoS Geschrieben 20. Oktober 2011 Geschrieben 20. Oktober 2011 @ 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. Zitieren
Tiro Geschrieben 20. Oktober 2011 Geschrieben 20. Oktober 2011 @ 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 Zitieren
ITasv Geschrieben 25. Oktober 2011 Autor Geschrieben 25. Oktober 2011 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 Zitieren
ITasv Geschrieben 25. Oktober 2011 Autor Geschrieben 25. Oktober 2011 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... Zitieren
ITasv Geschrieben 25. Oktober 2011 Autor Geschrieben 25. Oktober 2011 "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. Zitieren
ITasv Geschrieben 25. Oktober 2011 Autor Geschrieben 25. Oktober 2011 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.... Zitieren
Empfohlene Beiträge
Dein Kommentar
Du kannst jetzt schreiben und Dich später registrieren. Wenn Du ein Konto hast, melde Dich jetzt an, um unter Deinem Benutzernamen zu schreiben.