Führen Sie mit Exchange PowerShell für E-Mails, die mit dem freigegebenen Postfach als Absender gesendet werden, das folgende Cmdlet aus:
PowerShell
set-mailbox <mailboxname> -MessageCopyForSentAsEnabled $True
Führen Sie mit Exchange PowerShell für E-Mails, die im Namen des freigegebenen Postfachs gesendet werden, das folgende Cmdlet aus:
PowerShell
set-mailbox <mailboxname> -MessageCopyForSendOnBehalfEnabled $True
Wird ein Exchange Postfach einem anderen Benutzer per Vollzugriff freigegeben, zeigt Outlook trotzdem als privat gekennzeichnete Mails nicht an. Das macht Sinn, da oft die Postfächer der Vorgesetzten für Mitarbeiter freigegeben werden. Die Vorgesetzten erhalten somit die Möglichkeit den Mitarbeitern bestimmten Mailverkehr vorzuenthalten.
Allerdings muss gesagt werden, dass nur Outlook diese Anzeige unterbeindet. Über OWA und bei anderen Mailclients werden auch die privaten Mails angezeigt. Man sollte sich also nicht blind auf diese Funktion verlassen.
Nun gibt es Fälle, in denen auch die als privat gekennzeichneten Mails eines Postfachs angezeigt werden sollen. Z.B. bei einem zentralen Postfach für die Personalabteilung, in der Bewerbungen eingehen. Diese gehen oft als privat gekennzeichnet ein.
Hierzu muss ein sogenanntes Delegate für einen Benutzer definiert werden. Das geht am besten mit einem PowerShell Script. Besonders, wenn das Delegate für mehere Benutzer eingerichtet werden soll.
Dazu habe ich 2 Blogeinträge gefunden. In folgendem Post muss zuvor die EWS Managed API auf einem Client installiert werden.
https://gsexdev.blogspot.com/2009/04/add-delegates-to-mailbox-with.html
In diesem Blog ist das Beispiel abgeändert und kann direkt auf dem Exchange Server über die Exchange Console ausgeführt werden:
https://www.windowspro.de/tipp/exchange-private-nachrichten-freigabepostfach-sichtbar-machen
Hier das Script:
ACHTUNG: in dem Skript wird versucht die Mailadresse des angemeldeten Benutzers auszulesen und damit ein autodiscover durchzuführen. Sollte der Admin, mit dem das Skript ausgeführt wird, keine Mailadresse haben, kann man irgendeine existierende Mailadresse aus dem Unternehmen nutzen: $service.AutodiscoverUrl(„irgendwas@domain.de“).
$mbtoDelegate = "sharedMailbox@domain.de" $delegatetoAdd = "delegateMailbox@domain.de" # ACHTUNG!!! Je nachdem, auf welchem Laufwerk der Exchange installiert wurde, # muss der Pfad zur DLL angepasst werden!!! $dllpath = "D:\exchange\Bin\Microsoft.Exchange.WebServices.dll" [void][Reflection.Assembly]::LoadFile($dllpath) $service = new-object Microsoft.Exchange.WebServices.Data.ExchangeService([Microsoft.Exchange.WebServices.Data.ExchangeVersion]::Exchange2007_SP1) $windowsIdentity = [System.Security.Principal.WindowsIdentity]::GetCurrent() $sidbind = "LDAP://<SID=" + $windowsIdentity.user.Value.ToString() + ">" $aceuser = [ADSI]$sidbind $service.AutodiscoverUrl($aceuser.mail.ToString()) $service.ImpersonatedUserId = new-object Microsoft.Exchange.WebServices.Data.ImpersonatedUserId([Microsoft.Exchange.WebServices.Data.ConnectingIdType]::SmtpAddress, $mbtoDelegate); $mbMailbox = new-object Microsoft.Exchange.WebServices.Data.Mailbox($mbtoDelegate) $dgUser = new-object Microsoft.Exchange.WebServices.Data.DelegateUser($delegatetoAdd) $dgUser.ViewPrivateItems = $true $dgUser.ReceiveCopiesOfMeetingMessages = $false $dgUser.Permissions.CalendarFolderPermissionLevel = [Microsoft.Exchange.WebServices.Data.DelegateFolderPermissionLevel]::Editor $dgUser.Permissions.InboxFolderPermissionLevel = [Microsoft.Exchange.WebServices.Data.DelegateFolderPermissionLevel]::Reviewer $dgArray = new-object Microsoft.Exchange.WebServices.Data.DelegateUser[] 1 $dgArray[0] = $dgUser $service.AddDelegates($mbMailbox, [Microsoft.Exchange.WebServices.Data.MeetingRequestsDeliveryScope]::DelegatesAndMe, $dgArray);
Den aktuellen Exchange Health Checker gibt es imme rhier:
Wichtiger Thread-Beitrag von Marco Freund:
https://www.frankysweb.de/neue-sicherheitsupdates-fuer-exchange-server/
Ein Problem, welche ich in der Vergangenheit schon oft hatte, ist, dass nach einem Exchange Update die OWA/ECP Website nicht verfügbar ist und man seltsame Fehlermeldungen erhält – Entweder Error 400 oder die Seite wird unvollständig dargestellt. Mit den Logs konnte ich nicht viel anfangen.
Ich fand heraus, dass nach jedem Exchange Update zwei Skripte ausgeführt werden sollten. Das war mir lange so nicht bekannt. Vielleicht hilft es ja einem weiter. Hier sind die Skripte abgelegt (ggf. Installationsordner anpassen und Powershell mit Adminrechten starten)
C:\Program Files\Microsoft\Exchange Server\V15\Bin> .\UpdateCas.ps1
C:\Program Files\Microsoft\Exchange Server\V15\Bin> .\UpdateConfigFiles.ps1
Wichtig ist auch: Diese Skripte müssen auf dem Mailbox Server ausgeführt werden, also den Servern mit aktiver Mailbox Rolle oder auf Multi Role Servern. Es ist auf den Servern mit Client Access Rolle (betrifft nur Exchange 2010 und 2013) nicht erforderlich.
Wer Wildcard Zertifikate in Exchange 2013 oder 2016 einsetzen will, muss ein paar Dinge beachten. Microsoft macht es mal wieder etwas komplizierter als nötig.
Auf einer neue Partition die Ordnerstruktur erstellen. Z.B.:
D:\Microsoft Exchange\Queue
Exchange Management Shell öffnen und folgendes Kommando eingeben:
Move-TransportDatabase.ps1 -QueueDatabasePath: "D:\Microsoft Exchange\Queue" -QueueDatabaseLoggingPath: "D:\Microsoft Exchange\Queue"
Dieses Script führt die Verschiebeanforderung für die Datenbank und die Logs durch. Die Datenbank und die Logs erscheinen nach der Verschiebung am neuen Speicherort.
Hatte folgendes Problem mit TrendMicro und in dem Zuge was über die Transportagents gelernt:
get-transportagent Uninstall-TransportAgent -Identity "ScanMail Routing Agent" Uninstall-TransportAgent -Identity "ScanMail SMTP Receive Agent"
https://docs.microsoft.com/en-us/Exchange/plan-and-deploy/supportability-matrix?view=exchserver-2019
Powershell als Admin ausführen und folgende Befehle eingeben, damit der Befehl import-module activedirectory möglich ist:
Import-Module ServerManager Add-WindowsFeature RSAT-AD-PowerShell
Wenn ein Kalender benötigt wird, auf den mehrere Benutzer Zugriff haben sollen (z.B. ein Urlaubkalender für ein Team), bietet sich dafür ein Raumpostfach an. Der AD-Benutzer für ein Raumpostfach ist Standardmäßig deaktiviert, daher wird keine User-CAL benötigt. Auch eine Exchagne-CAL wird nicht benötigt, da Raumpostfächer keine Lizenz benötigen. Hier die Vorgehensweise für die Exchange Server 2010 bis 2016.
In der Exchange Management Konsole auf Empfängerkonfiguration->Postfach klicken. In der rechten Navigations „Neues Postfach…“ auswählen und Raumpostfach wählen. Neuer Benutzer->weiter. Name und Anmeldename eingeben->weiter. Evtl. Postfachdatenbank auswählen->fertig.
Das Postfach erhält automatisch auch einen Kalender, der so benannt ist, wie das Postfach unter Name. Nach dem Anlegen kann die gesamte Organisation Standardmäßig Einträge in dem Kalender einsehen aber nichts eintragen.
Die Berechtigungen kann man einsehen mit dem Powershell Befehl
Get-MailboxFolderPermission "Raumname:\Kalender"
Achtung: Exchange erstellt den Namen zuerst als „Raumname:\Calendar“. Nach ein paar Minuten Sobald der erste (deutschsprachige) Client auf den Kalender zugreift, wird das auf „Raumname:\Kalender“ umgeschrieben und das obige Kommando gibt die Berechtigungen aus.
Die Berechtigungen kann man auf 2 Arten setzen.
Add-MailboxFolderPermission "Raumname:\Kalender" -user Standard -AccessRights PublishingEditor
Mit dem obigen Befehl wird allen Benutzern die Berechtigung PublishingEditor eingeräumt. Man kann auch eine Universelle Sicherheitsgruppe angeben. Diese muss aber „Mailenabled“ sein. Also als Verteilerliste in Exchange konfiguriert sein.
Es ist möglich, dass nach Absetzen des Kommandos über die Powershell folgende Fehlermeldung erscheint:
Der Benutzer „Raumname“ wurde in Active Directory gefunden, ihm können aber keine Berechtigungen zugewiesen werden. Versuchen Sie stattdessen ein SMTP-Adresse.
Das kann mit folgendem Befehl gelöst werden:
Set-DistributionGroup -Identity „Raumname“ -MemberDepartRestriction closed
Diese Einstellung gibt eigentlich vor, dass die Mitglieder der Verteilergruppe die Gruppe nicht selbstständig verlassen dürfen. Keine Ahnung, warum das gesetzt sein muss…
Folgende AccessRights existieren:
*Author = CreateItems, ReadItems, FolderVisible, EditOwnedItems, DeleteOwnedItems *PublishingAuthor = CreateItems, ReadItems, CreateSubfolders, FolderVisible, EditOwnedItems, DeleteOwnedItems *PublishingEditor = CreateItems, CreateSubfolders, DeleteAllItems, DeleteOwnedItems, EditAllItems, EditOwnedItems, FolderVisible, ReadItems
© 2016 kinc.de