17
MSI Paket per Gruppenrichtlinie wird nicht installiert Fehler 102
Hallo,
ich bin am verzweifeln mit der Installation von Center Tools DriveLock per MSI Paket.
Folgende Fehlermeldung erhalte ich auf Windows XP Clients:
"Die Installation der Anwendung CenterTools DriveLock Agent der Richtlinie CenterTools 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.;
Fehler 102.
Bei Windows 7 32 Bit Rechnern funktioniert die Installation des Paketes. (32 Bit ist auch hinterlegt) Sprache habe ich auf "Ignorieren" gesetzt. Die Datei liegt im NETLOGON Verzeichnis der DC's. Als Pfad ist UNC gewählt: \\DC01\NETLOGON\drivelock7.msi
Woran liegt es? Es wird beim Starten kurz auf den Clients gezeigt:
1. Netzwerkeinstellungen vorbereiten
2. Computereinstellungen werden übernommen
3. Sicherheitseinstellungen übernehmen
4. CenterTools DriveLock wird installiert (aber nur für 1-2 Sek.) dann gehts direkt zum Anmeldescreen.
Danke Euch.
Gruß, Benny
ich bin am verzweifeln mit der Installation von Center Tools DriveLock per MSI Paket.
Folgende Fehlermeldung erhalte ich auf Windows XP Clients:
"Die Installation der Anwendung CenterTools DriveLock Agent der Richtlinie CenterTools 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.;
Fehler 102.
Bei Windows 7 32 Bit Rechnern funktioniert die Installation des Paketes. (32 Bit ist auch hinterlegt) Sprache habe ich auf "Ignorieren" gesetzt. Die Datei liegt im NETLOGON Verzeichnis der DC's. Als Pfad ist UNC gewählt: \\DC01\NETLOGON\drivelock7.msi
Woran liegt es? Es wird beim Starten kurz auf den Clients gezeigt:
1. Netzwerkeinstellungen vorbereiten
2. Computereinstellungen werden übernommen
3. Sicherheitseinstellungen übernehmen
4. CenterTools DriveLock wird installiert (aber nur für 1-2 Sek.) dann gehts direkt zum Anmeldescreen.
Danke Euch.
Gruß, Benny
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 177293
Url: https://administrator.de/forum/msi-paket-per-gruppenrichtlinie-wird-nicht-installiert-fehler-102-177293.html
Ausgedruckt am: 21.02.2025 um 11:02 Uhr
17 Kommentare
Neuester Kommentar
Hallo Benny!
Für XP hast du ja ein anderes MSI oder?! Wo liegt das? Kannst du (wie die Fehlermeldung schon sagt) sicherstellen, dass du auf den richtigen Pfad verweist bzw. Rechte hast, dorthin zu gehen? Hast du mehrere DC (weil du DCs schreibst)? Wenn ja: eventuell Datei noch nicht repliziert. Wenn du mehrere DCs hast finde ich bei der Wahl des UNC Pfads %LOGONSERVER% besser, dann bist du nicht direkt auf einen Verweis gebunden, sondern er holt es sich bei seinem Anmeldeserver ab.
lg
gsch
Für XP hast du ja ein anderes MSI oder?! Wo liegt das? Kannst du (wie die Fehlermeldung schon sagt) sicherstellen, dass du auf den richtigen Pfad verweist bzw. Rechte hast, dorthin zu gehen? Hast du mehrere DC (weil du DCs schreibst)? Wenn ja: eventuell Datei noch nicht repliziert. Wenn du mehrere DCs hast finde ich bei der Wahl des UNC Pfads %LOGONSERVER% besser, dann bist du nicht direkt auf einen Verweis gebunden, sondern er holt es sich bei seinem Anmeldeserver ab.
lg
gsch
Zitat von @gsch86:
Für XP hast du ja ein anderes MSI oder?! Wo liegt das? Kannst du (wie die Fehlermeldung schon sagt) sicherstellen, dass du
auf den richtigen Pfad verweist bzw. Rechte hast, dorthin zu gehen? Hast du mehrere DC (weil du DCs schreibst)? Wenn ja: eventuell
Datei noch nicht repliziert. Wenn du mehrere DCs hast finde ich bei der Wahl des UNC Pfads %LOGONSERVER% besser, dann bist du
nicht direkt auf einen Verweis gebunden, sondern er holt es sich bei seinem Anmeldeserver ab.
Für XP hast du ja ein anderes MSI oder?! Wo liegt das? Kannst du (wie die Fehlermeldung schon sagt) sicherstellen, dass du
auf den richtigen Pfad verweist bzw. Rechte hast, dorthin zu gehen? Hast du mehrere DC (weil du DCs schreibst)? Wenn ja: eventuell
Datei noch nicht repliziert. Wenn du mehrere DCs hast finde ich bei der Wahl des UNC Pfads %LOGONSERVER% besser, dann bist du
nicht direkt auf einen Verweis gebunden, sondern er holt es sich bei seinem Anmeldeserver ab.
Hi,
nein, das ist das gleiche MSI Paket? Es gibt da nur 32 Bit und 64 Bit? Habe allgemein die 32 Bit verwendet. Die Datei ist bereits auf allen DC's repliziert. Habe auch schon einen anderen Pfad getestet, wo "Jeder" darauf Lesen und Ausführen darf. Die Fehlermeldung bleibt.
Kannst du das Paket händisch auf einen XP Client installieren oder bekommst da auch eine Fehlermeldung?
Ist jetzt nur ne Vermutung, aber wenn es eine Win7 SW ist, die unter XP nicht unterstützt wird, wäre es erklärbar, dass es auf Win7 geht und unter XP nicht....
lg
Ist jetzt nur ne Vermutung, aber wenn es eine Win7 SW ist, die unter XP nicht unterstützt wird, wäre es erklärbar, dass es auf Win7 geht und unter XP nicht....
lg
Zitat von @gsch86:
Kannst du das Paket händisch auf einen XP Client installieren oder bekommst da auch eine Fehlermeldung?
Ist jetzt nur ne Vermutung, aber wenn es eine Win7 SW ist, die unter XP nicht unterstützt wird, wäre es erklärbar,
dass es auf Win7 geht und unter XP nicht....
lg
Kannst du das Paket händisch auf einen XP Client installieren oder bekommst da auch eine Fehlermeldung?
Ist jetzt nur ne Vermutung, aber wenn es eine Win7 SW ist, die unter XP nicht unterstützt wird, wäre es erklärbar,
dass es auf Win7 geht und unter XP nicht....
lg
Händisch funktioniert einwandfrei, wenn ich die MSI aufrufe. Laut CenterTools ist die auch für WinXP SP3 freigegeben. Habe jetzt mal von Adobe das Reader X 10.0 Paket getestet. Auch da habe ich den gleichen Fehler auf den XP Maschinen. Also scheint es schon mal nicht an CenterTools zu liegen.
Verstehe die Meldung nicht. Auf das Netlogon Verzeichnis hat doch jeder Zugriff? %LOGONSERVER% kann ich nicht eingeben, da ich direkt den UNC Pfad wählen muss, aber es haben eh alle DC's drauf.
Gruß, Benny
Hi.
Das Problem ist microsoft bekannt und tritt bei Verwendung des Netlogon-Shares auf. Nimm eine andere Freigabe.
Das Problem ist microsoft bekannt und tritt bei Verwendung des Netlogon-Shares auf. Nimm eine andere Freigabe.
Zitat von @DerWoWusste:
Hi.
Das Problem ist microsoft bekannt und tritt bei Verwendung des Netlogon-Shares auf. Nimm eine andere Freigabe.
Hi.
Das Problem ist microsoft bekannt und tritt bei Verwendung des Netlogon-Shares auf. Nimm eine andere Freigabe.
Habe ich nun geändert. Geht leider auch nicht
Und der Client hat den neuen Pfad auch schon benutzt? Log mal am Client mit (procmon bootlogging), was da passiert und ob ein echter "access denied" kommt.
Zitat von @DerWoWusste:
Und der Client hat den neuen Pfad auch schon benutzt? Log mal am Client mit (procmon bootlogging), was da passiert und ob ein
echter "access denied" kommt.
Und der Client hat den neuen Pfad auch schon benutzt? Log mal am Client mit (procmon bootlogging), was da passiert und ob ein
echter "access denied" kommt.
Wie mache ich das? Ist das ein Tool oder einfach das Windows Boot Logging?
Procmon runterladen bei Microsoft.
Siehe auch MSI Paket aus Netlogon-Verzeichnis nicht ausführbar
bzw. http://support.microsoft.com/kb/889710 (netlogon und sysvol teilen das selbe Problem, da der eine ein Unterordner des anderen ist).
Sieht genau nach Deinem Problem aus: win7 geht (so mein Test), xp nicht. Stell sicher, dass Deine Änderung des Pfades übernommen wurde. Gib auch an, ob es gelingt, wenn Du esw manuell aus diesem Pfad startest (wurde oben nicht deutlich, ob Du dabei den selben Pfad verwendest).
bzw. http://support.microsoft.com/kb/889710 (netlogon und sysvol teilen das selbe Problem, da der eine ein Unterordner des anderen ist).
Sieht genau nach Deinem Problem aus: win7 geht (so mein Test), xp nicht. Stell sicher, dass Deine Änderung des Pfades übernommen wurde. Gib auch an, ob es gelingt, wenn Du esw manuell aus diesem Pfad startest (wurde oben nicht deutlich, ob Du dabei den selben Pfad verwendest).
Zitat von @DerWoWusste:
Siehe auch MSI Paket aus Netlogon-Verzeichnis nicht ausführbar
bzw. http://support.microsoft.com/kb/889710 (netlogon und sysvol teilen das selbe Problem, da der eine ein Unterordner des anderen
ist).
Sieht genau nach Deinem Problem aus: win7 geht (so mein Test), xp nicht. Stell sicher, dass Deine Änderung des Pfades
übernommen wurde. Gib auch an, ob es gelingt, wenn Du esw manuell aus diesem Pfad startest (wurde oben nicht deutlich, ob Du
dabei den selben Pfad verwendest).
Siehe auch MSI Paket aus Netlogon-Verzeichnis nicht ausführbar
bzw. http://support.microsoft.com/kb/889710 (netlogon und sysvol teilen das selbe Problem, da der eine ein Unterordner des anderen
ist).
Sieht genau nach Deinem Problem aus: win7 geht (so mein Test), xp nicht. Stell sicher, dass Deine Änderung des Pfades
übernommen wurde. Gib auch an, ob es gelingt, wenn Du esw manuell aus diesem Pfad startest (wurde oben nicht deutlich, ob Du
dabei den selben Pfad verwendest).
Habe jetzt per MSIEXEC das mal testweise in den Anmeldescript der Benutzer eingebaut, da installiert er es von der Freigabe (nicht NETLOGON).... aber per GPO immer noch nicht bei XP. Werde das jetzt mal mit dem Monitoring Tool testen.
Wie finde ich jetzt in dem Log am besten die Stelle, wo der Fehler auftritt?
Moin.
Ich schrieb: "...ob ein echter "access denied" kommt" ->danach musst Du im Log suchen, eine Suchfunktion ist drin.
Beantworte aber bitte meine Rückfragen.
1) Gib auch an, ob es gelingt, wenn Du esw manuell aus diesem Pfad startest (wurde oben nicht deutlich, ob Du dabei den selben Pfad verwendest).
2) Stell sicher, dass Deine Änderung des Pfades übernommen wurde
Ich schrieb: "...ob ein echter "access denied" kommt" ->danach musst Du im Log suchen, eine Suchfunktion ist drin.
Beantworte aber bitte meine Rückfragen.
1) Gib auch an, ob es gelingt, wenn Du esw manuell aus diesem Pfad startest (wurde oben nicht deutlich, ob Du dabei den selben Pfad verwendest).
2) Stell sicher, dass Deine Änderung des Pfades übernommen wurde
Zitat von @DerWoWusste:
Moin.
Ich schrieb: "...ob ein echter "access denied" kommt" ->danach musst Du im Log suchen, eine Suchfunktion
ist drin.
Beantworte aber bitte meine Rückfragen.
1) Gib auch an, ob es gelingt, wenn Du esw manuell aus diesem Pfad startest (wurde oben nicht deutlich, ob Du dabei den selben
Pfad verwendest).
2) Stell sicher, dass Deine Änderung des Pfades übernommen wurde
Moin.
Ich schrieb: "...ob ein echter "access denied" kommt" ->danach musst Du im Log suchen, eine Suchfunktion
ist drin.
Beantworte aber bitte meine Rückfragen.
1) Gib auch an, ob es gelingt, wenn Du esw manuell aus diesem Pfad startest (wurde oben nicht deutlich, ob Du dabei den selben
Pfad verwendest).
2) Stell sicher, dass Deine Änderung des Pfades übernommen wurde
Ok, suche ich morgen nochmal...
Sorry, zu Deinen Fragen:
Ja, der Pfad ist \\DATEISERVER\MSI\paket1.msi
Habe jetzt per Logon Script vorrübergehend den Befehl "msiexec /i \\DATEISERVER\MSI\paket1.msi /qn" eingetragen und so können die Clients wunderbar auf die Installation zugreifen. Nur ist das ja nicht SInn der Sache und eher ein Hotfix, damit es überhaupt geht. Der Pfad ist an "Jeder" und an "Domänencomputer" freigegeben, da vor der Anmeldung doch der Computer an sich Zugriff haben muss oder? SYSTEM steht auch noch drin. Freigabe UND Sicherheit....
Hi.
Du beantwortest weder 1 noch 2, kann das sein ;) ?
Du beantwortest weder 1 noch 2, kann das sein ;) ?
Hmm, sorry. 1: Ja, ist der gleiche Pfad und starten aus dem Pfad geht...
2. Ja, wurde übernommen, sowohl beim MSI Paket als auch bei der Standardeinstellung für den Standard Ordner.... wenn ich das MSI Paket hinzufüge öffnet er auch direkt den MSI Ordner auf dem Dateiserver....
Zu 2)
Es ist doch entscheidend, ob es beim Client ankommt. Mach rsop.msc am Client und schau, ob der Pfad des Paketes auf den neuen Ort zeigt.
Es ist doch entscheidend, ob es beim Client ankommt. Mach rsop.msc am Client und schau, ob der Pfad des Paketes auf den neuen Ort zeigt.
