Exchange tip: Vergroot het Application log met PowerShell

Het is een best practice om het Application Log op een server met Exchange wat groter te maken. Standaard op een server met Windows Server 2008 of hoger is deze 20 megabyte groot. Wanneer er nu een issue optreedt waarbij een grote hoeveelheid events wordt weggeschreven, dan kan het voorkomen dat de events die informatie geven over de oorzaak van het probleem als overschreven zijn. Bijvoorbeeld als je na het weekend een issue blijkt te hebben wat vrijdagavond al voor het eerst opgetreden is.

Anno 2012/2013 doen we dat uiteraard met PowerShell. Geef in een elevated (Run as administrator) PowerShell window het volgende commando:

Limit-EventLog -LogName Application -MaximumSize 50MB

Mijn tip aan Exchange-beheerders en -specialisten is om deze aanpassing in de standaard procedure voor uitrol van een nieuwe server op te nemen.

Exchange 2010: Unhandled Exception “User setting 'PreferredSite' is not available.”

Beheerders die recent een upgrade van Exchange 2003 naar Exchange 2010 hebben uitgevoerd, of voor langere tijd een omgeving beheren met beide versies naast elkaar, kunnen de volgende melding in grote hoeveelheid aantreffen in het Application Log van de Client Access servers:

Het gaat om Event ID 1 van de source MSExchange Autodiscover. De foutmelding luidt Description: Unhandled Exception "User setting 'PreferredSite' is not available.". Deze melding wil zeggen dat Autodiscover voor een bepaalde gebruiker niet in staat was om de juiste gegevens te bepalen. De oorzaak is dat er een Autodiscover request werd gedaan door een gebruiker waarvan de mailbox nog op Exchange 2003 staat, het is dus logisch dat Autodiscover voor deze gebruikers geen informatie samen kan stellen.

Een fix voor dit issue is opgenomen in Update Rollup 5 (versie 2) voor Exchange 2010 SP2. Deze kun je hier downloaden, een lijst met alle opgeloste issues vind je hier. Overigens bevat Update Rollup 5-v2 ook een security fix wat inhoudt dat hij ook via Microsoft/Windows Update wordt aangeboden.

Belangrijk: Installeer KB2506143 en KB2506146 niet op Exchange 2007/2010

De afgelopen dagen melden verschillende mensen issues met Exchange 2007 en 2010 servers. Na onderzoek blijkt dat de installatie van twee updates de oorzaak hiervan is:

• KB2506143 Description of Windows Management Framework 3.0 for Windows 7 SP1 and Windows Server 2008 R2 SP1
• KB2506146 Description of Windows Management Framework 3.0 for Windows Server 2008 SP2

Deze updates bevatten Windows Management Framework 3.0. WMF is de managementlaag van Windows servers en bestaat uit onder andere WinRM, WMI en PowerShell. Exchange is sterk afhankelijk van dit framework, WMF wordt volop gebruikt om de lokale server te beheren maar ook voor communicatie tussen verschillende Exchange servers zoals DAG members.

Op dit moment ondersteunt Exchange 2007 versie 1.0 en 2.0 van WMF, Exchange 2010 ondersteunt alleen versie 2.0. Wanneer je nu met bovenstaande updates versie 3.0 van deze componenten installeert dan gaan er onherroepelijk problemen optreden, het is bijvoorbeeld niet meer mogelijk om Update Rollups te installeren.

Voor Exchange 2010 betekent dit dat je WMF 3.0 pas kunt installeren nadat Service Pack 3 geïnstalleerd is, deze wordt verwacht in het eerste kwartaal van 2013. Voor Exchange 2007 is het onwaarschijnlijk dat er ondersteuning voor WMF 3.0 gaat komen. Overigens zorgt de installatie van WMF 3.0 ook voor problemen met SharePoint en waarschijnlijk een grote hoeveelheid andere software. Ook hier is het devies dus: niet installeren voor je zeker weet dat het ondersteund wordt.

Voor Exchange 2013 is bovenstaande niet van toepassing, wanneer je Exchange 2013 draait is WMF 3.0 een vereiste namelijk en is deze dus al op je server geïnstalleerd.

Exchange en de taal van NDR’s aanpassen

In Exchange 2007 en 2010 probeert de Hub Transport rol te bepalen in welke taal een non-delivery report (NDR) verstuurt moet worden. Het zelfde geldt trouwens voor de Mailbox rol van Exchange 2013. In bepaalde gevallen geeft dit een ongewenst resultaat en dan is het goed om te weten dat je deze functionaliteit kunt configureren.

Exchange bepaalt de taal

Standaard probeert Exchange een NDR te sturen in de zelfde taal als het bericht waar het om gaat, dit doet Exchange met zowel interne als externe berichten. En voor intern en extern kunnen we dit uitschakelen met de ExternalDsnLanguageDetectionEnabled en InternalDsnLanguageDetectionEnabled parameters van Set-TransportConfig. Uit- en inschakelen doen we door deze op $false of $true te zetten:

Set-TransportConfig –ExternalDsnLanguageDetectionEnabled:$false -InternalDsnLanguageDetectionEnabled:$false

Standaardtaal

Maar dan gebruikt Exchange standaard de taal waarin de server geconfigureerd is, dus de taal van Windows Server. We kunnen deze ook zelf kiezen met de ExternalDsnDefaultLanguage en InternalDsnDefaultLanguage parameters van Set-TransportConfig. Bijvoorbeeld:

Set-TransportConfig -ExternalDsnDefaultLanguage en-us -InternalDsnDefaultLanguage en-us

Nu zal Exchange de NDR in het Engels verzenden als de taal van het oorspronkelijke bericht niet bepaald kan worden, of altijd in het Engels als we Language Detection uitgeschakeld hadden.

Let wel op, deze instellingen hebben alleen effect op NDR’s die door de Hub Transport rol gegenereerd worden en dus niet op NDR’s die door Outlook aangemaakt worden.

Met PowerShell snel Hyper-V VMs uitrollen op Windows 8

Vandaag wilde ik even snel 4 virtuele servers uitrollen in Hyper-V op mijn Windows 8 werkstation. Uiteraard kan dat met PowerShell, in dit artikel een kort verslag hiervan.

Voorbereiding

Eerder heb ik al een VM voorzien van Windows Server 2012, dit moest mijn template worden. Na de basisinrichting van deze server, in mijn geval niet veel meer dan het installeren van een paar updates, heb ik deze met Sysprep voorbereid voor het klonen. Sysprep haalt alle computerspecifieke informatie weg en zorgt er voor dat je gekloonde computer start alsof hij nog niet geconfigureerd is. Meet informatie over Sysprep vind je hier: System Preparation (Sysprep) Technical Reference.

Vervolgens heb ik deze VHD op mijn SSD disk gezet. Voor mijn labservers gebruik ik nu een differencing disk die deze template-disk als basis heeft.

Het script

Om nu een VM te maken hebben we dus twee taken uit te voeren:

• Maak een nieuwe differencing disk
• Maak een VM met de net aangemaakte disk gekoppeld

Voor het samenstellen van mijn script heb ik eerst gekeken welke cmdlets er bestaan binnen de Hyper-V module:

Get-Command -Module Hyper-V

Het resultaat is een lange lijst van 164 cmdlets, waaronder de New-VM en New-VHD cmdlets. Voor meer informatie heb ik de Help-pagina geraadpleegd: Hyper-V Cmdlets in Windows PowerShell, op iedere pagina staat welke parameters de cmdlets ondersteunen. Wat rest is dan een eenvoudig scriptje maken die de twee bovenstaande taken uitvoert en een dit kan herhalen.

Het resultaat:

1..4 | % {

### Construct VM name and VHD path
$VMname = "Lab$_"
$VHDpath = "D:\Hyper-V VHD\$VMname\$VMname.vhdx"

### Create new VHD
New-VHD –ParentPath "C:\VM Templates\_Server 2012\_Server 2012.vhdx" –Path $VHDpath -Differencing

### Create new VM
New-VM -Name $VMname -MemoryStartupBytes 800MB -BootDevice IDE -Path "D:\Hyper-V configs\" -SwitchName "Extern over bedraad" -VHDpath
$VHDpath
}

