Archiv für die Kategorie ‘Exchange 2010

OWA – Verkürzung der URL auf anderem Weg   1 comment

Die OWA-URL lautet hintern immer auf „owa“ und die Nutzung von HTTP ist Pflicht.

Eine korrekte URL sieht also so aus: https://owa.domain.dom/owa. Das überfordert manche Anwender deutlich. 🙂

Schön wäre es, wenn der Benutzer einfach nur „owa.domain.dom“ eingibt und automatisch auf der korrekten Seite landet.

Im Technet (z.B. hier) findet man Anleitungen, wie man das erreichen kann. Leider haben diese Anleitung den Nachteil, das relativ tief in die Konfig des IIS eingegriffen wird. Da es eine automatische Vererbung in den IIS-Seiten gibt, risikiert man außerdem, Schleifen zu produzieren.

Ich setze bei meinen Kunden eine andere Lösung ein, die deutlich weniger Eingriffe erfordert und die damit auch weniger Fehler hat.

Hierbei muss man zwei Dinge beachten:

– Aufruf ohne SSL
– Aufruf nur mit Servernamen, ohne „owa“ hintendran

Gehe wir zuerst das zweite Problem an, denn das ist ziemlich einfach:

In der Standardinstallation finden wir unter „C:\inetpub\wwwroot“ die „Homepage“ des IIS, die iisstart.htm.

Diese Datei tauschen wir aus, gegen eine mit folgendem Inhalt:

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta http-equiv="refresh" content="0;URL=https://owa.domain.dom/owa/">
<title>OWA</title>
</head>
<body>
<p><a href="https://owa.domain.dom/owa/">Bitte warten, es erfolgt gleich eine Weiterleitung zum OWA.</a></p>
</body>
</html>

Damit haben wir erreicht, dass jemand, der kein „owa“ am Ende der URL eingibt, durch seinen Browser dorthin weitergeleitet wird.

Noch nicht behandelt haben wir Leute, die das „s“ in HTTPS vergessen, die also ohne SSL kommen.

Hierzu ändern wir einfach die Fehlerseite ab. Der Code für „SSL ist erforderlich“ lautet 403.

Diese Änderung können wir gefahrlos so machen, wie es der Technet-Artikel von Microsoft vorschlägt, denn hier stört auch die Vererbung nicht, denn alle Seiten darunter werden durch die entsprechenden Client-Programme schon fehlerfrei aufgerufen (und wenn ein Benutzer wirklich die URL für EAS ohne SSL per Hand aufruft, soll er ruhig in OWA landen).

Um das ganze einheitlich zu machen, hier eine web.config, die diese Änderung macht und die man direkt unter „C:\inetpub\wwwroot“ speichert (sollte dort schon eine liegen, wurden bereits Anpassungen vorgenommen und die Änderungen müssen über den IIS-Manager gemacht werden):

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <httpErrors>
            <remove statusCode="403" subStatusCode="-1" />
            <error statusCode="403" prefixLanguageFilePath="" path="https://owa.domain.dom/owa/" responseMode="Redirect" />
        </httpErrors>
    </system.webServer>
</configuration>

Manuell sieht die Änderung so aus:

Es gibt aber eine kleine Einschränkung: Das geht nur, wenn die URL, die dort verwendet wird, von innen und außen erreicht werden kann (wenn OWA auch von innen benutzt werden soll).

Advertisements

Veröffentlicht 8. Juli 2011 von Robert Wille in Exchange 2007, Exchange 2010

Auswahl „öffentlicher / private“ Computer verstecken in Exchange 2010 SP1   1 comment

Mit dem Servicepack 1 für den Exchange Server 2010 hat Microsoft mal wieder den Aufbau für den OWA-Login geändert. Die bereits bekannte Anleitung (hier) funktioniert nicht mehr, also habe ich meinem MVP-Kollegen Walter versprochen, eine neue zu bauen.

