Well, the problem is the timeout associated with each application pool. When IIS detects that an application pool is not responding anymore IIS just assumes something terrible happend and recycles the application pool. But all that really happend is some plain-old-debugging.

In order to circumvent this problem you have to disable the pinging of application pools by IIS. Just open up the advanced settings of the IIS application pool and set pinging to false.

But with Windows 2008 this script is no longer provided. But fortunatly there is a new kid in town: appcmd.exe. This tool can be found in c:\windows\system32\inetsrv.

To restart (recylce) an application pool you just call:

c:\Windows\System32\inetsrv\appcmd recycle apppool "SharePoint - 80"

Once in a while you have to deploy assemblies for a SharePoint based solution (ok, you also might have other solutions which need Assemblies , but in my case I just stumbled across a SharePoint based solution). But deploying the assembly to the GAC or the local bin folder does not mean, that SharePoint (or the IIS) automatically pick up this new version of the Assembly.

Usually you’ll issue an iisreset command in order to get IIS to reload all needed assemblies. Unfortunatly this does take some time, until IIS is fully restarted. This is especially true, when more than one application-pool is running within IIS (for e.g. central administration as well as a couple of web-applications).

Actually it would be sufficient just to restart the portal web-application instead of the whole IIS. So this would mean, we only restart the application pool. Actually this is quite easy to do. Using iisapp.vbs this is just a matter of

cscript iisapp.vbs /a "SharePoint - 80" /r

Actually this could also be part of a nant-build script, so that with each build the application pool is being restart.

<?xml version="1.0" encoding="utf-8" ?>
<project name="Solution" default="deploy" xmlns="http://nant.sf.net/schemas/nant.xsd">
  <loadtasks assembly="f:\build-tools\nantcontrib\bin\nant.contrib.tasks.dll"/>
  <target name="build">
    <msbuild project="FirstActivity.csproj"/>
  </target>
  <target name="deploy" depends="build">
    <gac-install >
      <assemblies>
        <include name="bin\Debug\FirstActivity.dll"/>
      </assemblies>
    </gac-install>
    <exec program="cscript" commandline="iisapp.vbs" workingdir="c:\windows\system32" verbose="true">
      <arg value="/a &quot;SharePoint - 80&quot;" />
      <arg value="/r"/>
    </exec>
  </target>
</project>

A more detailed describtion on how to use this module can be found at Using the IIS Application Warm-Up Module.

But the eventlog stated something strange: the identity of my newly created app pool is invalid! And accessing the app kinda proves this: the app pool is being deactivated in IIS.

But now to the rescue: the identity setup in the app-pool must be a member of the local IIS_WPG group.

Grundsätzlich gibt es zwei unterschiedliche Möglichkeiten um PHP für den IIS unter Windows zu installieren. Zum Einen kann man PHP manuell installieren, zum Anderen gibt es einen fertigen Installer. Da ich bisher PHP immer nur manuell installiert habe, und das ganze auch mit wenigen Handgriffen erledigt ist, werde ich auch nur diesen Weg beschreiben. Auch gibt es verschiedene Möglichkeiten PHP mit dem IIS zu “verbinden”, am einfachsten und am häufigsten ist die Verwendung des ISAPI-Filters.

Diese Anleitung beschreibt das Vorgehen für den IIS 5.x; für Windows 2003 bzw. den IIS 6 sieht das ganze ein wenig anders aus, da muss man den ISAPI-Filter noch explizit zur Auführung aktivieren.

1. Für die Installation muss zunächst die aktuelle PHP-Version von php.net als ZIP-Archiv herungeladen und in ein beliebiges Verzeichnis entpackt werden.
2. Über Systemsteuerung\Verwaltung die IIS-Verwaltungskonsole Internet-Informationsdienste starten. Nun gibt es grundsätzlich ein paar Alterantiven:
   1. PHP wird für den gesamten Server eingerichtet
   2. PHP wird nur für ein einzelnes Verzeichnis oder einen einzelnen virtuellen Server eingerichtet

   Grundsätzlich ist das Vorgehen identisch, ausser daß einmal die Eigenschaften des Servers und ansonsten die Eigenschaften eines Verzeichnisses oder eines virtuellen Servers geändert werden müssen.

