SCOM & SCCM

PAYBACK TIME!

Det er hørt før…• ”Vores SCOM løsning støjer helt vildt med masser af irrelevante 

alarmer – vi kan ikke se skoven for bare træer.”

• ”Vi har slukket for notifikationer i SCOM, da vi bliver vækket midt om natten af alarmer. Konen er p…. sur.”

• ”Vores database log‐drev løb fuld og så stoppede ERP‐systemet, hvorfor opdagede vi ikke det i overvågningen?”

• ”Overvågningen viser ikke tilstanden af vores forretningskritiske systemer, men en masse komponenter.Vi har ikke noget overblik.”

Det er hørt før…• ”Når vi ruller arbejdspladser ud, skal vi lige rette dem lidt til efterfølgende, 

så de er klar til brugerne.”

• ”Vi ringer til brugerne for at få deres kodeord, så vi kan logge ind og rette de sidste ting på arbejdspladsen.”

• ”Nogle programmer installeres manuelt, da vi ikke har nået at lave installationspakker endnu.”

• ”Vi lader nogle applikationer opdatere sig selv, da vi ikke gider at lave opdateringspakker herpå så tit.”

• ”MSI‐formatet er rigtigt fedt, man kan jo alt. Jeg håber, at jeg får tid til at komme i dybden med det.”

Hvem er vi?• Microsoft Guld Partner• Fokus på System Center• Dyb teknisk kompetence som 

afsæt• Erfaringer fra den ”rigtige verden”

• Vores edge: – Tænke ”ud af boksen”– Skabe værdi– Forankring

Søren Egtved Lassen• Konsulent• Automation og integration• 10+ års erfaring med System Center

AgendaSystem Center Operations Manager• Design og implementering• Baselining / Støj • Forretningsdrevet overvågning• Automatisering

System Center Configuration Manager• Værdien af Desktop Management• Klassiske tidsrøvere• Repackaging• Patch Management og automation

Opsummering

Mål og formside 6

• Dele ud af erfaringer opsamlet i SCOM‐ og SCCM‐projekter• Illustrere forløb og løsningsmuligheder• Give praktiske eksempler• Spørg gerne undervejs eller efterfølgende i pausen

• Advarsel: mange slides – få demoer – beklager

SCOM og SCCM

.

• De ”klassiske” System Center‐discipliner

• Har defineret System Center‐begrebet

• Største udbredelse

Overblik fra 10 Km’s højdeOperations Manager• Server‐ og 

systemovervågning• Integration• Konsoller• Alarmering• Rapportering• Visualisering

Configuration Manager• Device Management• Deployment (OS + Apps)• Patch Management• Asset Management• Metering & Compliance• Endpoint Protection

Typiske udfordringerOperations Manager• Alarm støj• Skalering – topologi• Ukomplet overvågning• Tilpasning til organisation 

og forankring heri

Configuration Manager• Manuelle procedurer 

~ manglende automation• Inkonsistente patch 

management‐rutiner• Degradering af værdi• Lang leveringstid på nye 

softwareprodukter og ‐versioner

System Center Operations ManagerDesign og implementering• Topologi er afgørende for kapacitet og skalering• Operations Manager 2012 løser (tidligere) udfordringer (RMS i HA)

• Anbefaling: Tænk multi‐tiering fra starten

• Basér overvågning på forretningskrav

System Center Operations ManagerStøjkilder• Manglende baselining• Management Pack konfiguration• Sikkerhed (RunAs Accounts/Profiles)• Rigtige mænd læser ikke (MP‐)vejledninger• ”Usual Suspects” MPs:

– Windows Base OS– Exchange– SharePoint– SQL Server

Management packs• Modul indeholdende viden 

om overvåget teknologi• Leveres af software/hardware‐

producent eller 3.‐partsleverandør

• SCOM indeholder værktøjer til at udarbejde egne MPs

• MP Definerer:• Discovery• Health model• Monitors og alarmer• Præsentation• Automation• Rapporter• Overrides

Mere støj…• Overvågning kan blive påvirket af:

– Patch management– System vedligehold– Hardware service

• Maintenance Mode– Manuelt– Automatisk – f.eks. via Orchestrator

Baselining• En proces hvor Operations Manager 

”lærer” it‐miljøet at kende• Definition af normal tilstand• Initiel baselining foretages typisk som 

en del af implementeringsprocessen• Løbende baselining bør være en del 

af driftsvedligeholdelsen

Hvorfor baselining?

Non‐baselinedNon‐baselined BaselinedBaselined

VS.

System Center Operations ManagerAnbefales: Trinvis implementeringsforløb

Design Installation Management Packs step 1 Baselining step 1 Management 

Packs step 2 Baselining step 2 Osv.

Initiel baseliningAnbefalet proces• ”Bottom up” i teknologistakken• Gruppér Management Packs• Fejljusteringer i underliggende 

lag har afsmittende effekt i højere liggende lag

• Tålmodighed‐ hastværk er lastværk

Forretningsapplikationer

Middleware

Infrastruktur services

Net services

OS

Hardware

Inden for hvert trin…• Tilpas alarmer:

– Ændring af grænseværdier

– Ændring af severity– Deaktivering af irrelevante målinger

– Korrigér fejlkonfigurationer

• Opsaml alarmer over en periode

• Evaluer alarmer, f.eks.– Relevans– Grænseværdier– ”severity”

• Definér jeres normal tilstand

• Mål: 1:1 alarm:ticket ratio

Drift ‐ løbende baselining• Ingen it‐installation er statisk

