CTX-Blog

Kürzlich bekam ich den Auftrag, einen neuen XenDesktop 7.0 RDS Host zu installieren. Auf der neuen Plattform sollte dann auch Office 2013 laufen. Kein Problem dachte ich mir und ging ans Werk. Nach Abschluss der Installation und dem Einspielen aller Windows Updates (mehr als 3GB, unfassbar), gab es aber eine unliebsame Überraschung. Bei jedem Start von Outlook kam zuerst eine Windows Installer Meldung, die Outlook konfigurieren wollte. Anschliessend lief Outlook zwar problemlos, aber der Windows Installer meldete sich bei jedem weiteren Start erneut 🙁

Dem Eventlog konnte man leider keinen direkten Hinweis auf die Fehlerursache entnehmen, es wurden nur eine Reihe Informationen, aber keinerlei Fehler geloggt, s. Screenshot:

Eine Office 2013 Reparatur blieb genauso erfolglos, wie weitere “Rettungsversuche” mit Registry Keys von Office 2010, wie in diesem Thread beschrieben: Office-2010-Professional-Plus-configures-each-time-i-launch-fixed. Auch ein komplett neu installiertes System zeigte die gleiche Symptomatik.

Nach langem Suchen im Internet stiess ich dann auf folgenden Thread, der mir die Lösung brachte: Outlook-2013-starts-configuration-every-time

Outlook 2013 benötigt auf einem Server 2012 den Windows Search Service um das Setup abzuschliessen. Ist dieser Service nicht installiert (was auf einem RDS Host der Standard ist), kommt bei jedem Start von Outlook der Windows Installer und versucht das “Problem” zu reparieren. Nachdem ich den Search Service als Feature installiert hatte und den Service auf “disabled” gesetzt hatte, war die Windows Installer Meldung verschwunden 🙂

Gruss
Ecki

Not long ago I was asked to install a new XenDesktop 7.0 RDS host. Office 2013 should run on this system also. An easy one was my first thought and I went to work. After installing Server 2012, Office 2013 and all the needed Windows Updates (more than 3GB, incredible) I discovered an unpleasant surprise. With every start of Outlook, a Windows Installer window popped up, telling me that Office would now be configured. After that, Outlook worked fine without errors but the Windows Installer popped up again and again with every start of Outlook 🙁

The Windows Event Log didn’t really help much because it only showed some informational messages of the Windows Installer but no error messages, see the following screen-shot:

An Office repair didn’t help as was the case with several other “rescue attempts” with registry keys mentioned in an article about Office 2010 problems: Office-2010-Professional-Plus-configures-each-time-i-launch-fixed. Even a brand new installed system showed the same symptoms.

After a long search on the Internet I stumbled upon the following thread that helped me to solve the problem: Outlook-2013-starts-configuration-every-time

Outlook 2013 on Server 2012 needs the Windows Search service to finalize its setup. If this service is not installed, which is the default for RDS, then Outlook tries at every start to “fix” the problem. After installing the Windows Search service feature and setting it to “disabled” in the Services manager, the Windows Installer pop-ups disappeared 🙂

Regards
Ecki

Ich bin vor kurzem über ein sehr seltsames Verhalten der Citrix AMC gestolpert, bei der die Option für 32bit Icon Support nicht angezeigt wurde, obwohl alle Prerequisites installiert waren. Nur durch einen Zufall sind wir auf die Lösung gekommen.

Das Problem betrifft alle XenApp Versionen die ich testen konnte, einschliesslich Presentation Server 4.5 und XenApp 5.0, sowohl für W2k3 als auch für W2k8.

Das Problem zeigt sich folgendermassen. In den Eigenschaften der Farm ist der Platz, an dem die 32bit Icon Option stehen sollte leer. Die Option für 32bit Icons ist daher nicht verfügbar 🙁

Der Verursacher dieses Phänomens ist tatsächlich eine Konfiguration beim Farm-Discovery. Ich verwende gelegentlich LOCALHOST in der Liste der für das Discovery zu verwendenden Server. So funktioniert das Discovery immer, auch bei Roaming Profiles und XenApp Servern ohne IIS Installation.

Ist das Discovery folgendermassen konfiguriert, verschwindet die 32bit Icon Option aus der AMC:

Wird dagegen wieder der lokale Server beim Discovery verwendet,

erscheint wie durch ein Wunder die vermisste Option wieder in den Farm Eigenschaften.

Man kann das Verhalten jederzeit problemlos reproduzieren. Zugegebenermassen ist das nicht unbedingt ein alltägliches Problem, aber seltsam ist das Verhalten schon und wenn ihr in Zukunft mal darüber stolpert, seid ihr gewarnt…

Gruss
Ecki

I recently stumbled uppon a really weired problem with 32bit icon support in XenApp. Under certain circumstances the AMC won’t show the option for 32bit icon support in the farm properties even if all prerequisites are perfectly met. We found out the reason for that behaviour only by accident.

The problem can be seen with all versions of Presentation Server 4.5 and XenApp 5.0 for w2k3 as well as for w2k8.