Om het script uit te voeren moet PowerShell uitgevoerd worden als Administrator. Vervolgens worden de VM’s aangemaakt:

Tot besluit

Natuurlijk is dit script slechts een Proof of Concept: de functionaliteit is beperkt, de namen van directories en de switch staan vast, er zit geen error handling in en ook degelijke logging ontbreekt. Maar waar et om gaat is dat je Hyper-V ook vanuit Windows 8 volledig kunt besturen met PowerShell. Nog een reden waarom ik VMware Workstation niet meer nodig heb.

Microsoft bereidt Office 365 upgrade voor: beheerders aan de slag!

Wanneer ik met klanten over clouddiensten spreek dan benadruk ik eerst graag een aantal kenmerken van cloudcomputing. Vast punt wat aan de orde komt is het feit dat je cloudprovider een deel van de regie over je ICT overneemt. Een duidelijk voorbeeld is dat de cloudprovider op een bepaald moment kan vereisen dat je software op de werkplekken moet voorzien van een modernere versie omdat oude versies niet meer compatible zijn met de clouddienst. Natuurlijk gaat dit niet van de ene op de andere dag, maar organisaties die nu nou Outlook 97 gebruiken moeten iets gaan doen aan hun upgradecyclus.

Op dit moment stuurt Microsoft de volgende e-mail klanten van de bestaande ‘Wave 14’ Office 365 diensten. Hierin worden beheerders opgeroepen een aantal noodzakelijke updates te installeren voor Outlook 2007 en 2010. Voor Outlook 2003 was het officieel al niet meer mogelijk om met Office 365 te verbinden, maar werden connecties met POP3 of IMAP4 nog getolereerd. Deze clients zullen nu echt vervangen moeten worden door Outlook 2007, 2010 of 2013.

Voor deze specifieke klant wordt verwezen naar de volgende artikelen:

• Updates voor Outlook 2010
• Updates voor Outlook 2007
• Upgraden van Outlook 2003

Schokkend? Op zich niet. Voor de Microsoft Office suite is het sowieso verstandig om deze regelmatig te updaten, veel technische, functionele of beveiligingsproblemen worden op die manier opgelost. En Outlook 2003? Daarvan is de ondersteuning al in 2009 afgelopen en inmiddels is de derde opvolger op de markt. Hoog tijd om mee te gaan in de vaart der volkeren.

Windows Server 2012 SMB 3.0 en Exchange databases

SMB 3.0 is een wat technische term voor het nieuwe storage transport protocol in Windows Server 2012. Achter deze technische term zit een forse verbetering in performance en bovendien een groot aantal nieuwe features. Bijvoorbeeld:

• SMB Transparent failover
• SMB Scaleout
• SMB Multichannel
• SMB Direct
• SMB Encryption
• VSS for SMB file shares
• SMB Directory Leasing
• SMB PowerShell

Met SMB 3.0 wordt het mogelijk om ook zeer I/O intensieve toepassingen tegen een fileshare te laten ‘praten’ in plaats van direct naar de disks. Zo is het voor SQL Server 2008 R2 en 2012 toegestaan om de databases op een fileshare te plaatsen:

De voordelen van zo’n opstelling zijn legio, bijvoorbeeld dat je IOPs gewoon over goedkoop ethernet kunnen lopen of dat je een database heel eenvoudig aan een andere server kunt toewijzen. Zo ontstaat vanzelf de vraag of dit ook ondersteund gaat worden voor Exchange. Tot nu toe is het niet supported om de databases op een NAS of fileserver te plaatsen, Exchange vereist namelijk block-level toegang tot de storage, daar mag niet nog een SMB of netwerklaag tussen zitten. En ook met Server 2012 en Exchange 2013 blijft dit het support standpunt, wat kan met SQL gaat dus niet op voor Exchange. De reden is dat veel optimalisaties in Exchange uitgaan van directe toegang tot de disks, voor SMB zouden allerlei routines herschreven moeten worden.

Er is een uitzondering… Wanneer je Exchange in een VM draait op Hyper-V in Server 2012 dan mogen de virtuele harddisk bestanden op een SMB 3.0 share op worden geslagen. Interessant detail is dat Exchange nog steeds block-level toegang krijgt tot de storage, maar dat de virtualisatielaag vervolgens SMB 3.0 gebruikt om de data daadwerkelijk naar disks te schrijven of er van te lezen.

Nu is het de vraag of hier verandering in gaat komen. Mijn ervaring is dat er voor Microsoft een duidelijke driver moet zijn om hier tijd (lees: programmeurs) voor vrij te maken, zo was bijvoorbeeld de aanstaande lancering van Hyper-V reden om het supportstandpunt mbt. virtualisatie te moderniseren. Op dit moment zien we dat de meeste ontwikkelingen in Exchange gedreven worden door de eigen ervaringen in de Office 365 datacenters. Neem bijvoorbeeld de Exchange 2013 architectuur die vooral voordelig is voor zeer grote omgevingen en geleidelijke upgrades makkelijker maakt.

Wat storage betreft richt Microsoft zich momenteel op het plaatsen van meerdere databases op een fysieke disk (zonder RAID) en het bijhouden van meerdere kopieën in een DAG. Voor Office 365 is het scenario met Exchange databases op een fileshare dus niet interessant. Verder ondersteunt Exchange sinds 2010 al een ruime variatie aan storage-oplossingen. Daarom verwacht ik niet dat Microsoft Exchange databases op een SMB 3.0 fileshare op korte termijn zal gaan ondersteunen.

Exchange 2013 remote beheren met PowerShell

Bij de lancering van Exchange 2013 werd vooral veel nadruk gelegd op het nieuwe Exchange Admin Center (EAC). Dit is een webbased beheerconsole die de vervanger is van de MMC-gebaseerde Exchange Management Console (EMC) die we kennen van Exchange 2007 en 2010.

Ervaren beheerders missen in AEC al snel een aantal features die de EMC wel had, maar als sterke punt wordt vaak genoemd dat de console webbased is en je hem dus overal kunt gebruiken. Maar wat als je iets uit wilt voeren wat niet in EAC kan? Dan heb je toch de Exchange Management Shell (EMS) nodig voor volledige PowerShell toegang tot je omgeving. Zou het niet handig zijn als je die ook overal vandaan kunt gebruiken?

Om dit mogelijk te maken moet het volgende geregeld zijn:

• De /PowerShell virtual directory moet gepubliceerd zijn in de reverse proxy, als je deze gebruikt.
• Basic Authentication moet ingeschakeld zijn op de /PowerShell virtual directory.

En tenslotte hebben we een klein script nodig, maar daarover later meer. Het aanpassen van de reverse proxy is eenvoudig, open de publishing rule voor Outlook Anywhere en controleer of het pad /PowerShell gepubliceerd wordt. Vervolgens moeten we Basic Authentication aanschakelen op de PowerShell virtual directory, dit kunnen we mooi in het EAC uitvoeren. Navigeer hiervoor naar servers, virtual directories en kies de eigenschappen van PowerShell (Default Web Site).

In het authentication deel zet je een vinkje voor Basic authentication en klik je op save.

Het configureren van de server is hiermee afgerond. Nu hebben we nog een kort script nodig op onze werkplek, dit script maakt een remote PowerShell sessie met de server en importeert deze in de sessie. Dit script zou er zo uit kunnen zien:

# Functies
Function Vraag-Credentials
{
$Global:Cred = Get-Credential -Credential naam@domain.nl
}

Function Verbind-Exchange
{
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://webmail.domain.nl/powershell/ -Credential $Cred -Authentication Basic -AllowRedirection
Import-PSSession $Session
}

# Doe je ding
Vraag-Credentials
Verbind-Exchange

Sla dit bestand op met de .ps1 extensie nadat je de gebruikersnaam en url aangepast hebt en roep het script aan in een standaard PowerShell console:

Het kan zijn dat je PowerShell eerst moet configureren om een niet-ondertekend script uit te voeren. Na het uitvoeren van het script kun je de Exchange PowerShell cmdlets gebruiken net alsof je direct op je eigen server werkt.

Exchange 2013 op een domain controller: doe maar even niet

