Office 365: Aliases, Outlook Web App & Outlook 2010
Veel mensen maken gebruik van e-mail aliassen welke geen aparte mailboxen dienen te krijgen maar wel mails moeten verzenden. Een voorbeeld hiervan is bijvoorbeeld een kleinere organisatie waarbij de eigenaar vanaf zowel info@ als vanaf zijn persoonlijke adres wil mailen maar wel alles centraal in één mailbox wil ontvangen. Dit is in Office 365 te configureren middels distributiegroepen en wat configuratie via de powershell. Voor dit voorbeeld gaan we even uit van de situatie van een info@ mailbox en een henk@ voor de eigenaar.
Office 365 panel
Allereerst richten we een normale mailbox in voor henk@domeinnaam.nl. Ik ga er even vanuit dat dit geen probleem vormt verder. Daarna maken we via het panel een distributiegroep aan voor de gewenste alias. In dit geval dus info@domeinnaam.nl. Als identiteit geven we deze groep de naam 'info_domeinnaam_nl' zodat we hem makkelijk kunnen herkennen in de Powershell (mocht dat nog nodig zijn in de toekomst). We maken gebruiker 'henk' eigenaar en lid van deze groep zodat alle mails verzonden aan dit adres naar zijn mailbox toe worden gezonden. Wel een belangrijk punt van aandacht: Vergeet niet aan te vinken dat deze distributiegroep vanaf 'onbekende' adressen gemaild mag worden, standaard staat hij namelijk geconfigureerd als een box voor intern gebruik waarbij alleen bekende mailadressen welkom zijn.
Powershell
Via de powershell gaan we nu gebruiker 'henk' rechten geven om te verzenden namens de distributiegroep. Dit doe je met het volgende commando:
Add-RecipientPermission "info_domeinnaam_nl" -Trustee "henk" -AccessRights SendAs
Outlook Web App & Outlook
De outlook Web App is nu in principe klaar voor de nieuwe situatie. Bij het opstellen van een nieuw bericht kun je bij het kopje 'opties' een vinkje zetten voor het veld 'van weergeven' zodat je kunt kiezen namens wie je wilt mailen. Als je wilt wisselen tussen de verschillende afzenders (in dit geval dus henk@domeinnaam.nl en info@domeinnaam.nl) dan klik je op het 'van' veld en krijg je een lijstje met verschillende afzenderopties. Dubbelklik en bevestigen en je verzend nu namens een andere naam.
Outlook op de PC/Mac is wat lastiger op dit vlak. Normaliter is het niet mogelijk mail te versturen via een mailbox die niet is aangemaakt als mailaccount. Omdat het een distributiegroep betreft is het erg lelijk hem altijd te tonen. Voor nu zijn er echter geen echte opties voor, alleen 'workarrounds'. Enkele mogelijkheden zijn;
- De distributiegroep ook als POP3 account aanmaken naast je normale exchange identiteit in Outlook zodat je nu ook kunt verzenden namens deze mailbox
- Het niet erg vinden dat er 'verzending namens' komt te staan in je mails (dit krijg je als je in Outlook het 'van' veld activeert en een afzender gebruikt die niet als account is aangemaakt)
- Toch ervoor kiezen losse gebruikers ervan te maken
Office 365: Shared mailbox license required
Als Office 365 fans hebben wij de laatste tijd al een hoop gespeeld met de configuratie. Een probleem wat terug blijft komen (en ook erg veel terug te vinden is op het internet) is de vreemde werking van shared mailboxes in combinatie met licenties. De documentatie van Microsoft geeft op meerdere plaatsen zeer helder aan dat een shared mailbox geen licentie nodig heeft. Alleen gebruikers die deze mailbox willen openen moeten een licentie hebben (en mogen geen kiosk-account hebben).
Wat gaat er mis?
Stel je beschikt over een standaard P1 account en je maakt via de powershell een shared mailbox aan. Het lijkt een redelijke tijd goed te gaan maar ergens gaat het bij een hoop gebruikers fout als ze via de OWA proberen de mailbox te benaderen. Je krijgt dan een error ivm. te weinig toegekende licenties. Het rare is sowieso dat hij wel werkt via bijvoorbeeld Outlook 2010 en mails komen er ook gewoon in.
Na gisteren een ruim uur met een zeer vriendelijke medewerker van Microsoft dit probleem te onderzoeken heb ik zojuist als test een gedeelde mailbox opnieuw aangemaakt. Eerder had ik namelijk een beetje soep gemaakt van de mailboxen door ze ook als een user via het Office 365 admin panel aan te maken.
Mogelijke oorzaken
Omdat het via Outlook wel werkt maar via de OWA niet krijg je al vraagtekens. Wie heeft er gelijk en via welke route gaat er gewoon iets mis in het bepalen van licenties. Mijn eerste idee zou zijn dat de OWA een onjuiste manier gebruikt om de licenties te controleren. Waarom anders zouden er zoveel mensen zijn met dit probleem en er geen concrete oplossingen zijn nog. Het lijkt meer een bug dan een echt licentieprobleem te zijn. Daar de Microsoft medewerkers al enkele keren tussen neus en lippen hebben aangegeven dat zij denken dat Office 365 te snel gelanceerd is en nog best wat kinderziektes bevat ga je nog meer in deze richting neigen. Maar tot Microsoft een oplossing heeft wil je natuurlijk nadenken hoe dit probleem mogelijk kan worden omzeild. Enkele theorieen over waarom deze licentieproblemen getriggerd worden zijn:
- P1 licenties hebben geen security groups (zoals in de E licenties wel het geval is)
Als hier de oorzaak zit kan het nog wel eens lastig worden dit ooit werkend te krijgen - Standaard krijgt een shared mailbox normale quotas mee terwijl hij licentievrij maar 5 GB mag zijn
Zou eenvoudig oplosbaar moeten zijn maar denk niet dat dit het probleem geeft. - Standaard wordt er met het maken van een mailbox ook een useraccount gemaakt in het Office365 panel
Wat lastiger verhaal maar zou wel logischer zijn inzake het probleem via OWA. OWA loopt over de "office365 lagen" terwijl je lokale Outlook direct op Exchange rechten niveau werkt
Oplossingen?
Nog niet echt al denk ik ook dat dit meer een applicatie probleem is dan een configuratieprobleem aan de gebruikerskant. Ik zal de komende tijd in iedere geval alles kritisch in de gaten houden en nog wat tests uitvoeren en mocht het probleem zich niet meer voordoen bij specifieke configuraties dan zal ik hier zeker een nieuwe blogpost aan wijden.
Office 365: Retention policy wijzigen
Retention policy is een hele coole feature in Exchange waarmee je e-mails en complete mappen een retentie periode kan geven. Stel je hebt een project wat nu loopt tot eind deze maand dan zou je er bijvoorbeeld voor kunnen kiezen om de documentatie van dit project over 2 jaar na nu automatisch te laten verwijderen.
Soorten retention tags
Standaard krijgt iedere mail de "Default Policy Tag", daarnaast zijn er "Retention Policy Tags" die standaard op mappen zoals je inbox, prullenbank etc van toepassing zijn, als laatste zijn er de "Personal Tags" die een gebruiker zelf kan maken. Via de Powershell kun je van diverse tags de eigenschappen instellen. De onderstaande diagram van de Microsoft site geeft wel een aardig beeld van de verschillende tags en hun rol in het gehele plaatje:
Bron: http://technet.microsoft.com/en-us/library/dd297955.aspx
De tags tweaken
Standaard staat bijvoorbeeld de tag voor de prullenbak op iets van 30 dagen. Superleuk voor je hotmail account maar niet voor een productieomgeving in een bedrijf (of in ons bedrijf in iedere geval). Wil je dit wijzigen dan moet je even inloggen op de powershell. Met het volgende commando haal je de huidige tag informatie op:
get-RetentionPolicyTag "deleted items" | fl name,type,AgelimitForRetention,RetentionAction
Als je deze nu bijvoorbeeld wilt wijzigen in 5 jaar dan kun je dit doen met het volgende commando:
set-RetentionPolicyTag "deleted items" -AgeLimitForRetention 1825
De wijzigingen zullen in de loop van de komende uren bij alle gebruikers zichtbaar worden via de Outlook Web Access en de eventuele lokale Office installatie. Dit komt omdat het hele retention policy tag deel in handen is van de "Managed Folder Assistant". Dit is een mailbox-hulpje die om de zoveel tijd de mailboxen naloopt en alle retention policies naloopt, bijstelt etc.
Op vakantie en nu?
Stel je hebt een policy die redelijk strict is (bijvoorbeeld mails van organisatie X of box Y max 14 dagen bewaren) en je bent een maand op vakantie dan wil je natuurlijk dat deze fanatieke mailboxhulp even rustig blijft en niet mails gaat lopen opruimen voor je. Hierin is gelukkig voorzien al is dit op dit moment niet mogelijk om door de gebruiker zelf in te stellen. Je zult dus als admin zelf via de commandline dit moeten plaatsen.
Set-Mailbox <name> -RetentionHoldEnabled $true
En om hem weer uit te schakelen:
Set-Mailbox <name> -RetentionHoldEnabled $false
Om het nog informatiever voor de gebruiker (en jezelf te houden) kun je ook nog een comment toevoegen aan de retention hold:
Set-Mailbox <name> -RetentionHoldEnabled $true -RetentionComment <comment>
Office 365: Shared mailbox aanmaken via Powershell
Binnen Office 365 zijn twee manieren op gedeelde postvakken aan te maken.
Je maakt er een user-account voor aan met licentie
Deze mailbox heeft, dankzij zijn gebruikersaccount en licentie, dezelfde mogelijkheden als een gewone gebruiker. Denk aan zaken als archief-postvak, 25 GB opslag etc.
Je maakt alleen een gedeelde mailbox aan zonder user en licentie
Deze maak je vanuit de Shell aan en heeft beperkingen omdat er ook niet direct voor betaald wordt. Er is geen gebruiker om mee in te loggen, geen archief-postvak en een max van 5 GB mailboxruimte. Voor de meeste bedrijven zijn deze concessies echter geen probleem en dan heb je in principe geen kosten aan je gedeelde mailbox. Zeker voor kleinere organisaties niet onprettig.
Configuratie shared mailbox via shell
In dit geval ga ik uit van een mailbox zonder licentie maar een mailbox met licentie is niet veel anders. De eerste stap, connectie maken via de powershell, sla ik over. Het stelt eigenlijk niet veel voor. Eerst maken we een nieuwe gedeelde mailbox aan met het commando:
New-Mailbox -Name "info@websitenaam.tld" -Alias info -Shared -primarysmtpaddress "info@websitenaam.tld"
De nieuwe mailbox is nu een feit. Nu willen we bepaalde andere mailboxen rechten geven om deze mailbox te openen, mails te versturen namens etc. Dit doen we met het volgende commando:
Add-MailboxPermission "info" -User "gebruikersalias" -AccessRights FullAccess Add-RecipientPermission "info" -Trustee "gebruikersalias" -AccessRights SendAs
Note: De parameter -user is trouwens een beetje gemeen want dit kan zowel een individuele gebruiker als een groep zijn dus is een beetje misleidende benaming.
Optioneel kun je bijvoorbeeld ook alleen de rechten geven om te verzenden namens door de -accessRights parameter te veranderen. De volledige lijst met functies krijg je met get-help:
get-help Add-MailboxPermission
of
get-help Add-MailboxPermission -examples
bijvoorbeeld.
Als je nu wilt kijken of de rechten op de mailbox naar wens zijn kun je dit doen met het volgende commando:
get-mailboxpermission info
En om te kijken of de recipient rechten naar wens zijn:
get-recipientPermission info
Als je trouwens echt alles over een mailbox in 1x wilt zien kun je ook nog het volgende commando uitvoeren (let op! veel informatie zal tot u komen):
get-mailbox info | fl
Office 365 shell gebruiken
Sinds enige tijd bieden wij onze klanten de mogelijkheid Office 365 te configureren en implementeren. Standaard kun je via de Office 365 portal als administrator diverse basisinstellingen doen zoals licenties beheren, gebruikers aanmaken etc. Tevens krijg je vanuit de portal de mogelijkheid naar Outlook Web Access te gaan op admin niveau om vanuit daar bepaalde Exchange configuratiezaken te regelen. Als je echter meer wilt is de exchange shell de plek om te zijn.
Net als in een "normale" exchange installatie biedt de GUI je wat basics maar kun je het snelst en leukst configureren via de shell. In deze post leg ik in het kort uit hoe je hiermee aan de slag gaat voor jouw Office 365 omgeving. Allereerst: Vergeet Office 365 als je op zoek bent naar documentatie en functionaliteiten en zoek naar exchange 2010. Office 365 is namelijk een visuele verzamelplaats en naam voor exchange online (exchange 2010), sharepoint en office web apps.
Connectie maken met je exchange server
Als je op je lokale windows Powershell start krijg je het volgende scherm:
Voer dan het volgende commando in:
$LiveCred = Get-Credential
Waarna je een prompt krijgt om je inloggegevens in te voeren:
Als je ingelogd bent voer je onderstaand command in:
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell/ -Credential $LiveCred -Authentication Basic -AllowRedirection
He krijgt dan onderstaand scherm te zien:
Als laatste geef je een commando mee om de powershell opdracht te geven alle ingevoerde commando's aan deze sessie te koppelen:
Import-PSSession $Session
De verbinding is nu gelegd en je kunt via de shell je exchange gaan beheren. Type bijvoorbeeld onderstaande code om een overzicht van alle mailboxen te krijgen inclusief wat simpele statistische data:
Get-Mailbox -ResultSize Unlimited | Get-MailboxStatistics | Select DisplayName,StorageLimitStatus,@{name="TotalItemSize (MB)";expression={[math]::Round(($_.TotalItemSize.Split("(")[1].Split(" ")[0].Replace(",","")/1MB),2)}},@{name="TotalDeletedItemSize (MB)";expression={[math]::Round(($_.TotalDeletedItemSize.Split("(")[1].Split(" ")[0].Replace(",","")/1MB),2)}},ItemCount,DeletedItemCount | Sort "TotalItemSize (MB)" -Descending
Mocht je bepaalde "krachtigere" commando's willen gaan uitvoeren dan kan het nodig zijn om de executionPolicy aan te passen. Dit doe je met onderstaand commando:
set-ExecutionPolicy unrestricted