Autor-Archiv

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

OWA 2010 – Probleme beim Download von Anlagen mit MSIE 9   4 comments

Nach einem Upgrade auf den Internet Explorer 9 stellte ein Kunde fest, dass der Download von angehängten Dokumenten aus OWA 2010 nicht mehr funktionierte.

Es zeigte sich folgender Fehler:

Ein ähnlicher Fehler wurde auch im amerikanischen Exchange-Forum beschrieben (Klick).

Die Lösung ist relativ einfach. Offensichtlich verstellt das Setup manchmal die Internetoptionen.

Folgende Option muss abgeschaltet sein:

Internetoptionen -> Erweitert -> Sicherheit -> Verschlüsselte Seiten nicht auf dem Datenträger speichern

Einmal den MSIE neustarten, dann sollte der Download wieder funktionieren.

Veröffentlicht 30. März 2011 von Robert Wille in Allgemein

Replikation öffentlicher Ordner Ex 2003 zu 2010   1 comment

Angeregt durch einen Beitrag meines MVP-Kollegens Frank Carius in einer geschlossenen Mailing-Liste, habe ich mal sein dort beschriebenes Best-Practice der Replkation öffentlicher Ordner im Rahmen einer Migration aufbereitet.

1. Bevor begonnen wird: Funktioniert das AD fehlerfrei -> Replikationsfehler im Event-Log suchen und zuerst beheben!

2. Bevor begonnen wird: Funktioniert die Namensauflösung und können Mails von 2003 nach 2010 übertragen werden -> ÖO-Replikation findet als SMTP-Nachricht statt!

3. Test-Benutzer erzeugen -> das schadet nie!

4. Test-Ordner anlegen -> das schadet auch nie!

5. Abwarten, bis die Hierarchy zwischen denen beiden Servern repliziert wurde -> das kann bis zu 48 Stunden dauern! Als Ergebnis müssen in der Toolbox von 2010 und dem ESM von 2003 alle Ordner identisch sein.

6. Die Replikate auf den neuen Server für einige Ordner (Test-Ordner von 4.) hinzufügen, z.B. in der Toolbox bei 2010

7. Überprüfen, ob der neue Server auch als Replikat im EMS von 2003 auftaucht -> das kann zwischen 15 und 120 Minuten

8. Die Replikation selbst prüfen für die bei 6. hinzugefügten Ordner, z.B. mit Hilfe von „get-publicfolderstatistics“ oder Franks kleinem Script

9. Nach und nach mehr Ordner hinzufügen und Schritt 8 wiederholen

10. Nachdem alle Ordner repliziert sind: Mailbox Datenbank auf die neue ÖO-Datenbank umstellen

11. Replikate aus dem Original entfernen (siehe Tipp unten)

Noch ein paar Tipps:

– die Replikation der Ordnerinhalte erfolgt per SMTP -> das kann dauern
– nicht ungeduldig werden; insgesamt werden drei verschiedene Stufen repliziert -> das kann dauern
– bei einer Migration mit den öffentlichen Ordnern beginnen -> dann weiß man schon am Anfang, ob sie Probleme machen werden
– sobald die Ordner Repliziert sind; die Datenbanken (auch die alten!) mit dem Verweis auf den neuen Server versehen: Dann sieht man auch schnell eventuelle Outlook-Probleme
– die Replikate auf den alten Servern werden erst entfernt, wenn alle Daten übertragen wurden; es ist also nicht ungewöhnlich, dass die alten Server noch eine zeitlang (Stunden, Tage) da drin stehen

Troubleshooting:

– Replikationszeiträume auf den ÖO-Datenbanken checken
– Mailfluss checken
– Event-Log checken
Hierachy und Inhalte manuell senden

Weitere Punkte werde ich bei Gelegenheit ergänzen. Eigene Erfahrungen können aber gerne als Kommentar gepostet werden und werden dann von mir eingearbeitet!

Veröffentlicht 7. Februar 2011 von Robert Wille in Allgemein

Mailbox verschieben in Exchange 2010 – Wofür steht die Prozent-Anzeige?   Leave a comment

Immer wieder mal tauchte die Frage auf, wie aussagekräftig eigentlich die Prozent-Anzeigen beim Verschiebe-Vorgang einer Mailbox in Exchange 2010 ist.

Hier eine kurze Übersicht:

  • Die ersten 20%:
  • verschiedenen Vorbereitungsaufgaben
  • Erzeugen der Zielmailbox
  • Feststellen des zu verschiebenden Inhaltes
  • und noch ein paar andere Kleinigkeiten
  • zwischen 20 % und 95%
  • dynamische Anzeige basierend auf den verschobenen Daten
  • die letzten 5%
  • Differenz-Synchronisation
  • Verbindung zur alten Mailbox trennen
  • AD aktualisieren
  • alte Mailbox entsperren (falls Exchange 2003)
  • und noch ein paar andere Kleinigkeiten

Man kann also aus den Angaben einiges ablesen. Die ersten 20% können gerade bei großen Mailbox relativ lange dauern, wenn Exchange den zu verschiebenden Inhalt ermittelt. Ab 20% bis 95% ist die Anzeige aber nicht geschätzt, sondern genau. Bei kleinen Mailboxen kann es da also ab 20% wirklich zu großen Sprüngen kommen.

Interessant ist, dass man den Verschiebevorgang bei 95% „anhalten“ kann. Hierzu muss der Verschiebevorgang mit der Shell und der Option „-SuspendWhenReadyToComplete“ ausgeführt werden.

Beispiel:

New-MoveRequest -Identity 'tony@alpineskihouse.com' -TargetDatabase DB01 -SuspendWhenReadyToComplete

Mit dem Befehl Resume-MoveRequest -Identity 'tony@alpineskihouse.com' wird der Verschiebevorgang dann abgeschlossen.

Damit kann man den größten Teil der Daten im Hintergrund verschieben und den einzigen Vorgang, den der Benutzer „sieht“, aber z.B. erst am Abend ausführen.

Weitere Informationen gibt es unter den folgenden Links:

Accessing Exchange 2010 mailbox move history data

Grundlegendes zu Verschiebungsanforderungen
Erstellen einer lokalen Verschiebungsanforderung
New-MoveRequest

Veröffentlicht 22. Januar 2011 von Robert Wille in Allgemein

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