ACHTUNG: Sie ändern hierbei eine Datei im OWA des Exchange-Servers. Auch wenn diese Änderung grundsätzlich für den Betrieb ungefährlich ist, dürfen Sie nur die Stellen ändern, die ich hier zeige. Alle Änderungen geschehen auf eigene Gefahr – machen Sie unbedingt vor der Änderung eine Sicherungskopie. Außerdem beachten Sie bitte, dass Updates und Servicepacks die Datei wieder auf das Original zurücksetzen!

Aufgabe: Die Auswahlknöpfe (sog. Checkboxen) aus dem Login für den OWA entfernen und eine Auswahl vorab treffen.

Suchen Sie auf dem betreffenen CAS-Server im Dateisystem die Datei C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\Owa\auth\logon.aspx und machen Sie hiervon eine Sicherungskopie (an eine andere Stelle als diesen Ordner, da der Ordner bei einem Update eventuell komplett gelöscht und neu angelegt wird). Öffnen Sie nun die Datei in einem Editor (Notepad reicht).

Wir suchen die folgende Stelle in der Datei:

Wichtig sind drei Abschnitte:

  • das beginnende <TR>
  • der INPUT-Tag mit der ID „rdoPblc“ (= dies ist der Knopf „öffentlich“)
  • der INPUT-Tag mit der ID „rdoBrvt“ (= dies ist der Knopf „privat“)

Im Screenshot sehen Sie im INPUT-Tag für den „öffentlich“ Knopf am Ender der Zeile (vor dem <TD>) das Wort „checked“. Dieses Wort markiert, dass der Knopf ausgewählt ist.

Wenn Sie möchten, dass die Vorauswahl auf „öffentlich“ steht, müssen Sie nichts ändern. Dann sieht das so aus:

Wenn Sie möchten, dass die Vorauswahl auf „privat“ steht, müssen Sie das Wort „checked“ aus dem öffentlich-Knopf entfernen und dem privat-Knopf hinzufügen:

Achtung! Nur einer der beiden Knöpfe darf „checked“ sein! Wenn das Wort bei beiden steht, wird immer der öffentliche verwendet!

Microsoft hat eingebaut, dass beim Anklicken eines Knopfes ein kleines Script ausgeführt wird.

Scrollen Sie bis ans Ende der Datei und fügen Sie dort ein:

Nun können Sie die Änderungen bereits testen. Ohne Anklicken des Knopfes, sollte OWA im richtigen Modus gestartet werden. Wenn Sie lediglich eine andere Vorauswahl treffen wollten, ohne die Knöpfe zu verstecken, ist die Arbeit erledigt. Die Auswahl funktioniert wie vorher.

Wenn die Knöpfe versteckt werden sollen, geht das, in dem man einfach die betreffende Reihe ausblendet.

Ändern Sie hierzu einfach den Tag <TR> ab (siehe mein zweites Bild, der Pfeil der nach oben zeigt):

Fertig!

Veröffentlicht 7. Dezember 2010 von Robert Wille in Exchange, Exchange 2010

Zertifikat erstellen in Exchange 2010   2 comments

In Exchange 2010 hat uns Microsoft einen komfortablen Assistenten spendiert, mit dem Zertifikate z.b. für OWA einfach erstellt werden können.

Meine Aufgabe sah wie folgt aus:

  • ein neues Zertifikat für OWA, RPC und Autodiscover erstellen,
  • Signatur von der internen PKI reicht,
  • da Outlook 2010 getestet wird und dies mit mehrere Exchange Profilen ausgestattet ist, muss Autodiscover für alle diese Mail-Domänen funktionieren. Bei mir waren es Adressen mit unterschiedlichen Mail-Domänen, 2x .de und 1x. info.

Hier das alte Zertifikat. Wie man sehen kann, ausgestellt auf zwei Domänennamen, davon aber nur einmal für Autodiscover. Für die Kommunikation über Exchange Active Sync wird in diesem Fall die Subdomäne RPC verwendet.

