Archiv für die Kategorie ‘Exchange

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

Welche Exchange-Version läuft unter welcher Windows Version?   Leave a comment

Update vom 17.10.2010:

Microsoft veröffentlicht mittlerweile selbst eine umfangreiche Support Matrix, in der auch die alten Exchange-Versionen enthalten sind:

Exchange Server Supportability Matrix

Veröffentlicht 7. November 2009 von Robert Wille in Exchange

Exchange 2007: Besprechungsräume – Teil 2: Einschränkungen der Raumbuchungen   3 comments

Nach dem Sie im ersten Teil erfolgreich einen Besprechungsraum erzeugt haben und dieser auch schon munter auf Besprechungsanfragen antwortet, sollten wir noch ein paar weitere Konfigurationen vornehmen.

Alle Befehle müssen in der Exchange Shell eingegeben werden! Wichtig: Alle Befehle sind in eine Zeile zu schreiben, so lange der Befehl nicht anders gekennzeichnet ist!

Kalender-Aufsicht einstellen

Die Kalender-Aufsicht (auch “Ressource Delegate” genannt) kann Termine im Kalender genehmigen oder ablehnen oder vorhandene Termine löschen.

Einen Benutzer einstellen:

Set-MailboxCalendarSettings <Name des Raums> -ResourceDelegates <Name des Postfaches>

Den Kalender kann der eingestellte Benutzer danach über die Funktion “Freigegebenen Kalender öffnen…” öffnen und Termine darin bearbeiten.

Es ist auch möglich, mehrere Konten als Kalenderaufsichten einzutragen. Der Befehl dafür ist aber leider ein wenig länger:

Set-MailboxCalendarSettings <Name des Raums> -ResourceDelegates ($(Get-MailboxCalendarSettings <Name des Raums>).ResourceDelegates += $(Get-Mailbox <Name des Postfaches>).DistinguishedName)

Das Entfernen eines einzelnen Benutzer geschieht analog dazu mit folgendem Befehl:

Set-MailboxCalendarSettings <Name des Raums> -ResourceDelegates ($(Get-MailboxCalendarSettings <Name des Raums>).ResourceDelegates -= $(Get-Mailbox <Name des Postfaches>).DistinguishedName)

(Bitte beachten Sie bei beiden Befehlen, dass der Name des Raumes zweimal eingetragen werden muss und vergessen Sie keine runde Klammer!

Um alle Aufsichten zu löschen, benutzen Sie den folgenden Befehl:

Set-MailboxCalendarSettings <Name des Raums> -ResourceDelegates $null

Buchungszeitraum einstellen

Sicher möchten Sie nicht, dass Ihr Besprechungsraum Samstags oder morgens um 04:00 Uhr gebucht wird. Also legen wir einen ordentlichen Buchungszeitraum fest:

Set-MailboxCalendarSettings <Name des Raums> -ScheduleOnlyDuringWorkHours $true

Wer darf einen Raum buchen?

Das ist sicher die wichtigste Frage: Wer darf eigentlich einen Raum buchen.

Hier werden zwei Typen und zwei Gruppen unterschieden:

Typen:

  • Buchungen (= diese Termine werden sofort genehmigt)
  • Anfragen (= dies müssen von der Kalenderaufsicht bearbeitet werden)

Gruppen:

  • Alle Benutzer
  • eingetragene Benutzer

Eingestellt werden die einzelnen Typen und Gruppen über die folgenden Parameter:

Parameter bezieht sich auf alle Werte Standard Beschreibung
-AllBookInPolicy Alle Benutzer $true / $false True Ist diese Einstellung gesetzt, werden alle Buchungen, die den Richtlinien entsprechen, sofort genehmigt
-AllRequestInPolicy Alle Benutzer $true / $false False Ist dieser Einstellung gesetzt, darf jeder Besprechungsanfragen, die den Richtlinien entsprechen, senden. Diese Richtlinie wird nur beachtet, wenn die Richtlinie AllBookInPolicy auf $false steht!
-AllRequestOutOfPolicy Alle Benutzer $true / $false False Ist diese Einstellung gesetzt, dürfen alle Benutzer Anfragen stellen, die nicht den Richtlinien entsprechen.
-BookInPolicy eingetragene Benutzer Benutzer Leer Von Benutzern, die hier eingetragen sind, werden alle Anfragen sofort genehmigt, wenn die Anfragen den Richtlinien entsprechen
-RequestInPolicy eingetragene Benutzer Benutzer Leer Alle Benutzer, die hier eingetragen sind, dürfen Anfragen schicken, die den Richtlinien entsprechen
-RequestOutOfPolicy eingetragene Benutzer Benutzer Leer Alle Benutzer, die hier eingetragen sind, dürfen Anfragen schicken, die den Richtlinien nicht entsprechen

 

Hierbei ist folgendes zu beachten: Im Standard dürfen alle Benutzer Anfragen stellen, die den Richtlinien entsprechen. Diese Anfragen werden sofort genehmigt. Wenn wir umstellen wollen, dass nur noch einzelne Personen buchen dürfen, müssen wir das abschalten.

Bespiel: Für den Besprechungsraum dürfen nur ausgewählte Personen (1) Termine eintragen, die sofort genehmigt werden: der Chef und die Sekretärin (2). Beide dürfen auch Termine eintragen, die den Richtlinien nicht entsprechen (3). Alle anderen Mitarbeiter dürfen Anfragen schicken (4), die die Kalender-Aufsicht bearbeiten muss.

Hier die Befehle dazu:

(1) Set-MailboxCalendarSettings <Name des Raums> -AllBookInPolicy $false

(2) Set-MailboxCalendarSettings <Name des Raums> -BookInPolicy ($(Get-MailboxCalendarSettings <Name des Raums>).BookInPolicy+= $(Get-Mailbox <Chef-Postfach>).DistinguishedName)

(2) Set-MailboxCalendarSettings <Name des Raums> -BookInPolicy ($(Get-MailboxCalendarSettings <Name des Raums>).BookInPolicy+= $(Get-Mailbox <Sekträtrin-Postfach>).DistinguishedName)

(3) Set-MailboxCalendarSettings <Name des Raums> -RequestOutOfPolicy($(Get-MailboxCalendarSettings <Name des Raums>).RequestOutOfPolicy+= $(Get-Mailbox <Chef-Postfach>).DistinguishedName)

(3) Set-MailboxCalendarSettings <Name des Raums> -RequestOutOfPolicy($(Get-MailboxCalendarSettings <Name des Raums>).RequestOutOfPolicy+= $(Get-Mailbox <Sekträtrin-Postfach>).DistinguishedName)

(4) Set-MailboxCalendarSettings <Name des Raums> –AllRequestInPolicy $true

(Kleiner formeller Hinweis: Sie können auch Chef gegen Chefin und Sekretärin gegen Sekretär ersetzen, das ändert aber nichts an den Einstellungen. ;))

