Zur Beachtung - Anleitungen

Bitte beachten Sie, daß die bereitgestellten Informationen zum Zeitpunkt der Erstellung im Rahmen von durchgeführten Arbeiten dokumentiert und validiert wurden. In einer geänderten Systemumgebung können für die Schritte Anpassungen erforderlich sein. Dies gilt insbesonders, falls die Informationen Workarounds oder Fehlerbehebungen betreffen. Die Informationen sind entsprechend spezifisch für die Systemumgebung und Version der Systeme zum Zeitpunkt der Arbeiten. Schritte, die sich für uns von selbst erschließen, sind ggf. nicht in den Anleitungen enthalten. Dasselbe gilt auch für konzeptionelle Anleitungen. Diese sind für spezifische Umgebungen und spezifische Erfordernisse erstellt und müssen vor Anwendung überprüft werden, ob sie für die angedachte Umgebung passend sind. Die Verwendung erfolgt auf eigene Gefahr.

Wir raten in jedem Fall dazu, vorab ein Backup in einem Umfang zu erstellen, der die Wiederherstellung der Systeme im Fehlerfall sichert. Dies betrifft bei Active-Directory-integrierten Diensten auch das Active-Directory.

 

(Dieser Artikel wurde vorher auf http://www.tgvconsult.de/blog/4-geschichten-aus-dem-leben/19-exchange-2010-berechtigungen-in-postfachordnern-rekursiv-aendern-mit-im-ordnernamen.html veröffentlicht.)

Der Wechsel zu Exchange 2010 sorgt immer wieder für interessante Überraschungen. Heute stand ich vor dem Problem, in einer Mailbox rekursiv über eine große Ordnerstruktur Berechtigungen setzen zu müssen.

Google spuckte mir dann den Beitrag hier aus, der auch im Prinzip eine Lösung zeigt, in der Praxis war es dann aber nicht so einfach.

Ausgangspunkt ist eine Syntax für die Powershell

ForEach($f in (Get-MailboxFolderStatistics <UserAlias> | Where {$_.FolderPath.Contains("<FolderName>") -eq $True } ) ) {$fname = "<UserAlias>:" + $f.FolderPath.Replace("/","\");Add-MailboxFolderPermission $fname -User <GrantToAlias> -AccessRights <AccessRights> }

So weit, so gut.

Einziges Problem: in der Ordnerstruktur waren eine ganze Reihe Ordner mit Slash ( / ) im Ordnernamen - und da hat es geknallt. Auch das scheint ein allgemeines Problem zu sein, wie diverse Einträge zeigen.

Das Problem ist relativ einfach erklärt: Get-MailboxFolderStatistics liefert für die Slashs in den Verzeichnisnamen ein Fragezeichen zurück. Der Versuch, das mit erneutem Anhängen von ".Replace("?","/")" zu ersetzen, ist wirkungslos. Nun bin ich schon eine Weile im Geschäft und weiß daher, daß man nicht immer das erkennt, was angezeigt wird. Da der Slash in Get-MailboxFolderStatistics als Hierarchietrenner eingesetzt wird (würde auf eine Kompatibilitätssache mit OWA tippen), werden Slashs in Verzeichnisnamen schlichtweg anders zurückgeliefert. Add-MailboxFolderPermission (und auch die Verwandten, z.B. Set-MailboxFolderPermission) hingegen verwenden den Backslash als Hierarchietrenner und erwarten einen Slash im Ordnernamen auch als solchen. Da der Replace für Fragezeichen mit einem Slash in der Rückgabe von Get-MailboxFolderStatistics fehlschlägt, bei einem String, wie z.B. "Test?" als "Test?".Replace("?","!") jedoch funktioniert, bedeutet das, daß das, was als Fragezeichen angezeigt wird, keines ist, sondern etwas anderes.

Die Ausführung von

ForEach($f in (Get-MailboxFolderStatistics <UserAlias> | Where {$_.FolderPath.Contains("<UniqueFolderName>") -eq $True } ) ) {$fname = "<UserAlias>:" + $f.FolderPath.Replace("/","\");[int][char]$fname.SubString(<?-Pos>,1)}

gab 63743 zurück. Das, was als "?" dargestellt wurde, war also gar kein "?", sondern das Zeichen 63743, welches als solches nicht dargestellt werden konnte.

Nach der folgenden Anpassung funktionierte dann alles wie vorgesehen.

ForEach($f in (Get-MailboxFolderStatistics <UserAlias> | Where {$_.FolderPath.Contains("<FolderName>") -eq $True } ) ) {$fname = "<UserAlias>:" + $f.FolderPath.Replace("/","\").Replace([char]63743,"/");Add-MailboxFolderPermission $fname -User <GrantToAlias> -AccessRights <AccessRights> }

In diesem Postfach waren nun nicht weitere Sonderzeichen in Ordnernamen, aber ich würde davon ausgehen, daß man mit der Methode auch Ordner mit diesen vernünftig ersetzen kann.

Weiterführende Links: