Project Honolulu and Exchange servers

Recently Microsoft announced a new web-based server management console, it’s called Project Honolulu. Looking at the documentation and screenshots this is going to be a huge step forward from the native sever management consoles that we have seen from Server 2008-2016.

A technical preview of Project Honolulu is already available for download: https://aka.ms/HonoluluDownload Project Honolulu can be used to manage servers with Windows Server 2012, 2012 R2 and Server 2016. However, there is a requirement to install PowerShell v5 on those older servers. From the documentation:

Honolulu requires PowerShell features that are not included in Windows Server 2012 and 2012 R2. If you will manage Windows Server 2012 or 2012 R2 with Honolulu, you will need to install Windows Management Framework (WMF) version 5.0 or higher on those servers.

Unfortunately Microsoft does not support installing newer versions of WMF on servers that have Exchange installed. The Exchange Supportability Matrix says the following about the supported versions of WMF on servers running Exchange:

Version of Windows Management Framework built into the release of Windows Server you're installing Exchange on.

This means that installing PowerShell 5 on Server 2012 or Server 2012 R2 is not supported for servers running Exchange, effectively making it impossible to use Project Honolulu to manage Exchange servers. The only exception is Exchange 2016 running on Server 2016 because this OS was released with PowerShell v5 natively and meets the Project Honolulu requirements.

Setup can't continue with the upgrade because the mscorsvw has open files

Bij de upgrade naar Exchange 2013 SP1 kun je tijdens de Readyness Checks tegen de volgende foutmelding aanlopen:

Setup can't continue with the upgrade because the mscorsvw (4112) has open files.

 

Het getal tussen de haakjes, hier 4112, is iedere keer anders. Sterker nog, wanneer je op de retry-knop drukt dan kan dezelfde melding verschijnen maar nu met een ander proces-ID.

De oorzaak hiervan is de .Net Runtime Optimization Service, zo is ook te zien in de Task Manager:

Voor een uitgebreide uitleg verwijs ik je naar dit artikel: Wondering why mscorsvw.exe has high CPU usage? You can speed it up. In het kort komt het er op neer dat deze service belangrijk werk doet om je server sneller te laten werken. Dat neemt niet weg dat hij ons op dit moment in de weg zit omdat we de setup van Exchange niet kunnen vervolgenm. We kunnen rustig afwachten of het proces dwingen om snel af te ronden, dat laatste kunnen we oplossen met het volgende commando:

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\ngen.exe executeQueuedItems

Nu kunnen we de Readiness Checks opnieuw laten uitvoeren en zal deze foutmelding niet meer optreden.

ADFS op een domain controller, goed idee?

Met de opkomst van Office 365 rollen steeds meer organisaties Microsoft Active Directory Federation Services (ADFS) uit in hun omgeving. Voor de meeste mensen gaat het hier om nieuwe techniek die meestal ook nog eens gelijk komt met directory synchronisatie en nog maar de start is van een ingewikkeld migratietraject. Er leven dan ook nogal wat vragen rondom ADFS en één daarvan is of het een goed idee is om ADFS op een domain controller te installeren. In dit artikel wil ik hier uitleg over geven.

Waarom wel?

Het combineren van lichte rollen werd lang als best practice beschouwd, op deze manier werd zo efficiënt mogelijk gebruik gemaakt van de dure hardware en Windows Server licentie. Het installeren van ADFS op een domain controller vermindert dus het aantal servers.

Omdat Microsoft het adviseert voor organisaties met minder dan 1000 gebruikers: “For the federation servers, use two existing Active Directory domain controllers (DCs) and configure them both for the federation server role.” Waarom die grens van 1000 gebruikers, wat gebeurt er als je 1200 gebruikers hebt? Dit getal moet niet gezien worden als een harde norm maar je kunt wel uit het artikel afleiden dat Microsoft deze opstelling adviseert wanneer het moeilijk is om de inzet van dedicated servers te rechtvaardigen.

Domain controllers staan altijd aan en iedere beheerder weet dat deze server belangrijk is voor de werking van de Active Directory omgeving en vrijwel alle services in het netwerk. Als je ADFS ook op deze server zet dan wordt die waarschijnlijk met dezelfde zorg behandeld.

En waarom dan niet?

Tegenwoordig zijn de kosten per Windows server sterk gedaald, door virtualisatie draaien er meerdere servers op een fysieke host en de licentie is al gekoppeld aan de fysieke server. Hoe meer virtuele Windows Servers, hoe lager de kosten per server.

ADFS servers worden dubbel uitgevoerd, net als domain controllers, maar hebben wel load balancing nodig. Wanneer je kiest voor WNLB dan is het doorgaans nodig om een extra netwerkadapter toe te voegen. Dat is iets wat je op een domain controller zeker niet wilt doen.

Of omdat Microsoft het afraadt voor gebruik in productie: “Because ADFS requires the installation of Internet Information Services (IIS), we strongly recommend that you not install any ADFS components on a domain controller in a production environment.” Dit geldt weliswaar voor Server 2003 maar is ook van toepassing op ADFS in Server 2008, 2008 R2 en Server 2012.

Bij gecombineerde rollen gaat het niet alleen om ADFS. In de praktijk zien we op de domain controller nog tal van andere taken, zoals Certificate Authority, (Terminal Server) KMS/Licensing server, Citrix licensing of zelfs Exchange. Bij onderhoud, troubleshooting of in geval van disaster recovery werkt het een stuk makkelijker als een server slechts een taak heeft. Zo kan het wel eens wenselijk zijn om een problematische domain controller geforceerd uit AD te halen en daarna de metadata op te schonen. Probeer dat maar eens als er nog allerlei andere taken op de server draaien.

In de aanbevolen configuratie wordt met ADFS ook de Windows Internal Database geïnstalleerd. Hiermee neemt het aantal te installeren updates toe en dus de algemene beheerlast. Niet alleen de security footprint neemt hiermee toe, maar je vergroot ook het attack surface. Iets wat je zeker niet welkt met de server waarop de complete security databases van je domain is ondergebracht.

Dus?

Mijn advies is om ADFS op minimaal twee dedicated servers te installeren. Minimaal één server dus en extra server voor redundancy, daarboven heb je een ADFS server nodig per 15.000 gebruikers. Gebruik dan naar wens WNLB om de servers te load balancen of beter, gebruikt een echte load balancer die ook het gezond functioneren van de servers in het oog houdt.

En als het echt op een domain controller moet dan heeft ADFS 3.0 uit Windows Server 2012 R2 de voorkeur omdat deze niet meer afhankelijk is van IIS.

Server 2012: De pagefile configureren met PowerShell

De Windows pagefile, er zijn hele boeken geschreven over het nut ervan en de beste manier om deze te configureren. Op een aparte partitie om fragmentatie tegen te gaan, op een partitie die aan de binnenrand van de fysieke schijf ligt omdat doorvoer daar het hoogste is, anderhalf keer het fysieke geheugen, door het systeem beheerd of zelfs helemaal uitgeschakeld.

Tegenwoordig kun je in veel situaties zonder een grote pagefile, tenzij je bij een eventuele crash een volledige geheugendump op schijf wilt hebben om de oorzaak te kunnen onderzoeken. Voor een volledige dump moet de pagefile minimaal gelijk zijn aan de hoeveelheid werkgeheugen + 1 MB en bovendien op het systeemvolume staan. Zo valt te lezen in onder andere: Windows does not save memory dump file after a crash Als dat voor jou niet belangrijk is dan wil je de pagefile misschien kleiner maken, zeker in het tijdperk van machines met een werkgeheugen van 64 GB of zelfs nog meer.

Anno 2013 doen we dit bij voorkeur met PowerShell, want dit is snel (copy, paste), makkelijk te herhalen en te automatiseren. In het boek Windows Server 2012 Hyper-V Installation and Configuration Guide geeft de auteur het volgende voorbeeld om deze vast in te stellen op 10 GB groot.

