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!

Exchange 2010 en statische poorten voor load balancing

Er wordt wel eens gezegd dat je voor Exchange 2003 een storage specialist moest zijn, voor Exchange 2007 een specialist in certificaten en voor Exchange 2010 een specialist in load balancing. En eerlijk gezegd zit daar wel wat in, want hoge beschikbaarheid en load balancing is nog nooit zo belangrijk geweest.

Van alle Exchange 2010 protocollen die je kunt load balancen is MAPI wel de meest bijzondere. De reden is dat MAPI verkeer standaard gebruik maakt van dynamische hoge poorten voor de RPC Client Access en Address Book services, dat betekent dat je nooit vooraf weet welke poorten je moet load balancen. Dit kunnen we oplossen door Exchange zo te configureren dat deze vaste poortnummers gebruikt voor deze twee services.

Om te beginnen moeten we deze poortnummers bepalen. Hoewel in principe ieder hoog nummer wat niet in gebruik is voldoet, raadt Microsoft aan om een poort te kiezen binnen de range 59531 tot 60554. In dit voorbeeld ga ik uit van poort 60000 en 60001, omdat ze makkelijk te onthouden zijn als ik zo meteen de load balancing rules ga aanmaken. En het spreekt voor zich dat we de zelfde waardes gebruiken voor iedere Client Access server in deze site.

We kunnen Exchange configureren met behulp van twee registry keys. Om fouten te voorkomen raad ik aan om dit in te stellen met de volgende vier eenvoudige PowerShell regels:

New-Item HKLM:\SYSTEM\CurrentControlSet\services\MSExchangeAB\Parameters
Set-ItemProperty HKLM:\SYSTEM\CurrentControlSet\services\MSExchangeAB\Parameters RpcTcpPort 60001 -type string
New-Item HKLM:\SYSTEM\CurrentControlSet\services\MSExchangeRPC\ParametersSystem
Set-ItemProperty HKLM:\SYSTEM\CurrentControlSet\services\MSExchangeRPC\ParametersSystem "TCP/IP Port" 60000 -type dword

Vervolgens moeten we deze twee services opnieuw starten zodat we kunnen controleren of we het goed gedaan hebben:

Restart-Service MSExchangeAB
Restart-Service MSExchangeRPC

Nu controleren we of de server op de nieuwe poorten luistert:

netstat -ano | findstr 60000
netstat -ano | findstr 60001

We hebben ons werk goed gedaan, er luistert nu een proces op beide poorten. Dat betekent dat we nu de load balancer kunnen configureren voor poort 135, 60000 en 60001, maar dat valt buiten de scope van dit artikeltje.

Exchange 2010: Mailboxen exporteren naar PST

Een server met Exchange 2010 biedt de mogelijkheid om de inhoud van een mailbox of archief te exporteren naar een PST bestand. Dit kan handig zijn als backup voordat je mailboxen verwijdert, of wanneer je een kopie van de mailboxitems wilt bewaren tijdens troubleshooten of iets dergelijks.
In Exchange 2010 worden exports, imports en verplaatsingen van mailboxen uitgevoerd door de Mailbox Replication Service (MRS). In de praktijk betekent dit dat we een verzoek voor een bepaalde actie klaarzetten en dat de MRS het verzoek af gaat handelen. De MRS doet dit asynchroon, dat wil zeggen dat ze de verzoeken die wij klaarzetten oppakt en uit gaat voeren en niet per sé direct nadat wij opdracht geven. Het voordeel hiervan is dat het proces gewoon weer verder gaat als de server tussendoor een reboot gekregen heeft.
Eerst moeten we zorgen dat het account waarmee wij werken de juiste rechten heeft, in dit voorbeeld doe ik dit door de RBAC rol “Mailbox Import Export” toe te kennen aan de groep Organization Management:
New-ManagementRoleAssignment -SecurityGroup "organization management" -Role "mailbox import export"
Om een mailbox te im- of exporteren maken we een request met New-MailboxImportRequest of New-MailboxExportRequest, als je deze cmdlets nog niet kunt gebruiken nadat je bovenstaande aanpassing gedaan hebt dan moet je de EMS even opnieuw openen. Je zult zien dat de extra cmdlets nu tot je beschikking zijn. Een voorbeeldje nu:
$lijst = Get-Mailbox -OrganizationalUnit _users
$lijst | % { $_ | New-MailboxExportRequest -FilePath "\\ex01\c$\pst\$($_.alias).pst" }