3. In den Eigenschaften auf die Reiterkarte “Basisverzeichnis” wechseln und ggf. eine neue Anwendung konfigurieren. Bei virutellen Servern oder Verzeichnissen die Ausführungsberechtigung auf “nur Skritps” setzen.
4. Anschließend auf “Konfiguration” und auf “Hinzufügen” klicken. Als ausführbare Datei die php5isapi.dll auswählen, Dateierweiterung ist .php. Bei den Verben kann nun alle ausgewählt werden, wodurch alle HTTP-Methoden zugelassen werden (auch solche wie OPTIONS oder PROPFIND), oder das ganze auf GET, POST, HEAD einschränken. Abschließend noch sicherstellen, daß die Haken bei “Skriptmodul” und “Prüfen, ob Datei existiert” gesetzt sind.

Die Einrichtung ist nun schon fast vollständig abgeschlossen. Um die Konfiguration von PHP noch vornehmen zu können muss entweder die php.ini in das %WINDIR%\system32 kopiert werden, oder PHP muss per Umgebungsvariable PHPRC mitgeteilt werden in welchem Verzeichnis sich die php.ini befindet. Nach dem setzen der Umgebungsvariable muss der Rechner ggf. neu gestartet werden, bevor die Änderung übernommen werden kann, weil die Umgebungsvariablen von dem IIS nur während des bootens ausgelesen werden.

PHP Installation: Microsoft IIS / PWS (englisch) ]]> http://www.eiben.weite-welt.com/2007/05/install_php/feed/ 0 http://www.eiben.weite-welt.com/2005/07/compress_content/ http://www.eiben.weite-welt.com/2005/07/compress_content/#comments Mon, 25 Jul 2005 13:29:27 +0000 Henning Eiben http://blog.eiben.weite-welt.com/?p=216

Eine Möglichkeit besteht darin, den Datenverkehr, der von einem Webserver zum Browser gesendet wird zu komprimieren. Dazu wird in der Regel das gzip-Verfahren eingesetzt, welches im Hintergrund den gesamten Datenverkehr komprimiert. Somit können die Daten zwischen Server und Client schneller übertragen werden. Dieses Verfahren wird von den gängigsten Browsern und Servern unterstützt. Auch der IIS bietet die Möglichkeit sowohl statische als auch dynamisch erzeugte Web-Seite per gzip zu komprimieren.

Allerdings zeigt die Umsetzung dieser Technik auf Seiten des Clients (hier konkret des Internet Explorers) ein Problem auf. Gerade bei dynamischen Seiten, wie sie ja oftmals für Intranet-Inhalte typisch sind, will man oft nicht, daß die Seiten auf dem Client gecached werden, sondern die Seiten sollen bei jedem Zugriff immer wieder neu vom Server angefordert werden. Damit soll sichergestellt werden, daß die mobilen Anwender immer auf die aktuellen Daten und Informationen des Unternehmens zugreifen können. Um das Cachen von Seiten zu verhinden gibt es bestimmte “Attribute” die man einer HTML-Seite geben kann, damit sie vom Client nicht gecached wird. Leider werden diese Attribute vom Internet Explorer in zusammenhang mit gzip-komprimierten Seiten schlichtweg ignoriert. Das Ergebnis: die Seiten werden dennoch gecached.

Bei einfachen Inhalten, die sich sowieso nicht so häufig ändern stellt das noch kein Problem dar, allerdings bei Web-Anwendungen wird dies schon zu einem Problem. Hier wird oftmals immer nur eine einzige Seite, jeweils mit unterschiedlichen Parametern, aufgerufen, die dann die gesamte Darstellung und Verarbeitung übernimmt. Wird hier bei jedem Klick immer wieder die gleiche Seite angezeigt, weil der Browser die Seite, mit den nun “neuen” Parametern, nicht erneut vom Webserver anfordert sondern, wegen der permanent gleichen Adresse, die gecachte Seite anzeigt, so ist dieses Verhalten nicht akzeptabel.

Obwohl das gzip-Verfahren schon lange verwendet wird, gerade im Unix-Bereich schon seit Jahren etabliert ist, so scheitert der praktische Einsatz an den unzulänglichkeiten des Internet Explorers.

Informationen von Microsoft: Microsoft Knowledge Base Article – 321722 Content with “Content-Encoding: gzip” Is Always Cached Although You Use “Cache-Control: no-cache” ]]> http://www.eiben.weite-welt.com/2005/07/compress_content/feed/ 0