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.

Exchange 2007 en Server 2008: De truuk met ServerManagerCmd.exe

Al eerder schreef ik over het voorbereiden van Server 2008 voor Exchange 2007 SP1. Daar liet ik een alternatieve manier zien om roles en features te installeren, namelijk met ServerManagerCmd.exe. Zo kun je PowerShell eenvoudig aanzetten met het commando:

ServerManagerCmd -i PowerShell

Maar die werkwijze houdt in dat je soms 8 keer een commando moet geven en 8 keer moet wachten tot de bewerking is uitgevoerd, wat heeft dat nou voor meerwaarde ten opzichte van Server Manager? In dit artikel wil ik een slimmere manier beschrijven: we gaan ServerManagerCmd.exe een xml-file voeren.

Even over ServerManagerCmd.exe, hiermee kun je roles, role services en features installeren en verwijderen. Daarnaast kan ServerManagerCmd.exe een overzicht geven van alle geïnstalleerde onderdelen. Voor het installeren van de feature PowerShell heb ik hierboven al een voorbeeld gegeven, het zal duidelijk zijn dat wanneer we de switch –i (install) vervangen door –r of –remove PowerShell van het systeem verwijderd zal worden. De derde optie is interessant, welke roles, role services en features zijn eigenlijk op het systeem geïnstalleerd? Dat doen we met:

ServerManagerCmd –q



Met de switch –q of –query krijgen we een semi-grafisch overzicht, als iets op het systeem is geïnstalleerd dan staat er een [X] voor en wordt de regel met een andere kleur weergegeven. Die output gaan we zometeen gebruiken dus maken we even een dump naar bestand:

ServerManagerCmd –q > query.txt



Vervolgens moeten we dus een xml-file maken waarin staat welke roles, role services en features we willen installeren. Dat betekent dat we eerst uit moeten zoeken of de componenten die we willen installeren een role, role service of feature zijn. Daartoe openen we de zojuist gemaakte query.txt, die ziet er ongeveer zo uit:

----- Roles -----
[ ] Active Directory Certificate Services [AD-Certificate]
..[ ] Certification Authority [ADCS-Cert-Authority]
..[ ] Certification Authority Web Enrollment [ADCS-Web-Enrollment]
----- Features -----
[ ] .NET Framework 3.0 Features [NET-Framework]
..[ ] .NET Framework 3.0 [NET-Framework-Core]

Wat we hier zien zijn 1 role (AD-Certificate), 2 role services (ADCS-Cert-Authority en ADCS-Web-Enrollment) en 2 features (NET-Framework en NET-Framework-Core). Ik hoop dat zo duidelijk is hoe je aan de lay-out kunt zien of iets een role, role service of een feature is.

De xml-file die we gaan maken heeft de volgende indeling:



In regel 1 staat onder andere wat ServerManagerCmd.exe moet doen, installeren of verwijderen. Op regel 2 tot 4 volgen de gewenste componenten. Goed, nu kunnen we onze eigen xml-file maken, sla hem op als bijvoorbeeld exchange.xml.



We kunnen het resultaat van onze noeste arbeid eerst testen door de –whatif switch te gebruiken, er worden nu nog geen wijzigingen doorgevoerd.

ServerManagerCmd –InputPath exchange.xml –whatif



Als alles er goed uitziet dan starten we de installatie met:

ServerManagerCmd –InputPath exchange.xml

En klaar is Kees! Tot slot nog een paar aanvullende opmerkingen:

• We zien dat de server na de installatie een herstart nodig heeft, dit wordt veroorzaakt door de feature PowerShell. Desgewenst kunnen we dit automatiseren door de switch –restart toe te voegen aan ServerManagerCmd.exe.
• In dit voorbeeld heb ik gekozen voor de componenten die nodig zijn voor een standaardinstallatie met de Client Access, Mailbox en Hub Transport rol. Wanneer je deze methode wilt gebruiken om bijvoorbeeld een aantal Hub Transport servers voor te bereiden dan hoef je veel minder te installeren. In dit artikel staat per rol uitgelegd welke componenten er nodig zijn.
• Voor Outlook Anywhere heb je RPC-over-HTTP-proxy ook nodig.
• De feature Active Directory Domain Services Tools (RSAT-ADDS) is alleen nodig als je op deze server het Active Directory schema en je domein(en) wilt voorbereiden voor Exchange 2007. Als dit niet je eerste Exchange 2007 server is dan kun je deze achterwege laten.
• Kijk ook zeker even naar de Exchange 2007 System Requirements, dit is verplicht leesvoer wanneer je een Exchange 2007 omgeving wilt ontwerpen of de software gaat installeren.

Tot slot wens ik jullie veel plezier met Exchange 2007 SP1 en Windows Server 2008.

Howto: Install Exchange 2007 in Windows Server 2008 RC1

Voor wie? Dit artikel is bedoeld voor mensen die al enige ervaring met of kennis van Exchange 2007 hebben, zo ga ik er vanuit dat je op de hoogte bent van de rollen van Exchange. De bedoeling van dit artikel is om aan te geven hoe de installatie van Exchange 2007 verloopt onder Server 2008, wat toch wel wat afwijkt van een installatie in Server 2003.