Een veel voorkomende vraag: mag ik Exchange 2013 op een domain controller installeren? Het formele antwoord is: ja, mits… In de Exchange 2013 System Requirements schrijft Microsoft voor Exchange 2013 precies hetzelfde als bij Exchange 2007 en 2010:

For security and performance reasons, we recommend that you install Exchange 2013 only on member servers and not on Active Directory directory servers. However, you can't run DCPromo on a computer running Exchange 2013. After Exchange 2013 is installed, changing its role from a member server to a directory server, or vice versa, isn't supported.

Niet aanbevolen, maar wel ondersteund dus. Maar laten we wel zijn, er zijn verschillende situaties waar de installatie van Exchange op een DC niet zo’n hele rare keuze is. Bijvoorbeeld een enkele server op een kleine sublocatie of een om een test uit te voeren in een lab.

Alleen lijkt deze combinatie bij Exchange 2013 voor een aantal nieuwe problemen te zorgen. Met name de volgende twee issues:

• Te verzenden e-mail blijft in de Drafts folder staan, ook al is er een Send Connector aangemaakt met de * Address Space
• Exchange 2013 wil niet installeren, fouten treden op tijdens de installatie van de Transport Service

Voor dat eerste issue heb ik nog geen oplossing gezien, de enige work-around is om Exchange niet op een DC te installeren. Het tweede issue treed vooral op als IPv6 uitgeschakeld is, iets wat op een memberserver geen probleem is.

Op dit moment raad ik de installatie van Exchange 2013 voor productiedoeleinden dan ook af. In een lab zou het moeten werken, maar houd er wel rekening mee dat je bij een mislukte installatie veel opruimwerk moet verrichten voordat je een tweede poging kunt doen.

Exchange 2013 ondersteunt geen Realtime Block Lists

Zoals je wellicht weet is de architectuur van Exchange in versie 2013 grondig op de schop genomen. De Hub Transport rol bestaat niet meer en de functionaliteit van deze rol is verhuisd naar de Client Access en met name de Mailbox rol. In principe maakt die nieuwe architectuur voor dit niet zo veel uit, zeker niet als je beide rollen op één server installeert. Behalve dat het nu niet meer mogelijk is om op die server ook aan Connection Filtering te doen, wat betekent dat je niet meer een Realtime Block List (RBL) als die van Spamhaus kunt gebruiken.

Waar gaat het precies over? De Anti Spam agents zijn normaal gesproken actief op een Edge Transport server, maar wie deze functionaliteit op een Exchange 2007 of 2010 hub Transport server gebruiken wil kan ze gewoon installeren met het install-antispamagents.ps1 script. Van alle agents is dan alleen de Attachment Filtering agent niet beschikbaar, de rest kun je gewoon gebruiken net als een Edge Transport server.

Bij Exchange 2013 ligt dit anders, als we hier de Anti Spam agents installeren op de Mailbox rol, want daar draait de Transport service, hebben we de Attachment Filtering agent en de Connection Filtering agent niet tot onze beschikking. Het ontbreken van die laatste heeft best grote impact, want het filteren op connecties met een RBL houdt in de praktijk zo’n 90% van de spam buiten de deur aangezien deze verzonden wordt door servers die op een RBL staan. Zonder Connection Filtering wordt het dus een stuk moeilijker om effectief spam te filteren.

Natuurlijk verandert dit wanneer je een Edge Transport rol in zet, daar kun je dan nog steeds een RBL instellen om op te filteren. Maar in de praktijk kiezen veel organisaties er voor om geen Edge Transport server in te zetten, zeker niet bij kleine omgevingen. Sterker nog, voor Exchange 2013 is nog niet eens een Edge Transport server!

Helaas betekent dit dat klanten niet alleen voor een antivirusoplossing bij andere leveranciers terecht moeten maar dit ook geldt voor antispam, waar Exchange voorheen hele goede resultaten kon halen zonder dat hier extra servers of producten voor nodig waren. Neem dit in ieder geval goed mee bij het voorbereiden van de overstap naar Exchange 2013.

Exchange 2013 nu beschikbaar voor iedereen

De echte geeks wisten Exchange 2013 al te vinden op TechNet en MSDN en zijn er al volop mee aan de slag, zo draait de mailserver van ondergetekende al enige tijd op de definitieve versie van Exchange 2013. Inmiddels heeft Microsoft Exchange 2013 RTM ook als evaluatieversie beschikbaar gesteld: Download Microsoft Exchange Server 2013. Dit betekent dat hij nu voor iedereen te downloaden is.

Je krijgt de volledige versie van Exchange 2013, die je voor 180 dagen kunt proberen maar ook ‘officieel’ kunt maken door in die 180 dagen je licentiecode in te voeren. Om deze in een lab te installeren heb ik een korte howto geschreven: Hoe installeer ik Exchange 2013? Naar verwachting volgt er later ook een kant-en-klare VHD met een werkende installatie van Exchange 2013, welke je na het downloaden direct gebruiken kunt.

Outlook 2013 is geweldig, maar niet compatible met Exchange 2003

Inmiddels is Office 2013 beschikbaar via verschillende kanalen, onder andere voor TechNet en MSDN subscribers. In de reviews wordt veel gesproken over aanpassingen in het uiterlijk maar als je de nieuwe versie echt gaat gebruiken merk je al snel dat het vol zit met slimme handigheidjes.

Wel is het goed om te weten dat Outlook 2013 geen verbinding kan maken met Exchange 2003. Dat wil zeggen, niet door middel van een MAPI of Outlook Anywhere (RPC over HTTPS) verbinding. Als je echt graag met Outlook 2013 aan de slag wilt maar ook je mailbox op Exchange 2003 wilt benaderen dan zou je nog gebruik kunnen maken van IMAP4. Let wel, je hebt dan veel minder mogelijkheden tot je beschikking dan met een normale verbinding. Maar aangezien nog ongeveer 30% van alle Exchange mailboxen op een Exchange 2003 server staat kan ik me voorstellen dat er toch mensen zijn voor wie dit een oplossing is.

Misschien nog een reden om Exchange 2003 te upgraden naar een moderne versie van Exchange?

How to Enable IMAP Access to Exchange Mailboxes

Exchange 2013 klaar, maar niet voor bestaande klanten?

Groot feest gisteren, het is het Exchange team gelukt om Exchange 2013 klaar te krijgen op de geplande datum: 10.11.12 (volgens de Amerikaanse notatie). In de laatste weken zijn de meeste bugs uit eerdere builds opgelost en werd de lat voor een nieuwe build steeds hoger gelegd. Hoe dichter richting de geplande RTM datum, hoe ernstiger de bug moest zijn om de engineers er nog aan te laten werken. En dan is het build 516.32 geworden die de RTM (release to manufacturer) status gekregen heeft.

Als we kijken naar de cadans van nieuwe releases dan zien we dat Microsoft deze mooi heeft uitgelijnd tussen vrijwel alle client en server producten in de Office familie. Nieuwe versie van de Office suite, Lync, SharePoint en Exchange worden allemaal op het zelfde moment uitgebracht. Maar wat betekent dit nu voor bestaande klanten die Exchange 2013 in willen gaan zetten? Om te beginnen is het product pas later echt beschikbaar, na RTM volgt namelijk GA (general availability). Voor volume licensing klanten is Exchange 2013 vanaf midden november te downloaden en naar verwachting geldt het zelfde voor MSDN en TechNet abonnees. Rond dat moment start Microsoft ook met het upgrade van Office 365 naar de nieuwe 2013 versies. Toch wordt van echte GA gesproken over het eerste kwartaal van 2013. Zou dat misschien met het volgende te maken hebben?

Wanneer je namelijk Exchange 2010 in je omgeving hebt dan is het vereist om eerst SP3 op de Exchange 2010 servers te installeren en deze komt pas in 2013 uit, volgens geruchten misschien in februari. Over coexistence met Exchange 2007 is nog helemaal weinig bekend, anders dan dat het ondersteund zal gaan worden. Vermoedelijk is SP3 vereist maar welke Update Rollup minimaal nodig is voor ondersteuning van coexistence met Exchange 2013 is nog niet bekend gemaakt.

