Entsprechende Berechtigungen vorausgesetzt (“Senden Als” oder “Senden im Auftrag”) kann dies in Outlook problemlos bewerkstelligt werden, weil hier im E-Mail-Formular das “Von” Feld eingeblendet werden kann und man dort die entsprechende Absenderadresse einfach einträgt.

In Outlook Web Access von Exchange 2007 gibt es keine Möglichkeit, das “Von” Feld zu verwenden. Durch das Öffnen eines anderen Postfachs hat man die Möglichkeit E-Mails aus diesem Postfach zu versenden. Ein Senden im Namen einer Verteilerliste oder eines öffentlichen Ordners ist nicht möglich.

Exchange 2010 bietet in den OWA Einstellungen die Option “Absender immer anzeigen” (siehe Screenshot). Allerdings können keine S/Mime signierte bzw. verschlüsselte E-Mails über Outlook Web App versendet werden, wenn diese Einstellung aktiviert ist.

Mit einem kostenpflichtigen Third-Party-Tool “ChooseFrom” kann OWA von Exchange 2007 um die fehlende Funktion erweitert werden.

Mit dieser Erkenntnis wäre es interessant zu wissen, bei welchen Verteilern der eingetragene Manager nicht über die erforderlichen Bearbeitungsrechte verfügt, um ggf. die Berechtigungen nachzutragen.

Der folgende Powershell Code gibt jeweils eine Zeile mit dem Namen des Verteilers und dem Distinguished Name des eingetragenen Verwalters aus, wenn die Active Directory Berechtigungen ReadProperty und WriteProperty auf die Eigenschaft Member nicht gesetzt sind. Es werden alle Verteiler geprüft. Der Code kann unter Exchange 2007 nicht verwendet werden, da hier noch einiges anders ist. Für Exchange 2007 werde ich das entsprechende Script separat veröffentlichen.

#Alle Verteiler prüfen, bei denen das Property "ManagedBy" gefüllt ist
$groups = get-distributiongroup -ResultSize Unlimited | where-Object {$_.ManagedBy -ne $Null}
 
#Schleife wird für jeden gefundenen Verteiler durchlaufen
foreach ($group in $groups) {
 
	#Es können mehrere Verwalter eingetragen werden, deshalb der Zusatz -expandProperty
	$managers = $group.ManagedBy
 
	#Schleife wird für jeden gefundenen Verwalter durchlaufen
	foreach ($manager in $managers) {
 
		#Prüfe ob für den Verwalter eine Berechtigung für das Property "Member" eingetragen ist
		$permprop = get-adpermission $group.SamAccountName -user $manager.DistinguishedName | where-Object {$_.Properties -match 'Member'}
 
		#Wenn keine Berechtigung vorhanden ist, Ausgabe des Gruppennamens und des Verwalters
		if ($permprop -eq $Null) {
			Write-Host "Gruppe: " $group.SamAccountName "Verwalter: " $manager.DistinguishedName
		} Else {
 
			#Es müssen die Berechtigungen Read Property _und_ Write Property auf "Member" vorhanden sein
			$permright = $permprop.AccessRights
			if ($permright -notcontains "ReadProperty, WriteProperty") {
				Write-Host "Gruppe: " $group.SamAccountName "Verwalter: " $manager.DistinguishedName
			}
		}
	}
}

Hinweise: Die mehrfachenAbfragen get-adpermission sind leider erforderlich, da sonst das Abfrageergebnis nicht verarbeitet werden kann. Das Script wurde in einer Umgebung mit Exchange 2010 SP1 (Beta) erfolgreich getestet. Wer Fehler findet, bitte in den Kommentaren melden. Danke.

Administratoren, die es gewohnt sind, die Verwaltung einer Exchange Organisation über grafische Oberflächen durchzuführen, müssen beim Einsatz von Exchange 2007 bzw. Exchange 2010 in einigen Bereichen umdenken.

Zu den alltäglichen Aufgaben gehört das Festlegen eines Verwalters für Verteilergruppen, dem dadurch zumeist auch die Berechtigungen zugewiesen werden sollen, Mitglieder hinzuzufügen, bzw. wieder zu entfernen.  In Exchange 2003 Umgebungen hat man diese Aufgabe gewöhnlich in der Active Directory Benutzer und Computer Verwaltungskonsole (ADUC) ausgeführt. Wer dies in Exchange 2007 und Exchange 2010 Umgebungen beibehält, braucht nicht umzudenken.

Dabei ist es wichtig zu wissen, dass es hier um zwei verschiedene Dinge geht:

• die Anzeige des Verwalters in den Eigenschaften der Verteilergruppe im Adressbuch
• die Berechtigungen Read Member und Write Member (Mitglieder lesen / Mitglieder schreiben)

Weder über die Exchange 2007 Verwaltungskonsole, noch über die Verwaltungskonsole für Exchange 2010 können die Berechtigungen Read Member bzw. Write Member vergeben werden!

Verwalter mit Berechtigungen per ADUC setzen