$Pagefile = Get-WmiObject Win32_ComputerSystem
$Pagefile.AutomaticManagedPagefile = $false
$Pagefile.Put()

$NewPagefile = gwmi -query "select * from Win32_PageFileSetting where name ='C:\\pagefile.sys'"
$NewPagefile.InitialSize = [int]"10240"
$NewPagefile.MaximumSize = [int]"10240"
$NewPagefile.Put()

Het eerste deel van het scriptje slaat het juiste WMI-object op in een variabele waarna we de waarde van AutomaticManagedPagefile op False zetten en vervolgens het aangepaste object weer wegschrijven. Op mijn systeem bleek dat niet te werken:

De oorzaak heeft te maken met UAC, we kunnen dit omzeilen door de –EnableAllPrivileges switch toe te voegen:

$System = Get-WmiObject Win32_ComputerSystem -EnableAllPrivileges
$System.AutomaticManagedPagefile = $False
$System.Put()

Het resultaat is dat de pagefile nu niet meer door Windows beheerd wordt. Nu kunnen we de eigenschappen van de pagefile aanpassen, in dit geval kiezen we dus een vaste grootte van 10 GB:

$CurrentPagefile = Get-WmiObject -query "select * from Win32_PageFileSetting where name ='C:\\pagefile.sys'"
$CurrentPagefile.InitialSize = [int]"10240"
$CurrentPagefile.MaximumSize = [int]"10240"
$CurrentPagefile.Put()

Als je goed kijkt dan zie je dat ik in de twee scriptdelen voor andere variabelenamen gekozen heb dan de auteurs van het boek: $System in plaats van $Pagefile en $CurrentPagefile in plaats van $NewPagefile. Dit is maar cosmetisch, ik had ook kunnen kiezen voor $Appeltaart of $QWERTY, maar het beschrijft wel iets correcter waar we mee werken. In het eerste deel van het script doen we een bewerking op het WMI-object Win32_ComputerSystem en niet op de pagefile. In het tweede deel van het script passen we de eigenschappen aan van de huidige pagefile, niet van de nieuwe pagefile. Vandaar.

Met dank aan forumgebruiker Oldguard die e.e.a. hier samenvatte. In datzelfde topic beschrijft hij ook een alternatieve aanpak waarbij de de bestaande pagefile eerst verwijdert en daarna een nieuwe aanmaakt. Heel interessant om te zien wat je met PowerShell en WMI allemaal kunt.

Exchange 2010 SP3: UCMA 4.0 requires the following missing Windows features: Media Foundation

Als je Exchange 2010 SP3 op Windows Server 2012 wilt installeren begin je met de prerequisits. Als de server ook de Client Access rol gaat hosten dan valt daaronder het installeren van de Unified Communications Managed API 4.0 Runtime. Hierbij kan de volgende foutmelding voorkomen:

Microsoft Unified Communications Managed API 4.0, Runtime requires the following missing Windows features.

• Media Foundation

Deze fout treedt op als je de aanwijzingen op deze pagina gevolgd hebt: Exchange 2010 Prerequisites (Install the Windows Server 2012 operating system prerequisites). Microsoft schrijft voor een server met de drie basisrollen het volgende voor:

Bij deze aanwijzingen ontbreekt Server-Media-Foundation, dat is de Media Foundation component uit bovenstaande foutmelding. Maar wat is een Exchange-server zonder Telnet? Dus ook Telnet-Client moeten we toevoegen aan de opdrachtregel.

En dan nog een paar dingen. Ten eerste worden alle beschikbare PowerShell modules op Windows Server 2012 automatisch geladen als je de PowerShell console opent, dat betekent dat Import-Module ServerManager niet nodig is. O ja, als je Exchange Setup ook AD wilt laten voorbereiden dan heb je ook nog de AD remote managment tools (RSAT-ADDS) nodig. Het kan geen kwaad om deze standaard te installeren. Verder wil je na het uitvoeren van het commando misschien eerst de output op het scherm lezen, dit gaat niet als de server automatisch reboot door de –Restart switch. In de praktijk ziet onze opdrachtregel er dus zo uit:

Add-WindowsFeature NET-Framework-Features,NET-HTTP-Activation,RPC-over-HTTP-proxy,RSAT-Clustering,Web-Mgmt-Console,WAS-Process-Model,Web-Asp-Net,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-Net-Ext,Web-Request-Monitor,Web-Server,Web-Static-Content,Web-Windows-Auth,Web-WMI, RSAT-ADDS, Telnet-Client, Server-Media-Foundation

Succes met het installeren van Exchange 2010 SP3 op Windows Server 2012.

Windows Server 2012 en Exchange: Standard of Datacenter?

Sinds Exchange 2007 moet je voor een Exchange-server goed opletten welke versie van Windows Server je gebruikt. Bepaalde Exchange-features vereisen namelijk Windows Failover Clustering, traditioneel een feature waarvoor je minimaal de Enterprise Edition van Windows Server nog hebt. Bij Windows Server 2012 speelt dit niet meer, Standard en Datacenter Edition beschikken over dezelfde features en de Enterprise Edition bestaat helemaal niet meer.

Dus voor Windows Server 2003 x64, Server 2008 en Server 2008 R2 geldt dat je minimaal Enterprise Edition nodig hebt voor:

• Exchange 2007 SCC en CCR
• Exchange 2010 DAG
• Exchange 2013 DAG

De Standard Edition van deze versies voldoet voor alle andere opstellingen, bijvoorbeeld:

• Exchange 2007 CA, HT, standalone MB en SCR/LCR
• Exchange 2010 CA, HT, standalone MB
• Exchange 2013 CA en standalone MB

Bij Windows Server 2012 zijn zowel Standard als Datacenter Edition geschikt zijn voor alle opstellingen, dus ook voor:

• Exchange 2010 DAG
• Exchange 2013 DAG

Meer informatie over de verschillende edities van Windows Server 2012 vind je hier, maar kijk ook eens bij de System Requirements voor Exchange 2007, 2010 en 2013.

Server 2012 support voor Exchange, van de wal in de sloot?

Enige tijd geleden schreef ik al over de ondersteuning van Exchange voor Windows Server 2012. De reden is dat veel mensen zich afvragen of zij domain controllers met Server 2012 mogen inzetten in combinatie met Exchange 2007 of 2010. Of een nieuwe server met Exchange 2010 installeren op Server 2012? Het antwoord is op dit moment: nee. Waarom? Omdat de Exchange Server Supportability Matrix het zegt.

Het goede nieuws is dat Microsoft de Exchange Server Supportability Matrix inmiddels aangepast heeft, dit met het oog op Exchange 2010 SP3 die zeer binnenkort uit gaat komen. Het slechte nieuws is dat iemand heeft zitten slapen. Een paar dingen die mij opvielen waren deze. Het operating system mag niet anders zijn dan Windows Server 2012 voor Exchange 2010 SP3 en Exchange 2013. Sterker nog, wanneer je Exchange 2010 SP3 of Exchange 2013 gebruiken wilt dan moeten de Domain Controllers voorzien zijn van Server 2012.

Het lijkt er dus op dat men vergeten is om een aantal kruisjes te zetten in de tabel, want voor zover ik weet mag je Exchange 2013 ook installeren op Windows Server 2008 R2 om maar eens iets te noemen. Gelukkig zijn de gegevens bij de Exchange 2013 System Requirements ook aangepast, deze kloppen wel. Hetgeen dan weer niet opgaat voor de Exchange 2010 System Requirements, hier wordt nog met geen woord gerept over Exchange 2010 SP3 of Windows Server 2012.