En dan hebben we natuurlijk nog te maken met 3rd parties die software maken voor anti-spam, anti-virus, back-up of mobiele oplossingen (RIM!). Alle grote spelers zijn al betrokken geweest in het E15 TAP programma en hebben alle gelegenheid gehad hun oplossingen klaar te maken voor Exchange 2013. Maar de ervaring leert dat het maanden tot soms zelfs een jaar kan duren voordat zij hun laatste versie uitbrengen.

Tot eerste helft 2013 is het dus nog niet mogelijk om Exchange 2013 te installeren in een bestaande Exchange 2010 organisatie. Voor Exchange 2007 ligt dat misschien anders, maar ook dit is nog niet bekend. Voor wie is Exchange 2013 dan wel te gebruiken? Om te beginnen klanten die starten met een schone Exchange 2013 omgeving om hier naartoe te migreren van legacy producten als GroupWise, Lotus Notes of Zarafa. Ten tweede voor klanten die een resource forest opzetten of een cross-forest migratie naar een greenfield plannen. Voor alle andere klanten is het dus nog even geduld hebben…

De Windows 2012 Server Manager niet automatisch laten opstarten

Bij het inloggen op een Server 2012 machine start de Server Manager automatisch op. Omdat dit niet mijn startpunt is voor werkzaamheden klik ik deze iedere keer weg. Daarom wilde ik het automatisch opstarten van de Server Manager uitschakelen, maar moest echt even zoeken waar dit zit.

Klik rechtsboven op Manage en kies dan Server Manager Properties. Zet dan een vinkje voor de optie Do not start Server Manager automatically at logon.

Office 365 en ADFS op Windows Server 2012

Wanneer je Office 365 in gebruik neemt voor een omgeving van enige omvang dan wil je dat doorgaans doen met Single Sign-On. Hierbij gebeurt de authenticatie tegen Exchange Online, SharePoint Online of Lync niet tegen de Microsoft Online directory maar tegen de eigen interne Active Directory. Het component wat we in de eigen omgeving installeren is Active Directory Federation Services (ADFS), op Windows Server 2008 R2 downloaden we hiervoor ADFS 2.0 die we vervolgens op de server installeren.

Nu steeds meer organisaties beginnen met de uitrol van Windows Server 2012 voor nieuwe servers, krijg ik ook wel eens de vraag of deze ondersteund wordt voor ADFS. Het antwoord hierop is momenteel nog negatief. Hoewel Windows Server 2012 standaard over de ADFS rol beschikt, dit is ADFS 2.1, kan deze nog niet gebruikt worden voor Office 365. De reden hiervoor is dat Office 365 klanten hun ADFS niet zelf in hoeven te richten, dat proces is geautomatiseerd en wordt met de PowerShell module voor Microsoft Online uitgevoerd. En deze is nog niet compatible met ADFS 2.1.

De verwachting is dat Microsoft binnenkort met een aangepaste PowerShell module komt die wel support biedt voor Windows Server 2012, maar er is nog niet bekend wanneer. Meer informatie over het configureren van SSO voor Office 365 vind je hier.

SBS 2003: Mijn schijf loopt vol!

Wie mij al wat langer kent weet misschien dat mijn eerste grote (ICT-gerelateerde) liefde naar de naam Small Business Server 2003 luistert. :-) SBS 2003 was gebaseerd op Windows Server 2003, Exchange 2003, Windows SharePoint Services, ISA en SQL en natuurlijk Active Directory. Eigenlijk alles wat een kleine onderneming aan serversoftware nodig heeft en dan mooi op één server geïnstalleerd. De echte kracht van SBS 2003 zat in integratie, met een paar krachtige wizards kon je alle aspecten van de server configureren.

SBS 2003 was bij uitstek een product wat je moest kennen om het te waarderen. Regel 1: gebruik de wizards! In nieuwsgroepen, op fora, in blogposts en richting collega’s heb ik iedere keer weer gehamerd op nut en noodzaak van de wizards, waarom je die moest gebruiken om je netwerk te configureren, gebruikers aan te maken en om computers aan het domein toe te voegen. Talloze problemen waren in één klap verholpen door de Configure E-mail and Internet Configuration wizard (CEICW) te doorlopen.

Inmiddels is een groot aantal van de SBS 2003 servers al vervangen door een opvolger of omgezet naar de losse componenten van SBS. Latere versies van SBS zijn nooit meer zo succesvol geweest en zijn ook nooit zo geslaagd geweest in de integratie van de componenten als dat dit bij SBS 2003 het geval was. Inmiddels heeft Microsoft aangekondigd dat er geen opvolger meer komt van SBS 2011.

Waarom dan dit artikel, alleen uit nostalgische overwegingen? Ten eerste om het volgende nog eens onder de aandacht te brengen. Als je tijdens de installatie van SBS 2003 niet anders gekozen hebt, staat alle data van je server op de C:-schijf. Het verbaast me hoe vaak ik hier nog vragen over tegenkom, ook vandaag weer eentje. Microsoft heeft een artikel beschikbaar met de stappen die je kunt nemen om zoveel mogelijk data, bijvoorbeeld databases en mailboxen, naar een andere volume te verhuizen. Op deze manier kun je weer ruimte creëren op C:. Het artikel staat hier: Moving Data Folders for Windows Small Business Server 2003.

De tweede reden is om SBS 2003 gebruikers te wijzen op het aflopen van algemene en verlengde support op hun server. Na het aflopen van verlengde support worden er geen inhoudelijke verbeteringen meer uitgebracht maar ook geen oplossingen voor beveiligingsproblemen. En aangezien er regelmatig lekken worden gevonden in verouderde software betekent stilstand hier achteruitgang. Voor SBS 2003 RTM is de ondersteuning al lang afgelopen, daar moest dus al SBS 2003 SP1 op geïnstalleerd worden. Voor SBS 2003 R2 geldt dat de support lifecycles van de individuele componenten van toepassing zijn:

Exchange Server 2003: 8 april 2014
Windows SharePoint Services 2.0: 9 juli 2013
SQL Server 2000: 9 april 2013
Windows Server 2003 SP2: 14 juli 2015

En is dat dan goed nieuws of slecht nieuws? Het kan een mooie gelegenheid zijn om afscheid te nemen van verouderde hardware, misschien voor het eerst gebruik te gaan maken van virtualisatie, heroverwegen of cloud computing een oplossing is of gewoon moderne oplossingen inzetten om je gebruikers 25 GB mailboxen aan te bieden en overal te kunnen laten werken. De tijd heeft namelijk niet stil gestaan in de afgelopen tien jaar.

Hoe Exchange 2013 antimalware filtering uitschakelen?

Onlangs schreef ik over de ingebouwde antimalware filtering van Exchange 2013. Mijn conclusie is dat het ontbreken van essentiële functionaliteit er voor zorgt dat de meeste organisaties ervoor zullen kiezen om een 3rd party oplossing voor virusscanning in te gaan zetten. Maar als de ingebouwde functionaliteit standaard ingeschakeld staat, hoe zetten we die dan uit?

Optie 1: In de Setup.exe wizard

Wanneer je Exchange 2013 op een server installeert met de grafische wizard dan kun je in onderstaand scherm voor Yes kiezen om malware scanning niet in te schakelen op deze server:

Optie 2: Als commandline optie bij Setup.exe

Als je, zoals ik, de installatie start vanaf de commandline dan gebruik je de optie /DisableAMFiltering om het zelfde doel te bereiken:

Optie 3: Na installatie

Mocht je pas na de installatie besluiten om de ingebouwde malware filtering uit te willen schakelen, dan kan dat door een script uit te voeren die je kunt vinden in de \Scripts folder van je Exchange 2013 installatie.

cd $exscripts
.\Disable-Antimalwarescanning.ps1

In de praktijk zal ik zelf standaard de tweede methode kiezen. Voor specialisten is de commandline installatie sowieso de meest praktische optie, je kunt een groot aantal voorkeuren meegeven en deze eenvoudig hergebruiken voor volgende installaties. Maar zoals gezegd, ook na de installatie kun je deze functionaliteit makkelijk uitschakelen.

