Stel: Je hebt een SCCM siteserver (in mijn geval SCCM 2012 R2, versie 1602 Current Branch) welke lid is van Windows domein X. De (SCCM en SUS-) databases bevinden zich in een SQL cluster welke lid is van Windows domein Y.    Het SQL cluster bestaat uit meerdere nodes, welke middels active-passive prima dienst doen om de SCCM- en SUS databases te hosten. Alles werkt prima in dit cross-domain scenario zonder al te lastige configuratie-perikelen.

 
Leuk wordt het wanneer je (SSRS-) reporting aan dit instance wilt toevoegen. Het is prima mogelijk om SSRS op de individuele SQL nodes te installeren (check dit artikel voor een uitstekende guide hoe dat te doen), maar het probleem komt pas bij de installatie en configuratie van het cluster binnen SCCM. Wanneer de rol "Reporting Services Point" wordt toegevoegd aan het cluster zal de Component Manager-log binnen de kortste keren vol staan met errors. Logisch, want SSRS is niet cluster-aware, SCCM is niet slim genoeg om te ontdekken dat de clusternaam geen fysieke (of virtuele) server is.
 
Wanneer je in dit scenario vervolgens probeert om het cluster de Reporting Point rol te geven, zal het Component Manager-log snel volstromen met errors. Reden is, dat SCCM het cluster beschouwt als een host. En die host bestaat uiteraard niet, waardoor de installatie van de Reporting componenten zal falen en heel vervelende SQL errors tot gevolg zal hebben.
 
Wanneer je dan probeert om een van de SQL nodes te voorzien van de Reporting componenten kom je niet veel verder dan het eerste scherm van de wizard. Reden dat de installatie hier zal stokken is dat de node naam geen FQDN is en niet resolved kan worden naar een FQDN, waardoor installatie niet door kan gaan. Omdat het hier een cross-domain situatie betreft zal SCCM deze node beschouwen als of deze zich op het Internet bevindt!
 
Binnen een single domein scenario zal SCCM de servernaam en FQDN van een SQL node prima kunnen resolven en maakt er zelf een mooie FQDN van, maar binnen een cross-domain scenario werkt dit dus niet.
 
Oplossing is tweeledig:
1. Voeg de DNS suffixes van beide domeinen toe aan de IPv4 configuratie van de netwerkkaart (als dat niet al het geval is)
2. Open de hosts-file op de SCCM siteserver en voeg daar de Ip-adressen en FQDNs toe van de SQL nodes
 
Hiermee kan SCCM de SQL nodenamen prima resolven en er FQDNs van maken. Hou er wel erg in dat SSRS uitsluitend te configureren is op de aktieve SQL node. Consequentie hiervan is ook dat SSRS errors gaat genereren zodra de database een failover doet naar een andere node binnen het cluster, maar dat is logisch aangezien SSRS helaas nog steeds niet cluster aware is.

Tot en met Windows XP werd een zogeheten “SteadyState” functionaliteit officieel door Microsoft ondersteund. De SteadyState functionaliteit houdt in, dat alle wijzigingen die een gebruiker tijdens een sessie doorvoert (de “User-delta”) ongedaan worden gemaakt na een reboot. Bijvoorbeeld: een gebruiker meldt aan op een machine en installeert Microsoft Office. Deze Office installatie zal verdwenen zijn van de werkplek zodra de machine opnieuw opgestart wordt. De SteadyState functionaliteit is dus vergelijkbaar met de snapshot-functionaliteit van bijvoorbeeld VMWare, Virtualbox of Hyper-V, waarmee je teruggaat naar een eerdere “state” van de computer.

Een mooie functionaliteit die veel praktisch nut heeft, maar helaas wordt deze functionaliteit niet meer aangeboden of ondersteund onder Windows 7. Toch is het SteadyState principe nog steeds werkbaar te krijgen onder Windows 7. Zo heeft Panos Macheras hier een mooi artikel geschreven over zijn oplossing voor Windows 7 en SteadyState. Helaas zitten er aan deze oplossing nog wat haken en ogen welke ik in dit artikel zal beschrijven en oplossen.

