Archiv für Juli 2011

Adressbücher können nicht aktualisiert werden   14 comments

Beim manuellen Aktualisieren der Adressbücher in der EMS (z.B. mit get-addresslist | update-addresslist oder
get-globaladdresslist | update-globaladdresslist) erhälst Du folgende Fehler (können auch ähnlich sein):

WARNUNG: Der Empfänger "DOMÄNE.local/Microsoft Exchange System Objects/Offlineadressbuch -
\/o=DOMÄNE\/cn=addrlists\/cn=oabs\/cn=Standard-O" ist ungültig und konnte nicht aktualisiert werden.
WARNUNG: Der Empfänger "DOMÄNE.local/Microsoft Exchange System Objects/Offlineadressbuch - Erste administrative Gruppe"
 ist ungültig und konnte nicht aktualisiert werden.
WARNUNG: Der Empfänger "DOMÄNE.local/Microsoft Exchange System Objects/Schedule+ Zeitplaninformationen - Erste
administrative Gruppe" ist ungültig und konnte nicht aktualisiert werden.

Auffällig dabei ist, dass es sich um Objekte aus der OU „Microsoft Exchange System Objects“ und offensichtlich um öffentliche Ordner handelt.

Mit Exchange 2007 hat Microsoft eingeführt, das im Alias eines Kontos für Exchange kein Leerzeichen mehr sein darf. Bei einer Migration von Exchange 2003 machen die bei 2003 angelegten System-Folder probleme, weil diese Leerzeichen enthalten.

WICHTIG: Solange der Fehler nicht behoben ist, werden die Adresslisten nicht aktualisiert. In der Folge gibt es auch keine Offline-Adressbücher!

Die Korrektur ist einfach:

ADSI-Editor aufrufen und über das Menü „Aktion“ mit dem „Standardmäßigen Namenskontext“ verbinden:


Danach die linke Seite so weit aufklappen, bis die „Microsoft Exchange System Objects“ erreicht sind. Rechts die in der Fehlermeldung genannten Objekte anklicken und die Eigenschaften öffnen:

Wir suchen die Eigenschaft mailNickname. Diese öffnen und alle Leerzeichen aus dem Alias entfernen. Fortfahren, biss alle Objekte aus der Fehlermeldung bearbeitet worden sind:

Zum Abschluss brauchen wir noch mal die Exchange-Shell:

Get-EmailAddressPolicy | Update-EmailAddressPolicy
Get-AddressList | Update-AddressList
Get-GlobalAddressList | Update-GlobalAddressList
Get-OfflineAddressBook | Update-OfflineAddressBook

Alle Befehle sollten nun fehlerfrei durchlaufen. Bis das OAB bei den Clients ankommt, kann es aber nochmal bis zum 480 Minuten dauern!

Advertisements

Veröffentlicht 14. Juli 2011 von Robert Wille in Allgemein

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).

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