PHP (5.x) auf Windows Server 2012/2012R2 installieren

iis-mit-fastcgi-installierenInstall-Guides dieser Art gibt es zwar bereits einige, aber irgendwie fehlte am Ende doch irgendwas. Meistens ist das dann auch noch der unauffälligste Punkt, wo der Admin dann am Ende eine ewiglange Fehlersuche (mit Stirn->Kopf Effekt) betreiben muss. Hier also der totale ugg.li „comprehensive“ Best-Practice-Guide um ein heute aktuelles PHP 5.x auf Windows Server 2012R2 korrekt und sicher zu installieren.

Der guide geht von einem „nackigen“ System und einer „Standard“-Awendung als Ziel aus, die keine absonderlichen Config-Eigenheiten benötigt.

  1. IIS-Rolle mit FastCGI, HTTP-Redirect und Authentifizierung installieren
    1. Server-Manager öffnen, Rollen hinzufügen
    2. „Webserver (IIS)“ anhaken, darunter (mindestens) hinzufügen: HTTP-Fehler, Standarddokument, Statischer Inhalt, HTTP-Umleitung, Standardauthentifizierung, HTTP-Protokollierung, CGI, ISAPI-Erweiterungen
    3. Das .NET Framework 3.5 FEature hinzufügen (wird nicht von PHP selbst gebraucht, aber von einigen Modulen Extensions)
  2. Visual C++ Redistributable für Visual Studio 2012 Update 4 (oder höher) installieren (Voraussetzung für php*.exe). Je nach PHP (32bit oder 64bit) muss es auch die passende Version (32bit oder 64bit) sein.Achtung: Auch das x64 PHP hat einige Module Extensions dabie, die noch in x86 (32bit) kompiliert sind.
  3. PHP installieren
    1. Aktuelle PHP-Version herunterladen, die Non-Thread-Safe-Version, passend zur Plattform (x64). Die Thread-Sicherheit macht der IIS mit seinen Memorypools selber, an dieser Stelle wäre die Thread-Safe-Edition verschenkte Performace.
    2. In den Zielordner auspacken („c:\program files\php“ oder ähnliches). INSTALLER STINKEN.
    3. php.ini-production umbenennen in php.ini und wenn notwendig bearbeiten. Bewährt haben sich an dieser Stelle genauere Gedanken über „max_execution_time“, „max_input_time“, „memory_limit“, „open_basedir“, Temp-Pfade und so weiter.
  4. iis-php-handlerzuordnungPHP im IIS als Handler für *.php anlegen
    1. Systemsteuerung -> System -> Erweiterte Systemeinstellungen -> Erweitert -> Umgebungsvariablen (ganz unten) -> Systemvarianbel „Path“ bearbeiten und „c:\php“ (Den Pfad zu PHP) hinzufügen. Das präventiert einige schwer zu findende Fehler mit nicht-gefundenen-externals.
    2. IIS Manager öffnen -> links in der Baumstruktur auf den Computernamen klicken und dann Rechts das Feature „Handlerzuordnungen“ öffnen
    3. Rechte MT -> „Modulzuordnung hinzufügen“
    4. Anforderungspfad: *.php
    5. Modul: FastCgiModule
    6. Ausführbare Datei: C:\Program Files\PHP\php-cgi.exe (Pfad zur php-cgi.exe)
    7. Name: FastCGI-PHP (oder etwas ähnlich aussagekräftiges)

Testen mit einer phpinfo(); und fertig. Jetzt spricht ersteinmal jede IIS-site PHP(5).

Für MySQL sind in der PHP.ini nur noch die extensions einzukommentieren und der extension_path zu setzen. Achtung, das sind (stand heute) 32bit Extensions.

Server-Error 500: PHP erzeugt einen Fehler 500 beim ausführen? C++ Redist prüfen und php.exe direkt an der Kommandozeile (als Administrator) aufrufen. Wenn der Intepreter ein Problem hat, sagt er es dann dort. Wenn es eine PHP-Kommandozeile gibt (zu erkennen an … nichts), läuft der Interpreter. Rechte checken und Eventlog lesen. Mit „quit“ die interactive PHP command line wieder verlassen.

Office 2010/2013 oder Office365 „Product unlicensed“

Problem

office-product-unlicensedOffice 2010/2013 startet mit dem Hinweis „Produkt unlizensiert“ in der Titelleiste, oder je nach Version oder Edition auch „Produkt nicht lizensiert“ oder „Nicht lizenzierte Produkte“. Den Produkt-Key aktualisieren schlägt für den Administrator fehl, weil unter Datei/Hilfe der Button „Productkey eingeben“ fehlt. Der Fehler kann unter Office Professional Plus 2010 und 2013 auftreten.

Lösung

In den meisten Fällen ist eine doppel- oder mehrfachinstallation von verschiedenen Editionen oder Lizenzformen auf einem Compter schuld.

Wichtig: Alle Office-Anwendungen schliessen und die Systemuhr prüfen/korrigieren.

