Microsoft Office 2019 Updatepfad für mehrere Versionen
Hallo,
ich bereite zurzeit den Umzug auf Office 2019 vor. Leider musste ich zur Kenntnis nehmen, dass Office 2019 nicht mehr mit den WSUS kompatibel sind (danke Microsoft). Nach kurzer Recherche war klar, dass es nur zwei Möglichkeiten für regelmäßige Updates gibt:
1. per CDN runterladen
2. intern per Freigabe
Ich entschied mich für die 2. Möglichkeit. Nachdem ich die Gruppenrichtlinien genauer unter die Lupe genommen habe, kam mir die Frage auf: Wie soll der Pfad für die Updates mit 64- und 32-bit Versionen oder für MS Visio aussehen? Kann man irgendwie/irgendwo mehrere Pfade angeben oder habe ich eine Einstellung direkt bei z.B. MS Visio übersehen?
Vielen Dank im Voraus!
srLRAstsu
ich bereite zurzeit den Umzug auf Office 2019 vor. Leider musste ich zur Kenntnis nehmen, dass Office 2019 nicht mehr mit den WSUS kompatibel sind (danke Microsoft). Nach kurzer Recherche war klar, dass es nur zwei Möglichkeiten für regelmäßige Updates gibt:
1. per CDN runterladen
2. intern per Freigabe
Ich entschied mich für die 2. Möglichkeit. Nachdem ich die Gruppenrichtlinien genauer unter die Lupe genommen habe, kam mir die Frage auf: Wie soll der Pfad für die Updates mit 64- und 32-bit Versionen oder für MS Visio aussehen? Kann man irgendwie/irgendwo mehrere Pfade angeben oder habe ich eine Einstellung direkt bei z.B. MS Visio übersehen?
Vielen Dank im Voraus!
srLRAstsu
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 666236
Url: https://administrator.de/forum/microsoft-office-2019-updatepfad-fuer-mehrere-versionen-666236.html
Ausgedruckt am: 08.04.2025 um 10:04 Uhr
10 Kommentare
Neuester Kommentar
Moin,
wir sind grade mitten im Wechsel, daher kenne ich deine Probleme. Die Probleme sind allerdings nicht neu. Auch die Office 2016 hat sich keine Updates mehr geladen, obwohl es im WSUS angezeigt ist. Der WSUS braucht die Updates wenn du den MS Endpoint Configuration Manager nutzt. Wir haben uns dagegen entscheid, weil nur unnötig überdimensioniert.
Wir machen das auch per interner Freigabe und das ganze ich recht simpel. Du hast ja über config.office.com eine XML-Datei erstellt um dein Setup herunterladen zu können.
Das ganze legst du irgendwo ab, wo jeder drauf Zugreifen kann (lesend reicht). Zum Beispiel unter \\Server\Office2019
Auf dem Server (oder mit Schreibzugriff) legst du jetzt die die Setup Datei die du auch zum installieren nutzt unter \\Server\Office2019 ab und startest sie mit dem Download Befehl von oben. Es sollten dann entsprechende Ordner automatisch angelegt werden und je nach xml-Datei für die entsprechenden Programme und in den verschiedenen 32 bzw. 64. Bit Versionen.
Den Clients gibst du als Updatepfad \\Server\Office2019 mit. Die Installationen schauen dann dort nach und holen sich das Update was zu ihrer Version passt und was auf dem Client installiert ist
So funktioniert es bei uns mit Office und soll nach Aussage unseres Systemhauses auch mit allen anderen Office-Produkten funktionieren, die kein Update via WSUS mehr erhalten.
Gruß
Doskias
wir sind grade mitten im Wechsel, daher kenne ich deine Probleme. Die Probleme sind allerdings nicht neu. Auch die Office 2016 hat sich keine Updates mehr geladen, obwohl es im WSUS angezeigt ist. Der WSUS braucht die Updates wenn du den MS Endpoint Configuration Manager nutzt. Wir haben uns dagegen entscheid, weil nur unnötig überdimensioniert.
Wir machen das auch per interner Freigabe und das ganze ich recht simpel. Du hast ja über config.office.com eine XML-Datei erstellt um dein Setup herunterladen zu können.
Download:
setup.exe /download <pfad zur xml>
Installation
setup.exe /configure <pfad zur xml>
setup.exe /download <pfad zur xml>
Installation
setup.exe /configure <pfad zur xml>
Das ganze legst du irgendwo ab, wo jeder drauf Zugreifen kann (lesend reicht). Zum Beispiel unter \\Server\Office2019
Auf dem Server (oder mit Schreibzugriff) legst du jetzt die die Setup Datei die du auch zum installieren nutzt unter \\Server\Office2019 ab und startest sie mit dem Download Befehl von oben. Es sollten dann entsprechende Ordner automatisch angelegt werden und je nach xml-Datei für die entsprechenden Programme und in den verschiedenen 32 bzw. 64. Bit Versionen.
Den Clients gibst du als Updatepfad \\Server\Office2019 mit. Die Installationen schauen dann dort nach und holen sich das Update was zu ihrer Version passt und was auf dem Client installiert ist
So funktioniert es bei uns mit Office und soll nach Aussage unseres Systemhauses auch mit allen anderen Office-Produkten funktionieren, die kein Update via WSUS mehr erhalten.
Gruß
Doskias
Ergänzend zu Doskias Info
Office Deploment Toolkit herunterladen
https://docs.microsoft.com/de-de/deployoffice/overview-office-deployment ...
https://docs.microsoft.com/de-de/deployoffice/office2019/deploy
Office Deploment Toolkit herunterladen
https://docs.microsoft.com/de-de/deployoffice/overview-office-deployment ...
https://docs.microsoft.com/de-de/deployoffice/office2019/deploy
Zitat von @GarfieldBonn:
Ergänzend zu Doskias Info
Office Deploment Toolkit herunterladen
https://docs.microsoft.com/de-de/deployoffice/overview-office-deployment ...
https://docs.microsoft.com/de-de/deployoffice/office2019/deploy
Ergänzend zu Doskias Info
Office Deploment Toolkit herunterladen
https://docs.microsoft.com/de-de/deployoffice/overview-office-deployment ...
https://docs.microsoft.com/de-de/deployoffice/office2019/deploy
Richtig, danke. Das Setup.exe kommt aus dem Deployment Tool. Die XML von Config.office.com.
Gruß
Doskias
und hiermit kannst Du die XML-Dateien erstellen nach eigenen Bedürfnissen
https://config.office.com/deploymentsettings
PS:
Da war Doskias schneller ;)
https://config.office.com/deploymentsettings
PS:
Da war Doskias schneller ;)
Moin,
Visio nutzt den selben Update-Pfad wie der Rest vom Office-Paket. Deinen lesbaren Share-Pfad für die Updates kannst du in der Deployment-XML angeben, zusätzlich sollte dieser aber auch noch per GPO entsprechend verteilt werden.
Die ADMX-Dateien für die GPOs findest du hier:
https://www.microsoft.com/en-us/download/details.aspx?id=49030
Ich habe eine extra XML-Datei für den reinen Download gebaut, diese wird auf dem Share-Server per Task-Scheduler-Skript regelmäßig ausgeführt damit Office im Unternehmen die Updates automatisiert erhält. So hat das ganze etwas "WSUS-Feeling"!
Danke Microsoft, für diesen tollen Schritt nach vorne *nicht*
Gruß
Kümmel
Visio nutzt den selben Update-Pfad wie der Rest vom Office-Paket. Deinen lesbaren Share-Pfad für die Updates kannst du in der Deployment-XML angeben, zusätzlich sollte dieser aber auch noch per GPO entsprechend verteilt werden.
Die ADMX-Dateien für die GPOs findest du hier:
https://www.microsoft.com/en-us/download/details.aspx?id=49030
Ich habe eine extra XML-Datei für den reinen Download gebaut, diese wird auf dem Share-Server per Task-Scheduler-Skript regelmäßig ausgeführt damit Office im Unternehmen die Updates automatisiert erhält. So hat das ganze etwas "WSUS-Feeling"!
Danke Microsoft, für diesen tollen Schritt nach vorne *nicht*
Gruß
Kümmel
Moin
Allerdings führe ich das Skript nicht täglich aus, sondern prüfe vorab, ob die Website aktualisiert wurde. Dazu nutze ich powershells Invoke-Webrequest und prüfe das Aktualisierungsdatum der Seite https://docs.microsoft.com/de-de/officeupdates/update-history-microsoft3 .... Da ich Protokolleire Wann ich eine neue Version heruntergeladen habe, prüfe ich die beiden Daten gegeneinander und wenn die Website aktueller ist als meine Version erfolgt ein Download. Außerdem führt das Skript nach dem Download eine Bereinigung durch. Diese ist nötig, da Ansonsten da jeder Download ein Verzeichnis auf dem File-Server mit der Versionsnummer anlegt. Jeder Ordner enthält das Komplette (ca. 3 GB) Setup des Office-Paketes.
Lass die automatische Bereinigung weg und hast noch mehr WSUS-Feeling
Gruß
Doskias
Zitat von @Kuemmel:
Moin,
Ich habe eine extra XML-Datei für den reinen Download gebaut, diese wird auf dem Share-Server per Task-Scheduler-Skript regelmäßig ausgeführt damit Office im Unternehmen die Updates automatisiert erhält. So hat das ganze etwas "WSUS-Feeling"!
Das ist ein guten Hinweis und habe ich ebenso gemacht.Moin,
Ich habe eine extra XML-Datei für den reinen Download gebaut, diese wird auf dem Share-Server per Task-Scheduler-Skript regelmäßig ausgeführt damit Office im Unternehmen die Updates automatisiert erhält. So hat das ganze etwas "WSUS-Feeling"!
Allerdings führe ich das Skript nicht täglich aus, sondern prüfe vorab, ob die Website aktualisiert wurde. Dazu nutze ich powershells Invoke-Webrequest und prüfe das Aktualisierungsdatum der Seite https://docs.microsoft.com/de-de/officeupdates/update-history-microsoft3 .... Da ich Protokolleire Wann ich eine neue Version heruntergeladen habe, prüfe ich die beiden Daten gegeneinander und wenn die Website aktueller ist als meine Version erfolgt ein Download. Außerdem führt das Skript nach dem Download eine Bereinigung durch. Diese ist nötig, da Ansonsten da jeder Download ein Verzeichnis auf dem File-Server mit der Versionsnummer anlegt. Jeder Ordner enthält das Komplette (ca. 3 GB) Setup des Office-Paketes.
Lass die automatische Bereinigung weg und hast noch mehr WSUS-Feeling
Gruß
Doskias
@Doskias
Könntest du uns dein Script mal hier zur Verfügung stellen?
Könntest du uns dein Script mal hier zur Verfügung stellen?
Klar, aber es ist noch nicht ganz fertig.
In Zeile 24 wird eine Batch-Datei aufgerufen (damit ich das Update jederzeit händisch starten kann). Diese sieht so aus:
und die Bereinigung.ps1
Und ja: Man kann das auch alles in ein Skript packen, möchte ich aber bewusst nicht, da ich die einzelnen Punkte wie Download + Bereinigung oder auch nur die Bereinigung gerne auch separat starten möchte.
Und bevor jetzt der eine oder andere meckert: ja das Skript hat noch einiges an Optimierungspotential. Ich weiß, dass es unsinnig ist in Zeile 13 das Datum in die Log-Datei zu schreiben, in Zeile 16 wieder auszulesen und am Ende die log-Datei zu löschen. Und auch die Zeile 23 und 30 sind unnötig, weil sie bei der automatischen Ausführung es eh keiner liest. Das liegt wie oben angekündigt daran, dass es noch nicht ganz fertig und noch im stetigen Wandel ist. Die automatische Bereinigung nach dem Download der neusten Version ist beispielsweise erst am Dienstag hinzugefügt worden und hat bislang nur im händischen Test funktioniert. Und bis Dienstag wurde die Log-Datei auch nicht gelöscht und eine eigene Historie (zur Überprüfung der Funktion des Skriptes) über die von MS bereitgestellten Updates erstellt. Bei solchen auf den unsinnigen Zeilen handelt es sich daher zum Teil um Reste die erst kürzlich geändert worden als auch ggf. um Rest die durch die Anonymisierung entstanden sind. So prüft das Skript zum Beispiel zu Beginn ob alle relevanten Pfad und Server erreichbar sind mittels test-path und test-connection oder auch ob genug Speicherplatz auf dem dem Laufwerk frei ist. Einfach damit nicht versehentlich eine Protokoll-Datei ohne Download erstellt wird. Diese ganzen Dinge habe ich hier mal rausgeworfen und das Skript auf das (in meinen Augen) für den automatischen Download wichtige reduziert.
Gruß
Doskias
Also bitte keine Kommentare wie Das geht aber kürzer oder xyz ist unsinnig. Das weiß ich selbst
Gruß
Doskias
$Protokollpfad="\\[Protokoll-Server]\Logs\O365_Updates"
$WebSite = Invoke-WebRequest "https://docs.microsoft.com/de-de/officeupdates/update-history-microsoft365-apps-by-date"
$Inhalt_Website=$Website.content
$Inhalt_Website > $Protokollpfad\Umwandlung.txt
$Inhalt_Zeilen=gc $Protokollpfad\Umwandlung.txt
foreach ($zeile in $Inhalt_Zeilen)
{
if ($Zeile -like "*updated*")
{
$MS_Update=$zeile -replace '<meta name="updated_at" content="' -replace '" />'
$MS_update > $Protokollpfad\MS_Version.log
$Last_Update=get-date((gc $Protokollpfad\letztes_update.log))
$MS_Version=get-date((gc $Protokollpfad\MS_Version.log))
}
}
write-host "Letztes Update von MS:" $MS_Version
Write-Host "Letzter Download:" $Last_Update
if ($MS_Version -gt $Last_Update){
write-host "Update nötig"
start [lokaler Pfad]\Setup.bat
Send-MailMessage -from 'Office-Check@Domain.de <O365@Domain.de>' -To '<mich@Domain.de>' -Subject 'O365-Updates stehen bereit' -Body 'Updates wurden herunter geladen' -SmtpServer "mailserver" -encoding ([System.Text.Encoding]::UTF8)
Get-Date -format "dd.MM.yyyy HH:mm" > $Protokollpfad\letztes_update.log
Get-Date -format "dd.MM.yyyy HH:mm" >> $Protokollpfad\O365_Update_History.log
}
else
{write-host "Kein Update nötig"
Send-MailMessage -from 'Office-Check@Domain.de <O365@Domain.de>' -To '<mich@Domain.de>' -Subject 'keine neuen O365-Updates' -Body 'Es gibt heute keine neuen O365 Updates' -SmtpServer "mailserver" -encoding ([System.Text.Encoding]::UTF8) }
Remove-Item $Protokollpfad\Umwandlung.txt
Remove-Item $Protokollpfad\MS_Version.log
In Zeile 24 wird eine Batch-Datei aufgerufen (damit ich das Update jederzeit händisch starten kann). Diese sieht so aus:
[Freigegebener Ordnerpfad für alle]\setup.exe /download [Ordnerpfad für IT]\Setup.xml
powershell.exe -command "[Pfad zum Skript-Ablageort]\O365_Updates\Bereinigung.ps1"
und die Bereinigung.ps1
$Altes_office=Get-ChildItem [Freigegebener Ordnerpfad für alle]\Office\Data\ -Directory | ? LastWriteTime -lt (Get-date).AddDays(-1)
if ($Altes_office.length -ne 0)
{
Get-ChildItem [Freigegebener Ordnerpfad für alle]\Office\Data\ |? name -match $Altes_office |Remove-Item -Force -Recurse
}
Und ja: Man kann das auch alles in ein Skript packen, möchte ich aber bewusst nicht, da ich die einzelnen Punkte wie Download + Bereinigung oder auch nur die Bereinigung gerne auch separat starten möchte.
Und bevor jetzt der eine oder andere meckert: ja das Skript hat noch einiges an Optimierungspotential. Ich weiß, dass es unsinnig ist in Zeile 13 das Datum in die Log-Datei zu schreiben, in Zeile 16 wieder auszulesen und am Ende die log-Datei zu löschen. Und auch die Zeile 23 und 30 sind unnötig, weil sie bei der automatischen Ausführung es eh keiner liest. Das liegt wie oben angekündigt daran, dass es noch nicht ganz fertig und noch im stetigen Wandel ist. Die automatische Bereinigung nach dem Download der neusten Version ist beispielsweise erst am Dienstag hinzugefügt worden und hat bislang nur im händischen Test funktioniert. Und bis Dienstag wurde die Log-Datei auch nicht gelöscht und eine eigene Historie (zur Überprüfung der Funktion des Skriptes) über die von MS bereitgestellten Updates erstellt. Bei solchen auf den unsinnigen Zeilen handelt es sich daher zum Teil um Reste die erst kürzlich geändert worden als auch ggf. um Rest die durch die Anonymisierung entstanden sind. So prüft das Skript zum Beispiel zu Beginn ob alle relevanten Pfad und Server erreichbar sind mittels test-path und test-connection oder auch ob genug Speicherplatz auf dem dem Laufwerk frei ist. Einfach damit nicht versehentlich eine Protokoll-Datei ohne Download erstellt wird. Diese ganzen Dinge habe ich hier mal rausgeworfen und das Skript auf das (in meinen Augen) für den automatischen Download wichtige reduziert.
Gruß
Doskias
Also bitte keine Kommentare wie Das geht aber kürzer oder xyz ist unsinnig. Das weiß ich selbst
Gruß
Doskias
Moin,
Gruß,
Dani
2. intern per Freigabe
3. per HTTP(S). Diese Variante setzen wir bei uns ein. Somit können wir auch mehrere Webserver bereitstellen. Sogar im Internet und somit können auch die Notebooks zu Hause ihre Updates problemlos erhalten. Ist mir auch deutlich lieber als ein CIFS Share (Sicherheit, Firewalls, etc...).Gruß,
Dani