Gezien de storm van kritiek die het Exchange-team over zich heen kreeg na de, volgens velen, voortijdige release van Exchange 2013 zou je mogen verwachten dat er nu extra zorg wordt besteed aan communicatie en documentatie. Zo is er onlangs een nieuwe versie van de Exchange 2013 documentatie online gezet maar consultants zoeken nog tevergeefs naar sizing en scalability guidelines. Het lijkt er dus op dat Microsoft er de handen vol aan heeft om Exchange 2010 SP3 en misschien wel Exchange 2013 SP1 uit te gaan brengen. We wachten rustig af…

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.

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.

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.

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.

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?

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…

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

Server 2012 Hyper-V gebruiken in VMware Workstation

Windows Server 2012 is de nieuwste versie van Microsofts serverbesturingssysteem. Windows Server 2012 is veel meer dan alleen de nieuwste versie, het is misschien wel de eerste versie sinds Windows 2000 Server die zoveel nieuws brengt dat het niet de vraag is óf je gaat upgraden, maar wanneer. Naar verwachting wordt Windows Server 2012 later dit jaar uitgebracht maar je kunt de Windows Server 2012 Release Candidate (RC) nu al downloaden en uitproberen.

Eén van de gebieden waar veel ontwikkeling zit is Hyper-V en ik kan me voorstellen dat veel mensen de nieuwe mogelijkheden willen verkennen in een lab, bijvoorbeeld in VMware Workstation 8. In dit artikel beschrijf ik op welke manier je Hyper-V kunt gebruiken in een VM op VMware Workstation.

Het probleem

Wanneer je Hyper-V wilt inschakelen in een VM kun je tegen de volgende foutmelding aanlopen:

Install-WindowsFeature : A prerequisite check for the Hyper-V feature failed.
1. Hyper-V cannot be installed: A hypervisor is already running.

De oorzaak is dat we al in een hypervisor werken, namelijk in VMware Workstation.

De oplossing

Hyper-V is een hypervisor die hardware-asisted virtualisatie vereist, dat wil zeggen dat Hyper-V niet kan werken zonder dat het AMD-V of Intel-VT kan gebruiken. Daarom moeten we VMware Workstation vertellen dat het de nodige CPU features beschikbaar maakt voor onze VM. Ten eerste schakelen we Intel VT aan in de eigenschappen van de virtuele cpu:

De tweede aanpassing doen we in het configuratiebestand <naam VM>.vmx, deze vinden we in de werkdirectory waar de bestanden van deze VM staan. Wanneer je die lokatie niet kent kun je deze vinden op het tabblad Options van de VM eigenschappen:

In deze directory openen we het .vmx bestand met een text editor. In dit bestand voegen we de volgende regel toe: hypervisor.cpuid.v0 = "FALSE"

De exacte plek in het bestand maakt niet uit, de regel mag gewoon onderaan toegevoegd worden. Uiteraard slaan we het bestand op na het toevoegen van deze regel.

Hyper-V inschakelen

We kunnen onze VM nu starten en Hyper-V installeren via Server Manager of in PowerShell. Omdat ik op een server werk zonder GUI start ik PowerShell, in tegenstelling tot oudere versies zijn de verschillende modules al geladen dus kan ik direct het Install-WindowsFeature cmdlet gebruiken.

We zien dat we de Hyper-V role nu succesvol hebben ingeschakeld op een virtual machine in VMware Workstation 8.

En Hyper-V in Windows 8 dan?

Het zelfde verhaal geldt ook voor het inschakelen van Hyper-V in een VM met Windows 8, waarvan de Release Preview inmiddels beschikbaar is. Met die aantekening dat er nog een tweede regel benodigd is in het .vmx bestand: mce.enable = "TRUE".

Tot besluit

Ik hoop dat dit artikel je helpt om Hyper-V te gebruiken in een VM op VMware Workstation 8. Meer informatie over Hyper-V in de Windows Server 2012 Release Candidate kun je hier vinden: http://www.microsoft.com/en-us/server-cloud/windows-server/2012-overview.aspx Veel plezier gewenst!

Windows Server “8”: Een blik op de nieuwe dcpromo-wizard