If the problem hits you, the farm properties won’t show the option for 32bit icon support, but there will only be a blank space 🙁

The reason for this odd behaviour can be found in the configuration of the farm-discovery. I sometimes use LOCALHOST as the hostname for discovery. This is helpful in situations where you have roaming profiles and IIS is not installed on the XenApp servers.

But if you configure discovery that way there will be no 32bit icon option in the AMC.

If you change the discovery option back to the local server

the missing option reappeares again.

You can toggle that behaviour as you like. Admittedly this is not a common problem but it is odd and if you happen to see it, you will be warned…

Regards
Ecki

Best Practice im Citrix Umfeld ist es, Usern, die auf einen Presentation Server zugreifen dürfen, den Zugriff via RDP-Protokoll zu verweigern, da hier u. A. die Citrix Policies nicht ziehen. Das standardmässig von Microsoft vorgeschlagene Vorgehen, den Zugriff auf die Terminalserver durch die lokale Gruppe “Remote Desktop Users” zu steuern funktioniert dann allerdings nicht mehr. Es muss statt dessen eine eigene Gruppe erstellt und gepflegt werden, die den Zugriff über das ICA Protokoll steuern kann. Ich nenne diese Gruppe in unserem Beispiel “CTX_User”. Damit Mitglieder dieser Gruppe auf einen Presentation Server zugreifen können, müssen zwei Bedingungen erfüllt sein.

1. Berechtigung auf dem ICA Protokoll

2. Das Recht “Log on through terminal services”, etweder lokal, oder besser verteilt via GPO

Dies gilt für Windows Server 2003. Bei Windows Server 2000 wird das Recht “Log on localy” benötigt. Dabei ist zu beachten, dass bei Aktivierung dieser Policy alle Gruppen referenziert werden müssen, die später in irgendeiner Form via Terminal Services auf den Server verbinden dürfen. Fehlt ein User, oder eine Gruppe in dieser Auflistung, erscheint sonst bei einem Anmeldeversuch folgende Fehlermeldung:

Ein weiterer Tipp an dieser Stelle: Idealerweise verbietet man das Ressource Mapping auf dem RDP Protokoll zumindest für Drucker so früh wie möglich, um das Einschleppen von Druckertreibern zu verhindern. Da normalerweise nur Administratoren via RDP verbinden, die über genügend Rechte zum Installieren von Treibern verfügen, werden sonst alle lokalen Drucker auf dem Terminalserver installiert, was schnell zu einem Wildwuchs in der Treiberlandschaft führt. Weiter Ressourcen können nach Belieben ebenfalls schon hier geblockt werden, s. Screenshot:

Diese Tasks lassen sich, wie weiter Oben gesehen, bequem über die GUI erledigen. Dies ist jedoch sehr mühsam, wenn man 50+ Server zu betreuen hat. Hier hat Marcel Göertz aus den Niederlanden einen sehr interessanten Artikel verfasst, wie diese Aufgabenstellung mittels WMI viel eleganter zu lösen ist.

Benutzer(Gruppen) mittels WMI berechtigen
In dem Codebeispiel weiter Unten wird der User domain\johndoe auf dem RDP Protokoll als User berechtigt. Dabei ist es wichtig, dass der Code auf der Maschine ausgeführt wird, für die diese Berechtigung gelten soll.

Achtung: Alle Codebeispiele bestehen aus nur einer Zeile, egal wie der Browser dies darstellt! Evtl. vorhandene Zeilenumbrüche müssen mit einem Leerzeichen ersetzt werden.
WMIC /NODE:"." RDPERMISSIONS WHERE TerminalName="RDP-tcp" CALL AddAccount "domain\johndoe",1

Drei Teile dieser Kommandozeile müssen hier erläutert werden:

• TerminalName=”RDP-tcp”
  Für RDP ist der Name normalerweise RDP-tcp. Falls dieser Name auf deinen Servern anders lautet, muss der Wert angepasst werden.
  Um die Berechtigungen für das ICA Protokoll anzupassen, muss TerminalName=”ICA-tcp” verwendet werden. Konsolenzugang kann mittels TerminalName=”console” gesteuert werden.
• AddAccount “domain\johndoe”
  Die Funktion “AddAccount” benötigt entweder einen User-, oder Gruppennamen inklusive Domäne. Um Built-In User hinzuzufügen, kann domain mit builtin ersetzt werden, z. B. AddAccount “builtin\Administrator”. Um eine Gruppe hinzuzufügen, kann einfach der Gruppenname verwendet werden, z. B. AddAccount “domain\Domain Admins”.

Ein Beispiel:
WMIC /NODE:"." RDPERMISSIONS WHERE TerminalName="RDP-tcp" CALL AddAccount "domain\Domain Admins",2

• Vollzugriff, Gast-, oder Userzugriff
  Die abschliessende 2 in dem Beispiel beschreibt die Zugriffsrechte, wobei:
  • 0 : Guest Access
  • 1 : User Access
  • 2 : Full Control

  bedeuten.

