Outlook Anywhere (RPC/HTTP) über einen anderen (nicht-Standart) Port verwenden

Veröffentlicht am von — 2 Kommentare ↓

Aus verschiedenen Gründen – die allermeisten davon esoterisch – kommt es vor, das Administratoren oder Systembetreuer Ihr OWA nicht über den Standard-Port (SSL TCP/443) erreichbar machen, sondern über einen Geheimport (444, 4430 oder ähnlich seltsames). RPC-over-http ist eines der (glücklicherweise wenigen) Protokolle die von Natur aus nicht mit verbogenen Zielports leben können (http://www.ietf.org/rfc/rfc2818.txt). Trotzdem bleibt der RPC auf den meisten Sites, vor allem SBS-Servern, seit Exchange 2007 eingeschaltet, so dass man über einen vermeintlich simplen OWA-Zugang auch ganz passabel mit Outlook arbeiten kann. Wenn man seinem Profil diese Eigenart denn nun beibringt.

Weil „unsupported“ ist die Einrichtung leider etwas hakelig. Aber so geht’s:

  1. Zuerst ganz normal das MAPI-Profil einrichten (oder hinzufügen, je nachdem wie man möchte). Das geht über Systemsteuerung -> E-Mail -> E-Mail Konten

     

     

     

  2. Den Exchange-Server mit seinem INTERNEN Namen (z.B. foobar.local) hinzufügen. NICHT auf „Namen prüfen“ Klicken, das hätte eine lange Wartepause und ängstliche Fehlermeldungen zur Folge.

     

     

  3. Den RPC-over-http-Proxy einstellen. Wichtig: hier nicht den Port eingeben (das akzeptiert Outlook nicht), sondern diesen mit einem Minus an die Adresse anhängen. Die Haken setzen und auf „Standardauthentifizierung“ umstellen. NTLM stinkt ganz furchtbar, besonders über einen http/RPC.

 

 

  1. Ok – Ok – Ok – Schliessen – Schliessen – ok (Reihenfolge und Anzahl mag abweichen :-). Achtung, es kann zu ewig langen Wartezeiten kommen, weil die Verbindung ja tatsächlich (noch) nicht hergestellt werden kann. Das Timeout sind 30 Sekunden (mal drei). Den Fehler auch ignorieren und das Profil trotzdem erstellen.
  2. Jetzt kommt der interessante Teil 🙂
    1. Regedit aufmachen und zu diesem Schlüssel surfen: HKCUSoftwareMicrosoftWindows NTCurrentVersionWindows Messaging SubsystemProfiles
    2. Suche nach dem Servernamen-String mit dem Minus. Bei einem einzigen Profil ist das in der Regel der Schlüssel „13dbb0c8aa05101a9bb000aa002fc45a“.
    3. Finde die Zeichenfolge „001f6622“ (Das ist der MAPI-RPC-Servername) vom Typ Reg_Binary. Bearbeite diese mit einem Doppelklick.
    4. Ersetze das Minus (hex: 2D) durch einen Doppelpunkt (hex: 3A) und Bestätige mit OK
  3. Das wars schon – alles fertig. Beim nächsten Start richtet Outlook das Konto fertig ein.

Tipp: In den MAPI-Einstellungen ab jetzt NICHTS MEHR am RPC-Proxy ändern. Outlook wird das Schließen des Dialoges nicht mehr zulassen; aber sehen kann man die den Doppelpunkt durchaus schon.

WDS/RIS „Dies ist kein gültiges installations- Abbild“

Veröffentlicht am von — Keine Kommentare ↓

Beim Hinzufügen eines WIM-Installationsabbildes (kein Startabbild) zum WDS über die WDS-Konsole erscheint die Fehlermeldung Dies ist kein gültiges installations- Abbild.“. Stimmt auch fast – nur die Meldung ist gelinde gesagt „irreführend“. Das passiert schon mal, wenn das Abbild direkt aus einer laufenden Maschine heraus nach einem Sysprep mit imagex erstellt wird.

Die Lösung ist, dass die Integration der unattend.xml an dieser Stelle obligatorisch ist. Ohne Antwortdatei hält die WDS-Konsole das Abbild nur für ein Startabbild, nicht für ein Installationsabbild. Natürlich ist dieser Fall auch nicht dokumentiert. Dem Sysprep muss zwingend eine unattend-Datei mitgegeben werden und schon läuft das Image.

  • Es gibt noch einen zweiten Fall in dem das passiert: Wenn das WIM-Image nicht von der Windows-Installation stammt sondern nur von der Bootpartition des Systems. Vorher mit diskpart und „list volumes“ kurz prüfen … und sich im Fehlerfall wundern das imagex in 2 Sekunden ein Windows 7 Installationabbild erstellt haben will.

jqPlot funktioniert im Internet Explorer 9 nicht, wenn dieser automatisch den Renderingmodus falsch wählt

Veröffentlicht am von — Keine Kommentare ↓

Aus welchem wie auch immer gelagerten magischen Grund der Internet Explorer beim Aufruf eines Dokuments automatisch den Renderingmodus wählt, es ist im Falle von jqPlot desöfteren der falsche.

jqPlot bringt mit der excanvas.js zwar alles Nötige mit, damit auch in alten Internet Explorer Versionen alles so funktioniert wie es soll. Dafür gibt es die folgende Zeile in allen jqPlot-Seiten.

<!–[if lt IE 9]><script language=“javascript“ type=“text/javascript“ src=“excanvas.min.js“></script><![endif]–>

Der Internet Explorer 9 wählt nun manchmal für eine Seite die jqPlot enthält (100% gleiches Dokument, gleiche Sicherheitszone, jedoch unterschiedliche second-level-Domain) den Renderer für IE7 („Dokumentmodus: Internet Explorer 7 Standard“). Wenn das passiert bekommt man folgende Meldung im Debugger und der Plotbereich bleibt weiß.

SCRIPT438: Das Objekt unterstützt die Eigenschaft oder Methode „getTime“ nicht
jquery.jqplot.min.js, Zeile 57 Zeichen 143467

Um dies zu umschiffen muss die Seite dem Internet Explorer 9 mitgeben, dass sie zwingend mit dem Dokumentmodus für den Internet Explorer 9 gerendert werden soll. Um keine Abwärtskompatibilitäten zu zerstören, etwas umständlicher mit Conditional Comment:

<!–[if IE 9]><meta http-equiv=“X-UA-Compatible“ content=“IE=EmulateIE9″ /><![endif]–>

Windows Server 2008r2 DHCP Bug(s)

Veröffentlicht am von — Keine Kommentare ↓

Bei zwei DHCP-Servern unter Windows Server 2008 R2 bei zwei Bereichskonfigurationen (die typische 70/30 Verteilung z.B.) und identische Reservierungen werden Reservierungen gerne mal spontan (und natürlich sporadisch) gelöscht. Alternativ geht das auch mit einem Server, wenn ein DHCP-Client die abgerufenen IP-Adresse mehrere Male freigibt (bzw. schnelle Hardware unter windows CE oft rebootet). Dazu gibt es dann die kreativssten Fehlermeldungen in der Verwaltungskonsole wie „Die Adresse ist nicht verfügbar“ oder „Die IP- oder Hardwareadresse kann nicht verwendet werden“ und allerliebst auch „Es ist ein interner Fehler.“ (Ja, nichts weiter. äußerst Hilfreich).

Zum Glück gibt es einen (natürlich nicht öffentlichen) Hotfix: http://support.microsoft.com/kb/981776/en-us

*seufz*

jqplot funktioniert nicht im Internet Explorer, wenn nicht der richtige Doctype gesetzt ist

Veröffentlicht am von — Keine Kommentare ↓

Bei jqPlot handelt es sich um ein jQuery-Plugin mit dem man bequem Graphen und Charts zeichnen kann. Es ist wie jQuery browserunabhängig, sagt zumindest die Dokumentation. Leider ist das nicht die ganze Wahrheit.

Fehlt im HTML-Code der Seite, in der geplottet werden soll nämlich die explizite Angabe des Doctype, so funktioniert es im Internet Explorer nicht und der Zeichenbereich bleibt weiß. Das ergibt dann je nach Versionsständen von jQuery und jqPlot verschiedenste Fehlermeldungen. Hier mal ein kurzer Auszug aus dem internen Debugger des Internet Explorer:

jQuery 1.6.1 mit jqPlot 1.0.0b2_r792

SCRIPT5007: Für die Eigenschaft „initElement“ kann kein Wert abgerufen werden: Das Objekt ist Null oder undefiniert
jquery.jqplot.min.js, Zeile 30 Zeichen 2036

jQuery 1.7.2 mit jqPlot 1.0.0b2_r1012

SCRIPT5007: Für die Eigenschaft „initElement“ kann kein Wert abgerufen werden: Das Objekt ist Null oder undefiniert
jquery.jqplot.min.js, Zeile 57 Zeichen 2123

Fügt man nun einfach als erste Zeile in den HTML-Code den Doctype

<!DOCTYPE html>

ein, so funktioniert es mit einem Mal auch im Internet Explorer.