In de eerste regel vullen we de variable $lijst met alle mailboxen van de gebruikers in de OU _users. In de tweede regel beginnen we met het aanroepen van de zojuist gevulde variabele, waarna we voor elk van deze mailboxen een MailboxExportRequest aanmaken. Belangrijk is dat we het FilePatch in UNC formaat moeten opgeven, maar als de beheershare c$ gebruikt dan is het een koud kunstje om naar een lokale folder te verwijzen. Verder gebruik ik de Alias-eigenschap van de mailboxen om de bestandsnaam mee op te bouwen.
Direct na het klaarzetten van de verzoeken is de status Queued, zoals te zien is in de meest rechtse kolom van het screenshot hierboven. We kunnen de status van de verzoeken op elk moment opvragen met Get-MailboxExportRequest.

We zien hier niet alleen de 4 verzoeken die we net klaar hadden gezet, maar ook nog enkele oudere. Als de status van deze verzoeken niet meer belangrijk is dan kunnen we die verwijderen met Remove-MailboxExportRequest.
De beloning van onze noeste arbeid, met hulp van de MRS, vinden we in de opgegeven directory:

Leuk detail is misschien dat mijn mailbox (jetze.pst) aanzienlijk groter is dan ik hier zie staan. Dit komt omdat ik in het screenshot hierboven alle Move Requests verwijderd heb, inclusief eentje die nog als status InProgress had. Hiermee heb ik onbedoeld het exporteren afgebroken, hebben we die vraag ook meteen beantwoord.

Snel testgebruikers aanmaken in Exchange 2010

Zo af en toe is het handig om snel een paar testmailboxen aan te maken in Exchange 2010. Vaak is testgebruiker1 tot en met testgebruiker10 al voldoende. We kunnen dit in de Exchange Management Shell (EMS) eenvoudig doen door een oplopende nummers te produceren en deze nummers vervolgens te gebruiken bij het maken van mailboxen.

Als eerste zetten we een wachtwoord in een secure string:

$password = Read-Host “Geef het wachtwoord” -AsSecureString

Vervolgens maken we onze 10 testgebruikers aan als volgt:

1..10 | ForEach-Object { New-Mailbox -Name TestGebruiker$_ -UserPrincipalName testgebruiker$_@domaina.local -Password $password }

In bovenstaande regel staat $_ voor de waarde die we aan de linkerkant van de pijp hebben gegenereerd. Er wordt dus 10 keer een regel uitgevoerd waarbij $_ de eerste keer voor 1 staat, de tweede keer voor 2, enzovoort.

En als je je nu afvraagt of het ook werkt als je 1..10000 gebruikt of 29..34? Probeer het maar.

Actuele issues met Exchange ActiveSync devices

Exchange ActiveSync is een protocol van Exchange Server waardoor je je e-mail, agenda en andere items kunt synchroniseren naar je mobile. Die mobile kan een telefoon zijn maar ook bijvoorbeeld een tablet met een ingebouwde ActiveSync client. Exchange ActiveSync biedt veel meer functionaliteit dan synchroniseren via IMAP en SMTP, zowel voor de eindgebruiker als voor beheerders. De afgelopen jaren is er veel veranderd door de opkomst van smartphones en tablets. Eén van de ontwikkelingen is dat vrijwel alle fabrikanten het ActiveSync protocol zijn gaan ondersteunen, zo ook Apple bijvoorbeeld sinds versie 2.0 van de iPhone software.

Twee dingen zijn belangrijk om te weten. Ten eerste hebben niet alle fabrikanten de zelfde functionaliteit van het protocol in hun oplossing geïmplementeerd en evenzo bieden nieuwere versies van Exchange Server meer mogelijkheden dan de oudere voorgangers. Voor een uitgebreid overzicht verwijs ik naar dit Wikipedia artikel: Comparison of Exchange ActiveSync clients. Het tweede is dat deze grote verscheidenheid aan ActiveSync clients voor beheerders en helpdesk ook betekent dat zij vaker met issues geconfronteerd worden.

Naast het actief ondersteunen van fabrikanten die moeite hebben om problemen in hun software op te lossen, heeft Microsoft het volgende KB-artikel beschikbaar gemaakt: Current issues with Microsoft Exchange ActiveSync and third-party devices. Voor beheerders en helpdesk is het aan te bevelen om dit artikel af en toe door te nemen om te kijken of er oplossingen beschikbaar zijn voor issues.

