semihtest
Goto Top

30068-39 - Office Professional 2019 Fehlercode

Klar! Hier ist dein Beitrag in einer überarbeiteten, professionellen und gut verständlichen Formulierung – mit deinem Stil beibehalten:

---

Hallo zusammen,

wir richten aktuell eine neue RDS-Farm ein und stoßen dabei auf ein Problem bei der Office-Installation. Konkret tritt auf zwei von drei Session Hosts während der Installation per Office Deployment Tool folgender Fehler auf: Fehlercode 30068-39.

Die Installation erfolgt über eine XML-Konfigurationsdatei. Die Datei selbst ist korrekt, der Lizenzschlüssel stimmt ebenfalls. Auch die Netzwerkkonfiguration und Firewalleinstellungen passen – alle Hosts befinden sich im selben Netz, Kommunikation ist gegeben.

Interessant ist:

back-to-topEin Host konnte Office ohne Probleme installieren.

back-to-topZwei andere Hosts (ebenfalls frisch aufgesetzt) werfen beide denselben Fehler.


Auffällig ist zudem:

back-to-topDer Host, bei dem es funktioniert hat, ist aktuell alleiniger Bestandteil einer eigenen Session Collection.

back-to-topDie beiden betroffenen Hosts sind gemeinsam in einer anderen Collection eingebunden.

(Weiß nicht ob das was damit zu tun hat...)

Hat jemand Erfahrung mit dem Fehlercode 30068-39 in diesem Kontext?

Die verwendete XML-Konfiguration sieht folgendermaßen aus:

<Configuration ID="XXXXX-XXXX-XXX-XXX-XXXX">  
  <Add OfficeClientEdition="64" Channel="PerpetualVL2019">  
    <Product ID="ProPlus2019Volume" PIDKEY="XXXX-XXXX-XXXX-XXXX-XXXX">  
      <Language ID="de-de" />  
      <ExcludeApp ID="Groove" />  
      <ExcludeApp ID="Lync" />  
      <ExcludeApp ID="OneDrive" />  
    </Product>
  </Add>
  <Property Name="SharedComputerLicensing" Value="1" />  
  <Property Name="FORCEAPPSHUTDOWN" Value="FALSE" />  
  <Property Name="DeviceBasedLicensing" Value="0" />  
  <Property Name="SCLCacheOverride" Value="0" />  
  <Property Name="AUTOACTIVATE" Value="1" />  
  <Updates Enabled="TRUE" />  
  <RemoveMSI />
  <AppSettings>
    <Setup Name="Company" Value="Firmenname" />  
  </AppSettings>
  <Display Level="Full" AcceptEULA="TRUE" />  
</Configuration>

Content-ID: 672413

Url: https://administrator.de/forum/30068-39-office-professional-2019-fehlercode-672413.html

Ausgedruckt am: 13.04.2025 um 03:04 Uhr

BiberMan
BiberMan 09.04.2025 aktualisiert um 17:22:58 Uhr
Goto Top
Moin.
Klar! Hier ist dein Beitrag in einer überarbeiteten, professionellen und gut verständlichen Formulierung – mit deinem Stil beibehalten:
Muss man jetzt schon die Fragen von einer KI hier stellen lassen ?! Wo sind wir nur mittlerweile hingekommen ... nee nee nee ...

Fehlercode 30068-39.
  • Welche Maßnahmen die die Suchmaschine deiner Wahl vorgeschlagen hat, hast du denn schon abgearbeitet? Primär wird ja eine fehlerhafte Internet-Verbindung konstatiert, so das die Quellen nicht korrekt erreichbar sind.
  • Session Hosts haben welches OS?
  • Ist irgendwelches Schlangenöl im Einsatz, sowohl am Server oder in einer Firewall, Proxies?
  • Werden MS URLs/Quellen geblockt, DNS i.O.?
  • Wird Office erst mit setup /download config.xml in eine lokale Quelle heruntergeladen und dann erst instaliert, oder direkt mit setup /configure config.xml aus den Online-Quellen installiert/gestreamt? Wenn von lokaler Quelle, wie heißen die Verzeichnisse aus denen installiert wird, zufällig"Office"?
  • Event- und Installer-Logs sagen was ?

Gruß Biberman
TasteX
TasteX 09.04.2025 um 19:33:23 Uhr
Goto Top
Nabend zusammen,