Was haben wir getan?

  1. Wir schalten ab, dass die Anfragen von allen sofort genehmigt werden.
  2. Wir erlauben dem 1. und dem 2. Postfach die direkte Buchung
  3. Postfach 1 und 2 dürfen auch Anfragen außerhalb der Richtlinien stellen
  4. Alle anderen Mitarbeiter dürfen Anfragen innerhalb der Richtlinien stellen

Leider ist es bei Punkt 3 nicht möglich, den beiden Benutzer zu erlauben, gleich genehmigte Termine außerhalb der Richtlinien einzutragen. Außerhalb der Richtlinien sind nur Anfragen erlaubt, die von der Kalender-Aufsicht genehmigt werden müssen.

Richtlinien heißt übrigens in diesem Falle, dass die normalen Einstellungen des Kalenders beachtet worden sind, z.b. die Länge des Termines, Serientermineinstellungen, Arbeitszeiten, etc.

Und sonst noch?

Es gibt noch weitere interessante Einstellungen in Kalender, von denen ich hier exemplarisch einige vorstellen möchte:

Parameter Werte Standard Beschreibung
-AddOrganizerToSubject $true / $false True

Mit dem Parameter AddOrganizerToSubject können Sie festlegen, ob der Name des Besprechungsorganisators als Betreff der Besprechungsanfrage verwendet wird.        Dieser Parameter wirkt sich nur aus, wenn der Parameter AutomateProcessing auf AutoAccept festgelegt ist.

-AllowConflicts $true / $false False

Mit dem Parameter AllowConflicts können Sie festlegen, ob sich überschneidende Besprechungsanfragen zugelassen werden.

-BookingWindowInDays Zahl 180 Mit dem Parameter BookingWindowInDays können Sie festlegen, wie lange im Voraus Besprechungsanfragen gebucht werden dürfen.
-ConflictPercentageAllowed Zahl 0

Mit dem Parameter ConflictPercentageAllowed können Sie einen Schwellenwert für den Prozentanteil der Konflikte bei Besprechungsserien festlegen. Wenn der Prozentanteil der Instanzen einer Besprechungsserie, die sich mit anderen Besprechungen überschneiden, diesen Wert überschreitet, wird die Besprechungsserienanfrage abgelehnt.

-ForwardRequestsToDelegates $true / $false True

Mit dem Parameter ForwardRequestsToDelegates können Sie festlegen, ob eingehende Besprechungsanfragen an die für das Postfach definierten Stellvertreter weitergeleitet werden.

-MaximumConflictInstances Zahl 0