Nieuw Exchange 2010 Language Pack lost problemen op

Eerder schreef ik al over een vertaalfoutje in OWA na installatie van SP2 op de CAS servers. Na enige tijd bracht Microsoft een Language Pack Bundle uit die dit probleem herstelt, zie het artikel “Exchange 2010 SP2 toont Globale adreslijst in plaats van Berichten: opgelost”. Na installatie van dit Language Pack toont OWA nu E-mail in plaats van Globale Adreslijst:

Beheerders die deze update installeerden op een server met meerdere rollen, dus niet alleen Client Access, zagen nu een nieuwe error verschijnen in het Application Log:

Log Name: Application
Source: MSExchangeIS
Date: 23.03.2012 15:55:35
Event ID:10013
Task Category: General
Level: Error
Keywords: Classic
User: N / A
Computer: Server
Description:
The Active Directory entry for mailbox CN contains an invalid locale for attribute MsExchUserCulture: nl-NL

Inmiddels heeft Microsoft een nieuwe versie van de Bundle klaargezet die ook dit probleem oplost. Downloaden doe je hier.

Office 365: Migraties en performance

Iedereen die wel eens een mailmigratie heeft uitgevoerd weet dat de doorlooptijd een belangrijke factor is. Vaak is het lastig om te bepalen waar nu precies de bottleneck zit, is het de bronserver, het migratiestation of toch misschien de internetverbinding? En hoe zit dat met throttling in Exchange Online?

Microsoft heeft hier een mooi document voor uitgebracht: Microsoft Exchange Online Migration Performance Guide

Dit document behandelt niet alleen de standaard Office 365 migratiemethoden maar gaat ook in op third party tools als die van Quest, MigrationWiz en Binary Tree. De schrijvers gaan uitvoerig in op de hele keten van factoren, van bronserver tot Exchange Online. Absolute aanrader voor iedereen die een migratie naar Exchange Online wil voorbereiden.

Verlopen van het wachtwoord aan- of uitschakelen in Office 365

Wanneer je geen gebruik maakt van single sign-on in Office 365, hebben je gebruikers te maken met het standaard wachtwoordbeleid. Wat dit beleid precies inhoudt kunnen we lezen in de Office 365 Service Descriptions: Identity Service Description. Hierin vinden we de volgende tabel:

We zien hier dat de een wachtwoord maximaal 90 dagen oud mag worden, dan moet het echt aangepast worden. Wanneer het wachtwoord bijna verlopen is en je de Microsoft Online Services Sign-in Assistant geïnstalleerd hebt zie je onderstaande melding verschijnen:

In bepaalde gevallen zou je die termijn misschien aan willen passen maar dit is helaas niet mogelijk. Wat wel kan is om het verlopen van wachtwoorden helemaal uit te schakelen, dit is een instelling die je per gebruiker kunt zetten. Dit kun je eenvoudig doen in de Microsoft Online Services Module for Windows PowerShell, namelijk door de parameter -PasswordNeverExpires voor een gebruiker op $true te zetten. En wel  als volgt:

1. Open de Microsoft Online Services Module for Windows PowerShell of start een normale PowerShell sessie en importeer de MSonline module (import-module msonline)
2. Maak verbinding met de Office 365 tenant: Connect-MsolService
3. Pas de waarde voor -PasswordNeverExpires aan voor een gebruiker: Set-MsolUser -UserPrincipalName user@domain.com -PasswordNeverExpires:$True

Het spreekt voor zich dat we dit ook in één keer kunnen instellen voor al onze gebruikers:

Op deze manier kunnen we het verlopen van wachtwoorden in Office 365 uitschakelen.

Office 365 en een catch-all mailbox

Normaal gesproken zal een mailsysteem alleen berichten accepteren voor adressen die daadwerkelijk bestaan. Maar in sommige gevallen zou je graag alle berichten willen ontvangen, bijvoorbeeld om te weten wanneer iemand een mailadres verkeerd spelt of om te onderzoeken of oude adressen nog gebruikt worden. Zo’n vergaarbakje noemen we een catch-all mailbox.

In de Office 365 datacenters wordt Forefront Online Protection for Exchange (FOPE) ingezet om te filteren op spam, om dit zo goed mogelijk te kunnen doen worden berichten voor niet bestaande adressen dan ook niet geaccepteerd. Een catch-all mailbox is dus niet mogelijk in Office 365.

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.