01

Los geht’s mit der Exchange Management Console von 2010:

02

Es geht den Assistenten durch:

03

04

In den nachfolgenden Schritten habe ich mich durch die einzelnen Abschnitte durchgeklickt. Gezeigt wird hier nur, was ich auch ausgefüllt habe.

OWA soll intern und extern erreichbar sein. Die externe URL wird durch den Router auf den CAS geleitet:

05

EAS wird benutzt und verwendet hierzu eine eigene URL (auch wenn technisch zumindest zur Zeit noch alle URL auf die gleiche IP-Adresse enden):

06

Auch Outlook Anywhere wird verwendet. Hierbei will ich dann das Problem lösen, dass Outook 2010 zwar endlich mehrere Profile bittet, diese aber alle einzeln abruft. Outlook baut dazu getrennte Verbindungen zu den einzelnen URLs auf. DNS- und IP-technisch war das kein Problem bisher, aber da das alte Zertifikat die zwei zusätzlichen Domänennamen nicht beinhaltet, gab es bei jedem Outlook-Start über Outlook Anywhere zwei Zertifikatswarnungen.

07

Die einzelnen Abschnitte erleichtern die Eingabe der verschiedenen Domänennamen. Aber technisch sind die Abschnitte eigentlich nicht wichtig. Wichtig ist, was in der nachfolgenden Maske für Domänennamen aufgelistet werden. Hier können dann bei Bedarf auch noch weitere hinzugefügt oder falsche gelöscht oder geändert werden.