• F.eks. ændringer til:– Produkter/versioner– Belastningsprofiler– Ændrede forretningsprocesser

• Forbered evt. ændringer og reagér hvis overvågningen rapporterer afvigelser

Forretningsdrevet overvågning• Forretningen definerer 

”hvad der er vigtigt”• Nedbrydning i systemer og 

komponenter er vigtig for at identificere det, der bør overvåges

• ”Top‐down” 

Forretning

Processer

Systemer

Komponenter

Hvad kan overvåges?”I boksen”:• Windows Server OS• Windows Server Apps• Unix/Linux• Netværk/SNMP• Syslog• .NET 

applikationsovervågning

Andre (eksempler):• Citrix• VMware• Hardware• 3.‐parts platforme• Integration imod andre overvågningsplatforme

Hvad med ”det andet”?• Templates ‐Wizards

– Windows Services– Windows‐processer– Web‐applikationer– TCP‐port– Linux logs/processer– OLE DB databaseopslag

• System Center Orchestrator

• Egne MPs:– Authoring space– Authoring console

System Center Orchestrator• Automatiseringskomponent i 

System Center• Tidligere kendt som Opalis• Nem integration imod System 

Center og andre platforme• Integration igennem 

Integration PacksDEMO

Find problemet…• End‐to‐end systemovervågning• Distribution af prober –

”Watcher Nodes”

• Syntetiske transaktioner• Slutbrugerperspektiv• F.eks. Web, DB eller integration med test tools

OrgC.company.com

OrgB.company.com

dmz.company.com

SCOM01 SCOM02

OrgA.company.com

Vis det…• Dashboards, Diagrams og 

Distributed Applications• Mulighed for at kombinere 

overvågningsdata i en sammenhæng• Relationer og vægtning imellem 

løsningskomponenter• Kan integreres med SharePoint og 

Visio

Desktop Management ~ SCCM• Automatisering og rationalisering• Reducere manuelle arbejdsgange

– Udrulning  ‐ OS + software– Vedligehold ‐ software– Vedligehold ‐ patch management

• Fjerne kompleksitet fra vedligehold

Desktop ManagementTypisk implementeringsforløb

Design Installation af løsning Forankring Application Repackaging

RessourcekrævendeRessourcekrævende

RationaliseringApplikationskonsolideringFaser:

1. Indsamling af det, der er installeret, og det der bruges – SCCM er din ven 

2. Kill! – Fjern applikationer som (næsten) ikke bruges

3. Konsolidér applikationer med overlappende funktioner

Software‐distribution ‐mål• Høj færdiggørelsesgrad• Ingen manuelle arbejdsgange

• Hensigt: Arbejdspladser kan geninstalleres på et givent tidspunkt uden tab af opsætninger og funktionalitet

Desktop Management ‐ udfordringer• Forretningskrav ændrer sig• Behov for nye/andre softwarepakker• Høj opdateringsfrekvens på eksisterende 

pakker• It‐afdelingen kan ikke følge med, så 

manueller procedurer bliver nødvendige for at imødekomme forretningskrav

• Visse softwareprodukter kan være svære at automatisere / tilpasse

• MSI repackaging er ofte en tung/dyr proces

• Resultat: Løsning ”sander til”År 1 År 2 År 3 År 4

Værdi over tid

SOFT2go• Koncept og teknologi:

– Pakkeværktøj– Web service– Automation i SCCM

• Baseret på abonnementsvilkår

DEMO

System Center Configuration ManagerOptimering via SOFT2go

Design Installation af løsning Forankring Application Repackaging Vedligehold/nye 

pakkerVedligehold/nye 

pakkerVedligehold/nye 

pakkerVedligehold/nye 

pakker Etc.

Drift

Patch Management• PM i SCCM 2012 er enklere og mere overskueligt

• Færre begreber og trin end i tidligere versioner af SCCM (yay!)

• Nyt: Automatic Deployment Rules

Patch Management ‐ basis• Det anbefales altid at teste 

patches før udrulning• Med ADR er det nemt at 

definere test/prod‐udrulning:– Pilotklienter udrulles efter 

”Patch Tuesday”– Produktion udrulles f.eks. 14 

dage forskudt• Samme gælder servere• Brug Maintenance Windows i 

SCCM til at styre udrulning og genstartstidspunkter

Patch Management ‐ avanceret• Udfordring:

– Udrulning af patches i multi‐tieredapplikation

– Flere datacentre– Applikationslag er indbyrdes afhængige– Begrænsede tidsrum for gennemførsel af 

patches– Front‐end servere skal ”draines” for 

brugersessioner inden patching– Middle‐tier servere skal have services 

stoppet i en specifik rækkefølge for at sikre at batchkørsler afvikles korrekt

• Problemer:– Udrulning på passende tidspunkter– Genstart i rette rækkefølge– Afvikling af jobs før og efter patching

Front-end

Middle-tier

Back-end

Lokation Vest Lokation Øst

Patch Management ‐ avanceretLøsning: • SCCM + • Orchestrator + • Små scripts +• Lidt smarte Runbooks 

Patch Management ‐ avanceret• Kør jobs før/efter: 

– Stoppe/starte services– Flytte ressourcer– Afvikle køer– ”Drain”

• Kontrol:– Flow– Rækkefølge– Advisering

Opsummering• Kom godt fra start• Tålmodighed og vedholdenhed lønner sig 

• Automatiser, integrer og visualiser

• Visionær og moden teknologi• edgemo fokus på værktøj og proces

Spørgsmål