Kan ik Exchange 2013 installeren op Server Core?

De vraag in de titel is duidelijk, kan of mag ik Exchange 2013 installeren op een server zonder GUI? Dat wordt net als bij vorige versies van Exchange niet ondersteund en is ook niet mogelijk. En als je nu al je servers al hebt klaargezet met Windows Server 2012 in Core mode? Kijk dan hier: Eenvoudig wisselen tussen Server 2012 GUI en Core.

Eenvoudig wisselen tussen Server 2012 GUI en Core

Bij de installatie van Windows Server 2012 kun je kiezen of je de volledige GUI wenst of alleen een Server Core installatie:

Maar wist je dat je de GUI van Server 2012 ook heel eenvoudig kunt toevoegen of zelfs weer verwijderen? Het verschil wordt gemaakt door de volgende twee Windows Features:

• Server-Gui-Mgmt-Infra
• Server-Gui-Shell

Toevallig zijn dit de twee enige feature met de letters ‘gui’ in de naam, dus in de praktijk kunnen we overstappen op Core met:

Get-WindowsFeature *gui* | Remove-WindowsFeature

Net zo makkelijk installeren de we GUI weer met:

Get-WindowsFeature *gui* | Install-WindowsFeature

Wel is een reboot (Restart-Computer) nodig om de installatie of verwijdering af te ronden.

Exchange 2013 installatie: “The following error was generated when "$error.Clear()…”

Tijdens de installatie van de eerste Exchange 2013 server in je organisatie kun je tegen de volgende foutmelding aanlopen:

The following error was generated when "$error.Clear();
install-ExchangeSchema -LdapFileName ($roleInstallPath + "Setup\Data\"+$RoleSchemaPrefix + "schema0.ldf")" was run: "The system cannot find the file specified".

Dit probleem treed op wanneer Exchange setup het schema probeert up te daten. Onder de motorkap wordt hiervoor LDIFDE.exe gebruikt die in dit geval nog niet op het systeem geïnstalleerd was. Dit lossen we op door de AD management tools op de server te installeren:

Install-WindowsFeature RSAT-ADDS

Overigens is bovenstaande fout opgetreden op een machine met Windows Server 2012. Bij Windows Server 2008 R2 ziet hij er uit als volgt:

The Active Directory Schema is not up-to-date and Ldifde.exe is not installed on this computer…

De oplossing is bijna het zelfde, al moeten we op een Server 2008 R2 machine de PowerShell module voor ServerManager eerst even laden:

Import-Module ServerManager
Add-WindowsFeature RSAT-ADDS

Dit staat overigens ook beschreven in de Exchange 2013 Prerequisits: Active Directory Preparation.

Windows Update werkt niet op TMG server: 80072EE2

Wanneer je Forefront TMG op een server geïnstalleerd hebt, kan het zijn dat Windows Update niet meer werkt. Foutmelding 80072EE2 wordt dan gemeld:

De oorzaak is dat Windows Update nu de zojuist geïnstalleerde proxyserver moet gaan gebruiken voor internettoegang. Windows Update gebruikt WinHTTP voor internettoegang en negeert dus eventuele instellingen in Internet Explorer. We kunnen dit oplossen door de proxy in te stellen in WinHTTP, als volgt.

Open een elevated CMD prompt (Run as Administrator) en geef het volgende commando:

netsh winhttp set proxy localhost:8080

Wanneer je nu weer Windows Update uitvoert zal deze gewoon werken.

Server 2012: FSMO rollen verplaatsen met PowerShell

Het verplaatsen van FSMO rollen is al jaren een fluitje van een cent, maar het rondklikken in drie verschillende tools is niet meer van deze tijd. Daarom laat ik zien hoe je dat in Windows Server 2012 met PowerShell kunt doen.

In Server 2012 hoeven we de Active Directory PowerShell module niet meer expliciet te laden, alle modules worden standaard geladen bij het openen van de PowerShell console. Het cmdlet wat we gebruiken is Move-ADDirectoryServerOperationMasterRole. De belangrijkste parameters zijn:

• Identity
• OperationMasterRole

De parameter Identity is voor de server waar de we rol of rollen naartoe willen verhuizen. Met de parameter OperationMasterRole kiezen we welke rollen we willen verplaatsen. Dit kan door de naam op te geven of een nummer, meerdere keuzes gescheiden door een komma. De opties zijn:

• PDCEmulator of 0
• IDMaster of 1
• InfrastructureMaster of 2
• SchemaMaster of 3
• DomainNamingMaster of 4

Een voorbeeld: Move-ADDirectoryServerOperationMasterRole -Identity DC01 -OperationMasterRole 0,1,2,3,4

Met bovenstaande PowerShell one-liner hebben we alle vijf FSMO rollen verplaatst naar een andere domain controller. Makkelijk toch?

Exchange 2010/2013: Verwijder alle mailadressen met een bepaald domein

Dit is een vraag die vaak voorkomt: Hoe verwijder ik bij alle mailboxen de mailadressen in één bepaald SMTP domein? Bijvoorbeeld nadat migratiesoftware voor iedere gebruiker een @target.local of @source.local adres heeft toegevoegd en de migratie al lang klaar is. Of om mailboxen voor te bereiden voor het verplaatsen naar Office 365 in een ‘hybrid’ opstelling. Of omdat een organisatie al langer geleden op een nieuwe domeinnaam is overgestapt.

Wanneer je hier informatie zoekt dan merk je onder andere dat er verschillende manier zijn om dit aan te pakken. Wat het complex maakt is dat alle mailadressen staan opgeslagen in de Exchange-eigenschap EmailAddresses of het AD attribuut proxyAddresses. Dit is een zogenaamde mutli-valued string. Dat betekent dus dat we in PowerShell eerst alle waardes die in deze string staan op een rijtje moeten zetten, alvorens we er één of meerdere kunnen verwijderen.

Dit kunnen we doen met het volgende script:

$mailbox = Get-Mailbox –ResultSize Unlimited
$mailbox | foreach `
    {
    for ($i=$_.EmailAddresses.Count;$i -ge 0; $i--)
        {
        $address = $_.EmailAddresses[$i]
        if ($address.SmtpAddress -like "*@source.local" )
            {
            Write-host("Dit adres wordt verwijderd: " + $address.AddressString.ToString() )
            $_.EmailAddresses.RemoveAt($i)
            }
        }
    $_ | set-mailbox -EmailAddresses $_.EmailAddresses
    }

In de eerste regel worden alle mailboxen in een variabele gestopt. In de daarop volgende lus wordt voor ieder mailadres van de mailbox gekeken of het voldoen aan het filter, in dit geval *@source.local. Zo ja, dan wordt deze verwijderd uit het lijstje met mailadressen. Aan het eind van het script wordt het aangepaste lijstje weer ingesteld op de mailbox.

Wanneer je dit script wilt gebruiken is het raadzaam om eerst op één mailbox te testen of het doet wat je verwacht. Bijvoorbeeld door de eerste regel te veranderen in:

$mailbox = Get-Mailbox TestGebruiker1

Een andere mogelijkheid om bijvoorbeeld je syntax te controleren is het script uitvoeren met de –whatif parameter in de regel waarbij de aanpassingen definitief worden gemaakt:

$_ | set-mailbox -EmailAddresses $_.EmailAddresses -Whatif

Ik denk dat het geen toelichting behoeft dat je in bovenstaand script source.local even moet aanpassen aan het domein waarvan jij alle adressen wilt verwijderen. En uiteraard is deze methode ook bruikbaar voor distributielijsten. Verder werkt dis script zowel met Exchange 2010 als met Exchange 2013.

Originele versie door Lasse Petterson en aanpassingen van anderen.

Spam en malware bij Exchange 2013. Is er leven na FPE?

Update 19-9-2012: Hoofdstuk Deadlines toegevoegd.

Microsoft heeft onlangs aangekondigd om te stoppen met de ontwikkeling van Forefront Protection for Exchange, de bekende multi-engine malwarescanner die voorheen door het leven ging onder de naam Antigen. Als alternatief noemt Microsoft twee oplossingen: enerzijds haar hosted oplossing FOPE (voor de gelegenheid ‘rebranded’ tot Exchange Online Protection) en anderzijds naar de ingebouwde malware scanning van Exchange 2013. Hoogste tijd om op die laatste eens in te zoomen.

Wat is nieuw?

Als we naar Exchange 2013 kijken dan moeten we onderscheid maken tussen antimalware en antispam. Onder malware wordt verstaan virussen en spyware, voor de term antimalware mag je dus ook gerust antivirus lezen. Maar wat krijg je nu eigenlijk precies, en is het een geschikt alternatief voor FPE of 3rd party oplossingen? Laten we eerst eens kijken naar de antispam functionaliteit van Exchange 2013.

Antispam

Als we naar de antispam mogelijkheden van Exchange 2013 kijken dan zijn die grotendeels vergelijkbaar met wat we al kennen uit eerdere versies van Exchange. De verschillende taken worden uitgevoerd door zogenaamde agents die in de transportpijplijn inhaken. Het grootste verschil heeft te maken met de nieuwe architectuur van Exchange 2013, laten we eerst eens even naar de Exchange rollen kijken. Bij vorige versies van Exchange vond spamfiltering plaats op de Edge Transport of de Hub Transport rol. In Exchange 2013 bestaat de Edge Transport rol niet meer en is de functionaliteit van de oude Hub Transport rol verdeeld over de enige twee overgebleven rollen: Client Access en Mailbox.

Op de Client Access server wordt deze functionaliteit verzorgd door de Edge Transport service, op de Mailbox server is dat de Hub Transport service. Als we deze agents installeren, standaard staan ze uitgeschakeld namelijk, dan is dit hoe ze verdeeld worden:

Net als bij vorige versies installeren de we agents met een script wat standaard aanwezig is in de \scripts directory. Op een Client Access server doen we dat als volgt:

cd $exscripts
./Install-FrontEndAntiSpamAgents.ps1
Restart-Service MSExchangeFrontendTransport

De volgende stap is dat we de interne SMTP servers op moeten geven. Denk bijvoorbeeld aan een SMTP gateway die je in de DMZ hebt staan, het IP-adres van deze server wordt dan als ‘veilig’ beschouwd bij het beoordelen van de herkomst van een mailbericht. Hier is nieuw dat de Mailbox server ook geldt als een interne SMTP server die mail aflevert bij de Client Access server. Minimaal voegen we hier dus één interne SMTP server aan toe:

Set-TransportConfig –InternalSMTPServers 10.1.2.3

Op een server met de Mailbox rol installeren we de antispam agents als volgt:

cd $exscripts
./Install-BackEndAntiSpamAgents.ps1
Restart-Service MSExchangeTransport

Op een server waar zowel de Client Access als Mailbox rol geïnstalleerd is kunnen we de agents allemaal in één keer installeren:

cd $exscripts
./Install-AntiSpamAgents.ps1

Ook in dat geval moeten we nog de IP-adressen van interne SMTP servers opgeven. Dit is dan weer minimaal het IP-adres van de server met de Mailbox rol waarop je deze agents aan het installeren bent:

Set-TransportConfig –InternalSMTPServers 10.1.2.3

Het beheren en verder configureren van de antispam-agents is verder ongewijzigd ten opzichte van hoe dit in Exchange 2010 werkt.

Antimalware

Waar we zien dat antispam slechts op details afwijkt van wat er al kennen, is het ingebouwde scannen op virussen en spyware nieuw voor Exchange. En waar de antispam agents standaard niet geïnstalleerd zijn op een Exchange 2013 server, is antimalware filtering standaard ingeschakeld.

Als we eens onder de motorkap kijken dan zien we bij de gebruikte executables namen langs komen als Forefront Information Protection Filtering Server en Forefront Filtering Server. Op zich zou je denken dat we het hier over nieuwe Forefront producten hebben die misschien nog aangekondigd moeten worden, maar aangezien Microsoft heeft aangegeven definitief te stoppen met de ontwikkeling van FPE zal het hier niet om een opvolger gaan.

Update: De gebruikte engine is de Microsoft AV engine, dezelfde die we ook al kennen uit FPE en Microsoft Security Essentials.

Als we kijken naar de functionaliteit die de nieuwe malware filtering biedt dan zijn we snel klaar. We kunnen mailware filtering uitschakelen of weer aanzetten, deze tijdelijk bypassen of de opties voor notificaties aanpassen. Het uitschakelen en weer inschakelen doen we met een script wat standaard op de Exchange 2013 server aanwezig is:

cd $exscripts
.\Disable-Antimalwarescanning.ps1

En weer inschakelen:

cd $exscripts
.\Enable-Antimalwarescanning.ps1

Als we tijdelijk iets willen troubleshooten dan kunnen we malware filtering even omzeilen:

Set-MalwareFilteringServer -BypassFiltering $true

En uiteraard weer ongedaan maken met:

Set-MalwareFilteringServer -BypassFiltering $false

De rest van de beheermogelijkheden is beperkt tot het finetunen van de het updaten van de signatures en het aanpassen van de notificaties en precieze acties welke Exchange moet nemen als een fout item wordt gevonden. Deze laatste kunnen we vinden in het Exchange Administration Center (EAC):

In de Exchange Management Shell kunnen we dit uiteraard ook, de cmdlets hiervoor zijn:

• Get-MalwareFilteringServer
• Get-MalwareFilterPolicy
• Get-MalwareFilterRecoveryItem
• New-MalwareFilterPolicy
• Remove-MalwareFilterPolicy
• Remove-MalwareFilterRecoveryItem
• Resume-MalwareFilterRecoveryItem
• Set-MalwareFilteringServer
• Set-MalwareFilterPolicy

Dat is allemaal leuk en aardig, maar hoe werkt dit in de praktijk? Wat als we Exchange 2013 malwarescanning gebruiken en er per ongeluk een false-positive was? Hier wordt het tricky. We kunnen de filtering alleen inn- of uitscakelen, indien ingeschakeld dan wordt het verdachte attachment altijd verwijderd. Het is niet mogelijk om deze in quarantaine te zetten. Ook is het niet mogelijk om met een whitelist te werken waarop we bijvoorbeeld de naam van een afzender, de naam van een attachment of een attachmenttype zouden kunnen zetten zodat deze nooit gefilterd of verwijderd worden. Microsoft raadt aan om in dat geval het attachment opnieuw te laten verzenden in een ZIP-bestand met wachtwoordbeveiliging.

En als er nou een attachment doorgekomen was wat wel gefilterd had moeten worden? Vrijwel alle leveranciers van dit soort software hebben een laagdrempelige manier om je bestand aan te leveren zodat zij het kunnen analyseren en waar mogelijk hun scanengine of signatures kunnen aanpassen. Microsoft heeft er voor gekozen om hier hun Technical Support kanaal voor in te zetten. Het is op dit moment ook al mogelijk om Forefront issues via dit kanaal aan te melden maar veel klanten vinden de formele afhandeling van deze cases omslachtig. Hoe dit uitwerkt zal in de praktijk moeten blijken.

Tenslotte ontbreekt het aan andere dashboard, logging en report mogelijkheden die je bij 3rd party oplossingen en bij FPE vaak voor ziet komen.

Deadlines

Alles goed en wel, maar wanneer gaat er voor bestaande klanten effectief iets veranderen? Als eerste de producten die je in abonnementsvorm afneemt:

• Forefront Protection 2010 for Exchange Server (FPE)
• Forefront Protection 2010 for SharePoint (FPSP)
• Forefront Security for Office Communications Server (FSOCS)
• Forefront Threat Management Gateway Web Protection Services (TMG WPS)

Deze subscribtions worden ondersteund tot 31 december 2015. Ook voor klanten van wie het abonnement al eerder afloopt geldt deze datum, zo hebben zij meer tijd om een alternatief te zoeken. Updates voor spam- en virusfilters worden uitgebracht tot 1 januari 2016.

Dan de ondersteuning voor ForeFront TMG 2010 Server licenties. De ‘mainstream support’ loopt tot 14 april 2015 waarna het  tot 14 april 2020 in de ‘extended support’ fase is. Hier is overigens niets aan veranderd, dit was al te lezen op de Lifecycle Support pagina’s.

Minstens zo belangrijk is om te weten dat nieuwe licenties tot 30 november 2012 aangeschaft kunnen worden, daarna zijn deze niet meer te bestellen. Wanneer er dus een project in de pijplijn zit waar deze producten deel van uitmaken, is het aan te bevelen om de software alvast aan te schaffen.

Conclusie

Exchange 2013 beschikt over ingebouwde antispam en antimalware functionaliteit, die laatste is nieuw. Waar Exchange met antispam een goede reputatie heeft schat ik in dat de functionaliteit van antimalware voor veel organisaties onvoldoende blijkt. Met name het feit dat false-positives niet te voorkomen zijn, anders dan een met een wachtwoord beveiligd ZIP-bestand, zal veel voor veel organisaties onacceptabel zijn.

Zelf zal ik met mijn klanten blijven kijken naar een geschikte enterprise-oplosing voor het scannen op virussen. Daarbij zal Exchange Online Protection zeker meegenomen worden.

Update: Support voor Exchange 2010 op Windows Server 2012

Nu Windows Server 2012 beschikbaar is en in een aantal bedrijven al wordt uitgerold, doemt de vraag op in hoeverre Exchange 2010 al ondersteuning biedt voor dit operating system. In dit artikel beschrijf ik de stand van zaken zoals die begin september 2012 is. Wanneer ik hier Exchange 2010 schrijf dan gaat het over RTM, SP1 en SP2.

Operating system

Servers met Exchange 2010 moeten voorzien zijn van één van de volgende operating systems:

• Windows Server 2008 SP1
• Windows Server 2008 R2 of R2 SP1

Het installeren van Exchange 2010 op Windows Server 2012 is dus niet ondersteund.

Domain controllers

Domain controllers waarmee Exchange 2010 mee communiceert moeten voorzien zijn van het volgende besturingssysteem:

• Windows Server 2003 SP1 of SP2
• Windows Server 2008 RTM, SP1 of SP2
• Windows Server 2008 R2 of R2 SP1

Domain controllers met Windows Server 2012 worden dus niet ondersteund.

Domain en forest functional levels

In een Active Directory forest met Exchange 2010 worden de volgende Domain en Forest Functional Levels ondersteund:

• Windows Server 2003
• Windows Server 2008
• Windows Server 2008 R2

Uit het feit dat domain controllers met Windows Server 2012 niet ondersteund worden volgt dus ook dat dit geen ondersteund Forest of Domain Functional Level is.

Conclusie

Op dit moment is Windows Server 2012 dus niet geschikt voor Exchange 2010 servers en kan het ook niet gebruikt worden voor domain controllers in een Exchange 2010 omgeving. Mijn verwachting is dat Microsoft later dit jaar SP3 uitbrengt voor Exchange 2010. Dit service pack zal dan niet alleen coexistence met Exchange 2013 gaan bieden, maar ik verwacht dat daar tevens ondersteuning voor Windows Server 2012 aan toegevoegd zal worden.

Update 26 september 2012:

Inmiddels heeft Microsoft aangekondigd dat SP3 voor Exchange 2010 in de eerste 6 maanden van 2013 zal verschijnen, dit service pack maakt het inderdaad mogelijk om Exchange 2010 op Windows Server 2012 te installeren. Nog even geduld dus…

Exchange 2003 kan niet verwijderd worden: The component "Microsoft Exchange…" cannot be assigned the action "Remove" because

Wanneer je Exchange 2003 van een server wilt verwijderen moet je onder andere alle mailboxen op deze server verwijderen. Wanneer je dan Exchange wilt de-installeren kan de volgende foutmelding verschijnen:

The component "Microsoft Exchange Messaging and Collaboration Services" cannot be assigned the action "Remove" because:
- One or more users currently use a mailbox store on this server. These users must be moved to a mailbox store on a different server or be mail disabled before uninstalling this server.

Een mogelijke oorzaak is dat er toch nog AD user accounts zijn die de naam van deze server ingevuld hebben bij het attribuut msExchHomeServer. Een makkelijke manier om dit uit te zoeken is door een zoekopdracht te geven in Active Directory Users and Computers. Dat doen we als volgt:

• Rechter muisknop op het domein en klik Find.
• Tabblad Advanced
• Kies uit Field: User, Exchange Home Server
• Kies voor Condition: Ends with
• Kies voor Value: de NetBIOS naam van de betreffende server
• Klik Add

Onze zoekopdracht ziet er dan bijvoorbeeld zo uit:

Wanneer we nu op Find Now klikken krijgen we een overzicht van de gebruikers waarvan het msExchHomeServer nog de bewuste servernaam bevat. Een eenvoudige manier om de Exchange attributen van deze gebruikers leeg te maken is het rechstklikken op het account, dan te kiezen voor Exchange Tasks. In het volgende scherm kiezen we voor Remove Exchange Attributes:

Let op, dit verwijdert alle Exchange eigenschappen van het account. Nu kunnen we Exchange opnieuw proberen te de-installeren, de foutmelding treedt nu niet meer op waarna het verwijderen van Exchange 2003 gewoon uitgevoerd kan worden.

In dit artikeltje heb ik een mogelijke oplossing beschreven voor dit issue. Andere opties zijn natuurlijk het verwijderen van de gevonden accounts, als je deze niet meer nodig hebt, of het leegmaken van het betreffende attribuut met ADSIedit.

Hoe installeer ik Exchange 2013?

Exchange 2013 is de nieuwste versie van Microsofts oplossing voor e-mail, contactpersonen en agenda’s. Net als de voorgaande versies is ook Exchange 2013 een echte ‘enterprise’ oplossing, bedoeld om een stabiele en hoog beschikbare oplossing te bieden voor kleine of grote organisaties. Maar soms willen we het product gewoon zelf eens installeren in een lab, bijvoorbeeld om wat te kunnen verkennen of om een test uit te voeren.
In dit artikel beschrijf ik het installeren van Exchange 2013 op Windows Server 2012. Exchange 2013 is op dit moment alleen beschikbaar als Preview, als er na het uitkomen van de definitieve versie aanpassingen zijn dan zal ik deze doorvoeren in dit artikel.

Wat hebben we nodig?

We gaan Exchange 2013 installeren op een enkelvoudige server, zonder hoge beschikbaarheid of scheiding van rollen. Daarvoor hebben we het volgende nodig:

• Windows Server 2012. De Standard Edition is voldoende, ook wanneer er gebruik gaat worden gemaakt van High Availablity features. Sinds Windows Server 2012 zit er geen functioneel verschil meer tussen de Standard en Enterprise edities meer.
• Exchange Server 2013 Preview
• Hardware met 64-bit ondersteuning en circa 8 GB werkgeheugen of een vergelijkbare virtual machine. Zelf gebruik ik VMware Workstation 8 voor dit doel.

In dit artikel beschrijf ik de installatie van Exchange 2013 op een Active Directory domain controller. Microsoft ondersteunt deze opstelling maar beveelt het voor normaal gebruik niet aan. Wanneer je Exchange 2013 op een domain controller geïnstalleerd hebt kun je de domain controller rol (dcpromo) niet meer verwijderen, andersom kun je een server waar Exchange 2013 al op staat ook geen domain controller meer maken.

Windows Server 2012 installeren

Omdat het hier om een testopstelling gaat maakt het niet zo veel uit welke hardware we gebruiken. Voor het maken van dit artikel gebruik ik de volgende VM:

• 2 CPU cores
• 8 GB werkgeheugen
• 1 disk (C:) van 40 GB

De VM is geplaatst op een 500 GB 2,5” SATA disk in een HP EliteBook 8560w notebook, het operating system van deze laptop staat op een aparte SSD disk. Deze configuratie levert een prima werkbare testserver met een heel acceptabele performance.
Het installeren van Windows Server 2012 is eenvoudig, let er alleen even op dat we voor de configuratie in dit artikel een GUI gebruiken:

Na het inloggen beginnen we met het configureren van de netwerkadapter en het aanpassen van de servernaam. Ik heb gekozen voor een vast IP-adres en de naam Exchange2013. Dit doen we door een PowerShell console te openen, gevolgd door de volgende commando’s:
New-NetIPAddress -IPAddress 192.168.2.140 -InterfaceAlias "Ethernet" -DefaultGateway 192.168.2.1 -AddressFamily IPv4 -PrefixLength 24
Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses 192.168.2.140
Rename-Computer exchange2013
Restart-Computer

Server Domain Controller maken

Onze server is nu klaar om in te zetten als Active Directory Domain Controller. Daarvoor moeten we eerst de juiste Windows feature installeren. Vervolgens gebruiken we het Install-ADDSForest cmdlet om een nieuw domein aan te maken en deze server tot DC te promoveren. Meer informatie over deze procedure vind je in een eerder artikel.
Install-WindowsFeature AD-Domain-Services
Install-ADDSForest -CreateDnsDelegation:$false -DatabasePath "C:\Windows\NTDS" -DomainMode "Win2012" -DomainName "exchange.local" -DomainNetbiosName "EXCHANGE" -ForestMode "Win2012" -InstallDns:$true -LogPath "C:\Windows\NTDS" -NoRebootOnCompletion:$false -SysvolPath "C:\Windows\SYSVOL" -Force:$true

Voorbereiden voor Exchange 2013

Voordat we starten met de voorbereiding van de installatie van Exchange 2013 even iets over rollen. Bij Exchange 2007 en 2010 hadden we vijf serverrollen: Edge Transport, hub Transport, Client Access, Mailbox en Unified Messaging. Bij Exchange 2013 zijn het er nog maar twee: Client Access en Mailbox. De functionaliteit is nu verdeelt over deze twee rollen, alleen de functionaliteit die de Edge Transport rol bood is in zijn geheel komen te vervallen. Voor onze labserver combineren we de Client Access en de Mailbox rol op één server.
We starten met het installeren van de Windows componenten, voor een server met de Client Access en de Mailbox rol zijn dat:
Install-WindowsFeature AS-HTTP-Activation, Desktop-Experience, NET-Framework-45-Features, RPC-over-HTTP-proxy, RSAT-Clustering, Web-Mgmt-Console, WAS-Process-Model, Web-Asp-Net45, Web-Basic-Auth, Web-Client-Auth, Web-Digest-Auth, Web-Dir-Browsing, Web-Dyn-Compression, Web-Http-Errors, Web-Http-Logging, Web-Http-Redirect, Web-Http-Tracing, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Lgcy-Mgmt-Console, Web-Metabase, Web-Mgmt-Console, Web-Mgmt-Service, Web-Net-Ext45, Web-Request-Monitor, Web-Server, Web-Stat-Compression, Web-Static-Content, Web-Windows-Auth, Web-WMI, Windows-Identity-Foundation, Telnet-Client
Restart-Computer
De Telnet client is strikt genomen geen vereiste maar ik raad toch aan om deze gelijk te installeren. Telnet is één van de meest gebruikte tools om een Exchange server te troubleshooten, zowel vanaf een remote werkplek als op de server zelf. De Restart-Computer is nodig om de installatie van de componenten definitief te maken.
We zetten de zojuist geïnstalleerde Net.Tcp Port Sharing Service op Automatic met de volgende commando:
Set-Service NetTcpPortSharing -StartupType Automatic
Vervolgens installeren we onderstaande software in deze volgorde:

1. Microsoft Unified Communications Managed API 4.0, Core Runtime 64-bit
2. Microsoft Office 2010 Filter Pack 64 bit
3. Microsoft Office 2010 Filter Pack SP1 64 bit

Voordat je dit doet is het misschien handig om Internet Explorer Enhanced Security Configuratie voor beheerders uit te schakelen:
rundll32.exe C:\Windows\system32\iesetup.dll,IEShowHardeningDialog
Tenslotte verwijderen we Microsoft Visual C++ 11 Beta Redistributable (x64) van de server. Dit doen we gewoon via Control Panel, Uninstall a program:

Installatie Exchange 2013

Net als bij vorige versies kunnen we de installatie van Exchange 2013 starten met een wizard of van de commandline, ik geef de voorkeur aan die laatste optie. In vorige versies van Exchange deden we dit met Setup.com, nu is dat Setup.exe geworden. Je vind Setup.exe in de hoofdfolder waar je het bestand Exchange-x64.exe hebt uitgepakt.
We starten de daadwerkelijke installatie met het volgende commando:
./Setup.exe /Mode:Install /Roles:ca,mb,mt /IAcceptExchangeServerLicenseTerms /OrganizationName:MijnOrg /CustomerFeedbackEnabled:True /ExternalCASServerDomain:webmail.office365lab.com /EnableErrorReporting

Exchange Setup start nu met het kopiëren van bestanden, gevolgd door de prerequisite checks. Als aan alle voorwaarden is voldaan wordt Active Directory aangepast en Exchange 2013 op onze server geïnstalleerd. Wanneer dit proces klaar is, wat best een uurtje kan duren, is een reboot nodig. Vervolgens zien we twee knoppen extra verschijnen in het Start scherm:

De Exchange Management Console maakt geen deel meer uit van Exchange 2013, deze is vervangen door de Exchange Administration Center. Dit is een webinterface die tevens het Exchange Control Panel vervangt. Als we de Exchange Management Shell starten kunnen we met Get-ExchangeServer controleren of de rollen op de server aanwezig zijn:

Tot besluit

Voor beheerders met ervaring met de vorige twee versies van Exchange is er aan het installatieproces niet veel veranderd. Het aantal rollen is teruggebracht tot de Client Access en Mailbox rol, we moeten iets meer software installeren en het maakt bij Server 2012 niet meer uit of we Standard of Datacenter editie gebruiken. Is er dan niets nieuws onder de zon? Wel degelijk, Exchange 2013 zit vol met verbeteringen en nieuwe functionaliteit. Browse maar eens naar Outlook Web App (https://exchange2013/owa/) of het nieuwe Exchange Administration Center (https://exchange2013/ecp/).
Meer informatie over Exchange 2013 vind je onder andere hier:

• Exchange Technical Library
• Exchange Team Blog

Exchange 2010: “The certificate status could not be determined because the revocation check failed”

Na het installeren van een certificaat kan in de Exchange Management Console de volgende melding verschijnen in de Status-kolom: “The certificate status could not be determined because the revocation check failed”.

Om te bepalen of een certificaat geschikt is om aan Exchange-services te koppelen doet de server een aantal controles. Bijvoorbeeld of de private key geïnstalleerd is en of het certificaat niet ingetrokken is. De lijst waarop ingetrokken certificaten staan wordt bijgehouden door de instantie die het certificaat uitgegeven heeft, deze lijst is de Certificate Revocation List en de locatie waar deze te vinden is staat in het certificaat:

In dit geval is het dus niet zo dat Exchange ontdekt dat het certificaat ingetrokken is, maar dat het uitvoeren van deze controle mislukt is. Een vaak voorkomende oorzaak is dat de server achter een proxy zit en het operating system niet geconfigureerd is om deze te gebruiken. Exchange gebruikt voor HTTP en HTTPS connecties niet de instellingen in je browser maar WinHTTP. Wanneer de server een proxy moet gebruiken dan stellen we dat in met het netsh commando. Om de huidige instellingen te tonen gebruiken we:

netsh winhttp show proxy

Om een proxy-server in te stellen: (OnzeProxyServer is een placeholder voor de NetBIOS of FQDN naam of het IP-adres van de proxyserver)

netsh winhttp set proxy proxy-server="http=OnzeProxyServer:8080"

Met het volgende commando geven we een by-pass list mee:

netsh winhttp set proxy proxy-server="http=OnzeProxyServer:8080" bypass-list="*.domain.local"

(in bovenstaand screenshot is een deel van de servernaam verborgen in verband met privacy)

Na het doorvoeren van deze aanpassing is een refresh van de EMC voldoende, Exchange kan de controle nu uitvoeren en meldt dat het certificaat in orde is:

Wanneer dit niet direct te zien is kan het soms nodig zijn om de caches eerst te legen:

certutil -urlcache ocsp delete
certutil -urlcache crl delete

Na een reboot en opnieuw starten van EMC moet nu het goede resultaat te zien zijn.