Het mailbox type aanpassen in Exchange en Office 365

In Exchange 2003 kenden we eigenlijk maar één type mailbox. Toch worden mailboxen heel verschillend gebruikt, door één persoon of meerdere, om mail of contacten op te slaan of juist om iets te reserveren. Tegenwoordig kennen we een aantal soorten mailboxen, bijvoorbeeld Shared, Room, Equipment of de gewone User mailbox.

In Office 365 heeft een Shared mailbox nog een voordeel, je hoeft hier namelijk geen licentie voor aan te schaffen. Dit heeft ook een aantal beperkingen, zo is deze beperkt tot 10 GB grootte en kun je er niet mee aanmelden, dat betekent dus ook dat je hem niet kunt benaderen met Exchange ActiveSync.

Om die redenen wil je soms een mailbox omzetten van het ene naar het andere type. Dat kan gelukkig eenvoudig met het Set-Mailbox cmdlet. Bijvoorbeeld:

Set-Mailbox GedeeldeMailbox -Type Regular

Hiermee hebben we een mailbox omgezet naar een normale mailbox. Andere geldige waardes voor -Type zijn Room, Equipment en Shared.

Meer informatie:

Exchange 2013 Recipients
Set-Mailbox

Your message wasn't delivered due to a permission or security issue.

Bij het zenden van een mail aan een Distributiegroep (DG) kan het zijn dat je een NDR krijgt met de volgende foutomschrijving:

Your message wasn't delivered due to a permission or security issue. It may have been rejected by a moderator, the address may only accept email from certain senders, or another restriction may be preventing delivery.

Dit overkwam mij vandaag toen ik een testmailtje naar een net aangemaakt DG stuurde van een extern mailadres. De verklaring is simpel, standaard mag er alleen naar een DG gemaild worden door interne gebruikers. Je kunt dit in het EAC zien bij de eigenschappen van de DG onder bezorgingsbeheer:

De omschrijving bij de radio-buttons is heel gebruikersvriendelijk. De technische uitleg is dat we hiermee aangeven of authenticatie vereist is of ook niet-geauthoriseerde gebruikers aan deze groep mogen mailen. Dat blijkt ook uit het PowerShell cmdlet waarmee je dit in kunt stellen:

Set-DistributionGroup werkenbij@imara-ict.nl -RequireSenderAuthenticationEnabled $false

Uiteraard zien we de aangepaste instelling ook terugkomen in EAC:

Het is dus een goed idee om hier direct rekening mee te houden bij het aanmaken van de DG. Als je dat vergeet, zoals ik vandaag dus deed, dan levert je dat ongemak, ontevreden gebruikers en extra werk op.

Exchange 2013 en de pagefile

In mooi Nederlands heet het een wisselbestand. Het is een deel van het werkgeheugen van de server dat weggeschreven wordt in een bestand op schijf. Wanneer de server nu tijdelijk meer werkgeheugen nodig heeft dan er beschikbaar is, dan kan de ruimte in dit bestand gebruikt worden. Maar een goed geconfigureerde server (en applicatie!) heeft de pagefile normaal gesproken helemaal niet nodig.

De aanbeveling voor Exchange 2003 was om dit wisselbestand 1,5 maal de grootte van het werkgeheugen te maken, met een maximum van 4095 MB. Voor Exchange 2007 en hoger is de aanbeveling gelijk aan de grootte van het werkgeheugen + 10 MB. Omdat servers met Exchange tegenwoordig zeer veel werkgeheugen hebben resulteert dit al snel in belachelijk grote bestanden. Daarom is de nieuwe aanbeveling voor Exchange 2013:

Grootte werkgeheugen + 10 MB tot maximaal 32.778 MB (32 GB + 10 MB)

Microsoft durft deze aanbeveling toe doen omdat ze hiermee zelf al langer werken in de eigen datacenters, dat wil zeggen dus met Exchange 2013. Het is de vraag of deze aanbeveling ook voor Exchange 2010 of 2007 gaat gelden, deze vraag heb ik bij Microsoft uitgezet.

Verder nog paar opmerkingen over dit onderwerp. Ten eerste is Exchange 2013 system requirements nog niet aangepast, een formeel statement kun je hier vinden: Ask The Perf Guy: Sizing Guidance Updates For Exchange 2013 SP1.

Verder kan Windows Server bij een BSOD alleen een volledige dump van het werkgeheugen maken als hiervoor een pagefile op het systeemvolume staat van minimaal de grootte van het werkgeheugen + 10 MB. Wanneer jouw server bijvoorbeeld 48 GB werkgeheugen heeft en je pagefile 32.778 MB groot is dan kan de server bij een crash geen volledige dump wegschrijven. Dit heeft tot gevolg dat het lastiger is om de oorzaak van de crash te onderzoeken. Uiteraard is dit argument alleen relevant als je de dumpfile ook daadwerkelijk zou gaan analyseren, maar voor de volledigheid wil ik dit toch even noemen.

Ten slotte, uiteraard stellen we de pagefile in met PowerShell, Hierover schreef ik al eerder: Server 2012: De pagefile configureren met PowerShell