A System Center Mindenkinek csapata mostantól a Cloud Platform oldalon fogja a cikkeit publikálni.

Ezen a blogon levo tartalmaink továbbra is elérhetoek maradnak, de az új cikkek már a  Cloud Platform Blog oldalon jelennek majd meg.

A program képes önálló gépeket, valamint Operations Manager Management Group-hoz tartozó agenteket figyelni, tolük információt gyujteni. SCOM integráció esetén SP1 Update Rollup 6 (de inkább 7) vagy R2 Update Rollup 2 (de inkább 3) a minimum követelmény.

A teljes listát a https://msdn.microsoft.com/library/azure/dn884656.aspx linken találjátok.

Az oldal a https://preview.opinsights.azure.com keresztül érheto el, és mind Explorer-rel, mind Firefox-szal használható.

Az elso teendonk egy workspace létrehozása, amelyhez a vagy a Microsoft vagy a szervezeti fiókunkat használhatjuk.

A workspace létrehozása után össze kell kötnünk a Management Group-ot az Operational Insights szolgáltatással. Ehhez nyissuk meg az Operations Console-t, és navigáljunk az Administration - Operational Insights Connection nézetre. Amennyiben még nem telepítettük a SCOM 2012 R2 Update Rollup 5-öt (https://support.microsoft.com/kb/3023138), a konzol továbbra is System Center Advisor-t fog mutatni.

A kapcsolatot beállításait a Configure Operational Insights opcióra kattintva állíthatjuk be.

Eloször megadjuk a használandó accountot, majd kiválasztjuk a konfigurálandó workspace-t.

Ahhoz, hogy az Operational Insights elemezni tudja az agentekrol származó adatokat, azokat hozzá kell adni a kapcsolathoz. Ezt az Add a Computer/Group menünk keresztül érhetjük el.

A workspace és az agentek regisztrációja után az Operations Console-ban a Monitoring -- System Center Advisor alatt található állapot nézet segítségével követhetjük nyomon a komponensek állapotát.

A SCOM oldali konfigurálással ezzel készen is vagyunk, a munka további részét az Operational Insights portálon keresztül fogjuk elvégzeni.

Ha már konfiguráltuk a workspace-t, és esetleg küldtünk fel adatokat, akkor belépéskot az alábbihoz hasonló kép fogad minket:

Az Operational Insights "magját" az Intelligence Packnek nevezett monitorozási szabálygyujtemény adja. Mindegyik Intelligence Pack egy bizonyos technológiára (pl. SQL, Lync, SharePoint) vagy szcenárióra (pl. Capacity Planning, Log Management) van optimalizálva. Az elérheto Intelligence Pack-ek száma folyamatosan bovül, érdemes rendszeresen áttanulmányozni a galériában található listát.

Amikor egy Intelligence Pack-et regisztrálunk a háttérben a funkcionalitásához szükséges Management Pack-ek kerülnek be a Management Group-unkba, illetve a monitorozott agentekre.

A munkát innen a SCOM teljesen automatikusan végzi, az agentek a Management Pack-ekben tárolt monitorok és szabályok alapján begyujtött adatokat elküldik a Management Serverüknek, amely periodikusan feltölti az Operational Insights portálra. Fontos, hogy ezek az adatok nem kerülnek bele a SCOM adatbázisaiba, így nem növelik azokat.

A folyamatról a Management Server OperationsManager event logjából tudunk részletes információkhoz jutni. A könnyebb átláthatóságért érdemes a forrást az Advisor kategóriára szukíteni.

Az agentekrol periodikusan kap(hat)unk riasztásokat, attól függoen, hogy az Insights milyen konfigurációt talált, például figyelmeztet, ha egy adatbázist nem mentettünk a létrehozása óta:

Ha használjuk az SQL Server Intelligence Packet, a SCOM az alábbi riasztást dobhatja SQL 2012 monitorozása esetén.

Ahogyan a leírás is mondja, a hiba oka az, hogy az Operational Insights a Local System fiók nevében próbál az SQL 2012 instance-hoz csatlakozni, amely, ellentétben a 2005 vagy a 2008 (R2) verziókkal, már nem tagja alapból a Sysadmin szerepkörnek, így a kapcsolódás sikertelen lesz. Egyik megoldás, hogy a Local System login-t belerakjuk a Sysadmin role-ba, a másik, talán szebb is :), hogy egy megfelelo jogosultsággal rendelkezo Run As Account-ot társítunk a Microsoft System Center Advisor SQL Assessment Run As Profile-hoz.

