System Center 2012 Configuration Manager Reporting

Posted on by
Reply

Voor een bedrijf wat grip wil hebben op informatie binnen de organisatie, bieden de ingebouwde reporting mogelijkheden van System Center 2012 veel mogelijkheden.

In de Configuration Manager zitten in de default configuratie al meer dan 400 standaardrapporten die voor beheer en beleid van belang kunnen zijn.

Natuurlijk zijn niet voor elke organisatie alle beschikbare rapportages even relevant.

Deze rapportages kunnen handmatig worden gedraaid of door middel van de subscriptions automatisch verzameld worden.

Hiermee kan men orchestratie en procesbeheer makkelijker maken. Het verzamelen van data en genereren van rapporten kan door Orchestrator worden aangestuurd. In plaats dat de Orchestrator zelf contact legt met alle servers en gegevens verzameld, maakt het gebruik van deze high-level data, die al binnen het platform beschikbaar is.

Aan de andere kant maakt het de orchestratie vooral ook krachtiger: Door rapportages een basis te laten zijn voor automatisering. Op basis van de met de reporting verzamelde gegevens kan Orchestrator zelfstandig bepaalde runbooks starten of juist bepaalde processen (tijdelijk) stoppen.

Bondig gezegd: Reporting is een goede basis voor meer intelligentie in het systeem.

Een klein minpuntje aan het samenspel van Orchestrator en Configuration Manager Reporting is dat er geen directe standaardrapportages zijn voor performance en status van Orchestrator zelf.

Gelukkig is er ruimte om ‘custom’ reports te maken. Hierdoor is het mogelijk om real-time inzicht te hebben in het functioneren van Orchestrator, maar vooral ook in het verloop van processen, hun efficiency en ROI.

Microsoft Private Cloud Launch Event / Best of MMS NL – verslag

Posted on by
Reply

Afgelopen woensdag was in Fort Voordorp te Groenekan de Microsoft Private Cloud Launch Event. Een bijeenkomst, georganiseerd door Microsoft, om zowel System Center 2012 als Windows Server 2012 voor te stellen aan IT professionals.

Op deze prachtige dag was er naast de promotie- en netwerkmogelijkheden natuurlijk ook veel aandacht voor de techniek zelf.

De nadruk van de meeste presentaties ging over integratie. Voor Microsoft zelf betekent dat natuurlijk dat alle verschillende producten van System Center 2012 elkaar kunnen aanvullen. Dit is ook te zien in de nieuwe, versimpelde, licensing-voorwaarden, waar je geen licenties voor de losse producten betaalt, maar alle producten van de suite onder 1 licentie kunt inzetten.
Natuurlijk was er ook veel aandacht voor de “BYOD”-trend. Kon men bij de IT-afdeling vroeger vanuit gaan dat alle elektronische apparaten op het netwerk door hun beheerd werden, brengen werknemers tegenwoordig steeds vaker hun smartphones, tablets of zelfs laptops mee naar het werk.

Geen wolkje aan de lucht op de lokatie in Fort Voordorp. Maar wel volop aandacht voor de Cloud.

Opvallend was dan ook dat, mede door deze trend, de integratie en ondersteuning van concurrerende technologie niet gemeden wordt. Hoewel Microsoft bijvoorbeeld duidelijk erg sterk inzet op de eigen virtualisatie-technologie, Hyper-V, is er meer dan voldoende ondersteuning voor ESX, van concurrent VMWare.

Een spil bij deze integratie van producten is natuurlijk System Center Orchestrator 2012.

Waar de andere producten heel duidelijk hun eigen rol hebben en in principe nog steeds stand-alone kunnen worden gebruikt is Orchestrator de motor, of misschien beter gezegd, het brein van System Center.

Het belang van Orchestrator, zo benadrukte Kevin McCuistion van Microsoft, is dat het zonder problemen ook processen op Linux, XenApp, VMWare of zelfs webbased platformen kan begeleiden.
Hierdoor werd duidelijk dat voor Microsoft de aanschaf en ontwikkeling van Orchestrator een strategische keuze is. Ook op de langere termijn zien zij dat het steeds belangrijker wordt om meer controle op infrastructuur en processen te krijgen, waarvoor zij in Orchestrator de belangrijkste tool zien.

