IIS TimeOut while debugging a SharePoint application

By Henning Eiben in IIS, SharePoint 2 Comments

Who has not encounterd this problem: you’re just doing some debugging on your favorite SharePoint application and all over sudden – bam! The application pool gets recycled.

iis_app_timeout

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.

iis_adv_setting

Restart of application pools revised (Windows 2008)

By Henning Eiben in IIS 0 Comment

Up to Windows 2008 there was a nifty little VB-Script called iisapp.vbs. This allowed to just restart the application pool without having to restart the whole IIS. For one this is much faster and also this doesn’t effect other application pool. Thus you can restart a single application.

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"

Restart of an application pool instead of IIS

By Henning Eiben in IIS 0 Comment

Once in a while you have to deploy assemblies for a SharePoint based solution (ok, you also might have other solutions which need Assemblies Smiley, 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>

Setting the identity for ASP.Net application pools

By Henning Eiben in Programming 0 Comment

I just run into an odd problem. For testing purpose I wanted to run a ASP.Net application with some privileged account. So just for the heck I created a new app-pool in IIS and assigned this pool to my app. Then I set the identity of the app pool to my own domain-account – this should definitely work, since I’m a local administrator on this dev-machine – who if not the admin should run an app?

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.

PHP Installation

By Henning Eiben in IIS 0 Comment

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)

Komprimierung von HTTP-Verkehr

By Henning Eiben in IIS 0 Comment

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”