Ehhez eloször hozzuk létre a Run As Accountot, és adjuk meg, hogy melyik Windowsos fiókot fogja használni, és jutassuk el a monitorozandó agentekhez:

Ha ezzel kész vagyunk, adjuk a Run As Accountot a Run As Profie-hoz.

Miután az adatokat felkerültek az Operational Insights portálra, az elemzési ido után a megfelelo Intelligence Pack-re kattintva nézhetjük meg a különbözo kategóriák összesített eredményeit:

Az egyes alpontokat kiválasztva részletes információt kapunk a felfedezett jelenségrol, az érintett objektumokról, és a javasolt megoldásokról.

Ha kiválasztunk egy adott objektumot, akokr a portál megmutatja az összes hozzá tartozó pontot:

Remélem, sokaknek elnyeri a tetszését ez az új adatelemzési lehetoség, és minél többen próbálják majd ki a közeli jövoben.

Zárásul összegyujtöttem néhány hasznos, a témával kapcsolatos linket:

Operational Insights dokumentáció:

https://msdn.microsoft.com/en-us/library/azure/dn884662.aspx

Operational Insights FAQ:

https://azure.microsoft.com/en-us/services/operational-insights/faq/

Operational Insights árazás:

https://azure.microsoft.com/en-us/pricing/details/operational-insights/

Tamás

