srlrastsu
Goto Top

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

Content-Key: 666236

Url: https://administrator.de/contentid/666236

Printed on: April 18, 2024 at 02:04 o'clock

Member: Doskias
Solution Doskias Apr 29, 2021 at 10:36:11 (UTC)
Goto Top
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.

Download:
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
Member: GarfieldBonn
GarfieldBonn Apr 29, 2021 updated at 13:03:11 (UTC)
Goto Top
Member: Doskias
Doskias Apr 29, 2021 at 13:14:01 (UTC)
Goto Top

Richtig, danke. Das Setup.exe kommt aus dem Deployment Tool. Die XML von Config.office.com.

Gruß
Doskias
Member: srLRAstsu
srLRAstsu Apr 29, 2021 at 13:14:06 (UTC)
Goto Top
Danke.
Member: GarfieldBonn
GarfieldBonn Apr 29, 2021 updated at 13:16:33 (UTC)
Goto Top
und hiermit kannst Du die XML-Dateien erstellen nach eigenen Bedürfnissen
https://config.office.com/deploymentsettings

PS:
Da war Doskias schneller ;)
Member: Kuemmel
Kuemmel Apr 29, 2021 at 18:27:40 (UTC)
Goto Top
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"! face-smile

Danke Microsoft, für diesen tollen Schritt nach vorne *nicht*

Gruß
Kümmel
Member: Doskias
Doskias Apr 30, 2021 at 06:35:30 (UTC)
Goto Top
Moin
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"! face-smile
Das ist ein guten Hinweis und habe ich ebenso gemacht.
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 face-big-smile
Gruß
Doskias
Member: Kuemmel
Kuemmel Apr 30, 2021 at 06:39:57 (UTC)
Goto Top
@Doskias
Könntest du uns dein Script mal hier zur Verfügung stellen?
Member: Doskias
Doskias Apr 30, 2021 at 07:29:14 (UTC)
Goto Top
Klar, aber es ist noch nicht ganz fertig.

$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 face-big-smile

Gruß
Doskias
Member: Dani
Dani May 10, 2021 updated at 15:06:02 (UTC)
Goto Top
Moin,
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