In de basis is een SteadyState machine niets anders dan een Windows 7-installatie met twee verschillende boot-opties naar een VHD (Virtual Harddisk). De twee boot-opties zijn “Windows 7” en “SteadyState” en hebben de volgende functionaliteit:

• 1. SteadyState: Deze boot-optie zorgt ervoor dat Windows bij reboot teruggezet wordt naar de “SteadyState” van het image. Alle wijzigingen die zijn doorgevoerd door de gebruiker worden verwijderd en de machine is na reboot weer “terug bij af”.
• 2. Windows 7: In tegenstelling tot de SteadyState-boot optie, worden met de Windows 7 boot-optie wijzigingen wel permanent doorgevoerd. Op deze wijze kan het image opgebouwd en onderhouden worden.

Door de boot-timeout op 0 te zetten met als standaard boot-optie de SteadyState boot wordt zeker gesteld dat de gebruiker in SteadyState terecht komt. SteadyState werkt als volgt:

Zodra de machine start wordt een tijdelijke extra VHD aangemaakt waarin de User-delta wordt opgeslagen. Met het afsluiten van de sessie wordt de user-delta samengevoegd met de Windows 7 VHD (merge) of weggegooid (discard). De “Merge” vindt plaats wanneer naar de reguliere Windows 7 geboot wordt en de “discard” vindt plaats wanneer naar Steadystate geboot wordt.

De oplossing van Panos Macheras bestaat uit een (AutoIT-) script waarmee de merge en discard van de User-delta geregeld worden. Nou is Pi-CT eigenlijk geen fan van Auto-IT, maar in dit geval heeft het een aantal voordelen:

• 1.Het afvangen van melding is relatief eenvoudig en betrouwbaar
• 2. Het aanpassen van de scripts en (her-)compileren tot executables is zeer eenvoudig
• 3. Het is gemakkelijk inzichtelijk wat er gebeurt, doordat de scripts gemakkelijk leesbaar zijn

De scripts werken op zich prima, maar er zijn een aantal haken en ogen:

• 1. De scripts zijn Engelstalig en vangen dus Engelstalige meldingen af. Hierdoor werkt het niet op een anderstalig OS, zoals bijvoorbeeld Nederlands.
• 2. Vanuit de scripts worden scheduled tasks aangemaakt. Deze scheduled tasks worden vanaf een commandline aangemaakt. Vanaf de commandline staat standaard de optie aan dat de “taak dient te worden gestopt zodra de computer op accu gaat werken”. Hierdoor werkt de SteadyState oplossing dus niet wanneer een laptop gebruikt wordt welke niet aan het lichtnet aangesloten is.
• 3. In het artikel refereert Panos aan de “Microsoft Deployment Toolkit” welke gebruikt dient te worden om de juiste sources en ISO te compileren. De nieuwste versie van de MDT genereert echter errors; een oudere versie (2012) van de MDT dient dus gebruikt te worden.

Oplossingen voor deze punten zijn relatief eenvoudig:

• 1. Recompile de executable zodat deze Nederlandstalige meldingen afvangt.
• 2. Maak een eigen scheduled task aan zonder de Power-management setting, exporteer deze naar c:\Windows\System\Tasks en vervang de commandline in de executable waarmee de scheduled task aangemaakt wordt door een commandline waarmee de scheduled task geïmporteerd wordt. Eventueel kun je de aangepaste scripts downloaden middels deze link
• 3. Download de goed werkende (oudere) MDT-versie hier vanaf de Pi-CT website. Deze zip-file bevat zowel de X64 als de X86 versie van de MDT 2012.

Mocht je hiermee aan de gang gaan: Succes!

Stuur bij vragen of opmerkingen even een berichtje aan blog@pi-ct.com.