Runbookbeheer en de Orchestration Console (en een beetje security)

Posted on by
Reply

Voor de meeste Runbooks geldt dat ze volautomatisch draaien. Ze worden opgestart volgens een vast schema of reageren op een specifieke monitoringswaarde of ander startevenement. Een andere mogelijkheid is dat Runbooks worden aangeroepen als onderdeel van andere Runbooks.

In  een goed ingerichte omgeving haal je juist door deze automatisering het meeste voordeel uit Orchestrator. Toch zal zelfs in de meest robuuste omgeving het soms nodig zijn om ‘met de hand’ Runbooks te bekijken en te stoppen of juist weer te starten. Ook in ontwikkelomgevingen en tijdens acceptatietesten zal met enige regelmaat handmatig beheer noodzakelijk zijn.

Binnen praktisch iedere organsiatie is er een strikt beleid op toegang tot de servers zelf. Daarom is er voor beheerders en ontwikkelaars beheertoegang mogelijk gemaakt via de Orchestration Console. Dit is een webgebaseerde interface, te benaderen met de browser. Omdat de Orchestration doorgaans bedrijfskritische processen aanstuurt, is het van belang om over de veiligheid hiervan na te denken.

De Orchestration Console zoals bezien door de browser

Omdat de Orchestration Console via de browser te benaderen, is het dus primair zaak om deze website te beveiligen in overeenstemming met het bedrijfsbeleid voor informatiebeveiliging. Zo moet toegang van buiten het bedrijfsnetwerk voorkomen worden en bijvoorbeeld alleen via VPN of andere beveiligingsoplossingen mogelijk zijn.

Om de Runbooks zelf te beschermen kan gebruik gemaakt worden van permissies. Naast het Orchestrator Service-account is er ook de Orchestator Users Group. Deze groep heeft standaard volledige permissies op alle Runbooks. Bij grotere organisaties is een enkele groep onvoldoende granulair. Ontwikkelaars mogen bijvoorbeeld wel toegang hebben tot de ene set van Runbooks, maar niet tot de andere. De ene beheerder hoeft alleen maar een Runbook te kunnen stoppen en starten, een ander zal er ook wijzigingen aan mogen maken.

Binnen de Runbook Designer is het daarom mogelijk om gebruik te maken van permissies.

De rode pijl wijst aan waar je de instelling voor permissies kunt wijzigen

Deze permissies hebben de volgende uitwerking.

  • Read permissies laten toe het Runbook te bekijken en te draaien.
  • Write permissies staan wijzigingen aan het Runbook toe.
  • Full Control geeft ook de mogelijkheid om de permissies zelf te wijzigen.

Deze permissies integreren natuurlijk met lokale of Active Directory-groepen. Zo kun je bijvoorbeeld een Read-only groep voor beheerders maken en een of meerdere Read-Write groepen voor ontwikkelaars.

Daarnaast speelt natuurlijk de vraag, onder welke accounts de Runbooks zelf worden uitgevoerd en welke rechten ze nodig hebben voor het uitvoeren van hun taken. Dit zal behandeld worden in een toekomstige blogpost!

De vertaling van BPMN naar Runbooks

Posted on by
Reply

Wanneer we advies uitbrengen voor klanten maken we praktisch altijd gebruik van procesvisualisaties. Dat zijn plaatjes die helpen om de processen van een bedrijf inzichtelijk te maken. De tekentechniek die we hiervoor gebruiken is BPMN, Business Process Model and Notation.

Deze methode helpt om op basis van een aantal basiselementen een goed overzicht te krijgen van alle stappen van een proces en op welke plek beslissingen worden genomen. De methode is flexibel genoeg om zowel op operationeel niveau alle details te kunnen modelleren, als ook om op strategisch niveau een helikopterview te kunnen geven.

Een BPMN-schema van het deployen (installeren) van een in een WAR-bestand verpakte Java/Tomcat applicatie. (Klik voor volledig formaat)

Het voorbeeld toont het proces dat hoort bij het uitbrengen van een nieuwe release van een webapplicatie door een hostingbedrijf. Tussen de verschillende stappen is er telkens communicatie met de klant die goedkeuring moet geven over de resultaten.