Ich habe das selbe Problem mit einem Office 2019 Standard. (Installation auch via XML) Notebook mit Win 11 Pro 24H2.
Vorinstalliertes Office 365, deinstalliert, komplette Registry bereinigt. Selbe Fehlermeldung wie bei semihtest.
Auch schon mit lokalem Download versucht - führt zur gleichen Fehlermeldung.
Wäre für Tipps ebenfalls Dankbar.
Die Googlevorschläge habe ich bereits durch.

Gruß
TasteX
DivideByZero
DivideByZero 09.04.2025 um 19:41:50 Uhr
Goto Top
Moin,

in der Regel sind es doch irgendwo Office-Rückstände. Da liegt auch in den verschiedensten Unterverzeichnissen etwas vor.

Gruß

DivideByZero

P.S.: Die KI-überarbeitete Anfrage ist, ehrlich gesagt, doch etwas peinlich 🤔
semihtest
semihtest 10.04.2025 um 08:55:16 Uhr
Goto Top
Zitat von @DivideByZero:

Moin,

in der Regel sind es doch irgendwo Office-Rückstände. Da liegt auch in den verschiedensten Unterverzeichnissen etwas vor.

Gruß

DivideByZero

P.S.: Die KI-überarbeitete Anfrage ist, ehrlich gesagt, doch etwas peinlich 🤔

Moin,

leider habe ich in der Registry / sonst wo nichts gefunden. und auch alles bereinigt... bringt auch nichts.

Die KI-überarbeitete Anfrage ist tatsächlich Peinlich, aber ich hab den Beitrag schnell veröffentlicht und hatte zugegebenermaßen keine Zeit, auf Rechtschreibfehler zu achten, daher auch KI schnell verwendet :D


Zitat von @BiberMan:

Moin.
Klar! Hier ist dein Beitrag in einer überarbeiteten, professionellen und gut verständlichen Formulierung – mit deinem Stil beibehalten:
Muss man jetzt schon die Fragen von einer KI hier stellen lassen ?! Wo sind wir nur mittlerweile hingekommen ... nee nee nee ...

Fehlercode 30068-39.
* Welche Maßnahmen die die Suchmaschine deiner Wahl vorgeschlagen hat, hast du denn schon abgearbeitet? Primär wird ja eine fehlerhafte Internet-Verbindung konstatiert, so das die Quellen nicht korrekt erreichbar sind.
  • Session Hosts haben welches OS?
  • Ist irgendwelches Schlangenöl im Einsatz, sowohl am Server oder in einer Firewall, Proxies?
  • Werden MS URLs/Quellen geblockt, DNS i.O.?
  • Wird Office erst mit setup /download config.xml in eine lokale Quelle heruntergeladen und dann erst instaliert, oder direkt mit setup /configure config.xml aus den Online-Quellen installiert/gestreamt? Wenn von lokaler Quelle, wie heißen die Verzeichnisse aus denen installiert wird, zufällig"Office"?
  • Event- und Installer-Logs sagen was ?

Gruß Biberman

Ja.. :D passiert.

Was ich versucht habe:
1. wf.msc (Firewall überall deaktiviert) und die Verbindung zu den einzelnen MS-Servern überprüft – das klappt einwandfrei
2. Defender deaktiviert
3. Registry-Einträge gelöscht
4. Alle DISM-Vorgänge + SFC ausgeführt
5. Über setup.exe /download und dann setup.exe /configure zu installieren – setup.exe /download klappt einwandfrei

Aufklärungen:
1. MS-Quellen werden nicht geblockt, da sonst der eine RDS-Host, bei dem die Installation einwandfrei klappte, ebenfalls betroffen wäre
2. Server ist frisch aufgesetzt, es läuft nichts Proxytechnisches – in der Firewall ist Proxy ebenfalls deaktiviert
3. Die Installation erfolgt direkt mittels `setup /configure config.xml`
4. Als OS ist Windows Server 2022 im Einsatz auf den Session Hosts
5. Eventvwr ist nichts zu sehen
6. OfficeClickToRun.log ist vollständig leer.
mbehrens
mbehrens 10.04.2025 um 17:59:21 Uhr
Goto Top
Zitat von @semihtest:

leider habe ich in der Registry / sonst wo nichts gefunden. und auch alles bereinigt... bringt auch nichts.

D. h. es wurde nicht der von MS vorgeschlagene Weg über die Enterprise Version des Microsoft Support and Recovery Assistant gegangen?