Simpelste fake hybride Office 365 on premise constructie

Wij werden recent door een klant benaderd met het probleem dat zij eigenlijk een on-premise omgeving wilde combineren met een Office 365 omgeving. Normaliter zijn hiervoor wel wat routes maar deze vereisen aardig wat complexe configuratie en afstemming. Microsoft heeft hier diverse routes en plannen voor (zie ook de Microsoft site hierover) maar dit gaat veel te diep.

Inleiding

Met on-premise bedoeld Microsoft een omgeving die lokaal draait. In de meest ideale situatie is dit een Exchange platform waarmee een naadloze integratie op te zetten is. Hebben we het echter over een shared hosting server dan wordt het een heel ander verhaal. Waarom zou je dit überhaupt willen?

Stel dat je een organisatie hebt met een tiental mailboxen waarvan er maar 1 of 2 in de cloud terecht hoeven te komen (bijvoorbeeld om licentiekosten te sparen of omdat het gewoon geen zin heeft qua implementatie). Je zou dit liefst natuurlijk naast elkaar doen maar hierover is maar weinig te vinden.

De oplossing

Wij kwamen uiteindelijk na wat gestoei met de volgende oplossing;
Er wordt een regulier Office 365 account aangemaakt conform de normale regels behalve dat de mail primair bij de on-premise locatie blijft binnenkomen. Voor de 1 of 2 gewenste boxen zetten we een forward op naar het @onmicrosoftonline.com adres. Hierdoor komt deze mail daar binnen terwijl de rest bij de primaire server blijft binnenkomen. Uiteraard niet de mooiste oplossing en er zitten best een paar haken en ogen aan.

Zo is het niet mogelijk vanuit de boxen naar andere mailboxen intern te mailen omdat deze, logisch ook, door Microsoft gepoogd worden intern te bezorgen wat niet gaat. Daarnaast geeft deze constructie soms wat verwarring qua waar mail vandaan komt en naartoe moet (spamfilters, reply’s etc.). Echter is het de meest platte oplossing en zeker als het om één box gaat wat ons betreft een prima oplossing.

Zo creëer je eigenlijk heel snel en simpel een fake hybride Office 365 on premise oplossing.

Skydrive synchronisatie problemen

Het kan soms voorkomen dat Microsoft Skydrive stopt met synchronisatie. Hij geeft een minimalistische error zonder een specifiek bestand of map als schuldige te benoemen. Het herstarten van de synchronisatie werkt niet en enige optie lijkt het compleet verwijderen van de gesynchroniseerde map om deze opnieuw aan te maken.

Oplosbare errors

Toch zijn er een paar errors welke nog wel oplosbaar zijn. Sowieso loopt hij eruit bij bestandsnamen die onmogelijke karakters bevatten of te lang zijn – komt voort uit de Sharepoint web-structuur die onderhevig is aan andere technische kaders dan een normaal filesysteem. Zie ook de FAQ hierover op de Microsoft site.

Daarnaast kan het soms voorkomen dat hij een error ondervindt bij het uploaden van een map of bestand wat als gevolg heeft dat de cache defect is. Er is dan geen specifieke plek die fouten geeft maar hij is ook niet meer in staat opnieuw de synchronisatie op te zetten.

Kijk in het overzicht wat de laatste succesvolle synchronisatie was en ga naar
C:\Users\[jouwgebruikersnaam]\AppData\Local\Microsoft\Office\15.0\OfficeFileCache

En verwijder hier de file/files die aangemaakt zijn rondom de tijd van de laatste succesvolle synchronisatie. Met een beetje geluk bespaar je hiermee een complete ontkoppeling en herkoppeling van de synchronisatie.

Skydrive Pro error 0x80040208

SkyDrive Pro is een persoonlijke bibliotheek bestemd voor het opslaan en organiseren van documenten. Als integraal onderdeel van Office 365 (SharePoint Server 2013) kun je met SkyDrive Pro werken binnen de parameters van de organisatie, met functies zoals directe toegang tot het adresboek van uw organisatie enzovoorts.

