post

Microsoft is een paar jaar geleden een geheel nieuwe weg ingeslagen. Daarbij is de primaire focus op de cloud komen te liggen. Alles wat Microsoft doet vindt sindsdien plaats op basis van de inmiddels zeer bekende ‘Mobile-First, Cloud-First’ strategie. Een belangrijk vraagstuk vandaag de dag is: wat betekent deze nieuwe strategie voor de System Center suite? In een serie van drie delen deel ik mijn visie op dit vlak, waarbij dit eerste deel inzoomt op SCCM en SCOrch.

Alle inspanningen van Microsoft zijn sinds de koerswijziging primair gericht op de (door)ontwikkeling van haar cloud portfolio. Kijkend naar de enorme groei van Azure en Office 365, zowel qua dienstenaanbod, breedte als diepte, kan zondermeer gesteld worden dat Microsoft deze nieuwe strategie met hart en ziel volgt. In het kader van deze strategie zijn veel Microsoft toepassingen en diensten – die oorspronkelijk een on-premise bestaansrecht hadden – aangepast naar een meer hybride uitvoering. Hierdoor is de koppeling met Azure/Office 365 relatief eenvoudig te realiseren en in sommige situaties zelfs een harde eis om bepaalde functionaliteit te kunnen activeren.

Wat zijn de gevolgen voor System Center?

De gehele System Center stack (en dus alle afzonderlijke componenten) stammen uit het pre-cloud era. In die tijd was de cloud er wel, maar stond het – zeker in vergelijking met nu – in de kinderschoenen. Hierdoor heeft System Center een sterke on-premise focus die vervat is in de broncode en zich daardoor niet zonder zware investeringen laat omkatten naar een hybride variant. Daarnaast is Microsoft niet bezig om cloud-gebaseerde varianten van de afzonderlijke System Center componenten te realiseren. Kortom: System Center staat enigszins geïsoleerd in de nieuwe wereld van Microsoft. Om beter zicht te krijgen op de status van de afzonderlijke System Center stack componenten, geef ik per component een klein overzicht van de actuele status en of er überhaupt sprake is van een Azure-gebaseerd alternatief. Als afsluiting wordt in het laatste deel breder gekeken naar System Center als stack en welk bestaansrecht deze suite nog heeft ten aanzien van Azure en de enorme expansiedrift van Microsoft op dat gebied.

 

System Center – Configuration Manager (SCCM)

Hoewel SCCM deel uitmaakt van de System Center stack heeft dit product altijd al zijn eigen ruimte ingenomen of geclaimd. En met recht. De omzet die SCCM jaarlijks realiseert loopt in de vele honderden miljoenen dollars. Als direct gevolg heeft SCCM een eigen budget- en resource allocatie, geheel los van de overige System Center componenten. Daarbij is de ontwikkeling zelfs nu nog in handen van de ‘first base’ product-teams in Redmond, USA. Dit in tegenstelling tot de andere System Center componenten waarvan de ontwikkeling inmiddels is doorgezet naar India, ook wel ‘second base’ genoemd in Redmond…

SCCM is baanbrekend te noemen ten opzichte van andere onderdelen van de System Center stack. Zo worden er geen productversies toegepast, zoals bijvoorbeeld SCOM 2016, maar wordt SCCM eens per kwartaal geüpdatet, waarbij elke nieuwe versie aangeduid wordt als Current Branch (CB).

Het doel van de CB releases is veelvoudig. Denk aan o.a.:

  • Het naadloos aansluiten op de release cycle van Windows 10
  • Het geheel ondersteunen van nieuwe functies in Windows 10
  • Het sneller opnemen van gebruikers terugkoppeling in de software
  • Het nog beter aansluiten op Azure en Windows Intune

Met de CB releases is ook het traditionele ondersteuningsmodel van Microsoft (Mainstream & Extended Support) op de schop gegaan. In plaats daarvan kent SCCM CB twee nieuwe zogeheten servicing phases, te weten: Security & Critical Updates Servicing phase en Security Updates Servicing phase.

In tegenstelling tot het traditionele ondersteuningsmodel dat enkele jaren omvatte, duren deze fases maar enkele maanden en zijn ze alleen van toepassing op CB (Security & Critical Updates Servicing phase) en de vorige versie van CB, ook wel CB-1 (Security Updates Servicing phase) genoemd. Hierdoor worden bedrijven gedwongen zoveel mogelijk in pas te blijven lopen met de CB release cycle. Gelukkig is het updaten van SCCM een grotendeels geautomatiseerd proces geworden, waardoor het volgen van de CB cycle minder inspanningen kost dan het updaten van andere System Center componenten. Bij elke CB release wordt de integratie tussen SCCM en Azure steeds veelzijdiger en dieper, dit naast de alom bekende koppeling met Windows Intune.

SCCM en de toekomst

SCCM raakt steeds meer buiten de ‘reguliere’ en ‘klassieke’ System Center stack en claimt daarmee zijn eigen ruimte binnen het Microsoft portfolio. Hoewel het een sterke on-premise aanwezigheid heeft, neemt de integratie met Azure, Office 365 en Windows Intune met elke CB release verder toe. Hierdoor sluit SCCM naadloos aan op de ‘Mobile-First, Cloud-First’ strategie van Microsoft en is SCCM toekomstvast, zeker in vergelijking met andere System Center componenten.

System Center Orchestrator (SCOrch)

Waar SCCM goed aansluit op de nieuwe strategie van Microsoft en grote funding geniet, is SCOrch aan de andere kant van het System Center spectrum te vinden. De ontwikkeling van SCOrch is namelijk geheel stopgezet. Voor SCOrch 2016 zijn alleen de boilerplates vervangen (van 2012 R2 naar 2016) en de bijbehorende Integration Packs naar Windows Server 2016 getild. Onder de motorkap is er echter niks veranderd en dat zal ook niet meer gebeuren. Zo is SCOrch 2016 nog steeds een 32-bits toepassing, wat het tot een uitdaging maakt om op 64-bits systemen probleemloos taken uit te voeren. En er zijn geen plannen om daar verandering in aan te brengen. Microsoft maakt er zelf geen geheim van: SCOrch gaat verdwijnen en dient dan ook vervangen te worden door Service Management Automation (SMA, onderdeel van Windows Azure Pack) of – beter nog – door Azure Automation (AA, de cloud gebaseerde variant van SCOrch).

Een uitdaging is daarbij momenteel om een grafische interface voor het ontwerpen en onderhouden van runbooks voor AA te leveren, gekoppeld aan een goede methodiek om bestaande SCOrch runbooks en workflows te migreren naar AA. Tevens heeft AA de beperking dat het alleen on-premise resources kan benaderen die vanuit Azure toegankelijk zijn. Dit beperkt de on-premise ‘slagkracht’ van AA aanzienlijk waardoor het (nog) geen één op één vervanger van SCOrch is.

SCOrch 2016 en de toekomst

Hoewel SCOrch 2016 deel uitmaakt van de gehele System Center 2016 stack en daardoor Mainstream Support geniet tot 11 januari 2022, is het raadzaam deze tijd te gebruiken uit te kijken naar alternatieven (zoals SMA en/of AA) en daar stapsgewijs naar toe te migreren.

De algemene verwachting is dat er geen opvolger van SCOrch 2016 zal komen en dat het hierdoor een stille dood zal sterven.

Tot zover deel één. In het volgende deel komen Data Protection Manager, Service Manager en Virtual Machine Manager aan bod.

Leave a comment