Zugriff aus freigegebenes Postfach über Benutzer-Gruppe steuern
Problembeschreibung
Microsoft Exchange lässt eine Steuerung des Zugriffs auf ein freigegebenes Postfach über Benutzergruppen nicht zu. In der Grafischen-Umgebung (ECP) ist lediglich das hinzufügen von Benutzern für den Zugriff auf ein freigegebenes Postfach möglich. Verwendet man nun zur Anlage eines neues Benutzers die Kopie eines vorhandenen Benutzers wäre es doch von Vorteil wenn der Zugriff auf freigegebene Postfächer über die Mitgliedschaft in einer Gruppe mit kopiert werden könnten.
Lösungsansatz
Über die PowerShell ist es möglich auch Benutzergruppen Zugriff auf ein freigegebenes Postfach zu geben. Damit wäre der erste Schritt für den Zugriff erledigt, leider funktioniert danach das Auto-Mapping der freigegebenen Postfächer nicht, da hierzu das AD-Attribute „msExchDelegateListLink“ mit den entsprechenden Mitglieder der Gruppe gefüllt werden muss. Um das Ad-Attribute nun mit den entsprechenden Informationen zu füllen habe ich ein PowerShell-Script* erstellt. Dieses kann nun nach Änderungen von Hand oder per Aufgabenplanung (z.B. alle 15 Minuten) gestartet werden.
Einrichtung
Zunächst müssen die Gruppen für die Postfächer erstellt werden, hier nun Beispielhaft für ein Info- und ein Support-Postfach.
New-ADGroup Mailbox_Info_Vollzugriff
New-ADGroup Mailbox_Support_Vollzugriff
Den erstellten Gruppen werden dann im zweiten Schritt die Berechtigungen auf die Postfächer erteilt. Wichtig ist hierbei das diese in der Exchange-Shell ausgeführt werden. Setzen des Vollzugriffs:
Add-MailboxPermission info -User „Mailbox_Info_Vollzugriff“ -AccessRights Full
Add-MailboxPermission support -User „Mailbox_Support_Vollzugriff“ -AccessRights Full
Setzen der Berechtigung „Senden als“:
Add-ADPermission info -User „Mailbox_Info_Vollzugriff“ -AccessRights ExtendedRight -ExtendedRights „Send As“
Add-ADPermission support -User „Mailbox_Support_Vollzugriff“ -AccessRights ExtendedRight -ExtendedRights „Send As“
Nun sind die Vorarbeiten abgeschlossen und die Gruppen können mit Benutzern befüllt werden. Wenn dies erledigt ist das PowerShell-Script* ausführen um das Automapping zu „aktivieren“.
Verwendete Scripts
Mailbox_Zugriff_Automapping.ps1
Mit diesem Script wird das Automapping für die User der gruppe aktiviert, indem die User in das Attribut „msExchDelegateListLink“ übernommen werden.
Mailbox_Zugriff_Setzen.ps1
Dieses Script dient dazu den Gruppen Vollzugriff auf ein Postfach zu geben, dies ist über die grafische Oberfläche nicht möglich, da nur Benutzer zur Auswahl stehen.
# Mailbox_Zugriff_Automapping.ps1
# Neue Postfächer in Form "samacountname", "Mailbox-Gruppe" hinzufügen
$array = @( @("info", "Mailbox_Info_Vollzugriff"), `
@("support", "Mailbox_Support_Vollzugriff") )
for ($i=0; $i -lt $array.length; $i++){
$postfachname = $array[$i][0]
$gruppenname = $array[$i][1]
# Mitglieder der Gruppe auslesen
$user = Get-ADGroupMember $gruppenname
# Inhalt des Attributs löschen
Set-ADUser $postfachname -clear msExchDelegateListLink
foreach($users in $user){
# Alle Mitglieder in das Attribut übernehmen
Set-ADUser $postfachname -Add @{msExchDelegateListLink=$User.distinguishedName}
}}
# Mailbox_Zugriff_Automapping.ps1
# Exchange Management Shell einbinden
$CallEMS = ". '$env:ExchangeInstallPath\bin\RemoteExchange.ps1'; Connect-ExchangeServer -auto -ClientApplication:ManagementShell "
Invoke-Expression $CallEMS
Add-MailboxPermission Info -User "Mailbox_Info_Vollzugriff" -AccessRights Full
Add-ADPermission Info -User "Mailbox_Info_Vollzugriff" -AccessRights ExtendedRight -ExtendedRights "Send As"
Add-MailboxPermission Support -User "Mailbox_Support_Vollzugriff" -AccessRights Full
Add-ADPermission Support -User "Mailbox_Support_Vollzugriff" -AccessRights ExtendedRight -ExtendedRights "Send As"
Einrichtung Aufgabenplanung
Mithilfe der Aufgabenplanung lässt sich das PowerShell-Script in bestimmten Abständen durchführen. Hierdurch reicht die Pflege der Gruppe aus und das Automapping erfolgt automatisch. Die benötigten Einstellungen für die Aktion wären hierbei:
Aktion Programm starten mit folgenden Einstellungen: Programm/Script:
C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
Argument hinzufügen:
-command „C:\Scripts\Mailbox_Zugriff_Automapping.ps1“
Ich hoffe das beschriebene Verfahren ist für den ein oder anderen Nützlich. 🙂
IT-Fanatic
Posted in Allgemein, Exchange Server and tagged Active-Directory, Exchange, powershell, Scripting, shared-mailboxwith comments disabled.
Mailstore: Der Ordner mit der FolderID „xxx“ hat keinen gültigen Namen.
Die in der Überschrift genannte Fehlermeldung führte in Mailstore dazu das bei einigen Postfächer keine fehlerfreie Archivierung mehr durchgeführt wurde. Hier ein Screenshot der Meldung:
Erstes Ziel nun zu ermitteln um was für einen Ordner es sich den wohl handelt. Mit folgendem Befehl ließen sich die FolderIDs der betroffenen Postfächer anzeigen:
Get-MailboxFolderStatistics -Identity tim.taylor@it-fanatic.de | select Name, FolderId
Zwei Sachen waren hierbei nun auffällig zunächst haben die FolderIDs einen anderen Aufbau als die in der Meldung in Mailstore, allerdings gab es einen Ordner der keinen Namen hatte (rot) und diese ID passte wenigstens im hinteren Teil zu der aus der Meldung im Mailstore.
Eine Überprüfung der Ordner im OWA ergab das es sich um einen namenlosen Kalender handelte. Dieser wurde dadurch erzeugt, das es eine Termineinladung gab die in Form eines ICS-Kalenders beim Benutzer eintraf.
Durch das Bestätigen mit Ja wurde hierbei nicht ein Eintrag im eigenen Kalender erzeugt, sondern gleich ein komplett eigenständiger Kalender. Dieser war natürlich aufgrund des fehlenden Namens im Outlook nicht zu sehen, aber im OWA.
Nach Übernahme des Termins in den eigenen Kalender und löschen des Kalenders ohne Namen lief der Archivierungsjob wieder fehlerfrei.
PS: Den Papierkorb natürlich auch leeren 😉
Posted in Allgemein and tagged .ics, Exchange, Kalender, Mailstorewith comments disabled.
Verwenden der Powershell zum erstellen eines formatierten Auto-Replays bei einer shared-Mailbox
Die Aufgabe bestand darin bei einer shared-Mailbox eine automatische Antwort zu generieren. Bei der Antwort handelte es sich um eine Bestätigung des Rechnungseingangs.
Hier der zu verwendende Text:
„Sehr geehrte Damen und Herren, vielen Dank für Ihre Rechnung.
Bitte sehen Sie davon ab, diese auch in Papierform an uns zu senden.
Vielen Dank für Ihren aktiven Beitrag zum Umweltschutz.“
Um den Text in den Powershell-Befehl einlesen zu können verwenden wir eine einfache Textdatei. Bei der Textdatei ist auf die Kodierung beim speichern zu achten, damit die Umlaute im Text auch richtig dargestellt werden. Ich verwende hierbei Notepad++, da sich hier die Kodierung angeben lässt in diesem Fall UTF-8-BOM.
Für die restliche Formatierung , können wir HTML-Tags verwenden.
Da in unserem Text lediglich Umbrüche vorkommen, lässt sich dies mit einem einfachen <br> an den Satzenden bewerkstelligen.
Nun zu den Befehlen in der Exchange-Powershell:
Zunächst lesen wir den Text in eine Varialbel:
$outMessage = Get-Content „Dateiname.txt“
Danach setzen wir die automatische Antwort mit:
Set-MailboxAutoReplyConfiguration -Identity <Postfach-Alias>
-AutoReplyState Enabled –ExternalMessage $outMessage
-ExternalAudience ‚All‘
Damit ist die Nachricht konfiguriert und wir automatisch an alle externen Sender versendet. Möchte man die automatische Antwort wieder deaktivieren verwendet man folgenden Befehl:
Set-MailboxAutoReplyConfiguration -Identity <Postfach-Alias>
-AutoReplyState Disabled
Ich hoffe dies ist für den ein oder anderen eine nützliche Information.
Link zur Microsoft-Dokumentation:
Set-MailboxAutoReplyConfiguration
Posted in Exchange Server and tagged auto-replay, exchange powershell, oof, powershell, shared-mailboxwith comments disabled.
Das Verhalten beim Löschen und senden von Mails bei shared Postfächern steuern
Verwendet man eine shared-Mailbox fällt einem auf das wenn jemand eine Mail aus diesem Postfach versendet, diese nicht unter den gesendeten Mails des Postfach zu finden sind, sondern nun in dem des Sendenden. Genauso verhält es sich beim Löschen von Mails aus einer shared-Mailbox, die gelöschte Mail landet in der Mailbox desjenigen der sie gelöscht hat. Wenn mehrere Personen mit so einem Postfach arbeiten, wird es schwierig bestimmte Vorgange nachzuverfolgen.
Das zuvor beschriebene Verhalten ist als Standard zu verstehen und erstmal von seitens Microsoft auch so gewollt. Das ganze lässt sich aber über den Exchange selbst und Outlook steuern.
In der Exchange-Konsole lässt sich mit folgenden Befehlen das Verhalten vom senden so steuern, das gesendete Mails sowohl im gesendete Elemente Ordner der shared-Mailbox sowie in der des Sendenden landet.
Befehl für „Senden im Auftrag..“:
Set-Mailbox <Identity> -MessageCopyForSendOnBehalfEnabled $true
Befehl für „Senden als…“:
Set-Mailbox <Identity> -MessageCopyForSentAsEnabled $true
Das Verhalten beim löschen lässt sich dahingehend nur über Oulook selbst steuern, hierzu muss eine entsprechender Registry-Eintrag am System gesetzt werden:
Registry-Wert:
HKCU\SOFTWARE\Microsoft\Office\16.0\Outlook\Options\General
DelegateWastebasketStyle
REG_DWORD
Wert: 0x4 (4)
Hierbei macht es Sinn diesen Wert über Gruppenrichtlinien zu verteilen.
Posted in Exchange Server and tagged Exchange, O365, selden als, senden im auftrag, shared Mailboxwith comments disabled.
Mailstore: Aktivierung des HTTPS-Zugriff auf Exchange führt zu einem EWS Fehler bei Verwendung des FQDN
Mailstore kann bei Installation direkt auf dem Exchange nicht über den FQDN auf das EWS zugreifen. Es kommt zu einem Authentifizierungs-Fehler. Erfolgt der Zugriff über localhost, funktioniert die Authentifizierung reibungslos. Grund hierfür ist die Änderung eines Registry-Wertes durch Updates des Exchange-Servers.
HKLM\SYSTEM\CurrentControlSet\Control\Lsa
DisableLoopbackCheck Dword 1
Durch diesen Eingriff funktioniert die Autodiscover-Funktion direkt am Exchange nicht mehr.
Testen kann man dies mit folgendem Befehl in der Exchange-Konsole:
Test-OutlookWebServices -identity: xxx@mydomain.com –MailboxCredential (Get-Credential)
Die Autoermittlung wird in der Ausgabe der Konsole mit „failure“ angegeben.
Über den folgenden Befehl können wir uns weitere Informationen einblenden unter anderem den Eintrag „realm=“xxx““. Diesen Wert benötigen wir zum beheben des Problems.
Test-OutlookWebServices -identity: xxx@mydomain.com –MailboxCredential (Get-Credential) |
fl
Um das Problem nun zu beheben erstellen wir folgenden Registry-Eintrag:
HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0
BackConnectionHostNames (Wert der mehrteiligen Zeichenfolge) den Wert aus REALM eintragen.
Nach einem Neustart des IIS, sollte die AutoErmittlung lokal am Exchange Server wieder funktionieren.
Ab der Version 13.0.2 von Mailstore wird einem beim anlegen eines Archivierungstask weiterhin die Möglichkeit angeboten SSL-Warnungen zu ignorieren. Allerdings wird dies im LOG nicht mehr als Information sondern als Warnung dokumentiert.
Dies führt bei Sensoren zur Überwachung dazu, das diese den Fehler nun auch melden obwohl die Funktion nicht eingeschränkt ist.
Posted in Exchange Server and tagged EWS, Exchange, FQDN, Mailstorewith comments disabled.
Fehler: RecipientNotFound-PermanentException: Error: Cannot find a recipient that has mailbox GUID „GUID“.
Über den im Titel genannten Fehler bin ich bei einer Migration eines Postfachs zu O365 gestolpert. Man findet hierzu bei Microsoft direkt einen KB-Eintrag, dieser beschäftigt sich aber mit dem „offboarding“, also dem verschieben des Postfachs von O365 zu on-Prem. Die im Beitrag genannten Befehle helfen aber schonmal das Problem weiter einzugrenzen.
Der Befehl Get-Mailbox <Identity> | fl ExchangeGuid in der lokalen Exchange-Console eingegeben zeigt uns die lokale ExchangeGuid an.
Der Befehl Get-MailUser <Identity>| fl ExchangeGuid in der Exchange Online Powershell zeigt uns nach erfolgreicher Verbindung die ExchangeGuid in der Microsoft Cloud an.
Hierbei fällt nun auf das beide Guids identisch sind und sich diese von der Guid aus der Fehlermeldung unterscheiden.
Woher kommt nun diese Guid? Bei dieser handelt es sich um die Guid des „Shared-Postfachs“ das automatisch in der Cloud angelegt wird, sobald das Benutzerkonto dorthin synchronisiert wurde. Dieses Postfach was in der Oberfläche nicht zu sehen ist, dient dem Austausch von Informationen zwischen dem Online- und dem on-Prem-Exchange.
Mithilfe der Exchange Online Powershell lässt sich die Guid sichtbar machen. Der Befehl hierfür lautet Get-MailboxLocation -Identity <SMTP-Adresse> | fl MailboxGuid. Diese ist mit der Guid aus der Fehlermeldung nun auch identisch.
LÖSUNG
Um das Postfach nun erfolgreich zu Migrieren, bin ich wie folgt vorgegangen:
- Entfernen der O365 Lizenz vom Benutzer
- Löschen des Benutzers im Azure-AD über Powershell*
- Entfernen des Benutzers aus dem Papierkorb in Azure-AD**
- Sync mit Azure-AD Connect durchgeführt
- Anlage des Benutzers im Online Portal geprüft
- Lizenz im Office-Portal dem Benutzer wieder zugewiesen
- Neuen Batchmigration Task angelegt und gestartet
- Fertig! (Migration erfolgreich)
WICHTIG: Im Anschluss ist es notwendig am Client des betroffenen Benutzers die Anmeldedaten (SSO) einmal in der Systemsteuerung zu entfernen. Zusätzlich kann es notwendig sein das Mailprofil neu zu erstellen.
*)Remove-MsolUser -UserPrincipalName <Identity>
**)Remove-MsolUser -UserPrincipalName <IDentity>
-RemoveFromRecycleBin
Links zu weiterführenden Informationen:
Exchange Online Powershell
Azure-AD Connect Powershell
Posted in Microsoft O365 and tagged Exchange Migration, Exchange-Online, MAILBOX GUID, O365, RECIPIENTNOTFOUNDPERMANENTEXCEPTIONwith comments disabled.
Active Directory-Standorte und -Dienste
Fragestellung: Wie steuere ich die Anmeldung meiner Clients am Domänencontroller wenn ich mehr als einen Standort habe?
Voraussetzungen: An den beiden Standorten Hamm und Münster befindet sich jeweils ein Domänencontroller der Domäne IT-Fanatic.local. Beide Domänencontroller sind als Globaler Katalogserver konfiguriert. Die Domäencontroller haben sich repliziert und verarbeiten beide Anmeldevorgänge. An den beiden Standorten gibt es die Subnetze 192.168.23.0/24 für Hamm und das Subnetz 192.168.24.0/24 für Münster.
Konfiguration: Mit Hilfe des MMC Snap-Ins Active Directory-Standorte und -Dienste erstellen wir zunächst die beiden Standorte unter Sites. Als nächstes verschieben wir die beiden Server die sich unter Default-First-Site befinden an ihren entsprechenden Standort. Ist dies geschehen können wir unterhalb von Subnets die beiden Subnetze erstellen und sie einem Standort zuweisen. Damit ist die Konfiguration abgeschlossen.
Überprüfung: Um die Funktion zu prüfen sollte das DNS Snap-In geöffnet werden und überprüft werden ob sich die Domänencontroller innerhalb Zone der Domäne z.B. IT-Fanatic.local/_Sites/Hamm mit den entsprechenden Diensten eingetragen haben ( _gc,_ldap,_kerberos). Als nächstes kann man mit folgendem Befehl an jeweils einem Client des Standorts prüfen ob der Client den richtigen Standort mithilfe von DNS ermittelt: nltest /dsgetsite. Als Ausgabe sollte der Standort des Clients erscheinen.
Zusatz-Infos: Gibt es an beiden Standorten mehrere Domänencontroller macht es sind die Replizierung nur über bestimmte Domänencontroller zwischen den Standorten durchzuführen. Hierzu wählt man im Snap-In Active Directory-Standorte und -Dienste unterhalb jedes Standorts einen Domänencontroller aus und konfiguriert ihn für seinen Standort als sogenannten Bridgeheadserver. Die Standortübergreifende Replizierung findet dann über die Bridgeheadserver statt.
Anregungen und Kritik bitte in die Kommentare 🙂
Posted in Active Directory and tagged Active Directory, ADS, Microsoftwith no comments yet.