Bij het opstellen van dit proces waren alle stappen uit dit proces handmatig. Controle van de nieuw opgeleverde versie, het installeren en het communiceren met de klant was allemaal (duur) werk van specialisten.
Het voordeel van het in kaart brengen van zo’n proces is dat je hiermee al de eerste stap naar het automatiseren van het proces hebt gedaan.

Dit kan bijvoorbeeld met Orchestrator.

Een Orchestratro 2012 Runbook voor het deployment-proces. (Klik voor groter formaat)

Het BPMN-schema is nog duidelijk herkenbaar. De communicatie met de klant is vervangen door een object dat zich herhaalt en op feedback wacht. Bij ontvangst van een bevestiging wordt pas naar de volgende stap doorgegaan.

Hoewel in dit voorbeeld het hele proces geautomatiseerd is, zal dat niet altijd mogelijk zijn. Voor meer complexe releases zijn er bijvoorbeeld telkens gewijzigde aanvullende instructies. Een specialist zal die dan moeten uitvoeren.

Daarnaast is het aan te bevelen om het Runbook op te delen in kleinere onderdelen. Deze kunnen dan afhankelijk van de omstandigheden los worden aangeroepen door een overkoepelend Runbook. In de praktijk zullen met name de stappen tussen de twee goedkeuringsmomenten als los Runbook worden ingericht.
In een blog post gaat het wat te ver om alle implementatiedetails te bespreken. De essentie is dat het in kaart brengen van het proces en dit vervolgens te automatiseren, duidelijk een tijdsbesparing oplevert en daarmee de kosten drukt. Een specialist zal hierdoor zich niet meer met de standaard activiteiten bezig houden maar kan zich richten op verstoringen, aanvullende instructies en uitzonderingssituaties.

Orchestrator 2012 binnen de Microsoft System Center Suite

Posted on by
Reply

De hoofdinsteek van Microsoft System Center is traditioneel gericht op het beheren van de infrastructuur van IT omgevingen. Tools zoals de Configuration Manager, Endpoint Protection en Data Protection Manager zijn daar op gericht.

In System Center 2012 is er een duidelijke verschuiving zichtbaar richting functionaliteiten voor “de cloud”. Dit is om aansluiting te houden bij de ontwikkelingen in het veld.

System Center Orchestrator 2012

Een van de belangrijkste nieuwe tools is Orchestrator (voorheen Opalis), die gebruikt kan worden als spin in het web voor het automatiseren van een datacenter.

In een eerdere blog post is al ingegaan op het onderwerp orchestratie, nu zal ik vooral in gaan op de kracht van Orchestrator en hoe het product zich verhoud tot de rest van de System Center Suite.

De interactie tussen Orchestrator en de overige onderdelen werkt twee kanten op. Zo kan Operations Manager met behulp van het specifieke Management Pack ingericht worden om de werking van de Orchestrator te monitoren.

Nog veel krachtiger zijn de Integration Packs die voor Orchestrator beschikbaar zijn. Deze Integration Packs bieden een gemakkelijke manier om met, standaard objecten binnen Orchestrator, API’s en andere functionaliteiten van de System Center Tools te communiceren.

Het eindresultaat kan een verregaand geautomatiseerde en schalende omgeving zijn. De Orchestratie voegt extra intelligentie aan de processen van het Datacenter toe.

In de praktijk

Bij moderne toepassingen zijn vaak meerdere applicaties betrokken. Een webplatform bestaat meestal uit meerdere webservers, applicatieservers en databaseservers. Op basis van informatie uit Operations Manager kan bijvoorbeeld het signaal komen dat (op basis van een business rule) een omgeving opgeschaald moet worden.

Door een Runbook in Orchestrator in te richten kan dit signaal geautomatiseerd opgepakt worden, of kan zelfs de business logica in Orchestrator geconfigureerd worden. Met behulp van Integration Packs kunnen zo geautomatiseerd extra VM’s (met VMM) worden aangemaakt en daarnaast van de juiste configuraties worden voorzien inclusief de benodigde software. Tegelijkertijd kan ook de reguliere monitoring geregeld worden.