De Beta van Windows Server “8” zit vol met kleine en grotere verrassingen, maar ook een aantal gebieden die sinds Windows 2000 niet wezenlijk veranderd zijn. Als we kijken naar de dcpromo wizard dan lijkt er op het eerste gezicht weinig veranderd, maar als we beter kijken zien we een aantal opvallende zaken.
Na de installatie van de Active Directory Domain Services rol was me niet helemaal duidelijk waar ik dcpromo op moest starten. Dus opende ik een PowerShell scherm en wilde ik de wizard daar starten:

Terug in de Server Manager bleek de link naar deze wizard onder andere te vinden in het nieuwe Notification Area:

Als we de wizard starten dan valt op bijna ieder scherm wel iets op. Laten we een aantal schermen eens wat beter bekijken.

De drie deployment opties staan nu logisch gegroepeerd op het eerste scherm, afhankelijk van welke opties je kiest wordt ook gelijk de aanvullende informatie gevraagd. In het screenshot heb ik de optie gekozen om een nieuwe domein toe te voegen.

De belangrijkste functionele keuzes staan allemaal in het zelfde scherm: DFL en FFL, DSRM password en de opties voor DNS, GC of RODC. In de drop-down list zien we voor DF en FFL de waarde Windows Server 8 Beta staan, deze brengt geen nieuwe  features maar zorgt er wel voor dat we geen oudere domain controllers toe kunnen voegen.

Dit is het laatste scherm voordat de daadwerkelijke installatieprocedure begint. In eerste instantie zien we hier weinig nieuws, we kunnen de gemaakte keuzes nog een keer nalopen en hebben de optie om de instellingen op te slaan in een bestand zodat we de installatie kunnen automatiseren. Wat nieuw is, is dat dit nu een PowerShell script is. Als we op de knop View script klikken dan zien we het volgende:
#
# Windows PowerShell script for AD DS Deployment
#
Import-Module ADDSDeployment
Install-ADDSForest `
-CreateDNSDelegation:$false `
-DatabasePath "C:\Windows\NTDS" `
-DomainMode "Win8" `
-DomainName "windows8.local" `
-DomainNetBIOSName "WINDOWS8" `
-ForestMode "Win8" `
-InstallDNS:$true `
-LogPath "C:\Windows\NTDS" `
-RebootOnCompletion:$true `
-SYSVOLPath "C:\Windows\SYSVOL" `
-Force:$true
Of voor de liefhebbers van one-liners, de zelfde opdracht maar dan achter elkaar:
Import-Module ADDSDeployment
Install-ADDSForest -CreateDNSDelegation:$false -DatabasePath "C:\Windows\NTDS" -DomainMode "Win8" -DomainName "windows8.local" -DomainNetBIOSName "WINDOWS8" -ForestMode "Win8" -InstallDNS:$true -LogPath "C:\Windows\NTDS" -RebootOnCompletion:$true -SYSVOLPath "C:\Windows\SYSVOL" -Force:$true
Als er ooit een mooi moment is om een wizard af te breken en PowerShell te starten, dan is het nu wel. In PowerShell importeren we de ADDSDeployment module en starten we Install-ADDSForest:

Er wordt ons nu alleen nog om het DSRM password gevraagd, die hadden we in onze opdrachtegel ook nog mee kunnen geven met de –SafeModeAdministratorPassword switch.

Na de prerequisit check, die in mijn geval alleen maar warnings (geel) geeft een geen errors (rood), start de daadwerkelijke configuratie. Door de -RebootOnCompletion:$true parameter volgt automatisch een reboot waarna het proces afgerond is. Als we opnieuw inloggen zien we de AD DS verschijnen in de Server Manager.
Voor mij als consultant is de uitgebreide PowerShell ondersteuning voor forests, domains en domain controllers goed nieuws. Dit maakt het nog makkelijker om je werkzaamheden te automatiseren en te documenteren. Verder kunnen we concluderen dat Microsoft blijft investeren in PowerShell, niet alleen als het gaat om nieuwe producten maar ook voor functionaliteit die al lang bestaat.