RottenSon667 10 Geschrieben 26. April 2011 Melden Teilen Geschrieben 26. April 2011 So Jungs, ich habe mal wieder ein Problem mit diesen besch.... neuen betriebssystemen. Nachdem die 2008er Server im netzwerkverkehr nur noch 1/3 der Leistung der hornalten Windows2000-Maschinen erreichen hoffe ich dass ich und meine User uns mit diesem Problem nicht gleichermaßen als gegeben abfinden müssen. Das war nämlich nicht lösbar, ich habs einfach aufgegeben. Nun aber zum aktuellen problem: Ich habe auf den 2008er Servern vorigen Mittwoch die GPO`s für die Softwareverteilung von Adobe Flash, Adobe Reader und dem Microsoft Compatibility Pack für Office2007 Fileformats erstellt und hausintern gestestet -> IO. Auf einem Standort ausgerollt (der kleinste, mit 5 XP-Rechnern), am nächsten Tag geschaut ob alles Safe ist -> IO. Nun habe ich die GPO überall angewendet wo schon die neuen Server stehen. Ein Standort ist schon komplett auf Win7 umgestellt. Hier waren die aktuellsten Versionen des Readers und Flash schon installiert. Nur die FileFormatConverters hätten installiert werden sollen. Heute Morgen rief dann einer der User an, er hätte keinen Adobe Reader mehr drauf. Die GPO hat nun also folgendes getan: Adobe Reader, Flash und Office FileFormatConverters-Pack deinstallieren, gucken ob die Installationsquelle da ist und der Meinung sein dass sie nicht da ist. Geil! Nachdem ich nun den gesamten Vormittag damit verbracht habe Berechtigungen zu prüfen, die GPOS zu prüfen und mich wie ein irrer durch Foren und Google zu lesen habe ich gerade resigniert und erstelle diesen Beitrag. Folgende Meldungen begleiten das Phänomen, welches eindeutig auf Windows7 zurückzuführen ist: Die Installation der Anwendung Adobe Reader X - Deutsch der Richtlinie Installation - Adobe Reader ist fehlgeschlagen. Fehler: %%1612 Jeweils Fehler 1612. Dieser deutet laut meinen Recherchen darauf hin dass die Installationsquelle nicht verfügbar ist. Ich habe auf dem DFS Share wo die MSI-Dateien liegen von Anfang an Berechtigungen für Authentifizierte Benutzer und Domänen-Admins zugewiesen gehabt. Das Hinzufügen von "Domänencomputer" oder (testweise mal ein Sicherheitsloch in die saubere Struktur gerissen) "Jeder" brachte keine Besserung. Beide Einträge sind nun wieder entfernt. HELP! MfG Maik Zitieren Link zu diesem Kommentar
MichaStgt 10 Geschrieben 27. April 2011 Melden Teilen Geschrieben 27. April 2011 Guten Morgen, nicht Hilfreich, wie ich finde aber interessant: GPO in Windows 2008R2 (msi installation) - No contact with clients Gruß Micha PS: Wenn die Software wie der Reader schon drauf war, und du eine neuinstallation machst, wird im Regelfall ein Repair oder Deinstall in der GUI angeboten. Wenn wir mal kurz davon ausgehen, das die Software deinstalliert wird, möchte die Software , meistens, die deinstallation von der Lokalen HDD machen, und wenn dann die MSI oder ähnlichers nicht mehr da sein sollte, macht es schon sinn das diese Meldung kommt. Zitieren Link zu diesem Kommentar
zahni 550 Geschrieben 27. April 2011 Melden Teilen Geschrieben 27. April 2011 Du hast doch erst in den UAC-Thread gepostet. Glaubst Du nicht, dass Du das gleiche "Problem" hast ? Wie installierst Du denn genau die MSI-Pakete ? -Zahni Zitieren Link zu diesem Kommentar
RottenSon667 10 Geschrieben 27. April 2011 Autor Melden Teilen Geschrieben 27. April 2011 Danke für die Antworten. Leider hat der verlinkte Thread keine neuen Erkenntnisse gebracht. Hier mehr Input: Also. Die Es gibt je Softwarepaket eine GPO (Name: Installation - Programmname) in der die Softwarepakete in der Computerkonfiguration zugewiesen sind. Das heißt die Pakete installieren sich vor der Nutzeranmeldung mit den Credentials des Computerkontos bzw. "System". Die Pakete liegen auf einem DFS-Share (\\Domain.loc\dfs\public\install_msi), welches Freigabe- und Dateisystemberechtigungen für authentifizierte nutzer (lesen) und Domänen-Admins (Vollzugriff) hat. Ich habe hier wie beschrieben auch einmal mit "Domänencomputer" und "Jeder" Vollzugriff probiert, hat aber nichts genützt. Davon ab klappts ja bei den XP-Maschinen Domänenweit in 4 Standorten. Der DFS ist zugreifbar wenn man angemeldet ist, als Domänencomputer kann ich das natürlich nicht testen. UAC ist auf den betreffenden Maschinen wegen anderen kleinigkeiten deaktiviert. MfG Maik P.S.: Micha, es wäre schön gewesen wenn eine GUI gekommen wäre. Es hat jedoch nur die Richtlinie gegriffen und die vorhandenen Versionen der zu installierenden Adobe-Produkte deinstalliert. Wäre wie gesagt kein Problem gewesen, aber die Neuinstallation schlägt mit Fehler %%1612 fehl. die Knowledgebase satz dazu: List of error codes and error messages for Windows Installer processes in Office 2003 products and Office XP products The installation source for this product is not available. Verify that the source exists and that you can access it. Berechtigungen passen aber wie gesagt, und bei XP-Maschinen läufts tadellos durch. Zitieren Link zu diesem Kommentar
MichaStgt 10 Geschrieben 27. April 2011 Melden Teilen Geschrieben 27. April 2011 Bin auch noch am grübeln, kommt aber nichts brauchbares raus :) Da jeder Ansatz von mir durch ein anderes Ereigniss elemeniert wird.. Würde die MSI auf einem SYSVOL liegen, oder ist ein DFS mit einem Sysvol gleich zu setzen? Dann würde das hier in Frage kommen: Windows 2008 R2 doesn't like MSI on SYSVOL? in Windows Server Ähnliches Problem, nicht gelöst durch ein MVP siehe hier: GPO in Windows 2008R2 (msi installation) - No contact with clients Aber für dich wars***einlich nicht hilfreich. Der Fehler wird zwar dokumentiert, und fürht zu einem FixIT, aber unter XP gehts ja.. Tipparchiv - Microsoft Fix it Sammlung Teil IV - WinTotal.de Die Frage ist berechtigt wenn "mann" sich fragt ob die Datei auf dem Server vorhanden ist, wenn die Installation zum tragen kommt.. aber ich gehe davon aus das du eine kurze Replikation am laufen hast.. man ist echt nicht einfach. Ich weis aus meiner Netinstallpaketierei das sehr wohl unterschieden wird ob ein User angemeldet ist oder nicht, wenn eine MSI eine GUI aufruft, und es ist kein User angmeldet dann wird auch keine GUI aufgerufen.. aber bei dir scheitert es ja schon am Ansatz.. Was passiert wernn due die GPO umstellst? Das der User unter Software die Installation selbst aufrufen kann, klapp das ? Gruß Micha Zitieren Link zu diesem Kommentar
RottenSon667 10 Geschrieben 27. April 2011 Autor Melden Teilen Geschrieben 27. April 2011 Fehler eingegrenzt: Ich habe eine OU und eine Test-GPO erstellt. Einen Rechner zum Testen rein geschoben. Der Unterschied lag darin dass ich statt \\Domain.Loc\dfs\public das Paket von \\Servername\public zugewiesen habe. Ich bin nicht amüsiert. Irgendwelche Ideen warum die Windows7-Rechner das DFS-Share nicht mögen? Ich bin in der Lage von allen PC`s auf eben Dieses zuzugreifen wenn ein User angemeldet ist... MfG Maik Zitieren Link zu diesem Kommentar
RottenSon667 10 Geschrieben 28. April 2011 Autor Melden Teilen Geschrieben 28. April 2011 Neue Erkenntniss: Mir fiel auf dass ich in den Ordnernamen der MSI`s Leerzeichen hatte. Entfernung Dieser brachte keine Veränderung. Hat keiner eine Idee warum dieses ansonsten so gute Betriebssystem sich so abrupt weigert auf Dateien zuzugreifen die an einer Stelle liegen wo es ran darf? Wenn Ich ein NSLookup auf den Domainnamen mache kommt der lokale Server zurück. Die Berechtigungen passen (daran gesehen dass es bei Angabe des Servernamens direkt ja funktioniert!!!), das Systemkonto darf offensichtlich Sachen installieren und die gleiche Richtlinie unter XP angewendet funktioniert auch tadellos. An der MSI liegt es auch nicht, es schlagen mehrere fehl. Ich bin echt ein wenig ratlos. MfG Maik Zitieren Link zu diesem Kommentar
Cyrex4ever 10 Geschrieben 3. Juni 2011 Melden Teilen Geschrieben 3. Juni 2011 löl mein Acc geht hier sogar noch *freu* Ebenfalls freu über den thred... werde das ganze mal kurz von nem Server share testen aber es scheint als würde ich mich den ganzen abend ebenfalls mit der DFS thematik rumschalgen..... Dofes Win7 dass ^^ Aber zumindest eine verbesserung zu vista ^^ Zitieren Link zu diesem Kommentar
lefg 276 Geschrieben 4. Juni 2011 Melden Teilen Geschrieben 4. Juni 2011 ....unter XP angewendet funktioniert auch tadellos...... Hallo, eine Nachfrage: Betrifft das Problem nur W7-Rechner, unabhängig vom Standort und/oder Installationsquelle? Zitieren Link zu diesem Kommentar
lefg 276 Geschrieben 4. Juni 2011 Melden Teilen Geschrieben 4. Juni 2011 So Jungs, ich habe mal wieder ein Problem mit diesen besch.... neuen betriebssystemen. Mit welchem? Nachdem die 2008er Server im netzwerkverkehr nur noch 1/3 der Leistung der hornalten Windows2000-Maschinen erreichen hoffe ich dass ich und meine User uns mit diesem Problem nicht gleichermaßen als gegeben abfinden müssen. Das war nämlich nicht lösbar, ich habs einfach aufgegeben. Nun aber zum aktuellen problem: Ist das tatsächlich nicht lösbar? Ein 2008 erreicht im Netzwerk nur 1/3 der Leistung eines 2000? Ist das nur bei dem so oder haben andere Admins/unternehmen das auch? Ich habe davon noch nichts vernommen. Wie macht sich diese verminderte Leistung bemerkbar? Habe ich in diesem Thread den Begriff Ereignisprotokoll üeberlesen oder kommt er nicht vor? Steht darin eventuell doch etwas, etwas als Grundlage für weitere Recherche? Zitieren Link zu diesem Kommentar
RottenSon667 10 Geschrieben 4. Juni 2011 Autor Melden Teilen Geschrieben 4. Juni 2011 Da ist er wieder. Danke erst einmal für eure Antworten. Das Problem betrifft ausschließlich Windows 7 Clients. Ich habs bis heute nicht hinbekommen und die Softwareverteilung in den betreffenden Standorten deaktiviert. Das mit dem Eventlog hast du tatsächlich überlesen, denn wo sollte ich sonst die Event-ID 1612 her haben? Diese tritt nur bei Verwendung des DFS auf, weist man direkt über \\Servername\ zu gehts..... Die 1/3 Leistung merkt man we3niger beim Kopieren denn beim Arbeiten mit einer älteren Software, auf die wir aber momentan noch angewiesen sind. Diese arbeitet mit Paradox-"Datenbanken" (filebasiert). Beim sequentiellen Lesen dieser Dateien (bsp. bei einer Suche) kann man, wenn man mit Wireshark etwas mithört keinerlei Unterschied zwischen Win2K und Win2K8 Server feststellen. Der Ablauf der Datenübertragung ist ebenso wie die Paketgröße gleich. Wir haben schon probiert mit der Authentifizierung rum zu spielen, das hat aber keine Auswirkungen gezeigt. Ob man nun NTLMv1 oder v2 einstellt: keine Änderung.... MfG Maik edit: Ich muss auch mal klarstellen dass ich Win7 sehr gern habe. Hatte an jenem Tag nur etwas miese Laune, da ich mich schon Tagelang mit den Speedproblemen rumschlagen durfte und dann kommt noch die Grütze mit der nicht funktionierenden Softwareverteilung via DFS dazu.... Es ist einfach nervig... Zitieren Link zu diesem Kommentar
hevtig 10 Geschrieben 5. Oktober 2011 Melden Teilen Geschrieben 5. Oktober 2011 Konntest du das Problem in der Zwischenzeit lösen? Zitieren Link zu diesem Kommentar
iDiddi 27 Geschrieben 5. Oktober 2011 Melden Teilen Geschrieben 5. Oktober 2011 Vielleicht liegt's am DNS: Win 7 Error 0x80070035 when I try to access a DFS share on Remote Win2008 Server oder lege eine Verknüpfung an (letzter Beitrag): DFS share in windows 7 Zitieren Link zu diesem Kommentar
RottenSon667 10 Geschrieben 6. Oktober 2011 Autor Melden Teilen Geschrieben 6. Oktober 2011 ich muss mal meinen nachfolger in der firma fragen ob er es lösen konnte. damals habe ich meine letzten 1,5 monate damit verbracht den jungen der meinen platz einnahm anzulernen und konnte mich leider nicht weiter damit befassen :( aber ich les mir das ganze mal durch ;) Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.