Een alias aan een mailbox toevoegen

Door ralpje op zaterdag 18 mei 2013 00:04 - Reacties (1)
Categorieën: Exchange, Office365, Powershell, Views: 2.812

Iets wat je regelmatig doet en wat, zeker binnen Office 365, tot veel geklik leidt: het toevoegen van een alias aan een mailbox.
Omdat ik meeste beheerwerk in Office 365 via PowerShell doe maakte in een PS-Function die eenvoudig aan te roepen is om deze handeling uit te voeren.


PowerShell:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
Function Add-EmailAlias {
    param($Identity, $EmailAlias)

    begin {
        $mb = Get-Mailbox $Identity
        if($mb.EmailAddressPolicyEnabled) {
            Set-Mailbox $Identity -EmailAddressPolicyEnabled $false
            $policy += 1
        }
        $addresses = $mb.EmailAddresses += $EmailAlias
    }

    process {
        Set-Mailbox $Identity -EmailAddresses $addresses
    }

    end {
        if($policy) {Set-Mailbox $Identity -EmailAddressPolicyEnabled $true}
    }
}



Simpelweg de functie aanroepen met als parameter de naam van de mailbox en de gewenste alias is genoeg.
Add-EmailAlias username alias@domein.nl

Om de functie te gebruiken dien je hem aan je PS-Profile toe te voegen. Een overzicht van de verschillende profiles, waar je ze kunt vinden en wat ze doen vind je overal op internet, bijvoorbeeld bij The Scripting Guy.

Exchange en Automapping voor mailboxen

Door ralpje op vrijdag 17 mei 2013 23:04 - Reacties (4)
Categorieën: Exchange, Powershell, Scripting, Windows, Views: 5.216

Ik ben erg blij met de 'automapping' feature die sinds SP2 in Exchange 2010 zit. Voor wie het niet weet: deze functie zorgt ervoor dat als je iemand 'full access' geeft op een mailbox de user ook gelijk deze mailbox in zijn Outlook-client te zien krijgt. Je hoeft dus niet meer de gebruiker instructies te geven hoe hij de mailbox kan openen of zelf handmatig via de accountinstellingen de extra mailbox toe te voegen.
Bij het bedenken van deze functie heeft Microsoft helaas één ding gemist: hij werkt alleen als je een gebruiker rechstreeks rechten geeft op een mailbox en niet als je dit via een Security Group doet. Jammer, want het is natuurlijk best practice om via een groep rechten uit de delen. Het bevordert de overzichtelijkheid en beheersbaarheid enorm en geeft in één oogopslag duidelijkheid over wie welke rechten heeft.
Helaas is die quirck ook in Exchange 2013 nog niet gefixt...En dus is het tijd om iets anders te verzinnen: Powershell tot the rescue!


PowerShell:
1
2
3
4
5
6
7
8
9
$shared = (get-mailbox | where {$_.IsShared -eq $True})
$shared | foreach-object {
    $mbxname = ($_.name)
    $group = "SG-MBX-Access-$mbxname"
    $users = (Get-ADGroupMember -Identity $group | select name)
    $users | foreach-object {
        add-mailboxpermission -identity $mbxname -user ($_.name) -accessrights FullAccess -automapping $true
        }
    }


Simpel maar doeltreffend en eenvoudig via Task Scheduler te plannen.

Het script zoekt elke 'shared' mailbox in de organisatie, bekijkt welke users lid zijn van de bijbehorende groep en geeft deze users rechtsreeks rechten op de shared mailbox, inclusief de 'automapping'-functie.

Op deze manier kun je dus prima nieuwe gebruikers rechten op een mailbox geven, door ze in de bijbehorende Security Group te plaatsen. Als je echter een gebruiker uit de group haalt om hem zijn rechten te ontnemen, heeft dat geen effect. Er zijn verschillende manieren om dat op te lossen, maar ik hanteer graag het KISS-principe: Keep it simpel, stupid.


PowerShell:
1
Get-MailboxPermission $mbxname | where { ($_.IsInherited -eq $False) -and ($_.User -ne 'NT Authority\self') }


Deze regel Powershell geeft een overzicht van alle mensen die nu rechten hebben op de mailbox, met uitzondering van degene waarbij die rechten 'inherited' zijn én de mailboxeigenaar zelf.
Door nu voor het zetten van de rechten deze bestaande rechten te verwijderen, weten we zeker dat de rechten gelijk zijn aan de leden van de groep. In totaal komt het script er dan zo uit te zien:

PowerShell:
1
2
3
4
5
6
7
8
9
10
11
12
13
$shared = (get-mailbox | where {$_.IsShared -eq $True})
$shared | foreach-object {
    $mbxname = ($_.name)
    $group = "SG-MBX-Access-$mbxname"
    $current = (Get-MailboxPermission $mbxname | where { ($_.IsInherited -eq $False) -and ($_.User -ne 'NT Authority\self') })
    $current | foreach-object {
        remove-mailboxpermission -identity $mbxname -user ($_.user) -accessrights FullAccess -confirm:$false
        }
    $users = (Get-ADGroupMember -Identity $group | select name)
    $users | foreach-object {
        add-mailboxpermission -identity $mbxname -user ($_.name) -accessrights FullAccess -automapping $true
        }
    }



Oké, het kan wellicht iets netter en er zit absoluut geen errorhandling in, maar het doet wat het moet doen: rechten op een mailbox zetten aan de hand van de leden van een groep. Via task scheduler plannen en elk uur (of andere naar behoefte in te stellen tijd) laten lopen en je kunt rechten op mailboxen uit (laten) delen via groupmembership en toch de automapping feature gebruiken.

Je zou er voor kunnen kiezen om een dergelijk script te implementeren als functie, zodat je alleen de functie hoeft aan te roepen met de mailbox waar je rechten op wilt zetten als parameter. Een andere opties is het script te herschrijven om een csv-file als input te nemen waarin een lijst met te bewerken mailboxen staat. Die twee opties geven in ieder geval vrijheid in het bepalen welke mailboxen je wel en niet mee wilt nemen, zonder dat het beheersbaarheid al te veel aan tast :)