We maken een enkele server die ik domain controller is. Daar voegen we de volgende Exchange 2007 rollen toe: CA, MB en HT.

Wat hebben we nodig? Dat is makkelijk, de x64 versie van Server 2008 RC1 omdat Exchange 2007 een 64-bits OS vereist. Daarnaast natuurlijk Exchange 2007, in dit geval gebruiken we de versie die SP1 al ingebakken heeft. Daar is een goede reden voor, SP1 is namelijk een vereiste om te kunnen installeren in Server 2008.

Voor dit soort testscenario's gebruik ik VMware Workstation maar een echte testpc of server kan natuurlijk ook. Naast voldoende geheugen, 2 tot 4 GB, moet je dan wel even controleren of je processor 64-bits ondersteuning heeft.

Goed, aan de slag. Ik heb een nieuwe VM aangemaakt met de naam SR2 en verder de standaardwaarden van VMware Workstation. Na het installeren van VMware Tools doe ik de basisconfiguratie van het OS.

• Vast IP-adres, als gateway het adres van mijn router en als DNS kies ik voor 127.0.0.1.
• Computernaam, die wordt 'sr2'. De naam van de werkgroep is niet belangrijk, die gaat toch vervallen.
• Automatische updates en feedback aanzetten
• RDP aanzetten, als je de server wilt kunnen beheren via Remote Desktop (aanrader)

Vervolgens kunnen we deze server een domain controller maken, dit doen we door de rol Active Directory Domain Services toe te voegen. Ja, ook Server 2008 werkt tegenwoordig met rollen. Deze rol kun je toevoegen in de Server Manager. Aan het eind van de wizard kun je het proces starten door op een link te klikken, maar je kunt dit ook doen met het bekende commando 'dcpromo'.



In mijn geval maak ik een nieuw forest en het domein heet test.local (NetBIOS: TEST). Het forest functional level moet minimaal Server 2003 zijn, ik kies voor Server 2008. Daarnaast laat ik de wizard ook DNS installeren, lekker handig!

Voor de rollen CAS, MB en HT moeten we een aantal features gaan toevoegen, dit kan ook via de Server Manager. Maar het kan nog veel makkelijker: open een command prompt en doe het volgende om de AD beheertools te installeren:

ServerManagerCmd -i RSAT-ADDS

Herstart de server, hierna installeer je PowerShell. Die hoef je niet te downloaden omdat het al in Server 2008 aanwezig is, alleen standaard niet geïnstalleerd:

ServerManagerCmd -i PowerShell

Installeer vervolgens IIS door deze commando's één voor één in deze volgorde in te geven:

ServerManagerCmd -i Web-Server
ServerManagerCmd -i Web-ISAPI-Ext
ServerManagerCmd -i Web-Metabase
ServerManagerCmd -i Web-Lgcy-Mgmt-Console
ServerManagerCmd -i Web-Basic-Auth
ServerManagerCmd -i Web-Digest-Auth
ServerManagerCmd -i Web-Windows-Auth
ServerManagerCmd -i Web-Dyn-Compression

De volgende stap is de installatie van Exchange zelf. Ook dit kan natuurlijk grafisch door setup.exe te starten, maar in deze howto kiezen we voor de commandline.

setup.com /mode:install /roles:MB, HT, CA /organizationname:Exchange2k7 /EnableLegacyOutlook



Ik zal het commando even kort toelichten. Setup.com kent verschillende modes en uiteraard kiezen we nu voor Install. Daarna volgen de 3 rollen welke nu geïnstalleerd worden, MailBox, Hub Transport en Client Access. Omdat dit een nieuwe Exchange-organisatie is moeten we hier de naam van opgeven, deze mag niet leeg zijn en als er een spatie in zit dan moet je hem tussen dubbele aanhalingstekens (") zetten. De laatste optie kies je alleen als je nog clients hebt die ouder zijn dan Outlook 2007, Exchange zal nu bij de installatie ook een database voor de Public Folders aanmaken.

Een optie die je in de praktijk vaak zult gebruiken is /TargetDir om de programmabestanden bijvoorbeeld op D: te laten plaatsen. In dit geval gebruikt Exchange het standaard pad %ProgramFiles%\Microsoft\Exchange Server. Ook hier geldt de opmerking over het gebruik van spaties.

Na een goed half uurtje, op mijn virtuele testserver, is de setup klaar voor een laatste herstart en zien we het volgende scherm:



Klaar? Bijna, want er zijn nog een paar laatste dingen om de installatie volledig af te ronden. Daarvoor gaan we naar de Exchange Management Console, die is nu te vinden in je Startmenu.

Op de eerste tab zie je de noodzakelijke stappen die je moet nemen om de installatie af te ronden. Op de tab End-to-End Scenario vind je een aantal handige aanbevelingen, die kunnen handig zijn om een start te maken met het beheer en de optimalisatie van de nieuwe Exchange 2007 omgeving.

Tip: De rol van Domain Controller toevoegen hadden we ook via de commandline kunnen doen (hint: ADDS-Domain-Controller).

Veel plezier met Exchange 2007 en in het bijzonder met Windows Server 2008!