Automatische Adobe Reader Updates verhindern

image Ich hatte es ja angedroht, hier der zweite Artikel zum Thema “Automatische Updates” von Anwendungen in einer Citrix Umgebung. Ebenso nervig wie das allgegenwärtige Java Update empfinde ich die Versuche der aktuellen Adobe Reader (a.k.a Acorbat Reader) Versionen sich ständig automatisch zu aktualisieren. Ich denke jeder ist sich über Sinn und Zweck von aktuellen Versionen, gerade von das System gefährdende Komponenten bewusst und es deaktivieren des automatischen Updates heiß nicht kein Update.

Vor der Installation:
Die Installation des Adobe Reader zu verändern ist nicht ganz so einfach und funktioniert eigentlich nur mit Hilfe des Adobe Customizing Wizard. Hat man diesen installiert und den Adobe Reader in einer entpackten Version vorliegen kann man im Menüpunkt “Online and Adobe.com Features” den Punkt “Disable all updates” aktivieren und schon ist Ruhe.

image

Ein komplette Beschreibung wie man das Installationspaket des Adobe Reader entpackt, wie man eine angepasste Installation erstellt und noch viele weitere hilfreiche Tipps rund um den Adobe Reader und die Anpassung und Installation gibt es bei Aaron Parker in seinem Blog stealthpuppy.com. Dort findet sich ein eigener Abschnitt zum Thema Adobe Reader.

 

 

Für bereits installierte Systeme:
Wenn der Adobe Reader bereits installiert ist, kann das nervige Update auch später noch angepasst werden. Dazu nutze ich (wie immer) die Group Policy Preferences. um die Registry anzupassen.

Action Update:
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Policies\Adobe\Acrobat Reader\9.0\FeatureLockDown]
”bUpdater”=dword:00000000

.

Advertisements

Session Shadowing mit Multimonitor nicht möglich

XenAppLogo Manchmal ist es doch zum verrückt werden – da preisen wir über Jahre hinweg ein Feature von Citrix MetaFrame XP, Presentation Server, XenApp wie “Sauerbier” an und dann funktioniert es plötzlich nicht mehr. Gemeint ist das Session Shadowing von Benutzersitzungen. Ein kleines aber nettes Feature für den Support. Doch seit Windows Server 2008 R2 gibt es hier ein Problem.

Schöne neue Welt – inzwischen haben nahezu alle Benutzer zwei Monitore auf dem Schreibtisch stehen und auch Thin Clients werden mit Multi Monitor Funktion geliefert und Microsoft killt die Funktion die von Citrix genutzt wurde. Allerdings hatte inzwischen jemand ein einsehen und hat sich zumindest einen Workaround ausgedacht.

Im Citrix Knowledgebase Artikel CTX125693 ist beschrieben wie man eine “ähnliche” Funktion realisieren kann. Natürlich ist es nicht ganz so komfortabel wie es “früher” war und auch mir wäre es lieber wenn es weiterhin über den Klick im Kontextmenü auf “Shadow” klappen würde – aber da hier keine Änderung in Sicht ist nutze ich eben diese Variante.

Nicht schön – aber funktioniert !

Automatische Java Updates verhindern

Sie sind der Alptraum für jeden Citrix Administrator – automatische Update Funktionen von Anwendungen. Beliebteste Beispiele sind für mich immer wieder Java und der Adobe Reader. Wenn ich in meiner zeit als Consultant für jede Anmeldung auf einem Citrix Server bei der mir irgendeine Updatemeldung entgegen blinkt 10 Euro bekommen hätte, dann könnte ich meinen Job aufgeben und in Florida am Strand liegen.
Dabei ist es eigentlich so einfach, den meist kann der Updatemechanismus bereits im Rahmen der Installation ziemlich einfach verhindert werden. In diesem Artikel soll es um die korrekte Installation der JAVA Runtime gehen, den Adobe Reader werde ich mir in einem späteren Artikel vornehmen. Die Updatekomponente kann entweder direkt bei der Installation oder auch bei bereits installierten Komponenten deaktiviert werden.

Vor der Installation:
Die Installation kann mit der Kommandozeile UPDATE=0 verhindert werden. Dies erfordert das die Java Installation über eine angepasste Installation ausgeführt wird. Eine gute Beschreibung findet sich im folgenden Blogartikel.

<jre>.exe /s /v"/qn IEXPLORER=1 ADDLOCAL=ALL UPDATE=0 REBOOT=supress"

Für bereits installierte Systeme:
wurde die Java Komponente bereits installiert, kann es im Nachgang angepasst werden. Dazu nutze ich (wie immer) die Group Policy Preferences um die Registry anzupassen.