Mit dem Parameter MaximumConflictInstances können Sie die maximale Anzahl von zulässigen Konflikten für Besprechungsserien festlegen. Wenn die Anzahl der Instanzen einer Besprechungsserie, die sich mit anderen Besprechungen überschneiden, diesen Wert überschreitet, wird die Besprechungsserienanfrage abgelehnt.

-MaximumDurationInMinutes

Zahl 1440

Mit dem Parameter MaximumDurationInMinutes können Sie die maximal erlaubte Dauer für eingehende Besprechungsanfragen festlegen.

-ProcessExternalMeetingMessages $true / $false False Mit dem Parameter ProcessExternalMeetingMessages können Sie festlegen, ob Besprechungsanfragen, die von außerhalb der Exchange-Organisation stammen, verarbeitet werden.

 

Alle Parameter finden Sie wie immer mit folgendem Befehl heraus:

Get-Help Set-MailboxCalendarSettings –Detailed

 

Weitere geht es demnächst im dritten Teil mit den benutzerdefinierten Ressourceneigenschaften.

 

Weitere Links:

Managing Resource Scheduling

How to Set Resource Booking Policies

Veröffentlicht 6. November 2009 von Robert Wille in Exchange, Exchange 2007

Exchange 2007: Besprechungsräume – Teil 1: Konfiguration der automatischen Annahme von Besprechungsanfragen   Leave a comment

In Exchange 2007 hat Microsoft eine sehr schöne Funktion eingebaut, mit der man einfach sog. Ressourcen-Postfächer erzeugen kann, z. B. für einen Besprechungsraum oder einen Beamer.

Als Highlight kann man diese Postfächer dann auch noch so konfigurieren, dass sie Besprechungsanfragen automatisch beantworten und Termin selbsttätig zu- oder absagen.

Leider ist die Konfiguration nur über die PowerShell möglich. Daher hier eine kleine Schritt-für-Schritt-Anleitung:

Legen Sie mit Hilfe der Konsole ein Raumpostfach an:

raum1

Denken Sie bei den weiteren Schritten daran, dass auch ein Raumpostfach einen normalen Active Directory-Benutzer benötigt – so wie jedes andere Postfach in Exchange auch. Wenn Sie im nächsten Dialog einen vorhandenen Benutzer wählen, muss der User in AD deaktiviert sein. Wenn Sie einen neuen Benutzer anlegen, müssen Sie ihm auch ein korrektes Kennwort (entsprechend den Kennwortrichlinien!) eintragen. Der neuen Benutzer wird automatisch so angelegt, dass er deaktiviert ist und sein Kennwort nicht abläuft.

Alle weitere Schritte des Assistenten beantworten Sie gewohnt, wie auch bei normalen Postfächern.

Schauen Sie sich danach die Eigenschaften des Postfach einmal an:

raum2

Sie können unter “Ressourcenkapazität” zum Beispiel die Anzahl der Sitzplätze eines Besprechungsraumes einstellen. Bitte beachten Sie aber, dass die Eingabe hier keine Auswirkungen auf die Anzahl der Teilnehmer in der Einladung hat. Selbst wenn Sie hier eine kleine Zahl eintragen –> es lassen sich problemlos auch mehr Leute einladen. Zu den “benutzerdefinierten Ressourceneigenschaften” werde ich im dritten Teil dieses How-To etwas sagen.

Nun muss die Funktion der automatischen Bearbeitung noch eingeschaltet werden. Leider hat Microsoft hier keine Möglichkeit der grafischen Eingabe vorgesehen, sondern zwingt uns in die Shell:

Get-MailboxCalendarSettings <Name des Raumes> | Format-List -Property AutomateProcessing

Die Eigenschaft “AutomateProcessing” ist die, die wir suchen. Stellen Sie diese auf den Wert “AutoAccept” ein:

Set-MailboxCalendarSettings <Name des Raumes> -AutomateProcessing AutoAccept

(Die weiteren Optionen, die man hier einstellen kann, werden wir im zweiten Teil besprechen.)

Fügen Sie nun den Besprechungsraum einer Besprechungsanfrage hinzu:

raum3

Kurz nach dem Senden wird eine automatische E-Mail des Besprechungsraumes eingehen:

raum4

Fertig! Natürlich würde der Raum die Einladung ablehnen, wenn er schon für einen anderen Termin gebucht ist.

Im zweiten Teil werden Sie erfahren, wie man genauer einstellen kann, wer eine Ressource buchen darf.

Im dritten Teil erfahren Sie, was sonst noch mit Ressourcen-Postfächern möglich ist!

Weitere Informationen:

How to Enable the Auto-Processing of Meeting Messages

How to Upgrade Exchange 2003 Auto Accept Agent-Based Resource Mailboxes to Exchange 2007

Veröffentlicht 10. Oktober 2009 von Robert Wille in Exchange, Exchange 2007

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