Am gestrigen Dienstag, dem 15.12.2020, wurde die neue DSM-Version 2020.2 freigegeben. Neue Features wie Unterstützung für die Verteilung von MSIX-Paketen, PowerShell 7 Support, die Integration von Xtraction Reporting und weitere kleinere neue Optionen sowie natürlich die Behebung bekannter Probleme, lassen eine vielversprechende Version erwarten. Details finden Sie wie üblich in den offiziellen Release Notes, die Sie hier nachlesen können.
Allerdings möchte ich Sie mit diesem Blog-Artikel auf ein Problem aufmerksam machen, das sowohl in DSM 2020.1 als auch noch in der neuen Version 2020.2 besteht und das eventuell schwerwiegend genug ist, dass Sie aktuell von einem Update auf DSM 2020.x absehen sollten.
Gerade in Corona-Zeiten arbeiten ein nicht unerheblicher Anteil der Büro-Mitarbeiter vom Home-Office aus und greift remote auf Cloud-Services aber auch auf On-Premises Systeme zu. Da diese Rechner in privat betriebenen Netzwerken natürlich höheren Risiken ausgesetzt sind, als das bei Rechnern im abgesicherten Firmennetzwerk der Fall ist, ist es umso wichtiger, dass diese Clients stets sowohl betriebssystemseitig über einen aktuellen Patch-Stand verfügen als auch die neuesten Applikations-Versionen und -Updates installiert haben.
Viele Firmen, die Ivanti DSM zur Verwaltung ihrer Clients einsetzen, haben daher in den vergangenen Jahren ihre DSM-Umgebung erweitert, um auch Clients, die sich nicht im Firmennetz befinden oder sich per VPN einwählen, erreichen und verwalten zu können. Der Ansatz der Wahl ist dabei die Installation eines DSM-Depots und Management Points in der DMZ, auf die die Clients über das Internet per https zugreifen und sich so ihre ihnen zugewiesenen Software-Pakete und Patches abholen.
In den Versionen 2020.1 und auch der neuen 2020.2 befindet sich allerdings ein Bug, der dazu führt, dass sich Clients, die auf ein solches http(s)-Depot zugreifen, nicht aktualisieren können. Im untenstehenden Logfile-Ausschnitt aus einem UpdateCheckDownload-Log (zu finden unter NiLogs\ClientServices) ist zu sehen, dass der Client versucht, auf eine FPI-Datei im Unterverzeichnis rev\rev\1 des ClientBinaries64bit-Verzeichnisses zuzugreifen. Dieses Verzeichnis existiert aber nicht (eine rev-Ebene ist zuviel) und so findet der Client keine Client-Files, um sich zu aktualisieren.
Da sich veraltete Clients aber nicht mit einer neueren DSM-Infrastruktur „unterhalten" können, sind diese Clients so lange nicht managebar, bis der DSM-Client aktualisiert wurde. Es lassen sich also keine Software-Pakete verteilen oder Patches installieren, was aus den oben genannten Gründen ein großes Problem darstellt.
Ivanti beschreibt das Problem in einem Knowledgebase-Artikel unter https://forums.ivanti.com/s/article/DSM-Client-Update-over-HTTP-DMZ-Depot-Directory-rev-rev-1-doesn-t-contain-a-FPI-file. Die dort genannten Workarounds sind allerdings in der aktuellen Corona-Situation, wenn in großen Unternehmen mehrere tausend Mitarbeiter von zu Hause aus arbeiten und auf absehbare Zeit nicht in die Firma kommen, eher unpraktikabel. Sollten Sie die DSM DMZ-Option verwenden und darauf angewiesen sein, Ihre Remote-Arbeitsplätze darüber zu verwalten, empfehlen wir daher, das DSM-Upgrade so lange auszusetzen, bis ein Fix für das Problem verfügbar ist.