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