Die Lizenzierungssituation lässt sich an der Kommandozeile im (passenden Office-Verzeichnis) sehr genau prüfen:

cscript "%ProgramFiles%\Microsoft Office\Office14\ospp.vbs" /dstatusall

In den meisten Fällen wirft Office eine Meldung aus, die dieser hier ähnelt:

---------------------------------------
SKU ID: ****
LICENSE NAME: Office 15, OfficeProPlusVL_MAK edition
LICENSE DESCRIPTION: Office 15, RETAIL(MAK) channel
LICENSE STATUS:  ---UNLICENSED---
Last 5 characters of installed product key: *
ERROR CODE: 0xC004F014
ERROR DESCRIPTION: The Software Licensing Service reported that the product key
is not available.
---------------------------------------

Dern passenden (!) Schlüssel aktualisiert man dann einfach mit:

cscript "%ProgramFiles%\Microsoft Office\Office14\ospp.vbs" /inpkey:DERRI-CHTIGE-KEYMIT-STRICHEN

Und schliesslich kann das Office (Internetverbindung vorausgesetzt) dann auch gleich aktiviert werden:

cscript "%ProgramFiles%\Microsoft Office\Office14\ospp.vbs" /act

Windows 8/8.1, Server 2012/2012R2 UAC richtig ausschalten

Problem

Unter Windows 8/8.1 und den zugehörigen Serversystemen kann man die UAC (User Account Control) in der Systemsteuerung unter „Benutzerkontensteuerung“ zwar ausschalten, aber so richtig aus ist die Kontrollinstanz nicht. Immer wieder muss der Admin Dinge nocheinmal zusätzlich „als Administrator“ ausführen:

windows8-uac-endgueltig-ausschaltenLösung

Um ganz genau zu sein, beschwert sich hier nicht die UAC, sondern die LUA („Least Privilege User Access“). Das ist ein Überbleibsel aus der Vista-Zeit. Natürlich lässt sich die LUA ebenfalls ausschalten – dank Microsoft’s übermächtiger Weisheit aber nicht via GUI, sondern via Registry:

REGEDIT4

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System]
"EnableLUA"=dword:00000000

oder direkt via Kommandozeile:

%windir%\System32\reg.exe ADD HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v EnableLUA /t REG_DWORD /d 0 /f

Windows (Server) Update schlägt fehl: Fehler 8024402C

Problem

windows-update-8024402cWindows sucht keine Updates und bricht den Vorgang mit dem Fehler „8024402C“ ab. Die Hilfe zeigt nur einen eher weniger hilfreichen Artikel. die Datei WindowsUpdate.log in %windir% zeigt einen Reporting-Fehler „80070057“. Google hat gaaaanz viele Antworten, aber keine Lösung.

Lösung

Die Maschine hat keinen Zugang zu seinem WSUS, zu Microsoft Update oder zu einem eventuellen Proxy dazwischen. Dieser Fehler ist nicht eindeutig, aber der findige Administrator hat die Verbindungs- und Funktionswege zwischen dem zu aktualisierenden System und einer Updatequelle ja sicher schon umfassend geprüft – daher muss es das System sein. Ist es auch.

In meinem aktuellen Fall zeigt das WindowsUpdate.log beim starten des „Windows Update“ Dienstes folgende interessanten Zeilen:

Service    *************
Service    ** START **  Service: Service startup
Service    *********
Agent      * WU client version 7.6.7600.256
Agent      * Base directory: C:\Windows\SoftwareDistribution
Agent      * Access type: Proxy
Agent      * Proxy-Adress: gibtsnicht.foo.bar:8080

Windows-Update nutzt den System-Proxy um sich zum Update-Server zu verbinden. die Einstellungen im Internet-Explorer bleiben ohne wirkung. Wie auch immer dieser Proxy dort hingekommen ist, er muss weg. Das geht via Netsh:

netsh winhttp reset proxy

Und nach einem Neustart des Dienstes „Windows Update“ tut es auch das Update-Suchen wieder.

Eine geschützte Partition kann nicht ohne festgelegten Force Protected-Parameter gelöscht werden.

diskparty-recovery-01
diskparty-recovery-02

Wiederherstellungspartitionen entfernen ist ein bisschen umständlicher als (unserer Meinung nach) notwendig. In der Datenträgerverwaltung geht das gar nicht, weil die benötigten Aktionen gar nichts erst angezeigt werden:
Und Diskpart (intern „Diskparty“ genannt) mängelt sehr direkt einen fehlenden Kontakt zu Midi-Chlorianer an:

Fehler beim Dienst für virtuelle Datenträger:
Eine geschützte Partition kann nicht ohne festgelegten Force Protected-Parameter gelöscht werden.

Das Geheimnis ist nun, die MACHT gar nicht erst zu bemühen, sondern die Meldung einfach zu überschreiben. Der Parameter ist in der Hilfe nicht auf allen Windows7-Installationen enthalten, in den meisten aber offenbar (Danke Henrik) schon . So gehts:

DISKPART> delete partition override

… und schon ist auch die hartnäckige Recovery-Partition nicht mehr da.