In der Active Directory Benutzer und Computer Verwaltungskonsole die Eigenschaften der Verteilergruppe öffnen und den Reiter “Verwaltet von” bw. “Managed By” auswählen. Durch Klick auf “Ändern” und anschließender Auswahl des gewünschten Verwalters wird die Anzeige des Gruppenverwalters im Adressbuch festgelegt. Das Aktivieren der Option “Vorgesetzter kann Mitgliedsliste ändern” werden die oben genannten Berechtigungen vergeben.

Es kann hier nur ein Verwalter eingetragen werden. Wenn mehrere User die Berechtigungen zur Anpassung des Verteilers benötigen, müssen die Berechtigungen über “Sicherheit”, Erweitert hinzugefügt werden (siehe Screenshot)

Verwalter über die Exchange Verwaltungskonsole setzen

In der Verwaltungskonsole für Exchange kann sowohl unter Exchange 2007 als auch unter Exchange 2010 ein Gruppenverwalter eingetragen werden, der dann im Adressbuch angezeigt wird.

Der Unterschied zwischen Exchange 2007 und Exchange 2010 an dieser Stelle besteht darin, dass bei Exchange 2010 auch mehrere Verwalter eingetragen werden können.

Verwalter per Powershell setzen

Der Powershellbefehl mit dessen Hilfe ein Verwalter definiert werden kann und mit dem gleichzeitig die erforderlichen Berechtigungen gesetzt werden, sieht so aus:



Set-DistributionGroup -Identity verteilername -ManagedBy username | add-adpermission -user username -AccessRights ReadProbperty, WriteProperty -Properties ‘Member’

Rollenberechtigungen in Exchange 2010

Durch Anpassung der “Default Role Assignment Policy”, die für alle Benutzer gilt, kann man den Anwendern pauschal die Berechtigung zuweisen, alle Verteilergruppen zu bearbeiten, für die sie als Verwalter eingetragen sind.

Die Bearbeitung ist dann allerdings nur über die Exchange Systemsteuerung in Outlook Web App möglich. Ein Hinzufügen oder Entfernen von Mitgliedern über das Outlook Adressbuch ist nicht möglich.

Fazit

Auch bei Einsatz von Exchange 2007 und Exchange 2010 bleibt die Active Directory Benutzer und Computer Verwaltungskonsole das Tool, mit dem Verwalter für Gruppen gesetzt werden, sofern man keine Powershell einsetzen möchte.

Bei Exchange 2010 besteht zwar die Möglichkeit, den Anwendern die Berechtigung einzuräumen, Verteiler für die sie als Verwalter/Besitzer eingetragen sind über Outlook Web App verwalten zu können. Ob dies in Umgebungen erfolgreich umgesetzt werden kann, wo Anwender Verteiler bisher über das Outlook Adressbuch  gepflegt haben, bezweifle ich.

Bei Microsoft gibt es den EWS Editor, einen Exchange Postfach Explorer, der die EWS Schnittstelle verwendet. Der EWS Editor verwendet Autodiscover, um sich mit dem eigenen Postfach zu verbinden. Alternativ kann man die Verbindung manuell konfigurieren und dort unter anderem die Service URL, die zu verwendende Exchange Version und die ID eines anderen Postfachs angeben.

Nach dem Verbindungsaufbau wird der Inhalt des Rootcontainers des Postfachs inklusive der Systeminhalte angezeigt. Per Rechtsklick auf einzelne Ordner kann man sich unter anderem den “Associated Content”  anzeigen lassen. Für manche Aufgaben im Rahmen des Troubleshootings bei Problemen mit einem Postfach, ist der EWS Editor somit eine Alternative zu MFCMapi.

Links:

• EWS Editor Home
• Introduction to Web Services
• Exchange Web Services Reference

Einmal festgelegt taucht die Abfrage nie wieder auf. Sicher, man kann die Einstellungen später noch in Outlook Web App anpassen, dennoch ist die Frage interessant, wo die Einstellungen gespeichert werden. Diese Frage tauchte im Zusammenhang mit der Signatur auf, die man in den Einstellungen in Outlook Web App definieren kann. 

Diese Einstellungen werden im Rootcontainer des Postfachs gespeichert und zwar im “Associated Content”. Wenn man sich per MFCMapi mit  dem Postfach verbindet, kann man sich den “Associated Content” des Rootcontainers durch Rechtsklick und Auswahl der entsprechenden Option anzeigen lassen. In der Liste taucht eine “Nachricht” vom Typ IPM.Configuration.OWA.UserOptions (Message Class) auf, diese beherbergt die vorgenannten Einstellungen.

Im Property mit der Bezeichnung “PR_ROAMING_DICTIONARY, PidTagRoamingDictionary” ist unter anderem die von Outlook Web App verwendete Signatur gespeichert. Die Einstellungen werden im XML Format abgelegt. Eine Bearbeitung der Properties per MFCMapi empfiehlt sich eher nicht, es sei denn, man kennt die genaue Syntax, die hier angewendet werden muss.

