So mal als Input:
Hallo @voipstack,
wir haben hier oft das umgekehrte Problem - Supportanfragen für Bugs die schon behoben sind und sich mit einem Update ganz leicht beheben lassen. Deshalb haben wir diesen Update-Check in einer der letzten Versionen auch für Terminal-Server Installationen eingeführt.
Die gut sichtbare rote Meldung ist, wenn das --noUpdate-Flag gesetzt ist aber tatsächlich etwas aufdringlich.
Die kommende Version 53 des Clients wird das, wenn das Flag gesetzt ist, auf einen kurzen gelben Hinweis reduzieren.
Hilft dir das schon weiter?
Grüße,
Jan
Muss ich erst live sehen, könnte aber helfen.
Ich habe mir das gestern beim Update nochmals angeschaut. Den noupdate Parameter setzen wir nicht derzeit, der müsste ja bei der Verknüpfung angegeben werden? Der Client merkt ja über die Schreibrechte seit geraumer Zeit dass er sich nicht aktualisieren kann. Entsprechend sollte er in diesem Falle wenn überhaupt auch nur die gelbe kurze Nachricht zeigen.
Der Sinn einer Managed Install ist ja denn auch das Prinzip Test > Approve > Rollout. Da ist es wenig angezeigt wenn der Enduser (Flottenkunde der nichts mit IT zu tun haben will) mit einer Nachricht darüber informiert wird dass sein Client veraltet ist, der System-Admin aber tätig werden muss. Ist irgendwie unprofessionell und es gibt gute Gründe einen Update zurückzuhalten.
Lösungsvariante 1: Keine Schreibrechte > nichts anzeigen (oder höchstens kurze Mitteilung)
Lösungsvariante 2: Den noupdate Parameter im Sinne einer Policy zur Verfügung stellen (Firefox löst das z.B. sehr schön mit eine Policy-json File im Programm-Ordner das ausgelesen wird. Hierüber kann der Admin diverse Settings einstellen, z.B. Noupdate oder Rendering Mode, etc.
Die Methode 2 fände ich auch eine echt schicken Idee.
Kann man dann ganz einfach per GPO, oder Script ausrollen und jederzeit anpassen. Dazu kommt das dann auch bei MacOS benutzen könnte. Da ist das ja im Moment echt fürchterlich.
Gruß Markus
Ja, ich bin auch bei euch, der Rollout sollte auf Admin-Seite steuerbar sein, aber weil das für alle -auch die mobilen Clients- funktionieren sollte, müsste man diese Steuerung mMn via pascom Server regeln. Da ja alle aktiven Clients ohnehin ständig mit dem Server in Kontakt sind, könnte man den Clients so auch eine “Update-Policy” übergeben. Wobei ich mir aber nicht sicher bin, ob man damit in die Update-Automatik von z.B. Google Play Store eingreifen kann, also ob die App selber auf ihr Update-Verhalten aus dem Store Einfluss nehmen könnte? Selbst wenn man bei den mobilen Clients damit nur das Update auf die letzte stable Version (nach erfolgreichen Tests auf Test-Geräten) gezielt freigeben könnte, wäre das ein großer Fortschritt zum jetzigen ungesteuerten Zwangsupdate.
just my 2 cents
Robert
Hallo zusammen,
ja, wir könnten das Desktop Update, zusätzlich zum --noUpdate Schalter auch per Policy verhindern.
Das würde das Problem aber nur zur Hälfte lösen. Für Play- und App-Store hilft nur die Verwendung eines Mobile-Device-Managers. Das ist aber pro Kunde sicherlich zu aufwendig.
LG
Mathias
@Mathias
Danke. Mir würde das schon auf den Desktop OS reichen. Bei den Mobilgeräten haben die Flottenkunden tatsächlich auch immer ein MDM bei uns, da geht die Steuerung heute schon recht gut.
Hallo,
wie ist hier das aktuelle Verhalten? Wir möchten den Client auch zentral ausrollen und managen, ohne das die Nutzer einen Hinweis über die veraltete Version bekommen.
Ich habe den Client nach C:\Program Files deployed. Das Verzeichnis ist für User nicht schreibbar. Der Client blendet nun oben eine rote Hinweisleiste ein, dass der Client veraltet ist.
Nun habe ich zusätzlich die Environment-Variable PC_NO_UPDATE gesetzt. Wie ist nun das erwartete Verhalten?
Gibt es auch andere Möglichkeiten, das Clientverhalten zu manipulieren, als über Environment-Variablen oder Parameter? Die Idee mit einer Settings-Datei im Installationsverzeichnis oder den Settings direkt auf der Pascom ist aus Sicht einer Softwareverteilung viel charmanter umzusetzen.
Gruß
Stephan