Errol van egy rövidke kis leírás a Techneten (https://social.technet.microsoft.com/wiki/contents/articles/24595.operations-manager-dashboard-script-widgets.aspx#PowerShell_Grid_Widget) érdemes átolvasni, illetve a példát megnézni gyakorlatban.

A cikkben lévo példa arra mutat lehetoséget, hogy hogyan tudunk megjeleníteni SCOM objektumokat egy PowerShell widgetben. Viszont arra nem, hogy hogyan tudunk Alerteket kilistázni. A gond abból származik, hogy a ScriptContext objektum CreatefromObject metódusa egy Operations Manager osztály egy példányát képes megjeleníteni ebben a vezérloben és az Alert-ek nem ilyen objektumok.

Ehhez a ScriptContext objektum CreateInstance metódusa fog kelleni, ezzel képesek vagyunk saját tartalom megjelenítésére a widgeten belül, nézzünk erre egy egyszeru példát:

$alerts = Get-ScomAlert | ? {$_.resolutionstate -eq 0}

 foreach($alert in $alerts){

    $dataObject = $ScriptContext.CreateInstance("xsd://one!dummy/string")

    $dataObject["Id"] = [string]($alert.ID)

    $dataObject["Name"] = [string]($alert.Name)

    $ScriptContext.ReturnCollection.Add($dataObject)

    }

A példa meg fogja jeleníteni azokat az Alert-eket melyek 0-s resolution state-tel rendelkeznek. Itt egy dologra szeretném felhívni a figyelmet, hogy a vezérlo használatakor mindig szükség van egy Id mezore, ami egyedileg azonosítja az adott sort a widgeten belül. Esetünkben az Id oszlop az alert egyedi azonosítóját használja erre a célra, mely nem is jelenik meg a nézetben.

Ez viszont erosen hiányos, mivel csak az Alert-ek nevét jeleníti meg, semmilyen más adat nem látszik a vezérlon. Ezt viszonylag könnyen tudjuk bovíteni a $dataObject[””] sor ismétlésével:

$dataObject["TimeRaised"] = [string]($alert.TimeRaised)

Már csak egy feladatunk akadt, az pedig Severity információ megjelenítése. Ehhez a ScriptContext objektum CreateWellKnownType metódusa fog a segítségünkre szolgálni. Ezzel tudunk speciális objektumokat létrehozni a vezérlon belül (https://social.technet.microsoft.com/wiki/contents/articles/21625.scriptcontextobject.aspx#CreateWellKnownType)

Az alábbi script részlet kiegészíti a fenti példát pár plusz információval (az ikonnal is, mely a riasztás szintjét jelzi)

$alerts = Get-ScomAlert | ? {$_.resolutionstate -eq 0}

foreach($alert in $alerts){

    $dataObject = $ScriptContext.CreateInstance("xsd://one!dummy/string")

    $dataObject["Id"] = [string]($alert.ID)

    $dataObject["Severity"] = $ScriptContext.CreateWellKnownType('xsd://Microsoft.SystemCenter.Visualization.Library!Microsoft.SystemCenter.Visualization.OperationalDataTypes/SeverityType',($alert.severity))

    $dataObject["Name"] = [string]($alert.Name)

    $dataObject["State"] = [string]($alert.ResolutionState)

    $dataObject["TimeRaised"] = [string]($alert.TimeRaised)

    $ScriptContext.ReturnCollection.Add($dataObject)

     }

Érdemes kihasználni ezt az új képességet, hiszen a Widget segítségével, gyakorlatilag bármilyen adatot össze tudunk gyujteni és meg tudunk jeleníteni az Operations Console-n. A késobbiekben még erre fogok példákat hozni.

Az SCCM 2012 R2 beépített eszközt biztosít számunkra a kész operációs rendszer image-eink rendszeres frissen tartására - operációs rendszer frissítések telepítésére. A tipikusan két-lépcsos OSD folyamatunk elso lépésében eloállítunk egy referencia image-et, majd ezt a referencia image-et használva alapnak, telepítjük a saját szájízünk szerint testreszabott munkakörnyezetet. Az ily módon kialakított telepítési folyamat második fázisában lehetoség van az aktuálisan elérheto és publikált frissítések telepítésére. A teljes telepítési folyamat gyorsítható, ha idorol-idore a jóváhagyott frissítéseket belegyúrjuk a referencia image-be. Erre ad megoldást az Offline Servicing funkciója az SCCM-nek, mely segítségével offline-módban, azaz a referencia image újraépítése nélkül lehetoségünk van a frissítések telepítésére.

A folyamat menete a következo:

1. Operációs rendszer image kijelölése, majd a ’Schedule Updates’ opció kiválasztása

2. Ezután megjelennek az adott operációs rendszer verzióhoz passzoló, az SCCM-ben elérheto (=letöltött) frissítések a listában, amin igény szerinti szurés végezheto:

Az alábbi szempontokat érdemes figyelembe venni ennél a pontnál:

• • a listában az SCCM-re letöltött frissítések jelennek meg, melyek passzolnak az operációs rendszer verzióhoz

  • ezzel a módszerrel kizárólag olyan frissítések telepíthetoek, melyek támogatják a Component Based Servicing technológiát (Microsoft Vista SP2-tol támogatott), tekintettel arra, hogy maga a módszer a DISM eszközre épül

    SMS Provider logban látható a lekérdezés, amit a rendszer kiad a lista feltöltése során: 

    select * from SMS_SoftwareUpdate where IsOfflineServiceable = 1 and IsContentProvisioned = 1 and CategoryInstance_UniqueIDs in ("Product:d31bd4c3-d872-41c9-a2e7-231f372588cb") and CI_ID NOT IN (select UpdateID from SMS_ImageUpdateStatus where ImagePackageID = "00100007" and (UpdateStatus = 1 or UpdateStatus = 2 or UpdateStatus = 4 or UpdateStatus = 5))
    

     

3. A frissítés módjának konfigurációja az alábbi lapon teheto meg:

• tekintettel arra, hogy a muvelet diszk-intenzív érdemes ezeket a frissítéseket pl. estére idozíteni
• a Distribution Point frissítését szintén érdemes már itt bejelölni, nehogy elmaradjon...

4. Az indítást követoen az image-et felcsatolja a rendszer a C:\ConfigMgr_OfflineImageServicing\<csomag azonosító> könyvtár alá

• a ténylegesen használt meghajtó az alábbi cikkben leírtak szerint kiolvasható: https://blogs.technet.com/b/configmgrteam/archive/2013/07/15/customizing-offline-servicing-of-operating-system-images.aspx

5. A telepítés menetét az OfflineServicingMgr.log-ban nyomon lehet követni

• innen kiolvasható, ha egy adott frissítés nem kerül bele az image-be, (az ilyen frissítések többet nem jelennek meg a listában a folyamat ismételt, késobbi futtatása során)

6. Utolsó lépésként gyozodjünk meg arról, hogy az image frissült a Distribution Point-okon.

Ez a fajta megközelítés a tradicionális mentorendszerek esetében megszokott muködésbol fakad, ahol is minden egyes teljes mentés során jelentos adatmennyiség halad át a hálózaton – terhelve a mentett kiszolgálót, a hálózatot ill. a mento szervert magát. A DPM mentorendszer ezzel szemben jóval kisebb adatmennyiségeket mozgat meg a hálózaton a mentések során. A hálózat-kímélo muködés a Volume Shadow Copy (VSS) technológiának köszönheto, ugyanis minden mentés során – beleértve a ”teljes mentéseket” is – kizárólag az elozo állapothoz képest történt változásokat járatja meg a rendszer a hálózaton (a legtöbb diszk-alapú mentési típusra igaz ez az állítás, néhány kivételével). Ennek a hálózat-kímélo muködésnek köszönhetoen a legtöbb esetben nem indokolt a hálózati forgalmak szétválasztása még akkor sem, ha mentett adatforrásaink nem 10g Ethernet hálózatra csatlakoznak.

Amennyiben az adott környezett és mentési igények indokolttá teszik a hálózati forgalom optimalizálásának igényét, a jó hír az, hogy erre több alternatív lehetoség is rendelkezésre áll:

• elso és legfontosabb a mentések megfelelo ütemezése figyelembe véve az optimális terheléselosztást

• További DPM által kínált beépített funkciók:

  • hálózati sávszélesség szabályozás (https://technet.microsoft.com/en-us/library/jj628105.aspx#BKMK_Throttle)

  • adattömörítés (https://technet.microsoft.com/en-us/library/jj628105.aspx#BKMK_Compress) – itt érdemes figyelembe venni a mentett kiszolgáló oldali extra CPU terhelést

  • szinkronizációk indításának eltolása (https://technet.microsoft.com/en-us/library/jj628105.aspx#BKMK_Stagger)

  • manuális replika készítés (https://technet.microsoft.com/en-us/library/jj628105.aspx#BKMK_Replica)

• hálózati QoS megoldások

Az a tapasztalatom, hogy a fenti lehetoségek közül az esetek legnagyobb részében a különbözo adatforrások megfelelo csoportosításával, a mentések indításának gondos ütemezésével – figyelembe véve a párhuzamosan futó feladatokat – a hálózati terhelés optimalizálható.

Az alábbiak néhány példa azokra az esetekre, amikor tervezni kell a nagyobb hálózati terheléssel:

• replika készítés

• visszaállítás

• közvetlen disk-to-tape mentés

• BMR mentés

Angry Birds? Naná, hogy fent kell, hogy legyen a mobilomon!!

De nem akkor, ha mi menedzseljük azt az eszközt, igaz? Játéknak semmi helye – mi komoly dolgozó embereket akarunk magunk mellett tudni. Így mi nyugodtan játszhatunk közben… :)

Nos, ha meg szeretnénk szabadulni bizonyos alkalmazásoktól, és a kedves user ellenorzése nélkül biztosra tudni, hogy nem hülyeségre használja a telefonját/tabletjét (van ilyen??), akkor mostantól ezt Windows Phone 8.1 platformon megtehetjük!

Lássuk is, hogyan megy ez:

Eloször is keressük meg a kiszemelt alkalmazást, ami böki a szemünket. Ehhez mást nem kell tennünk, mint a Windows Phone Store-t meglátogatnunk. Az alkalmazás URL-jében fogjuk megtalálni az App GUID-ot, ezt jól jegyezzük fel valahová:

Nos, ha megvan a GUID, irány a ConfigMgr konzol, ahol egy Mobile device típusú Configuration Item-et fogunk létrehozni.

Itt viszont ne válasszunk ki semmit a felsorolt opciók közül, hanem csináljunk egyedi beállítást:

Adjunk hozzá egy új elemet, és itt nyomjunk rá a Create gombra

Miután adtunk egy hangzatos nevet neki, mindenképpen az OMA URI típust válasszuk ki, adattípusnak pedig String-et állítsunk be:

Az OMA URI, amit meg kell adni (ez minden alkalmazás korlátozási beállításnál ugyanaz):

./Vendor/MSFT/PolicyManager/My/ApplicationManagement/ApplicationRestrictions

Király, most már ott figyel a saját jópofa beállításunk a listában –érdemes a Configuration Item oszlop szerint rendezni:

Nyomjunk rá a Select-re:

Az érték minden esetben egy xml blob kell, hogy legyen, sortörés nélkül!!

A Spider-man Unlimited app letiltásához az alábbi xml szükséges – az App ProductID értéket a korábban leírt módon az App Store URL-bol másoltuk ki:

<AppPolicy Version="1" xmlns="https://schemas.microsoft.com/phone/2013/policy"><Deny><!-- Deny App - Spider-man --><App ProductId="{24f5b889-f7ea-467b-acbb-a2677ca81053}"/></Deny></AppPolicy>

Több alkalmazás korlátozása esetén egy xml-be kell minden alkalmazást beleraknunk (ld. alább a példáknál).

Ezután már csak a támogatott platformok listáját kell kiválasztanunk – Windows Phone 8.1-en kívül mást nagyon nem érdemes (persze attól még lehet, ha jólesik).

Végezetül a Configuration Item-et adjuk hozzá egy meglévo, vagy egy új Configuration Baseline-hoz, majd készítsünk egy Deploymentet a kívánt collection-re.

A korábban tanult módon triggereljünk egy policy kérést a WP 8.1 eszközön, majd voilá:

Ha netán mégis rá merek kattintani, egy elrettento üzenet fogad:

Néhány példa xml blob, amit tesztelésre érdemes használni:

Facebook
<AppPolicy Version="1" xmlns="https://schemas.microsoft.com/phone/2013/policy"><Deny><!-- Deny App - Facebook --><App ProductId="{82a23635-5bd9-df11-a844-00237de2db9e}"/></Deny></AppPolicy>

Skype
<AppPolicy Version="1" xmlns="https://schemas.microsoft.com/phone/2013/policy"><Deny><!-- Deny App - Skype --><App ProductId="{c3f8e570-68b3-4d6a-bdbb-c0a3f4360a51}"/></Deny></AppPolicy>

YouTube
<AppPolicy Version="1" xmlns="https://schemas.microsoft.com/phone/2013/policy"><Deny><!-- Deny App - YouTube --><App ProductId="{f8371fa2-4149-4a9d-98ce-f6916c8f008d}"/></Deny></AppPolicy>

Facebook/Spider-man
<AppPolicy Version="1" xmlns="https://schemas.microsoft.com/phone/2013/policy"><Deny><!-- Deny App - FaceBook --><App ProductId="{82a23635-5bd9-df11-a844-00237de2db9e}"/><!-- Deny App - Spider-man --><App ProductId="{24f5b889-f7ea-467b-acbb-a2677ca81053}"/></Deny></AppPolicy>

FaceBook/Spider-man/YouTube
<AppPolicy Version="1" xmlns="https://schemas.microsoft.com/phone/2013/policy"><Deny><!-- Deny App - FaceBook --><App ProductId="{82a23635-5bd9-df11-a844-00237de2db9e}"/><!-- Deny App - Spider-man --><App ProductId="{24f5b889-f7ea-467b-acbb-a2677ca81053}"/><!-- Deny App - YouTube --><App ProductId="{8371fa2-4149-4a9d-98ce-f6916c8f008d}"/></Deny></AppPolicy>

További részletek és útmutatás:

https://technet.microsoft.com/en-us/library/dn771706.aspx

Legközelebb jól adunk majd megint a WP 8.1-nek, és ami még maradt rajta, azt is letiltjuk…

A Windows Phone 8.1 frissítéssel megújult az OMA-DM kliens, ezáltal a menedzselheto beállítások listája is. Megújult? Alaposan kibovült.

Egy kis ízelíto a most már kezelheto (ha úgy jobban tetszik, letiltható) funkciókról:

Screen capture

Camera

Bluetooth

Store

NFC

Teljes lista:

https://technet.microsoft.com/en-us/library/dn376523.aspx

Tiltsuk le például a Bluetooth, és az NFC funkciókat – a kamerát meghagyom, mert hátha fényképezni kell :)

Illetve kapcsoljuk ki a Windows Store hozzáférést – akár megelégedhetnénk egy jelszóval is, de most legyünk gonoszak:

Íme az eredeti állapot…

… és az eredmény:

A következokben két új, nagyon érdekes WP 8.1 MDM funkcióról lesz szó – az alkalmazás korlátozásról és az Assigned Accessrol.

XIII. rész - Windows Phone 8.1 App restrictions

Windows Phone kezelés?? De hiszen errol már volt szó!

Naná – de ez most mégis valami új.

A ConfigMgr + Intune páros korábban a Windows Phone 8.0 verziót tudta kezelni. A néhány hónapja megjelent Windows Phone 8.1 frissítés telepítése után felmerülhet bennünk a kérdés, hogy most akkor most a 8.1-es készülékünket tudjuk-e menedzselni.

Az elso tapasztalat – az enrollment gond nélkül megy (errol mindjárt részletesen), megjelenik a Company Portal is. Viszont a Company Portalban már nem látunk semmit, töküres szegény, aztán csalódottan veszi észre az ember, hogy a beállítások sem jönnek le.

No de mi már tapasztalt szakik vagyunk, eszünkbe is jut hát, hogy vannak Extension-ök.

2014. október végi állapot szerint az alábbiakat kell látnunk:

Nos, nincs is más teendonk, mint a Windows Phone 8.1 Extension-t bekapcsolni, aztán megvárni, amíg a telepítés végbemegy. Ezután már meg fognak jelenni az alkalmazásaink a Company Portal app-ban, illetve a beállítások is megérkeznek.

Az iOS 8 platform támogatása is a megfelelo Extension-nel érkezik egyébként.

Miért is izgalmas ez? Hát azért, mert az új verzió megjelenését követoen viszonylag rövid idon belül megjelent az új platformot támogató Intune Extension, ezáltal közel nulla ido- és energiabefektetéssel hozzájutottunk egy új funkcióhoz!!

Ez a hihetetlenül dinamikus feature rollout a Windows Intune és úgy általában véve a felho szolgáltatások egyik legnagyobb elonye.

Az enrollment folyamata viszont némileg eltéro a WP 8.0-hoz képest.

A Windows/Windows RT platformon már megismert Workplace Join-t kell itt már használnunk. Ezt szintén a Beállítások alatt találjuk:

Ezután hasonlóképpen meg kell adnunk a felhasználónevet, jelszót, illetve adott esetben az enrollment szervert:

Ezután viszont meglepodhetünk – ilyen korábban, WP 8.0-n nem volt:

Innentol viszont a folyamat telejesen ugyanúgy megy végbe, mint WP 8.0 esetében.

Egy újdonság azért még várat magára a Workplace alatt. WP 8.0 esetében ha véletlenül töröltük a Company Portal app-ot, vagy enrollmentkor nem választottuk ki a telepítését, újbóli enrollmenttel kellett szembenéznünk.

Most viszont ha a “download hub”-ra kattintunk, újratelepíthetjük a Company Portalt.:

Legközelebb megnézzük, milyen új beállításokat hozott magával a WP 8.1 megjelenése.

XII. rész - Windows Phone 8.1 Beállítások

1. DISM /Get-MountedImageInfo – a visszatérési értékben ott van a mount-olt mappa

2. DISM /Unmount-Image /MountDir:<az elozo parancs visszatérési értékében található elérési útvonal> /Discard

Amint a folyamat befejezodik újra lehet indítani az aktuális offline servicing folyamatot.

Az Offline Servicingrol bovebben itt: https://blogs.technet.com/b/inside_osd/archive/2011/04/18/configuration-manager-2012-offline-servicing-for-operating-system-images.aspx

Task ‘Stop services’ completed, state is ‘failed’ ExceptionText: Error: Setup detected an unexpected problem during installation. Error message: Cannot stop tmlisten service on computer ‘.’.

Secondary Site esetében a hiba (<rendszermeghajtó>\Windows\Temp\cm12-r2rtm-qfe-kb2905002-x64-enu.msi.log):

Windows Installer installed the product. Product Name: Cumulative Update 3 for Configuration Manager R2 (KB2994331). Product Version: 5.0.7958.1401. Product Language: 0. Manufacturer: Microsoft Corporation. Installation success or error status: 1603.

Mindkét esetben a telepített, aktív TrendMicro vírusvédelmi megoldás akasztotta meg a folyamatot. Elso esetben megakadályozta a dependens szolgáltatás leállítását, második esetben a szükséges fájlok megnyitását blokkolta. A TrendMicro Unload funkcióját használva a telepítés sikeresen befejezodött. A befejezést követoen ne felejtsük el visszakapcsolni a védelmet!

Megjegyzés: valószínuleg ezek a hibák SCCM 2012 SP1 illetve más CU verziók esetén is elojöhetnek, érdemes lesz a jövoben is odafigyelni erre.