Das Löschen der versteckten “Nachricht” Typ IPM.Configuration.OWA.UserOptions kommt einem Zurücksetzen der individuellen Einstellungen gleich und hat zur Folge, dass die o.g. Abfrage bei der nächsten Anmeldung wieder erscheint.

Das Update kann bei Microsoft heruntergeladen werden. Die Verteilung über Windows Update (WSUS) ist in 2 Wochen vorgesehen.

Links:

• Beschreibung des Updates
• Download
• Weitere Informationen im Blog des MS Exchange Teams

Mit dem Servicepack 1 hat Microsoft die Möglichkeit eingeführt, die Aufbewahrungsrichtlinien über die grafische Oberfläche der Exchange Verwaltungskonsole zu verwalten. Vermutlich erhofft man sich dadurch eine größere Akzeptanz.

In folgendem Beispiel werde ich eine Aufbewahrungsrichtlinie anlegen, die lediglich einen Tag enthält, der dafür sorgen soll, dass die Systemmeldungen, die ich erhalte, automatisch nach 14 Tagen gelöscht werden.

1. Anlegen des Aufbewahrungsrichtlinientags (was für ein Wort)
   Nach dem Öffnen der Exchange Verwaltungskonsole findet man unter Organisationskonfiguration, Postfach den Reiter “Aufbewahrungsrichtlinientags”. Dort sind die vorgefertigten Tags bereits enthalten.Groß ist des Meisters Kraft, wenn er mit der rechten schafft: Ein Rechtsklick auf eine leere Stelle fördert das Kontextmenü zutage, hier bitte “Neues Aufbewahrungsrichtlinientag” auswählen

   

   Die Auswahl von “Persönliche Ordner” hat zur Folge, dass dieser Tag dem Anwender in Outlook als Wahloption zur Verfügung steht und nicht als Standardtag festgelegt wird.

   

   Auswahl der Aktion “Löschen und Wiederherstellung zulassen”

   

   Gut finde ich, dass hier am Ende auch der entsprechende Powershellbefehl angezeigt wird. In diesem Fall wäre der Powershellbefehl:

   New-RetentionPolicyTag -Name 'Remove-Systemmsgs-14d' -Type "Personal" -Comment ' -AgeLimitForRetention '14.00:00:00' -RetentionAction 'DeleteAndAllowRecovery' -RetentionEnabled $true

   

2. Anlegen der AufbewahrungsrichtlinieAuswahl “Neue Aufbewahrungsrichtlinie” aus dem Kontextmenü
   
   Hinzufügen des Aufbewahrungsrichtlinientags

   

   Last but not least, Zuweisen der Aufbewahrungsrichtline an ein Postfach. Wichtig: Jedem Postfach kann nur eine Aufbewahrungsrichtlinie zugewiesen werden.

   

3. Und so sieht das dann aus, wenn die Aufbewahrungsrichtlinie einem Ordner zugewiesen ist

   

   In E-Mails taucht dann ebenfalls der Hinweis auf den Ablaufzeitpunkt auf:

   

Hintergrund: Mit Exchange 2010 hat Microsoft das Online Archiv eingeführt, um die PST Dateien (Persönliche Ordner) abzulösen. E-Mails können wahlweise automatisiert durch das Messaging Records Management, oder manuell in das Archivpostfach verschoben werden. Auf das Archivpostfach kann wahlweise mit Outlook Web App oder mit Outlook (ab Version 2010) zugegriffen werden. Das Archivpostfach steht im Offlinebetrieb nicht zur Verfügung.

Weitere Informationen zum Online Archiv: http://www.roland-ehle.de/archives/868

Mit der Möglichkeit das Hauptpostfach und das Archivpostfach in verschiedenen Datenbanken zu speichern ist jetzt die Anwendung unterschiedlicher Backup-Strategien realisierbar. Für Haupt- und Archivpostfach können unterschiedliche Größenbeschränkungen aktiviert werden. Je nach Anwendung der Größenbeschränkung kann davon ausgegangen werden, dass Archivpostfächer wesentlich mehr Daten enthalten und somit für ein Full Backup  bzw. ein Restore wesentlich mehr Zeit aufgewendet werden muss.

Der Befehl New-MoveRequest wurde entsprechend um  Paramter ergänzt: -ArchiveOnly und -ArchiveTargetDatabase sind neue Parameter. Über die GUI sieht dann eine “Neue lokale Verschiebungsanforderung” so aus:

Für die Installation des SP1 muss insgesamt eine knappe Stunde eingeplant werden.  Mit der Installation des Servicepacks wird erneut das Active Directory Schema erweitert, dies sollte man bei der Installation in größeren Umgebungen berücksichtigen.

Installationsvoraussetzungen:
Für die Installation wird ein Hotfix für .NET 3.5 SP1 benötigt. Das Hotfix verlangt einen Neustart nach der Installation.

Links:
KB891002 – Hotfix für .NET 3.5 SP1
Microsoft Exchange Server 2010 Servicepack 1 Beta
Exchange Server Active Directory Schema Changes Reference, June 2010