Interacties

In bovenstaande weergave zijn de interacties gesimplificeerd weergegeven. Binnen het Datacenter wordt gebruik gemaakt van de tools van System Center. Operations Manager, Orchestrator en Service Manager zijn er voor het gemak even uitgelicht en uitvergroot om de verhouding tussen de producten goed weer te kunnen geven.

Vanuit het Datacenter wordt continue status informatie doorgegeven aan Operations Manager. De Operations Manager vertaalt deze informatie, zoals belasting van webservers naar een event (“te hoge belasting”) en geeft dit vervolgens door aan Orchestrator als signaal. Op basis van de geconfigureerde business logic bepaalt een Orchestrator Runbook hoeveel webservers er bijgeschakeld moeten worden en stuurt deze opdrachten naar Virtual Machine Manager in het Datacenter en controleert of dit daadwerkelijk uitgevoerd wordt.

Interessant is dat Orchestrator zelf ook status informatie ontvangt en daardoor intelligentie in de opdrachten kan stoppen. Zo kunnen de precondities gecontroleerd worden voor het succesvol uitvoeren van een actie: is er bijvoorbeeld wel voldoende capaciteit op storage aanwezig op een host? Zo niet, dan zal er eerst extra storage geprovisioned moeten worden. Zo kan Orchestrator het gehele proces end-to-end controleren en begeleiden.

Externe bronnen

Orchestrator is niet alleen intern op het DataCenter gericht, maar kan ook communiceren met externe bronnen. Een voorbeeld is dat een incident van Service Manager gelogd kan worden, maar ook (aangegeven met de gestippelde lijnen) kan interacteren met overige niet-infrastructurele bronnen. Hierbij kun je denken aan het toevoegen van extra informatie op basis van de business logic om de juiste prioriteit aan een incident te geven. Een ander voorbeeld is het doorgeven van de procesvoortgang of het versturen van een rapportage naar de verantwoordelijke leidinggevende.

Als laatste vind ik het belangrijk om te melden dat het toevoegen van krachtige Orchestratie en intelligentie niet betekent dat de beheerder buitenspel komt te staan. In tegendeel! Hij of zij gaat juist een centrale rol vervullen. Niet als procesuitvoerder maar als proces designer en bewaker. Op deze manier kan een beheerder veel effectiever en efficiënter zijn werk uitvoeren.

De (on)mogelijkheden van Commandline en Integration Pack wizards

Posted on by
Reply

De kracht van System Center Orchestrator komt voort uit de vele beschikbare objecten die standaard aanwezig zijn. Met deze objecten hun je bijvoorbeeld gegevens uit een database halen, een webservice aanspreken, of een programma opstarten. Deze standaardobjecten zijn geschikt voor alle denkbare processen. Om het aantal stappen in een proces terug te brengen, kun je custom objecten bouwen.

Voor eenvoudige handelingen is het vaak handiger om het standaard object binnen Orchestrator te gebruiken. Hiermee kan een maatwerk .NET library aangesproken worden of een PowerShell script.

Wanneer een specifiek programma in veel verschillende processen terugkomt, is het verstandig om hiervoor een custom object aan te maken, zodat het eenvoudig hergebruikt kan worden.

Soms heeft een fabrikant van third-party software zelf een Integration Pack gemaakt. Voor Opalis, de voorganger van Orchestrator, zijn ruim meer dan 30 verschillende Integration Packs beschikbaar.

Voor System Center is er ook een groeiende verzameling beschikbaar. Microsoft geeft zelf het goede voorbeeld door Integration Packs te bouwen voor alle producten binnen de System Center Suite, Active Directory en VMware. Deze zijn op System Center Central te downloaden.

Wanneer er geen standaard Integration Pack beschikbaar is, kun je gebruik maken van de Orchestrator Integration Toolkit. De basis hiervan zijn twee wizards. De Commandline Activity Wizard, die van commandline-opdrachten een .net-dynamic link library maakt. En de Orchestrator Integration Pack wizard. Op basis van methoden uit een .net-dll (zoals gegenereerd door de Commandline Wizard) maakt deze wizard System Center Orchestrator objecten.

