b. Also you have to add the Feature “.NET Framework 3.5.1”
ATTENTION: It is really important to change the sorting to “Latin1_General_CI_AS_KS_WS” otherwise the Database will not be usable!!
Furthermore you have to grant an AD-User “DB-Owner rights” for the just created Database. Moreover this user must have the rights to “Log on as a Service” and “Log on as a batch job” – both can either be configured by using a group-policy or by modifying the local security settings.
a. Accept the license agreement
b. Now choose „Advanced“. This is really important because otherwise it will not be possible to choose an SQL-Database-Server – instead the Windows Internal Database will be used.
c. At the next screen it is again really important to choose “Web Front End” instead of the default selection “Stand-alone”.
After selecting „Web Front End“ start the installation with „Install Now”
d. At the end of the installation start the Configuration Wizard
e. Just click on Next
f. Accept the following warning with “Yes”
g. Now choose „No, I want to create a new farm”
h. Insert the name of your MS-SQL-Database-Server, the name of the Database and the created user with the configured password.
i. In the next screen you can change the Port of the SharePoint Central Administration Web-Page and choose an authentication method.
j. After this an overview of the chosen Configuration is displayed. With a click on „Next“ the configuration starts.
k. When the configuration was successful the following information’s will be displayed.
l. When you now click on finish the SharePoint-Administration-Website should be launched and ask you for administrative login information’s. Log-In with an Administrator-Account – now the Administration-Website is visible. Just close the Website: We will now install the Multi-Language-User interface.
i. Run the SharePointLanguagePack Setup – there is no configuration needed – just accept the license.
ii. When the installation is finished remove the checkbox and choose finish.
iii. Now Service Pack 2 has to be installed for the Language Pack – start with accepting license.
iv. When the Configuration Wizard pops-up click on Next and accept the restart of some services with “Yes”
At the end again a Successful Configuration Dialog will be displayed and the Administration-Web-Page is opened.
You can now create a SharePoint Website and choose a language for this Website. BUT it is not possible (or better: I didn’t find a solution for it) to display a Website in two language. So you have to choose at the Website CREATION in which language the Website will be displayed!!
After searching a while which service doesn’t exist i found the correct one. It was the "Wlansvc" service.
1. Download the 64bit Isap_Redirect.dll from http://www.apache.org/dist/tomcat/tomcat-connectors/jk/binaries/
2. Copy the downloaded file to c:Program FilesApache Software FoundationTomcat 6.0binwin64 (or any other path)
3. Import the following registry file into the registry (change the path to the isapi_redirect.dll and to the tomcat folder).
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINESOFTWAREApache Software FoundationJakarta Isapi Redirector1.0]
@=""
"extension_uri"="/jakarta/isapi_redirect.dll"
"log_file"="C:\Program Files\Apache Software Foundation\Tomcat 6.0\logs\isapi_redirect.log"
"log_level"="error"
"worker_file"="C:\Program Files\Apache Software Foundation\Tomcat 6.0\conf\workers.properties.minimal"
"worker_mount_file"="C:\Program Files\Apache Software Foundation\Tomcat 6.0\conf\uriworkermap.properties"
4. Open IIS Manager => Server => ISAPI and CGI Restrictions
5. Select the isapi_redirect.dll, and choose a description – also activate “Allow extension path to execute”
6. Open the Website where you want to activate the redirect and open the option “ISAPI Filters”
7. Add an ISAPI Filter with the following configuration:
Filter name: isapi_redirect (for example)
Executable: click on “…” and change to the isapi_redirect.dll folder and choose the “isapi_redirect.dll”
8. Add an “Virtual Directory” under your Website. Name it “jakarta” and choose as the path the path to the isapi_redirect.dll
9. Now open the “Handler Mappings” on the just created “Virtual Directory” and click on “Edit Feature Permissions”
10. Activate Execute
11. Create a file named „workers.properties.minimal” in the “conf” folder which you can find in the tomcat folder.
Insert the following lines into this file:
#
# The workers that jk should create and work with
#
worker.list=local
#
# Defining a worker named ajp13w and of type ajp13
# Note that the name and the type do not have to match.
#
worker.ajp13w.type=ajp13
worker.ajp13w.host=localhost
worker.ajp13w.port=8009
12. Create another file named „uriworkermap.properties” in the same directory.
Insert the following lines into this file (for a web-application named “testapp”, if your webapp is “called” “hansifransi” you must remove “testapp” and add “hansifransi”):
/testapp/*=local
13. Restart the Tomcat Service and the IIS Web-Server
14. Finished 🙂 Now you can open your Tomcat-Websites by addressing an “virtual” IIS Website.
A short description how to activate PHP5 (X64) under IIS7.5 (Windows 2008 R2 X64):
One thing before: I found some solutions in which it was explained how to activate PHP5 with FastCGI – these solutions didn’t work for me so I decided to use the “old” Isapi way.
1. Download a PHP X64 Version (for example from http://fusionxlan.com/PHPx64.php (php-5.2.5-x64-2007-11-12.zip))
2. Extract the files to a temporary folder
3. Copy everything that is inside of the extracted folder “php-5.2.5 (x64)” to a new folder (for example) “C:php”
4. Activate the “ISAPI IIS Role Service” with the Server Manager (or the power shell)
5. Rename the file “C:phpphp.ini-recommended” to “php.ini”
a. Open the php.ini and change the following things:
i. Activate the option “open_basedir” and point it to the folder where the website(s) files are located.
ii. Activate the option “extension_dir” and point it to a folder where the PHP extensions can be found. In a typicall installation it would be:
extension_dir = “./ext”
iii. Activate the required php extensions (uncomment the needed “lines”) for example:
extension=php_mssql.dll
extension=php_mysql.dll
b. To test if the PHP installation is successful, run the following from the command line prompt:
C:PHP>php –info
If everything is correct a lot of php infos are displayed now.
6. Open Internet Information Services (IIS) Manager from the Startmenu
7. Open “Handler Mappings”
8. Choose: “Add Module Mapping”
9. Add the following entries:
a. Request path: „*.php“
b. Module: „IsapiModule“
c. Executable: „C:phpphp5isapi.dll“
d. Name: „PHP via Isapi“
e. Confirm with „OK“
10. Allow the „Isapi extension“
11. For testing if the mapping works correctly creat a file called “phpinfo.php” in C:inetpubwwwroot. Insert this code into the file:
<?php phpinfo(); ?>
12. Now you can open the phpinfo file in a WebBrowser:
or if you are logged on to the web server:
You will now see the default php Info page:
13. Finished – now you can use php scripts in your IIS 7.5 under Windows 2008 R2 64 Bit
In meinem heutigen Post möchte ich euch erklären, wie ihr mithilfe des Citrix Provisioning Servers auf einem Igel Universal Desktop Thin Client (Vorzugsweise UD5) ein vollwertiges Windows XP (Windows 7) bereitstellen könnte. Hierfür benötigt ihr folgendes:1. Citrix Provisioning Server
2. Igel Universal Desktop (UD5)
3. USB-DVD-Rom-Laufwerk
4. Eine 2,5 Zoll HDD und ein passendes “IDE-Kabel”. Alternativ könnt ihr auch eine 3,5 Zoll Festplatte verwenden. Ihr benötigt dann einen 2,5 => 3,5 Zoll Adapter und ein externes Netzteil
5. Eine CD/DVD mit Windows XP (Windows 7)Und dann kann es auch schon losgehen:
1. Zunächst schraubt ihr auf der Hinterseite des Igels die vier rot markierten Schrauben heraus.
2. Anschließend könnt ihr das “Innenleben” problemlos nach vorne aus dem Gehäuse herausschieben/-ziehen. Zum Vorschein kommt das folgende Board:
3. Auf diesem zieht ihr nun die Compact-Flash-Karte aus ihrem Slot und legt sie beiseite.
4. Danach schließt ihr das 2,5 Zoll IDE Kabel (alternativ den Adapter) an den erkennbaren IDE-Anschluss (vor dem Halteplatz der Compact-Flash-Karte) an. Achtet hierbei unbedingt darauf, dass ihr den 1. Pol des Kabels/Adapters auf den richtigen Pin steckt. Die Pins des Boards sind beschriftet, so dass hier keine Probleme entstehen sollten. Die erste Ader des Kabels ist die lila markierte. An das andere Ende des Kabels kommt natürlich die IDE-HDD 🙂
Falls ihr lieber eine 3,5” HDD verwenden möchtet, dann benötigt ihr folgenden Adapter:
Achtung: Ihr benötigt dann noch eine externe Stromversorgung für die 3,5” HDD. Das am Adapter vorhandene Stromkabel darf allerdings NICHT mit einer Stromquelle verbunden werden.5. Nun verbindet ihr den Igel mit Monitor, Maus, Tastatur und dem USB-DVD-Rom-Laufwerk. In das DVD-Rom-Laufwerk legt ihr schon einmal die Betriebssystem-CD/DVD ein.6. Beim starten des Igels drückt ihr “Entf” auf der Tastatur, so dass ihr in das Bios gelangt. Hier stellt ihr nun als erstes Boot-Device “USB-CD-Rom” ein. Anschließend erscheint wie gewohnt das Windows Setup und einer Windows-Installation steht nichts mehr im Wege.7. Nachdem Windows installiert ist, müsst ihr natürlich noch die üblichen Provisioning Server Schritte durchführen, damit ihr die “echte” Festplatte in eine virtuelle umwandelt.
7 a. Installation der Provisioning Server Tools
7 b. Neustart des Gerätes (Hierbei unbedingt im Bios die Option “Boot from Lan” aktivieren, damit der Igel-Thin-Client vom Netzwerk startet.
ACHTUNG: Es genügt nicht die Boot-Reihenfolge zu ändern. In einem separaten Bios-Menü-Punkt muss noch der Lan-Boot (grundsätzlich) aktiviert werden, damit dieser funktioniert! Solange diese Option aktiviert ist, könnt ihr übrigens (bei eingebauter Compact-Flash-Karte mit Igel OS) nicht mehr von dieser starten – erst nach Deaktivierung von dieser Funktion startet das Igel Betriebssystem wieder fehlerfrei.
7 c. Der Igel sollte nun in der Provisioning Server Console auftauchen. Weist ihm hier eine neu angelegte virtuelle Festplatte mit ausreichend Kapazität zu.
7 d. Erneuter Neustart des Igel-Thin-Clients
7 e. Konvertieren der “echten” Festplatte mithilfe der Provisioning Server Tools in die virtuelle Festplatte
8. Jetzt wo die Festplatte umgewandelt ist, könnt ihr den Thin-Client wieder in sein Gehäuse einbauen. Aus Performance-Gründen würde ich euch allerdings empfehlen den eingebauten Arbeitsspeicher gegen ein etwas größeres Modul zu tauschen. 1GB und 2GB Modelle habe ich erfolgreich und ohne Probleme getestet. Ob hier allerdings jeder Hersteller funktioniert, kann ich natürlich nicht sagen :)9. Ihr seit nun fertig mit allen grundsätzlichen Installationen/Konfigurationen. Entweder ihr installiert nun noch alle benötigten Programme/Treiber usw. in die virtuelle Festplatte und verwendet sie anschließend als “Standard”-Image für mehrere Thin-Clients oder Ihr belasst es bei einem “Private”-Image und könnt von nun an auf einem Igel-Thin-Client mit einem vollwertigen Windows arbeiten.Ich hoffe euch hat diese kleine Anleitung gefallen und zum “nachbasteln” angeregt. Abschließend möchte ich Euch nur noch auflisten, was uns dazu bewogen hat Windows XP provisioniert auf Igel-Thin-Clients bereitzustellen:
– Verschiedene Arbeitsplätze benötigen lokale Scanner oder z.B. Kartenlesegeräte. Unter dem “Igel Universal-Desktop” Betriebssystem ließen sich diese Geräte nicht ansprechen, unter Windows PE fehlten uns die eingeschränkten administrativen Vorgabemöglichkeiten. Bei dem auf diese Methode bereitgestellten Windows ließen sich problemlos die benötigten Treiber installieren. Zudem können die Geräte auch problemlos aus einer hergestellten Citrix-Sitzung angesprochen werden, so dass auf den Clients selber lediglich z.B. die Scann-Software gestartet wird.
– Wir erreichen so eine noch weitere Standardisierung der Hardware. Da wir viele Arbeitsplätze haben, welche bereits nur noch mit einem Thin-Clients ausgestattet sind, können wir so nun auch an den “speziellen” Arbeitsplätzen die gleiche Hardware einsetzen ohne großen Konfigurationsaufwand betreiben zu müssen.
– Bei Ausfall eines der Geräte kann der Benutzer zeitnah weiterarbeiten: Es wird einfach ein neuer Igel-Thin-Client auf den Netzwerk-Boot umgestellt. Anschließend wird ihm in der Provisioning Server Console noch die benötigte virtuelle Festplatte zugewiesen und schon kann der Benutzer weiterarbeiten.Diese Lösung ist natürlich nicht für Hochleistungs-Arbeitsplätze (z.B. CAD) geeignet – dafür sind die Igel-Thin-Clients von der Hardware definitiv zu langsam. Für Arbeitsplätze an denen aber lediglich ein lokaler Treiber benötigt wird, um z.B. Scanner bereitzustellen (welche in einer XenApp Sitzung verwendet werden sollen), ist diese Lösung mehr als ausreichend.
Heute möchte ich euch von einem mehr als kuriosen Fehler berichten:
Verschiedene Benutzer von uns haben versucht die Webseite http://www.minden-luebbecke.de aufzurufen. Alle diese Benutzer arbeiten entweder mit einem etwas älteren Igel Gerät (z.B. 53XX LX und der Firmware 3.09.200) oder mit aktuellen Geräten der Universal Desktop Serie (z.B. UD5 mit Firmware 4.01.100.01). Die Benutzer verbinden sich alle per ICA-Verbindung zu einem „vollen“ Desktop eines Terminal-Servers und starten auf diesem den Internet-Explorer 7.
Wenn die Benutzer nun die Webseite aufgerufen haben, dann sah diese wie folgt aus (zur Erstellung aller folgenden Screenshots wurde ein Thin-Client mithilfe der Igel Universal-Management-Suite gespiegelt):
Wenn nun der Benutzer von dieser Webseite einen Screenshot erstellt hat, damit er uns den Fehler zeigen konnte, dann sah der Screenshot wie folgt aus:
Im Screenshot wird die Webseite korrekt angezeigt, obwohl sie im Browser total „verhunzt“ aussieht. Dies ist schon mehr als merkwürdig.
Wenn sich nun ein anderer Benutzer die „fehlerhafte“ Sitzung mit den Citrix-Hilfsmitteln spiegelt, dann sieht die Webseite augenblicklich beim Benutzer so aus:
Es erfolgt also ebenfalls eine korrekte Darstellung der Webseite.
Auch nach Beendigung der Spiegelung bleibt die Darstellung korrekt. Zudem können nun auch problemlos weitere Unterseiten aufgerufen werden, ohne dass die Darstellung nicht mehr korrekt ist. Sobald aber der Browser neu gestartet wird oder erneut die Startseite aufgerufen wird, ist wieder der gleiche Fehler vorhanden.Mit Windows-PCs als Clients ist der Fehler nicht reproduzierbar.
Nach längerem suchen habe ich schließlich die Lösung für das Problem gefunden:
Sobald auf der XenApp Farm die Funktion „Speed Screen Browser Beschleuning“ deaktiviert wird und die ICA-Verbindung neu aufgebaut wird, ist der Fehler verschwunden – hier scheint also in der Kombination Linux (Igel) Ica-Client und der „Speed Screen Browser Beschleunigung“ etwas nicht korrekt zusammen zu arbeiten.
Hier die Fortsetzung des Berichtes über die (nicht) im Netzwerk funktionierenden HP Druckertreiber:
Nachdem ich nun im “Master-Image” unserer XenApp Server sämtliche Netzwerk-Drucker lokal installiert hatte, aktivierte ich noch eine Gruppenrichtlinie und ein Kix-Script zum löschen der Drucker:
Ergebnis war, dass die Anmeldungen am Montag noch länger dauerten, bzw. teilweise gar nicht möglich waren und zudem regelmäßig die Druckwarteschlangen auf den einzelnen XenApp-Servern abstürzten, so dass in etlichen Benutzerprofilen weiterhin Netzwerkdrucker vorhanden waren.
Wir entschlossen uns daher am Montag Abend noch einmal alle Benutzerprofile zu löschen, so dass diese bei einer Anmeldung der Benutzer am Dienstag erneut neu angelegt werden. Dies ist nun heute geschehen – und siehe da: Die XenApp Server arbeiten wie von vornherein geplant ohne extreme CPU-Auslastung und nur mit gelegentlichen Spitzen beim starten einzelner Programme.
Noch einmal zusammengefasst unsere Lösungsschritte, damit die Benutzer (trotz HP Druckern) performant arbeiten können:
1. Installation sämtlicher Netzwerkdrucker lokal auf den XenApp Servern
2. Umbenennen/Sichern der beiden folgenden Dateien: cioum32.msi, HPZBDI32.msi (Beide sind in folgendem Ordner zu finden: c:windowssystem32spooldriversw32x863)
3. Erstellen einer 0Byte txt-Datei mit exakt dem gleichen Namen der gerade umbenannten/gesicherten Dateien und Speicherung von diesen unter “c:windowssystem32spooldriversw32x863”
4. Löschen sämtlicher Benutzerprofile und Neuerstellung dieser ohne Netzwerkdrucker
Mit Druckern einiger anderer Hersteller waren diese extremen Auslastungen/Verzögerungen bei der Druckerverbindung übrigens nicht reproduzierbar. Ich warte auch zudem noch auf einen Vorschlag von Microsoft zur Problembeseitigung – mal schauen, was die Jungs sich dort noch überlegen 🙂
Moin Moin.
In meinem ersten Blog-Eintrag möchte ich euch aus meinem Admin-Leben von meinen neuesten Erfahrungen mit HP Druckern und ihren Treibern berichten:
Vergangenen Mittwoch stellten wir unsere XenApp Farm von Windows 2003 auf Windows 2008 mit XenApp 5.0 um. In Tests vorab hatte ich festgestellt, dass das verbinden von freigegebenen HP Druckern vom Druckserver beim Benutzer recht lange dauert (ca. 45-60 Sekunden pro Drucker) und die CPU des Terminal-Servers sehr stark belastet wird – anschließend lief das System im Test aber problemlos.
Ich änderte also die automatische Druckerverbindungen so, dass diese nicht mehr bei der Benutzeranmeldung verbunden werden (der Anmeldeprozess hätte bei einigen Benutzern sonst locker 1-2h gedauert), sondern erst anschließend. Die Benutzer wurden informiert, dass nach der erstmaligen Anmeldung die Drucker über einen längeren Zeitraum verbunden werden, sie aber ansonsten normal arbeiten können, es nur aufgrund der starken CPU-Belastung zu leichten Verzögerungen kommen kann. Dies hat soweit auch alles geklappt und abgesehen von den angekündigten Verzögerungen lief auch alles recht reibungslos.
Wir rechneten also damit, dass es ab Donnerstag wieder ruhiger werden würde und auch die aufgetretenen Verzögerungen verschwinden – dem war leider nicht so 😦
Es stellte sich heraus, dass sobald mehr als ein paar Leute auf einem Terminal-Server angemeldet waren, die CPU-Belastung durch die Prozesse "spool" und "system" wieder extrem anstiegen. Zudem schien dies auch die Ursache für die weiter auftretenden Verzögerungen (z.B. beim schreiben in Word dauerte es bis die eingegebenen Buchstaben auf dem Bildschirm erschienen oder das System machte den Anschein komplett zu “hängen”) zu sein. Nach langer Recherche im Internet entdeckte ich schließlich eine mögliche Ursache: Der von uns verwendete HP Universal Printing Driver soll wohl derartige Fehler verursachen. Die Empfehlung war doch wieder für jeden Drucker die speziellen Treiber zu verwenden – also stellte ich am Donnerstag Abend sämtliche Drucker – die mit dem UPD Treiber liefen – auf ihre speziellen Treiber um in der Hoffnung, dass damit die Verzögerungen am Freitag endlich verschwunden sind.
Leider blieben die Verzögerungen auch am Freitag: Ich suchte also weiter und entdeckte schließlich im HP Support Forum (kleine Anekdote: ich hatte bereits Anfang des Monats bei HP einen Call eröffnet, dass das Verbinden von freigegebenen HP Druckern über das Netzwerk sehr lange dauert – auf eine Reaktion warte ich bis jetzt vergeblich) einen Eintrag vom April. In diesem wurden die gleichen Fehler/Probleme beschrieben, welche auch bei uns auftraten. Die hier vorgeschlagene Lösung war es alle Drucker direkt auf jedem Terminal-Server zu installieren und diese nicht mehr über das Netzwerk zu verbinden. Von Seiten HP gab es auch hier keine Hilfe.
Da die Performanceeinbußen/Verzögerungen für uns nicht mehr akzeptable waren, habe ich nun über das Wochenende alle Drucker auf den Terminal-Servern direkt installiert (zum Glück stellen wir unsere Terminal-Server per Provisioning bereit, so dass ich dieses nur einmal durchführen musste). Zudem war es nötig zweie MSI Dateien durch 0Byte Dateien zu ersetzen, da ansonsten regelmäßig ein Setup der HP Druckertreiber gestartet wird, welches erneut zu einer hohen CPU-Belastung führt. Am Montag werden nun bei allen Benutzern die verbundenen Netzwerkdrucker gelöscht – dies führt übrigens ebenfalls zu einer hohen CPU Belastung durch spool und System – und anschließend läuft das ganze System hoffentlich endlich "Störungsfrei”.
Als Konsequenz aus dem ganzen werden wir jetzt übrigens erst mal Drucker anderer Hersteller (wir hatten uns egtl. für den ausschließlichen Einsatz von HP Druckern entschieden) anschauen, welche ebenfalls einen Universal-Treiber für ihre Drucker anbieten. Mal hoffen, dass diese besser laufen als die HP Treiber.
So das war mein erster (doch recht lang gewordener) Blog Eintrag – ich werde berichten, wie die Umstellung auf “lokale” Drucker geklappt hat 🙂
Jan Hendriks Blog 