Meine Liste sieht so aus und umfasst die folgenden Namen:

  • 3x autodiscover mit unterschiedlichen Domänen, für die drei Outlook Profile
  • 1x home für OWA
  • 1x rpc für die schlussendliche EAS-Kommunikation (auch wenn drei verschiedene Autodiscover “Anrufe” gesehen, so enden alle drei Autodiscover Vorgänge immer in der gleichen RPC-URL.
  • 1x interne URL, damit auch die internen Clients beruhigt sind

08

Nun den Assistenten beenden:

09

10

11

Die Zertifkatsanforderung wurde unter dem Dateinamen “c:\certreq2.req” gespeichert. In der Console taucht nun ein neues Zertifikat auf, dass aber noch nicht benutzt wird.

12

Nun reichen wir die Anforderung an unsere interne CA ein. Es handelt sich hierbei um eine Windows PKI unter Windows 2008, die auf einem anderen Server läuft. Ich benutze die Dom-Admin Anmeldung, da hier im Standard für diese Konto Autoenrolltment aktiviert ist.

Außerdem unbedingt darauf achten, dass die Webseite in den vertrauswürdigen oder intranet Sites enthalten ist, da sonst ActiveX nicht geht!

13

14

15

16

Inhalt der REQ-Datei kopieren und in der Web-Anforderung einfügen:

17

18

19

Danach wird das Zertifikat in einer Datei gespeichert, in meinem Fall unter dem Namen c:\certnew2.cer.

Das müssen wir nun importieren:

20

21

22

Danach muss es aktiviert werden. Ich will es nur für die Webdienste benutzen:

24

25

26

27

28

29

Fertig: Das neue Zertifikat wird vom Webserver ausgeliefert.

30

Mein IPhone hat das geänderte Zertifikat natürlich bemerkt und nach einer Rückfrage dann akzeptiert.

In Outlook intern gab es keine Probleme, auch Outlook extern hat keine Fehlermeldungen mehr angezeigt.

Da es sich um ein intern signiertes Zertifikat handelt, wird es natürlich extern nicht als fehlerfrei akzeptiert, da die signierende CA nicht vertrauenswürdig ist. Hierzu muss entweder das Zertifikat von einer externen Stelle gekauft werden oder das Zertifikat der CA allen Clients bekannt gemacht werden. Intern ginge dies z.B. über eine Gruppenrichtlinie.

 

Veröffentlicht 10. März 2010 von Robert Wille in Exchange, Exchange 2010

E-Mail-Adressrichtlinien lassen sich nach Migration von Exchange 2000/2003 nicht auf 2007 umstellen   1 comment

Bei einer Umstellung von einer Exchange 2003-Umgebung auf 2007 kam mir neulich in bis dahin neues Problem unter:

Nach Abschluss der Migration wollte ich die "Defaul Policy"-Empfängerrichtlinie umstellen auf 2007. Dies muss geschehen, da sich sonst die gleichnamige E-Mailadressrichtlinie (das ist der Nachfolger der Empfängerrichtlinien) nicht bearbeiten lässt.

Normalerweise ist das schnell getan:

Exchange Verwaltungs-Shell starten und den folgenden Befehl eingeben:

Set-EmailAddressPolicy "Default Policy" -IncludedRecipients AllRecipients

Nur in diesem Fall weigert sich das Cmdlet und gab folgenden Fehler aus:

Set-EmailAddressPolicy : Die Empfängerrichtlinie ‚Default Policy‘ mit Postfach-Manager-Einstellungen kann nicht über die aktuelle Version der Exchange-Verwaltungskonsole verwaltet werden

Zuerst war die Verwirrung groß. Sie legte sich aber bei genauem Lesen der Fehlermeldung. Es steht ja eigentlich da: die Empfängerrichtlinie hat Postfach-Manager-Einstellungen.

Der Postfach-Manager ist eine in Deutschland selten genutzte Funktion. Inhalte aus Postfächern lassen sich damit automatisch bearbeiten, z.B. kann alles, das älter als 30 Tage ist, gelöscht werden.

Unter 2003 sieht das beim Öffnen der Empfängerrichtlinie dann so aus:empfrl1

Exchange Server 2007 kennt diese alten Einstellungen nicht mehr. Microsoft hat das Thema deutlich ausgebaut und nennt es nun "Richtlinien zum Verwalten von Nachrichtendatensätzen" (weitere Informationen im Technet).

Die alten Postfach-Managereinstellungen müssen vor einer Migration erst entfernt werden (die Schritte werden im Systemmanager von Exchange 2003 ausgeführt!):

empfrl2

empfrl3

(Haken entfernen).

Wenn die Richtlinie gespeichert wurde, kann der Vorgang der Aktualisierung in der Exchange 2007-Verwaltungs-Shell wiederholt werden.

Normalerweise sollte er jetzt fehlerfrei durchlaufen.

Veröffentlicht 15. November 2008 von Robert Wille in Exchange, Exchange 2007, Exchange 2010

Ex 2007: Abwesenheitsnachrichten haben keinen Absender   Leave a comment

Beim Umstieg auf einen Exchange 2007-Server fiel einem Kunden auf, dass Abwesenheitsnachrichten ohne Absender, bzw. mit dem Absendereintrag <> verschickt werden. Diese Mails wurden durch sein Gateway auf dem Weg nach draußen abgefangen, weil dieses Gateway Mails ohne Absender nicht erlaubte.

Auch wenn dieses Verhalten auf den ersten Blick komisch erscheint, so ist es doch vollkommen standardkonform.

RFC 3798 regelt für sog. Message Disposition Notification (darunter fällt auch die Abwesenheitsnachricht) dass die "envelope sender address null (<>)" sein muss. Dieses Verhalten soll verhindern, dass auf automatische Meldungen wiederum automatisch (z.B. mit einer Unzustellbarkeitsnachricht) reagiert wird.

Exchange 2007 hält sich an diesen Standard und verschickt Abwesenheitsnachrichten mit dem Absender <>.

Quellen:

Veröffentlicht 11. September 2008 von Robert Wille in Exchange, Exchange 2007, Exchange 2010