Google Startseite wird im IE11 erst beim zweiten Versuch geladen

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.

Windows 7 herunterladen

Da Microsoft die Download-URLs gerne ein bisschen versteckt, haben wir die Windows 7 ISO-Downloads hier zusammengefasst. Diese Downloads enthalten natürlich keine Lizenz. Die Nutzungslizenz (meistens ein MKA- oder Product-Key) muss nach der Installation oder spätestens nach 30 Tagen eingegeben werden.

Diese Installations-ISOs funktionieren auch mit OEM-Product-Keys.

Exchange 2003 entfernen – Fehler 0xC0070035

Problem

Ein alter Exchange 2003 Server soll sauber deinstalliert werden. Das geschieht natürlich am besten über die Deinstallationsroutine, diese bricht aber ab.

Das Exchange-Setup legt ein Log über seine Tätigkeiten ab: C:\Exchange Server Setup Progress.log
 Fehlermeldung während Deinstallation
 HrPromptForCDIfNecessary: encountered error 0XC0070035
 HrPromptForCDIfNecessary: encountered error 0XC0070035, sleeping for 20 seconds before trying again
 [20:35:35] ScFindFileInDirTree (f:\titanium\admin\src\libs\base\basemisc.cxx:2068)
 Error code 0XC0070035 (53): Der Netzwerkpfad wurde nicht gefunden.

Lösung

Das Setup aus <buchstabe>:\SETUP\I386\setup.exe von der Orginal-Installations CD aufrufen. Dann ganz normal deinstallieren, das Setup läuft dann ohne diesen Fehler durch. Achtug, die CD muss zur installierten Version passen: Es gibt einen Standard-Datenträger, eine Enterprise-Version und eine SBS-Edition. Jeweils diese nocheinmal als Retail/OEM und als Volumenlizenz. Die VL-Datenträger funktionieren (sofern die Edition passt) eigentlich immer.

In ganz wiederspenstigen Fällen hilft aber immer das manuelle entfernen von Exchange.

IP-Adressen von allen HP ProCurve Switchen im Netzwerk finden

Es gibt diverse Tricks um die IP-Adressen von Switchen im LAN zu finden. Einige Tools pingen sich fröhlich durch das LAN und filtern MAC-Adressen, andere machen einen LLDP-Scan, wieder andere connecten auf den HTTP(S) Port und schauen nach ob da der embedded „eHTTP v2.0“ antwortet (der in den meisten ProCurve Produkten zu finden ist) und dergleichen mehr. Das funktioniert auch ganz gut, wenn das Netz (noch) nicht in VLANs oder verschiedene logische Netze segmentiert ist.

Ein Kollege zeigte mir soeben diesen Trick, den ich noch nicht kannte: den Switch einfach nach seinen bekannten Nachbarn fragen. Da hätte ich auch selber drauf kommen können 🙂

So bekommt man immer die Management-IP und die zugehörigen Netzdaten – auch ohne config-context:

show cdp neighbors detail

Da ist auch gleich der Uplink-Port dabei, sehr praktisch. Jaja, PCM+ kann das auch, aber wir sind hier bei ugg.li und nicht bei kauf-dir-was.

ProCurve Switches im LAN finden

Office365 „winmal.dat“ (TNEF) versand abschalten

Problem

Einige Empfänger berichten, das Sie anstelle des gewünschten anhanges eine Datei namens „winmail.dat“ erhalten. Das betrifft vor allem ältere E-Mail-Programme, Apple-Mail und Systeme hinter älteren Firewalls/Mailfiltern.

Lösung

Man kann dem ausgehenden Connector des Office365 Exchange Online Dienstes das versenden des Microsoft TNEF-Formates vollständig abgewöhnen. Man stellt eine Verbindung zur Office365 Powershell her und konfiguriert die Einstellung mit dem Commandlet Set-RemoteDomain.

$Cred = Get-Credential
$shell = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell -Credential $cred -Authentication Basic –AllowRedirection
Import-PSSession $shell
Set-RemoteDomain Default -TNEFEnabled $false

Mit „Get-RemoteDomain |fl“ lassen sich die aktuellen Einstellungen für den Connector überprüfen. Die folgenden Einstellungen sind für den Parameter TNEFEnabled verfügbar:

  • $true: TNEF wird für alle Nachrichten verwendet
  • $false TNEF wird nie für Nachrichten verwendet
  • $null der Absender gibt die Einstellung vor (Standardeinstellung). Funktioniert TOTAL großartig, denn jeder Mensch weiss ja wie man in Outlook-Kontakten das TNEF-Format konfiguriert. </ironic mode=“off“>

Gezielt lässt sich die Einstellung für bestimmt Domains so setzen:

Set-RemoteDomain foo.bar -TNEFEnabled $false