Action Update:
[HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Update\Policy]
”EnableJavaUpdate”=dword:00000000

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\JavaSoft\Java Update\Policy]
”EnableJavaUpdate”=dword:00000000

[HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Plug-in\<Plugin Version>]
”HideSystemTrayIcon”=dword:00000000

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\JavaSoft\Java Plug-in\<Plugin Version>]
”HideSystemTrayIcon”=dword:00000000

[HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Update\Policy]
”NotifyDownload”=dword:00000000

Action Delete:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run}
”SunJavaUpdateSched”

.

Client drive mapping

Noch ein Nachtrag zu meinem Artikel zum Thema Laufwerksbuchstaben. Die Clientlaufwerke des Computers werden in einer Citrix Sitzung vom Buchstaben V: beginnend rückwärts verbunden. Dabei wird für das lokale Clientlaufwerk C: der Buchstabe V:, für das lokale Clientlaufwerk D: (wenn vorhanden) der Buchstabe U: usw. verwendet.

imageDas Laufwerk D: ist hier allerdings schon ein Sonderfall, denn grundsätzlich werden nur Laufwerksbuchstaben “ersetzt” die auf dem Server schon benutzt sind. Sollte der Server selbst also z.B. nur über ein C: Laufwerk verfügen dann wird das lokale Clientlaufwerk D. auch innerhalb der Sitzung auf D: verbunden.

Leider wird gerade das Laufwerk U: in verschiedenen Unternehmen gerne als “Home-Laufwerk” (U: für User) genutzt. Dies führt dann zum Problem das hier der selbe Buchstabe für unterschiedliche Verknüpfungen genutzt werden soll. Im Knowledgebase Artikel CTX122061 gibt es hierzu eine Lösung. Das lokale Laufwerk C: kann über einen Registryeintrag auf einen anderen Buchstaben gewechselt werden indem quasi der “Startpunkt” der Client Drive Mappings verändert wird. Auch dieser Wert lässt sich mit einer Group Policy Preference Einstellung konfigurieren. 

imageIn diesem Beispiel wurde das InitialClientDrive auf M gesetzt und somit wird das lokale Clientlaufwerk C: in der Session mit dem Buchstaben M: angezeigt.

Grundsätzlich sollte Client Drive Mapping nur eingerichtet werden wenn es unbedingt gefordert ist.

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Citrix]
”InitialClientDrive”=”M”
 

.

Anmeldeprozess optimieren

XenAppLogoEs gibt bessere Dinge die man an einem Feiertag machen kann, aber was macht man nicht alles wenn beim grillen im Garten ein Freund von der neuen Citrix XenApp 6 Farm in der Firma erzählt und wie LANGSAM die Anmeldung an dem Teil sei. Wenn er dann noch zufällig das Notebook im Auto hat und die UMTS Verbindung klappt, dann kann man ja zwischen Steak auf dem Grill umdrehen und sonstigen wichtigen Dingen ein wenig spielen. Zu seiner Ehrenrettung – er muss das Teil seit kurzem administrieren, installiert wurde es von einem “Systemhaus mit tiefem Know How in der Citrix Welt”. Klingt schon mal nicht schlecht.

In den vergangenen Jahren gab es immer wieder nette Menschen die ihre Informationen zum Thema An- und Abmeldeprozess und den damit verbundenen Problemen und Möglichkeiten zur Optimierung im Citrix XenApp Umfeld gesammelt und veröffentlicht haben. Zu erwähnen sind da die beiden Monster – Visio – Charts zum Logon und Logoff die Brian Madden 2006 veröffentlicht hat, sowie das aus meiner Sicht nach wie vor beste Dokument zu diesem Thema von Thomas Koetzing aus dem Jahr 2003 (aktualisiert 2006). Was ich allerdings richtig Cool fand ist, dass Citrix genau an dem Tag an wir es benötigen einen neuen Knowledgebase Artikel mit der Nummer CTX128277 hat in dem es ebenfalls um die User Logon Optimization geht.

Der eigentliche Grund für die Anmeldeverzögerung lag aber in einer anderen Sache – der hier nicht namentlich genannte Dienstleister hat die Server ohne SP1 installiert und bekanntlich gibt es dort die in den MS Knowledgebase Artikeln 2409711 und 977346 beschriebenen Probleme – wenn man die notwendigen Voraussetzungen erfüllt. In seiner Umgebung waren beide Dinge erfüllt “Solid Background” und “Hide all icons on Desktop”.

Ich bin schon jetzt auf die Stellungnahme zu den Fragen – warum XenApp 6.0 und nicht 6.5, warum Windows Server 2008 R2 ohne SP1 und warum Einstellungen wie die oben genannten wenn doch eigentlich nur Published Applications genutzt werden gespannt.

Ja – manchmal bin ich auch schadenfroh. Zwinkerndes Smiley