Probleem met synchronisatie

Skydrive Pro loopt in sommige gevallen vast met een synchronisatie probleem waarbij voor alle bestanden een rood kruis komt te staan in Windows Explorer. Kijk je bij het synchronisatie log dan geeft hij de errorcode 0x80040208.

Error 0x80040208

Deze ontstaat als er één of meer bestanden van meer dan 64 tekens in de gesynchroniseerde folders staan. Lastig is deze te vinden al zijn hier wel tools voor te vinden (zie hier een voorbeeld van een Powershell oplossing op Stackoverflow). Mocht je direct al weten welke bestanden het zijn dan ben je er al bijna. Als alles goed gaat kun je de synchronisatie opnieuw opstarten en werkt alles naar behoren. Mocht hij toch problemen blijven geven / helemaal niets veranderen dan volgt het volgende scenario.

Alle cachefiles vernietigen

Beetje een grove methode (je moet hierna de synchronisaties opnieuw aanmaken etc) maar soms de enige oplossing.

  1. Sluit Skydrive Pro
  2. Ga naar \%userprofile%\AppData\Local\Microsoft\Office\15.0\
    en verwijder OfficeFileCache
  3. Ga naar \%userprofile%\AppData\Local\Microsoft\Office\Spw \
    en verwijder de inhoud

Nu even Skydrive Pro opnieuw starten, de synchronisaties opnieuw starten en klaar.

Office 365 domein verwijderen of aanpassen

Als je in Office 365 de primaire domeinnaam wilt wijzigen of in zijn geheel wilt verwijderen gaat dat niet zomaar. De primaire domeinnaam wordt in Office 365 op diverse plaatsen toegepast en is ‘hard’ gekoppeld. Verwijderen kan pas als hij volledig ontkoppeld is.

Redenen om dit te willen?

Stel dat je organisatie een nieuwe naam, en dus ook domeinnaam, krijgt of dat de persoon die de migratie startte een fout heeft gemaakt in de domeinnaam. Een andere reden, en de reden dat wij dit vandaag deden, is dat iemand een P-pakket* heeft maar heeft gekozen voor het laten beheren van de DNS door Microsoft. Wij gebruiken zelf normaliter de E-pakketten* omdat je hierin altijd zelf de DNS kunt beheren. In een P-pakket* kan dit wel maar als je eenmaal voorbij de wizzard bent is dit niet meer aanpasbaar. De makkelijkste weg leek mij het gehele proces terug te draaien en opnieuw te starten met de juiste configuratie. Hiervoor moest het domein wel eerst ontkoppeld worden.

* Met een P-pakket bedoelen we de licenties voor kleine- en middelgrote bedrijven. Lees meer over de verschillende pakketten

De stappen

Voor het in Office 365 verwijderen of aanpassen van een primaire domeinnaam moet je de volgende stappen doorlopen;

  1. Log in als admin van het account
  2. Klik rechts op ‘bedrijfsgegevens’
  3. Scroll naar beneden bij bedrijfsprofiel en verander het default domein naar het standaaard @microsoftonline account
  4. Verwijderen aliassen van e-mailboxen op dit domein (mits van toepassing)
  5. Ontkoppel eventuele licenties die aan het domein hangen (bijv. voor Lync)
  6. Je kunt nu het domein verwijderen

Het kan zijn dat het toch niet lukt de domeinnaam te verwijderen uit de lijst. Controleer even op alle schermen of er toch niet toevallig een gebruiker, licentie of iets aan gekoppeld is. Spijtig genoeg geeft Microsoft je geen goede informatie over de redenen van het niet kunnen verwijderen. Het kan soms even zoeken zijn. Maar met bovenstaande lijst heb je vaak het meeste al gedekt.

Office 365 backups

Naar de cloud overstappen is zo gedaan maar nu? Hoe veilig zijn je bestanden eigenlijk en moet je zelf nog backups maken? Laten we deze vraag even opsplitsen in de twee mee belangrijke zaken die van een backup zouden kunnen worden voorzien:

  • E-mail & agenda
  • Documenten