ICA/RDP Berechtigungen entfernen
Um Berechtigungen auf einem Protokoll wieder zu entfernen, muss die Syntax etwas angepasst werden.
In diesem Beispiel wird der Built-In Gruppe “Remote Desktop Users” der Zugriff über das ICA Protokoll entzogen:
WMIC /NODE:"." RDACCOUNT WHERE "TerminalName='ICA-tcp' and AccountName='Builtin\\Remote Desktop Users'" CALL Delete

Um die “Domain Users” Gruppe zu entfernen, wird folgender Code benötigt:
WMIC /NODE:"." RDACCOUNT WHERE "TerminalName='ICA-Tcp' and AccountName='domain\\Domain Users'" CALL Delete

Hast du den doppelten Backslash bemerkt? Dieser ist, aus für mich nicht nachvollziehbaren Gründen, leider notwendig. Zumindest bist du jetzt gewarnt 😉

Komplettes Beispiel
Hier ist ein Beispiel für ein dreizeiliges Batch Script, um einen Terminalserver abzusichern.
Mit PsExec, einem genialen Tool aus der PsTools Sammlung von Sysinternals auf allen Remote Servern ausgeführt, ist eine Serverfarm in kürzester Zeit aktualisiert.
Die drei Zeilen machen folgendes:

• 1. Stellt sicher, dass nur Citrix Administratoren (domain\citrixadmins) den Server via RDP erreichen können
• 2. Entfernt die Berechtigungen für die “Domain Users” Gruppe
• 3. Entfernt die Berechtigungen für die “Remote Desktop Users” Gruppe

WMIC /NODE:"." RDPERMISSIONS WHERE TerminalName="RDP-tcp" CALL AddAccount "domain\citrixadmins",2
WMIC /NODE:"." RDACCOUNT WHERE "TerminalName='RDP-tcp' and AccountName='domain\\Domain Users'" CALL Delete
WMIC /NODE:"." RDACCOUNT WHERE "TerminalName='RDP-tcp' and AccountName='Builtin\\Remote Desktop Users'" CALL Delete

Info: Wenn ein, oder mehrere Gruppen die gelöscht werden sollen nicht berechtigt waren, läuft das Script trotzdem, mit einer Meldung ‘no such instance’, weiter.

Der Originalartikel kann übrigens hier nachgelesen werden.

Gruss
Ecki

I recently stumbled across this realy good article about restricting access to the RDP/ICA protocol on a Citrix or terminal server through WMI. You don’t have to be a programmer to understand the code, since it is realy easy to use and implement. With just one line of code it is possible to add/remove a user or group from the ICA/RDP protocol, thus allowing for better security for your servers.

If you have to setup or manage several terminal servers, this article can ease your life.

The article can be found here.

Regards
Ecki

Wer schon ein Mal einen Desktop gepublished hat, kennt sich dieses Phänomen. Ein User meldet sich zum ersten Mal am Terminal Server an und obwohl weder im Default User, noch im All Users Profil ein Outlook Express Icon vorhanden ist, erscheint es im Startmenü des Users.

Wo kommt es her? Und noch viel wichtiger, wie bekomme ich es weg?

Das Icon manuell aus jedem Userprofil zu löschen kann keine Lösung sein, daher ist die Suche nach dem “Woher” der bessere Weg. Die Lösung findet sich, wie so oft, in der Registry

Unter dem Key:

HKEY_LOCAL_MACHINE\Software\Microsoft\Active Setup\Installed Components\{44BBA840-CC51-11CF-AAFA-00AA00B6015C}\

findet sich ein REG_SZ Eintrag mit dem Namen “StubPath“. Wenn dieser Eintrag gelöscht wird, erzeugt der Terminal Server keine neuen Outlook Express Icons mehr bei der Useranmeldung. Bestehende Icons werden dadurch jedoch nicht mehr entfernt.

Ein Beitrag aus der DCUG beschreibt das blosse Umbenennen des Eintrags in “HideStubPath“, welches den gleichen Effekt erzielt und sich leichter rückgängig machen lässt.

Gruss
Ecki

If you have ever published a terminal server desktop, you have seen this happening almost for sure. Even if there is no Outlook Express icon in the All Users or Default Users folder, the icon appears in the start menu after a user logs on for the first time.

Why is this happening? And much more interesting, how can you avoid this?

To delete the icon from every users profile is not a viable option. So it’s best to look for the root cause of this problem. As often, the solution can be found in the registry.

Below the key:

HKEY_LOCAL_MACHINE\Software\Microsoft\Active Setup\Installed Components\{44BBA840-CC51-11CF-AAFA-00AA00B6015C}\

you can find a REG_SZ entry with the name “StubPath“. If you delete this entry, the terminal server will never again create this icon at user logon. Existing icons however will not be deleted.

A post in the DCUG describes a similar procedure but simply renames the entry to “HideStubPath“. The effect is the same, but it is much easier to revert back.

Regards
Ecki