Widerstand ist zwecklos: Das gilt mittlerweile nicht nur für Exchange-Administratoren. Auch für die Verwaltung von SharePoint oder IIS gilt: Wer die Konsole meidet, bringt sich um die Möglichkeit, alle administrativen Aufgaben durchführen zu können.
Allerdings ist Microsoft bei der Implementierung der PowerShell in Exchange Server seit der Version 2007 nicht unbedingt einem geradlinigen Pfad gefolgt. Nach einem fulminanten Beginn bestand in der Version 2010 eine annähernde Gleichwertigkeit von Exchange Management Shell und Exchange Management Console. Eine Aktion wie das Aktivieren eines Anti-Spam-Agenten auf einem Hub Transport Server ließ auch in der GUI einen entsprechenden Reiter in der Verwaltung erscheinen.
In Exchange Server 2013 ist diese Ebenbürtigkeit nicht mehr vorhanden. Auch die erweiterten Einstellungen der ActiveSync Policies wurden verlagert. Die Berechtigungen sind nun ausschließlich über die Konsole konfigurierbar. Die Möglichkeiten, einzelne Rechte über Checkboxen zu gewähren, gibt es nicht mehr. Selbst Rechte wie die Nutzung des Internet Explorers oder Verwendung der Kamera lassen sich nur noch über Parameter des Cmdlets "Set-ActiveSyncPolicy" setzen.
Im Fokus unseres Workshops stehen die Mailboxberechtigungen. Die PowerShell bietet Ihnen neben einem Skriptinterpreter für PS1-Dateien auch eine Konsole. Auf dieser Befehlsebene verarbeitet die PowerShell Befehlstypen, sogenannte "monards" (Funktion, Alias, Cmdlet). Diese Monards gruppieren sich dabei zu Befehlsfamilien, die wiederum durch gemeinsame "noun" gebildet werden. Einem jedem Noun sind dann Aktionen zugeordnet, die "Verbs".
Betrachten wir das Cmdlet "Get-Mailbox", wird dieses Prinzip augenfällig. Ziel des Befehls ist eine Mailbox, die Aktion ist "hole". Die Mailboxeinstellungen werden durch das Substantiv
...Der komplette Artikel ist nur für Abonnenten des ADMIN Archiv-Abos verfügbar.