Wat doet Microsoft al voor mij?

Microsoft zelf draagt zorg voor zijn Office 365 backups van de zaken in de cloud waarvan we mogen veronderstellen dat deze afdoende zijn voor het beschermen van de data die je ze in vertrouwen geeft (o.a. middels redundante opslag etc.). Lees hier meer over hoe Microsoft hier zelf tegenaan kijkt als het gaat om haar verantwoordelijkheden.

Het grootste risico is echter het zelf per ongeluk verwijderen van data;

E-mail & agenda

Standaard beschikt Office 365 over een ‘prullenbak’ waarin je verwijderde items terug te vinden zijn. De termijn dat ze bewaard worden hangt af van je instellingen maar is standaard 14 dagen en kan (hang beetje af van de gekozen licentie) aanzienlijk langer gemaakt worden. Dit dekt in principe het (per ongeluk) verwijderen van e-mail en agenda items.

Optioneel zou je, als je helemaal zeker wilt zijn, zelf handmatig of automatisch backups kunnen maken van je PST bestanden voor het geval van een complete vernietiging van alle bij Microsoft opgeslagen data.

Documenten

Alles wat je in de cloud opslaat (Skydrive pro, sharepoint etc) wordt bij verwijdering wederom via een prullenbak voor je veilig gesteld. Daarnaast biedt Microsoft een soort versie-controle bij bestandstypen die het systeem ondersteund (zoals Word-documenten, PDF-bestanden etc). Dit houdt in dat er van iedere mutatie een kopie bewaard wordt van de vorige versie. Zo kun je terug gaan naar eerdere versies zodat bijvoorbeeld het abusievelijk leegmaken van een document nog op te lossen is.
Wil je echter serieuze backups van de documenten dan zijn de opties wel iets lastiger. Je zou ze lokaal kunnen dupliceren met backup software.

Backup oplossingen

Nu je ziet dat meer een meer organisaties de cloud in stappen zijn de leveranciers van Office 365 backups en gerelateerde diensten hier even snel bij. Het inwisselen van je fysiek aanwezige servers voor cloud opslag is bij veel bedrijven een (niet onterecht) spannende stap. Om deze angst weg te nemen zijn er zeer veel oplossingen waarbij je kunt kiezen uit het online (wederom in een cloud) laten opslaan van je data of lokaal (zoals vroeger ). Bij beide zou je je weer opnieuw moeten afvragen of dit qua veiligheid en privacy opweegt tegen het risico op een complete failure bij Microsoft.

Office 365: Shared calendar (no licence)

Vandaag een leuke vraag gekregen waar ik nog niet direct het antwoord op had. Dit ging om het opzetten van een gedeelde agenda zonder echte ‘gebruiker’ dus bijvoorbeeld een algemene agenda voor een kantoor of iets. Dacht eerst dat ik het moest zoeken in de richting van distribution- of securitygroups maar dit was te diep gedacht. Al snel realiseerde ik me dat dit gewoon eenvoudig te realiseren was met een gedeelde mailbox.

Als eerste maak je via de powershell een gedeelde mailbox aan (in dit geval noemen we hem kantooragenda@bedrijf.nl):


New-Mailbox -Name "kantooragenda@bedrijf.nl" -Alias "kantooragenda" -Shared -primarysmtpaddress "kantooragenda@bedrijf.nl"

Daarna geef je de gewenste gebruikers maximale rechten op deze mailbox. Stel dat de gebruikers met de aliasen ‘henk’ en ‘annie’ toegang moeten krijgen tot deze agenda dan configureer je dit met:


Add-MailboxPermission "kantooragenda" -User "henk" -AccessRights FullAccess
Add-MailboxPermission "kantooragenda" -User "annie" -AccessRights FullAccess

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;

  1. De distributiegroep ook als POP3 account aanmaken naast je normale exchange identiteit in Outlook zodat je nu ook kunt verzenden namens deze mailbox
  2. 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)
  3. 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