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.

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.

ADMT versie 3.2

De nieuwste versie van de Active Directory Migration Tool (ADMT) is versie 3.2. Deze versie ondersteunt Windows Server 2008 R2 en de nieuwe ‘managed service accounts’. Je vindt de download hier en de bijbehorende ADMT Migration Guide hier.

Group Policy Objects bewerken met PowerShell

De uitdaging

Onlangs vroeg een klant mij advies over het configureren van het Outlook 2007 profiel op hun nieuw uit te rollen werkplekken. Nu is dit al redelijk eenvoudig doordat de nieuwe Exchange 2010 omgeving Autodiscover aanbiedt, maar de gebruiker wordt nog steeds geconfronteerd met een eenmalige wizard om Outlook te configureren. Ik zocht dus naar een oplossing die er voor zorgt dat Outlook deze wizard overslaat en Autodiscover gebruikt om een Outlook profiel te configureren.

Voorkennis: Voor dit artikel ga ik er van uit dat je bekend bent met de basics van het configureren van een Outlook profiel, dat je weet hoe Autodiscover in een Active Directory domein werkt en bekend bent met GPO’s.

Omdat mijn ervaring op dit gebied uit het 2003-tijdperk stamt, heb ik het volgende artikel gelezen om meer te weten te komen over het aanpassen van Outlook: Deploying additional registry values in the Office Customization Tool for Outlook 2007. Daar lees je over de ZeroConfigExchange key, als we deze in het register zetten en een waarde van 1 geven dan zal Outlook het gewenste gedrag vertonen. Om precies te zijn:

Key:	HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Outlook\AutoDiscover
DWORD:	ZeroConfigExchange
Values:	0 (or missing) = default autoconfiguration functionality
	1 = no interaction except for credentials prompt (if required)

De vraag is dan natuurlijk hoe we deze key op 1500 werkplekken in het register krijgen. Er zijn verschillende manieren om dit te doen, onder andere:

1. Een opdrachtregel in het inlogscript, bijvoorbeeld: reg /s MijnKey.reg
2. Een GPO en een custom ADM template schrijven
3. Group Policy Preferences gebruiken
4. Een 3rd party ‘workspace manager’ gebruiken
5. Een GPO bewerken met PowerShell

Met PowerShell?

Deze klant heeft servers met Windows Server 2008 R2 en Windows 7 beheerwerkplekken, dus het ligt voor de hand om de nieuwe AD PowerShell functionaliteit te gaan gebruiken. Naast PowerShell, hebben we ook de GPMC Windows Feature nodig. Laten we deze eerst op ons systeem installeren. In PowerShell:

Import-Module ServerManager
Add-WindowsFeature GPMC

Met de eerste regel importeren we de PowerShell module ServerManager, dit is de PowerShell variant van de bekende beheertool die we voor het eerst in Windows Server 2008 zagen. Het resultaat is dat we een aantal nieuwe cmdlets beschikbaar krijgen in deze sessie, kijk maar eens met Get-Module ServerManager | fl welke dat zijn. In de tweede regel gebruiken we één van deze cmdlets om de Group Policy Management Console feature te installeren, die hebben we nodig om GPO’s te kunnen bewerken. Wanneer dit klaar is importeren we de GroupPolicy module in onze sessie:

Import-module GroupPolicy

Nu kunnen we de Set-GPRegistryValue cmdlet gebruiken om een registry value aan het een bestaande GPO toe te voegen. Hiervoor moeten we onder andere de naam van de GPO hebben, ik weet dat er iets van ‘user’ in de naam staat maar herinner me de naam niet precies. Daarom gebruik ik de Get-GPO cmdlet om de juiste naam te kunnen gebruiken:

Get-GPO -all | where { $_.displayname -like "*user*" }

Het resultaat:

DisplayName      : User Settings
DomainName       : domain.local
Owner            : DOMAIN\Domain Admins
Id               : aec2911a-cc51-427e-8b8a-767dbfef87d7
GpoStatus        : ComputerSettingsDisabled
Description      :
CreationTime     : 31-1-2010 13:42:19
ModificationTime : 25-4-2010 11:24:12
UserVersion      : AD Version: 51, SysVol Version: 51
ComputerVersion  : AD Version: 0, SysVol Version: 0
WmiFilter        :