Het is wel belangrijk om de limieten van de Wizards te erkennen. Het is primair een mogelijkhed om een API of commandline aan te spreken. De kwaliteit van de output en mogelijkheden tot verwerking ervan hangen in grote mate af van de software zelf.

In de praktijk betekent dit dat bij inzet van custom objecten altijd een afweging gemaakt moet worden waarin het beste geïnvesteerd kan worden: Configureerwerk in de Orchestratie of maatwerk in .NET zodat met weinig configureerwerk krachtige acties kunnen plaatsvinden.

Optimalisatie in de praktijk

Posted on by
Reply

Recent onderzoek van de universiteit Twente bracht aan het licht dat bijna een half uur per dag aan productiviteit verloren gaat door de ICT-problemen van medewerkers. Het hele onderzoeksrapport (getiteld “CTRL ALT DEL”) is publiek beschikbaar.

Alhoewel het rapport in de eerste plaats de inzet van meer ICT-training suggereert, is dit natuurlijk ook een uitdaging voor procesoptimalisatie.
De werknemers van een bedrijf zijn nou eenmaal in de eerste plaats experts op hun eigen werkgebied, bijvoorbeeld in accounting of op gebied van logistiek. Het is irreëel om van werknemers te verwachten dat ze daarnaast ook nog eens uitgebreide ICT-expertise opdoen. Dit zou eenzelfde situatie opleveren dat een ICT-medewerker de financiele administratie zou voeren. Evenzo is het ongewenst dat de boekhouder zich bezig houdt met het installeren van printers en een secretaresse even tussendoor netwerkconnectiviteit gaat troubleshooten.

Wat natuurlijk wel wenselijk is, is dat de basis ICT-vaardigheden goed ontwikkeld zijn.

Waar procesoptimalisatie zich primair kan bewijzen is bij het structureel voorkomen van “de kleine” ICT-problematiek. Door een proces volgens een goede standaard in te richten, zullen medewerkers minder vaak buiten hun expertise-gebied opereren. Door middel van Orchestratie gekoppeld aan goede procesmonitoring kunnen ICT-problemen, zoals netwerkproblemen, tijdig opgemerkt worden en zonder ingrijpen van medewerkers worden opgelost.

Wanneer er desondanks ICT-problemen optreden die niet automatisch kunnen worden afgehandeld, dan is een optimaal proces ook nuttig. Een goed proces voorziet namelijk dat zo snel mogelijk de juiste personen worden ingeschakeld. Niets frustrerender natuurlijk, dan dat een afdeling een half uur met een probleem heeft lopen worstelen, als dit binnen 5 minuten door de juiste persoon had kunnen worden opgelost. Monitoring op beschikbaarheid van de juiste resources vermindert de tijdsverspilling in dat geval met een factor 6!

Ook tijd besparen doe je dus door middel van een goed proces!

Orchestrator 2012 Architectuur: Capaciteitsplanning

Posted on by
Reply

Voor het plannen van het aantal Runbook Servers binnen een System Center Orchestrator omgeving bestaan verschillende richtlijnen. Standaard heeft Microsoft dit erg conservatief ingesteld op maximaal 50 actieve Runbooks per Runbook Server.

http://technet.microsoft.com/en-us/library/hh420378.aspx

De basis van de beperking ligt in het opstarten van PolicyModule.exe. Dit proces is al eerder aan bod gekomen in een vorig blog. Voor een goede capaciteitsplanning is het dus van belang om dit proces goed te begrijpen.

Een voorbeeld runbook.

Ter illustratie: We hebben een Runbook voor batchverwerking van adressen. Het Runbook controleert iedere 5 minuten een fileshare, of er een tekstbestand met adressen is aangeleverd. Deze worden vervolgens verwerkt tot een Excel-file die per e-mail wordt doorgestuurd.

Bij het (her)starten van de Runbook Service wordt onmiddelijk een PolicyModule.exe-proces opgestart. Dit proces monitort de aangegeven fileshare op aanwezigheid van het bestand.

Orchestrator 2012 Runbook in Process Explorer

