Archiv der Kategorie: Windows

Google Startseite wird im IE11 erst beim zweiten Versuch geladen

Veröffentlicht am von — Keine Kommentare ↓

Problem

Wenn im Netzwerk ein Proxy-Server genutzt wird, wird Google erst „beim zweiten Versuch“ geladen. Das tritt besonders Produkte auf, die auf dem OpenSource Proxy Server Squid basieren. Der Fehler ist erst ab Internet Explorer 11, besonders unter Windows 8/8.1, zu beaobachten.

ie11-seite-kann-nicht-angezeigt-werdenWird die Seite neu geladen (F5), wird Google korrekt anzeigt.

Lösung

Die Ursache dieses Phänomens ist, das die meisten Proxy-Lösung die properitäre Google-Erweiterung von HTTP „SPDY“ nicht unterstützen. So auch Squid – die Entwickler wollen erst die fertige Version von HTTP2.0 implementieren, die SPDY in weiten Teilen ähnelt.

ie11-google-spdyIn den Internet Explorer 11 Einstellungen findet sich der entsprechende Parameter zu SPDY:

ie11-spdy-abschaltenWird der Haken bei “SPDY/3 verwenden” entfernt, funktioniert der Aufruf von Google sofort beim ersten Versuch – auch als Startseite.

Zuständig ist der Registry-Schlüssel

HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings

Dort gibt es einen DWORD-Wert namens “EnableSPDY3_0” der mit dem Wert “0” versehen erstellen SPDY abschaltet.

Die SPDY-Einstellung lässt sich natürlich auch via GPO (Preference) regeln:

Benutzerkonfiguration\Administrative Vorlagen\Windows-Komponenten\Internet Explorer\Internetsystemsteuerung\Seite „Erweitert“\Für Internet Explorer die Verwendung des SPDY/3-Netzwerkprotokolls zulassen

Mit dieser Richtlinieneinstellung wird festgelegt, ob von Internet Explorer (ab 11) das SPDY/3-Netzwerkprotokoll überhaupt verwendet wird.

vSphere Client auf DC installieren

Veröffentlicht am von — 4 Kommentare ↓

Problem

Der vmware vSphere Client ab Version 5.1u1 lässt sich nicht mehr freiwillig auf einem Domänencontroller installieren. Versucht man das, erhält man folgende Ferhlermeldung:

„vSphere Client erfordert Windows XP XP2 oder höher. vSphere Client kann auf dem Domänencontroller nicht installiert.“

vsphere-client-auf-dc-installieren

Lösung

Aufgrund der Microsoft-Vorgabe „Always Isolate DC Role“, der auch grundsätzliche zuzustimmen ist, hat vmWare den OS-Check in den MSI-Wrapper eingebaut. Selbstverständlich lässt sich das (auf eigene Gefahr) auch umgehen. Der Client läuft auch stressfrei auf einem DC.

  • Plattform-Installer (~100mb) aus dem Globalen Installert (~350MB) befreien. Dazu einfach das Paket ganz normal aufrufen un den „viclient-setup.exe“ aus %temp%\{langeinummer} wegkopieren. Danach den Installer nach der Fehlermeldung wieder schliessen.
  • Den Installer aufrufen mit: viclient-setup.exe /VSKIP_OS_CHECKS=“1″

Update: Ein vmware Engineer sagt zu diesem Installer folgendes (Zitat):

We did this deliberately to enforce a Microsoft standard that our guys agree with – don’t install software on a DC, but they made that decision in isolation. Nothing more than that.  So use the workaround safely and hopefully we can undo this in the future.

Scanner senden keine E-Mails über Windows IIS-SMTP-Relay (Logfile: „BDAT“)

Veröffentlicht am von — Keine Kommentare ↓

Problem

windows-iis-smtp-log-BDATEin Flur-Scanner (wir nennen diese Dinger intern gerne „Raumschiff“) versendet „auf einmal“ keine (größeren) Dokumente mehr per E-Mail. Kleine Dokumente funktionieren fehlerfrei – die Meldung am Display des Gerätes dazu lautet „Die Festplatte des Servers ist voll“. Es wird über ein Windows IIS-SMTP-Relay an Office365 gemailt. Der Fehler tritt bei Geräten von Develop (Beispiel ineo+ 220) auf, andere Geräte verschicken mit der Meldung „Message size too big“ überhaupt nichts. Der Server hat selbstverständlich ausreichend Platz.

Lösung

Der Scanner versendet keine größen eingescannten Dokumente mehr, weil die Nachrichtengröße überschritten ist und der Scanner zu dem erweiterten SMTP-Befehl BDAT wechselt. Das funktioniert so nicht richtig, weil die IIS-Metabase zwar die verwendung von BDAT zulässt, die Verbindung aber (ohne Fehlermeldung) beim erreichen der maximalen Nachrichtengröße beendet. Das sieht man sehr schnell und eindrucksvoll in den zugehörigen IIS SMTP LogFiles (\inetpub\LogFiles\SMTPSVC*). Anstell des DATA-Commands folgt da ein auf den ersten blick verwirrender Stapel Binärdaten. Dieser Stapel bricht irgendwann kommentarlos ab.

Zwei Möglichkeiten zur Fehlerbehebung:

  1. Maximal Nachrichtengröße erhöhen (IIS 6.0 Manager > SMTP Virtual Server > Eigenschaften > Nachrichten > „Nachrichtengröße beschränken“ anpassen
  2. In der IIS6 Metabase den SmtpInboundCommandSupportOptions Integer anpassen (/LM/SmtpSvc/<id>/) um das BDAT-Verb zu verbieten.

iis6-smtp-metabase-explorer

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

Veröffentlicht am von — 9 Kommentare ↓

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.