Goed, nu we weten welke GPO we willen bewerken en weten wat de er in willen zetten kunnen we aan de daadwerkelijke opdracht beginnen. In plaats van een lange regel te typen, geef ik de voorkeur aan een klein scriptje waar in we met variabelen werken. Het is niet strikt noodzakelijk, maar maakt het wel heel gemakkelijk om je stukje code aan te passen of nog eens vaker te gebruiken. In de Technet Library heb ik de help-pagina opgezocht van de cmdlet: Set-GPRegistryValue. Daar lees ik over de parameters die nodig zijn om de registry key vaan de GPO toe te voegen. In het script begin ik met het vullen van deze variabelen:

$gpo = "User Settings"
$key = "HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Outlook\AutoDiscover"
$valuename = "ZeroConfigExchange"
$type = "Dword"
$value = 1

Vervolgens roep ik de cmdlet aan met de juiste parameters:

Set-GPRegistryValue -Name $gpo -Key $key -ValueName $valuename -Type $type -Value $value

Voor de duidelijkheid voeg ik nog wat commentaar toe en sla ik het scriptje op als BewerkGPO.ps1, dat ziet er uiteindelijk zo uit:

## Vul hier de juiste waardes in:
$gpo = "User Settings"
$key = "HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Outlook\AutoDiscover"
$valuename = "ZeroConfigExchange"
$type = "Dword" # Mogelijke waardes: {<Unknown> | <String> | <ExpandString> | <Binary> | <DWord> | <MultiString> | <QWord>}
$value = 1

## Importeer de GPMC module voor PowerShell
Import-module grouppolicy

## Voeg de key toe aan de GPO
Set-GPRegistryValue -Name $gpo -Key $key -ValueName $valuename -Type $type -Value $value

Het resultaat

En, zou het gelukt zijn? Helaas zijn deze cmdlets in bepaalde opzichten nog niet zo gebruiksvriendelijk als ervaren beheerders van Exchange misschien zouden verwachten. Sommige Get-cmdlets kennen bijvoorbeeld een –all parameter, anderen accepteren een wildcard en bij andere cmdlets moet je precies weten wat je zoekt. Om overzicht te krijgen is het misschien beter om een rapportje te laten genereren:

Get-GPO -all | where { $_.displayname -like "*user*" } | Get-GPOReport -ReportType html -Path c:\temp\report.html

In dit artikel hebben we gezien hoe we PowerShell kunnen gebruiken om met Group Policies te werken. Voor meer informatie over de gebruikte Group Policy cmdlets verwijs ik naar deze plek in de TechNet Library. Ter afsluiting nog een tip, verander 12.0 in de key door 14.0 om de key ook voor Outlook 2010 toe te voegen.

Exchange 2003 SP2 en Server 2008 R2 domain controllers

Stel, je hebt nog Exchange 2003 in je domein maar wilt je domain controllers upgraden naar Server 2008 R2. Tot voor kort was dat een ‘blocker’, omdat Exchange 2003 niet ondersteund werd met domain controllers die Server 2008 R2 draaiden. Dat is inmiddels aangepast, met Exchange 2003 SP2 kun je doorgaan met vervangen van domain controllers. Ook mag je het forest en domain functional level ophogen tot Server 2008 R2.

Meer informatie vind je hier.

Server 2008 R2 loopt vast in VMware ESX

Verschillende mensen melden vastlopers wanneer ze Windows Server 2008 R2 draaien onder VMWare ESX 3.5 en 4. De oorzaak hiervan zou de videdriver zijn die geïnstalleerd wordt met de VMware Tools. Een tijdelijke oplossing is om ofwel geen VMware Tools te installeren, ofwel de VMware videodriver te verwijderen. Een definitiefe oplossing in de vorm van een nieuwe driver is helaas nog niet voor handen.