Zodra het bestand is aangeleverd, wordt er eerst een tweede PolicyModule.exe-proces gestart, dat de directory opnieuw gaat monitoren (te beginnen op het volgende interval), terwijl het oorspronkelijke proces de workflow zal doorlopen om uiteindelijk de e-mail met Excel-file te versturen en daarna te termineren.

Zolang de verwerking uit het voorbeeld loopt, zijn er dus 2 processen actief voor het uitvoeren van dit specifieke Runbook. Beide processen tellen mee tegen de eerder genoemde limiet van 50. Eigenlijk is de limiet dus niet het aantal Runbooks, maar het aantal draaiende PolicyModule.exe-processen!

Voor capaciteitsplanning is het dus ook van belang te weten hoe lang een Runbook doorgaans doet over zijn uitvoering. Runbooks met een hoge frequentie van monitoring en een lange doorloop in uitvoering zorgen ervoor dat je sneller tegen de maximumlimieten aanloopt.

En het is ook van belang wanneer een Runbook andere Runbooks aanroept. Immers, zolang een Runbook wacht op terugkoppeling, zal het proces blijven draaien.

Tenzij je er zeker van bent dat monitorende Runbooks niet tegelijkertijd met elkaar draaien, is het dus van belang om niet meer dan de helft van de limiet van je runbooks aan monitor-events te koppelen. Een mogelijke work-around is om niet ieder runbook een eigen monitor te geven, maar om een enkel monitor-runbook de verschillende runbooks als ad hoc proces op te laten starten. Hiermee bespaar je een flink aantal processen aan overhead.

Overigens is de limiet van 50 processen geen keiharde, maar kan je deze met de hand aanpassen. Lees hiervoor de instructies van Technet.

Orchestrator 2012 architectuur: Runbook Service

Posted on by
Reply

Naast de high level componenten is er ook een uitvoerende component binnen de System Center Orchestrator 2012. Deze rol wordt vervuld door zogenaamde Runbook Servers. Door hun functie hebben ze een wat bijzondere positie binnen de architectuur. Zij vormen namelijk de interface met bijvoorbeeld databases en fileshares. Daarnaast zorgen ze er voor dat programma’s starten of data gemuteerd wordt. Het regelen van toegang vanuit de RunBook Servers naar deze resources is van vitaal belang!

system center orchestrator 2012 architecture

De complete architectuur. In deze post wordt ingegaan op de Runbook Servers, aangegeven met de rode pijl.

Vanwege de belangrijke rol binnen de architectuur is het dus goed om te weten hoe een Runbook Server zelf zijn taak uitvoert.

Op de server draaien twee Orchestrator-gerelateerde processen: de “OrchestratorRemotingService” en de “Runbook Service”. De Remoting Service handelt communicatie met de Management Server af. De Runbook Service zorgt er voor dat de Runbooks daadwerkelijk draaien op de desbetreffende machine.

Een belangrijk punt hier is dat de Runbook Service geen communicatie heeft met de Management Server, maar direct met de Orchestrator-database. Daarom moet een Runbook Server op de juiste poorten toegang krijgen tot de Orchestrator database (Standaard SQL Server poort is TCP 1433). Binnen een lokaal netwerk zal dit geen probleem opleveren, maar binnen een gedistribueerde omgeving kunnen firewalls roet in het eten gooien. Een best practice is om Runbook Servers en de Orchestrator database binnen één site van een Active Directory-domein te draaien. Op deze manier hoef je op externe firewalls alleen toegang voor resources buiten de ‘perimeter’ te regelen. Een bijkomend voordeel is dat de latency binnen een site beperkt blijft. De communicatie tussen Runbook Server en database is in principe als real-time te beschouwen.

De Runbook Service zelf voert overigens niet direct Runbooks uit. Hiervoor wordt namelijk iedere keer (onder hetzelfde user-account als de service zelf) een apart proces gestart: PolicyModule.exe. De naamgeving laat een erfenis van Opalis, de voorloper van System Center Orchestrator 2012, zien. In vorige versies werden Runbooks namelijk Policies genoemd. Het is goed mogelijk dat in een volgende versie van Orchestrator PolicyModule.exe door RunbookModule.exe vervangen wordt.

In een vervolgpost ga ik dieper in op PolicyModule.exe en de relatie met capaciteitsplanning.