System Center Mindenkinek

Endpoint Protection – frissítések központi terítése

2013-05-19T12:49:31Z

Az alábbi cikkben a System Center Endpoint Protection 2012 SP1 (a továbbiakban SCEP) verziójával használható különböző definíciós állomány frissítési konfigurációkat mutatom be – kiemelve a System Center Configuration Manager 2012 SP1 integrált megoldás részleteit.

A frissítések központi terítésére az alábbi alternatívák állnak rendelkezésre:

Configuration Manager integrált terítés – ebben az esetben a Configuration Manager Software Update Management szolgáltatásán keresztül jutnak el a frissítések a kliensekig.

Windows Server Update Services (WSUS) – ebben az esetben a vállalati WSUS infrastruktúrán keresztül jutnak el a frissítések a kliensekig.

Microsoft Update – ebben az esetben a kliensek direktben kapcsolódnak a Microsoft Update szolgáltatáshoz és töltik le a számukra szükséges frissítéseket.

Microsoft Malware Protection Center – ebben az esetben a Microsoft Malware Protection Center szolgáltatáshoz csatlakoznak a kliensek és töltik le a számukra szükséges frissítéseket.

UNC megosztás – ebben az esetben a frissítéseket valamilyen automatizált módon letöltjük és egy megosztáson keresztül tesszük elérhetővé a kliensek számára.

A Configuration Manager integrált megoldás kivételével mindegyik alternatíva esetében a frissítések menedzsmentje a SCEP kliensen keresztül történik. A különböző beállítások központi terítésére az Antimalware Policy-k szolgálnak, melyeket a Configuration Manager-ben definiálhatunk.

A Configuration Manager integrált megoldás esetében a frissítések letöltését a Configuration Manager végzi, ennek automatizálására Automatic Deployment Rule (ADR a továbbiakban) létrehozása szolgál – ami adott feltételeknek megfelelően letölti és publikálja az aktuális frissítéseket a kliensek felé. Az ADR-t 8 óránként sűrűbben futtatni nem érdemes. A frissen publikált frissítésekről a Configuration Manager agent-ek a soron következő házirend letöltés után tudomást szereznek, majd a Windows Update Agent segítségével kiértékelik azokat és a szükségesnek ítélt frissítéseket a Configuration Manager agent telepíti az adott számítógépre. Az aktuálisan használatban lévő definíciós állományról a SCEP UI-on keresztül tájékozódhatunk.

Amennyiben nem az elvárásainknak megfelelően működik a frissítések terítése, a nyomozás során az alábbiak segíthetnek:

Ha kizárólag Configuration Manager integrált forrást állítottunk be, a SCEP UI-on keresztül nem lehet azonnali frissítési folyamatot indítani az alábbi képen látható ’Update’ gomb megnyomásával – ez megfelel az elvárt működésnek a korábban
ismertetettekkel összhangban.

Minden más esetben használható a felület pl.: WSUS, UNC, stb.

Configuration Manager specifikus log-ok (C:\Windows\CCM\Logs):

ccmexec.log
updatesdeployment.log
execmgr.log
ciagent.log
updateshandler.log
scanagent.log
wuahandler.log

SCEP kliens specifikus log-ok (C:\ProgramData\Microsoft\Microsoft Antimalware\Support):

MPDetection-<date-timestamp>.log
MPLog-<date-timestamp>.log
MPCacheStats.log

Végül, de nem utolsó sorban rengeteg hasznos információ található a Windows Update log-ban (C:\Windows\windowsupdate.log), a következő bejegyzésekre érdemes keresni:

Configuration Manager agent által indított hívás:

COMAPI -- START -- COMAPI: Init Search [ClientId = CcmExec]

SCEP kliens által indított hívás:

COMAPI -- START -- COMAPI: Init Search [ClientId = System Center 2012 Endpoint Protection]

Exchange 2013 Management Pack

2013-05-15T07:59:47Z

A tegnapi nappal elérhetővé vált az Exchange Server 2013 Management Pack. Továbbra is támogatott SCOM 2007 R2-n, illetve természetesen SCOM 2012 alatt is.

A legfontosabb változás, hogy nincs szükség az Exchange 2010-es felügyelet kapcsán használt Correlation Engine szolgáltatásra, a teljes monitoring funkcionalitást az Operations Manager natív képességeivel biztosítja a megoldás.

A hivatalos leírás a TechNet-en itt található: http://technet.microsoft.com/en-us/library/5e3d40c1-9230-467e-be80-633407078468.aspx, amit minden esetben javasolt elolvasni!

Magát a csomagot innen lehet letölteni: http://www.microsoft.com/en-us/download/details.aspx?id=39039.

- Marci

Operations Manager Agent–Server kommunikáció monitorozása

2013-05-13T08:36:07Z

Előfordulhat, hogy az Agent – Server kommunikációban hiba lép fel, de erről semmilyen visszajelzést nem látunk a konzolon. Az eseménynaplók alapján is úgy tűnik minden rendben van és hátradőlünk mondván, hogy miden remek. Egyszer csak leáll egy szolgáltatás és az adott alkalmazás gazda jelzi, hogy xy kiszolgálóval probléma volt, ám a SCOM nem jelzett. Sajnos ilyen valóban előfordul, bár igen ritkán. Ennek az oka az, hogy az Agent – Server kommunikáció megáll. Az Agent továbbra is végzi a dolgát, de nem küldd a Server felé adatot. Erre is ad megoldást az 2012-es SCOM.

Van két beépített, de alapértelmezetten kikapcsolt monitor, amely azt vizsgálja, hogy egy adott Agent esetében került-e be az elmúlt x percben eseménynapló bejegyzés illetve került-e be teljesítmény adat az adatbázisba. A monitorok System.OleDbProbe modult használják és az OperationsManager adatbázis egyes nézeteiből olvassák ki a megfelelő adatokat. Az alábbi képen látható a két monitor: Event collection health és Performance data collection health, amelyeket én most bekapcsoltam.

A monitoroknak az alábbi paramétereit lehet állítani (zárójelben az alapértelmezett beállítások):

- Query Timeout. Mennyi ideig futhat a query, mielőtt azt a SCOM megszakítja (120 mp).

- Interval. Mennyi időnként fut le a query (3600 mp – 1 óra).

- Sync Time. Időzítés szinkronizáció (00:01), azaz minden óra :01-edik percében fut.

- Watch Period in Hours. Mekkora intervallumot vizsgáljon a lekérdezés (48 óra).

- Max Event Age in Hours. Hány óránál régebbi esemény esetén riasztunk (8 óra).

A monitor bekapcsolása után már “hátradőlhetünk” :)

- Marci

Windows Server 2012 WSUS letöltési hiba

2013-05-10T18:43:39Z

Egy közelmúltban felfedezett termékhibára hívnám fel a figyelmet, amely Windows Server 2012 WSUS letöltések esetén lép fel, kizárólag abban az esetben, ha proxy szervert használunk, és proxy autentikációra van szükség.

Ilyen infrastruktúra esetén a BITS alapú letöltések sikertelenek.

Natív WSUS esetén a katalógus szinkronizálás gond nélkül lefut, kivéve a licenszszerződések letöltése (EULA), illetve a frissítésekhez tartozó telepítőfájlok letöltése ad hibát.

Configuration Managerből indtott szinkronizálásnál az alábbi hibát kapjuk a Wsyncmgr.log-ban:

Failed to sync update a024086f-17fd-4875-8d84-a5d9a6811ed4. Error: The Microsoft Software License Terms have not been completely downloaded and cannot be accepted. Source: Microsoft.UpdateServices.Internal.BaseApi.SoapExceptionProcessor.DeserializeAndThrow

A hibát a Microsoft javította, jelenleg belső tesztelés alatt áll a javítás, és nemsokára hivatalos tudásbázis cikk is megjelenik erről.

Jelenleg a hiba elkerülésének módja a proxy autentikációhoz tartozó felhasználó, és jelszó eltávoltása (ami sajnos azzal jár, hogy ki kell kapcsolni a proxy autentikációt).

Itt felhívnám a figyelmet arra, hogy Configuration Manager integráció esetén nem megfelelő a WSUS konzolban a proxy autentikációt kikapcsolni, mivel a Configuration Manager a WSUS API-n keresztül ezt automatikusan felülrja! Kapcsoljuk ki a proxy autentikációt a Configuration Manager oldalon (és csak ott).

Configuration Manager 2012 replikációs problémák kezelése

2013-05-06T16:38:43Z

Több helyen előjött a közelmúltban, hogy System Center Configuration Manager 2012 SP1-re való frissítése után SQL Server Service Broker replikációs hibák léptek fel. A Configuration Manager konzolban a Monitoring workspace alatt a Data Replication “Link Failed” státuszt mutatott a replikációs útvonalaknál, és a link kiválasztása után az útvonalhoz tartozó Replication Group-ok “Failed” Initialization Status-t mutattak.

Bizonyos esetekben ez betudható volt annak, hogy az adatbázist tartalmazó köteten ideiglenesen elfogyott a tárhely.

Mielőtt az alábbi, replikációt helyreállító lépéseket éles rendszeren végrehajtjuk, legyen aktuális Configuration Manager Site mentésünk, vagy legalább egy biztonsági mentés a site adatbázisról. Javasolt a Microsoft Terméktámogatást felkeresni az ilyen jellegű problémákkal, mivel elképzelhető, hogy a hiba, bár hasonló jeleket mutat, de mégis más eredetű.

A problémás Replication Group-ok újrainicializálásához nyissunk először egy új lekérdező ablakot (Query window) SQL Server Management Studio-ban, majd futtassuk le az alábbi lekérdezést:

update RCM_DrsInitializationTracking set InitializationStatus = 7 where ReplicationGroup = '<Failing Replication Group name>' and SiteRequesting = '<Site code for requesting site>' and SiteFulfilling = '<Site code for fulfilling site>'

Ha tehát például a Collection_Membership Replication Group-unk nem tud inicializálódni, az alábbi lekérdezéssel tudjuk ezt kikényszeríteni a CAS site-unkon (C01) az alárendelt primary site felől (P01):

update RCM_DrsInitializationTracking set InitializationStatus = 7 where ReplicationGroup = 'Collection_Membership' and SiteRequesting = 'C01' and SiteFulfilling = 'P01'

Hasonlóképpen járjunk el az összes többi problémás Replication Group-nál is.

Előfordulhat, hogy a fenti lépések után továbbra is hasonló bejegyzéseket találunk az RCMCtrl.log-ban (részletes logolás esetén):

CSqlBCP::BCPIN: bcp_exec failed. SMS_REPLICATION_CONFIGURATION_MONITOR 1/1/1601 12:00:00 AM 2400 (0x0960)

*** DRS_Init_BCPIN() failed SMS_REPLICATION_CONFIGURATION_MONITOR 1/1/1601 12:00:00 AM 2400 (0x0960)

*** BCP fails due to internal sql error. Check if this table has a trigger failed to execute. SMS_REPLICATION_CONFIGURATION_MONITOR 1/1/1601 12:00:00 AM 2400 (0x0960)

CBulkInsert::DRS_Init_BCPIN : Failed to BCP in SMS_REPLICATION_CONFIGURATION_MONITOR 1/1/1601 12:00:00 AM 2400 (0x0960)

BCP in result is 2147500037. SMS_REPLICATION_CONFIGURATION_MONITOR 1/1/1601 12:00:00 AM 2400 (0x0960)

ERROR: Failed to BCP in for table CI_CurrentComplianceStatus with error code 2147500037. SMS_REPLICATION_CONFIGURATION_MONITOR 1/1/1601 12:00:00 AM 2400 (0x0960)

ERROR: Failed to apply BCP for all articles in publication General_Site_Data. SMS_REPLICATION_CONFIGURATION_MONITOR 1/1/1601 12:00:00 AM 2400 (0x0960)

Ebben az esetben kapcsoljunk ki minden triggert az érintett adatbázis táblán (a fenti példánkban ez CI_CurrentComplianceStatus), majd ezután kényszerítsük ki megint az inicializálást.

Miután a Replication Group sikeresen inicializálódott, ne felejtsük el a kikapcsolt triggereket visszakapcsolni. (Vigyázat, nem mindegyik trigger van alapból bekapcsolva a táblákon!)

Configuration Manager 2012 SP1 agent telepítési probléma

2013-05-04T08:03:43Z

A héten találkoztam egy Configuration Manager 2012 SP1 agent telepítési problémával. Néhány gépre sikeresen települt az agent, néhány gépen azonban hibára futott a telepítés. Az agent telepítési logban (c:\windows\ccmsetup\logs\ccmsetup.log) a következő hibát találtam:

Couldn't verify 'C:\Windows\ccmsetup\MicrosoftPolicyPlatformSetup.msi' authenticode signature. Return code 0x800b0101

Feltételeztem, hogy nem a telepítőkészlettel lesz a gond, hiszen voltak sikeres telepítések. Tettem egy próbát, kézzel telepítettem a MicrosoftPolicyPlatformSetup.msi komponenst a számítógépre, majd újra elindítottam az agent telepítőt - ezúttal sikerrel járt.

Egy kis kutakodás után az alábbi cikket találtam a probléma végleges megoldására:

http://support.microsoft.com/kb/2801987?wa=wsignin1.0

A fenti cikkből az is kiderült, hogy a felemás eredmények a kliensek különböző patch-szintjéből adódtak (Method 2).

VMware-ről Hyper-V-re migráció lehetőségei

2013-04-24T15:00:00Z

A blogbejegyzés célja áttekintő jelleggel bemutatni a VMware virtualizációs platformról Hyper-V alapú virtualizációs platformra migrációs (V2V) alternatívákat. Jelen cikk csak áttekintő jelleggel mutatja be a rendelkezésre álló Microsoft alapú migrációs lehetőségeket, alternatívákat a részletes step-by-step leírások megtalálhatók a vonatkozó Technet cikkekben.

A VMware platformról Microsoft Windows Server Hyper-V platformra migráció elvégzésére az alábbi Microsoft megoldásokon alapuló lehetőségek állnak rendelkezésre:

V2V migráció System Center 2012 Virtual Machine Manager SP1-el: A System Center 2012 Virtual Machine Manager képes kapcsolódni mind a Hyper-V, mind a VMware virtualizációs platformokhoz (és a XEN virtualizációs platformokhoz is), valamint képes automatizálni a VMware-ről Hyper-V-re migráció menetét: http://technet.microsoft.com/en-us/library/gg610672.aspx
P2V migráció (fizikai gépnek tekintve a VMware gépeket és úgy migrálni Hpyer-V-re) a System Center 2012 Virtual Machine Manager SP1-el: http://technet.microsoft.com/en-us/library/hh368990.aspx
V2V migráció a Microsoft Virtual Machine Converter Solution Accelerator segítségével: http://technet.microsoft.com/en-us/library/hh967435.aspx

V2V: System Center 2012 Virtual Machine Manager

A System Center 2012 Virtual Machine Manager képes kapcsolódni a vCenter-en keresztül a VMware infrastruktúrához és így egységes felügyeleti felületet biztosítani mind a VMware mind a Hyper-V alapú virtualizációs platformokra. Ehhez előfeltétel, hogy a megfelelő vCenter és ESX verziók fussanak. Az alábbi táblázat összefoglalja mely vCenter és EXS verziókkal képes az SCVMM 2012 és SCVMM 2012 SP1 kapcsolódni:

vCenter, ESX verzió	SCVMM 2012 támogatás	SCVMM 2012 SP1 támogatás
VMware vCenter Server 4.1	Igen	Igen
VMware vCenter Server 5.0		Igen
VMware vCenter Server 5.1		Igen
ESX 3.5, ESXi 3.5	Igen
ESX 4.1, ESXi 4.1	Igen	Igen
ESXi 5.0		Igen
ESXi 5.1		Igen

Miután csatlakozott az SCVMM mind a VMware infrastruktúrához, mind a Hyper-V infrastruktúrához utána képes a gépeket átmozgatni és konvertálni a két rendszer között. A konvertálási folyamat során az SCVMM konvertálja a VMware .vmdk fájlokat .vhd-re és a futó operációs rendszert kompatibilissé teszi a Microsoft virtualizációs technológiákon futtatásra, telepíti a szükséges bővítményeket. A Hyper-V infrastruktúrán létrehozandó gép paraméterei megegyeznek a VMware paraméterekkel (név, leírás, memória, CPU, disk és bus összerendelések). Az SCVMM-ben három mód van a V2V konverzió végrehajtására:

közvetlenül egy ESX host-ról
VMM Library tárolón keresztül
Windows vagy NFS fájlmegosztásról

Mindegyik esetben a virtuális gépnek kikapcsolt állapotban kell lennie, a V2V nem képes futó gépek mozgatására. Az SCVMM V2V folyamata során a forrás gépből csak olvasás történik, sem módosítás sem törlés nem történik a VMware gépeken, így a visszaállás egyszerű és biztonságos.

Előfeltételek az SCVMM-el végrehajtott V2V-re:

A géphez kell léteznie .vmx fájlnak (VMware konfiguráció leíró)
A géphez egy vagy több .vmdk virtuális lemez fájlnak tartoznia kell, amelyek fel vannak tüntetve a .vmx konfigurációban. A támogatott VMware virtuális lemez formátumok között szerepelnek az alábbiak:

monolithicSparse
monolithicFlat
vmfs
twoGbMaxExtentSparse
twoGbMaxExtentFlat

A VMware Tools nem lehet telepítve a guest gépen
Nem lehetnek snap-shot-ok a virtuális gépről

A fenti feltételek teljesítése esetén tehát a System Center 2012 Virtual Machine Manager képes a virtuális gépeket a VMware infrastruktúrából, offline módon átvinni a Hyper-V infrastruktúrára.

P2V: System Center 2012 Virtual Machine Manager

A System Center 2012 Virtual Machine Manager a V2V migrációk mellett támogatja a fizikai gépekről virtuális gépekre való migráció menetét is, amely nem csak fizikai gépek, hanem virtuális gépek migrációja esetén is alkalmazható. A P2V migráció során az migrálandó gépről készül egy image alapú mentés, majd az SCVMM kompatibilissé teszi a gép futtatását Hyper-V környezetben (a szükséges eszközmeghajtókkal, kiegészítésekkel). Fontos hogy a P2V migráció esetében létezik online és offline migráció.
A P2V migráció előfeltételei a következők (nem csak VMware hanem valódi fizikai gép migárciót is):

A forrás gépeknek Advanced Configuration and Power Interface (ACPI) BIOS-al kell rendelkezniük
Nem lehet titkosított kötet a gépen
Nem lehet Itanium architektúra a forrás gép

Online konvertálás

Az online konvertálás esetén nincs szükség a forrás gép újraindítására, az SCVMM a Volume Shadow Copy Service (VSS) segítségével készít egy image-t a forrás gépről, amely egy alkalmazás szinten konzisztens mentés, majd az alapján elkészíti a virtuális gépet. Az online konvertálás az alábbi fő lépésekből áll:

A forrás gépre az SCVMM agent telepítése. Az SCVMM agent-je telepítésre kerül a forrás gépen, a hardver és szoftver konfigurációs paraméterek begyűjtésére. A konvertálás végével az agent eltávolításra került.
Konfiguráció begyűjtése, amely tartalmazza az OS verzió, Service Pack és hotfix telepítettségi állapotok, lemez kiosztás, fájlrendszerek, adatait. Az SCVMM exportálja ezeket az adatokat a saját adatbázisába, a virtuális gép létrehozása ez alapján történik.
Image készítése, amely során minden egyes kötetről VSS mentés készül. Ha a cél virtuális gépen dinamikus disk kerül használatba akkor a forrás gépről csak a használt területek adatai kerülnek átszinkronizálásra, az üres helyek nem. Az adatok közvetlenül stream-elődnek BITS segítségével az SCVMM host-ra és minden fizikai kötet egy új VHD fájl lesz.
Eszközmeghajtók, komponensek hozzáadása amely során az agent felkészíti a guest OS-t a Hyper-V környezetben létrehozásra.
Virtuális gép létrehozása, amely során az SCVMM elkészíti a virtuális gépeket és csatlakoztatja a létrehozott virtuális lemezeket, beállítja a megfelelő hálózati adaptereket, memória konfigurációt, stb.

Offline konvertálás

Az online konvertálással ellentétben az offline konvertálás nagyobb adatkonzisztenciát biztosít mivel ebben az esetben a forrás gép nincsen használatban a migráció ideje alatt. Továbbá online migrációval nem migrálhatóak, sem Windows 2000 alapú gépek, sem tartomány vezérlők, vagy olyan gépek, amelyek nem NTFS kötetet tartalmaznak. Az offline migráció egy Windows Pre-boot Environment (WinPE) környezetbe történő beboot-olás révén megy végbe. Az offline P2V migráció lépései:

SCVMM Agent telepítés a forrás gépre.
Az SCVMM agent letölti a WinPE image-t a forrás gépre és módosítja a boot record-ot hogy a következő újra indítás után a WinPE induljon el az alapértelmezett operációs rendszer helyett.
A VMM agent a WinPE-ben elkezdi stream-elni a fizikai lemez tartalmakat az SCVMM kiszolgáló felé.
Ez után hasonlóan az online migrációhoz a szükséges eszközmeghajtók, integrációs komponensek telepítésre kerülnek a gépen.

V2V: Microsoft Virtual Machine Converter

A Microsoft Virtual Machine Converter (MVMC) egy ingyenesen letölthető Solution Accelerator a Microsoft-tól, amely segít a VMware virtuális gépeket Hyper-V platformra konvertálni. Az MVMC egy teljesen script-elhető parancssoros felületet biztosít, így jól integrálható az adatközpont automatizálási folyamatokba. Segítségével könnyen és gyorsan, alacsony kockázat mellett migrálhatók a VMware virtuális gépek a Hyper-V platformra. A migráció során a virtuális lemezek konvertálásra kerülnek, valamint a migrációs folyamat megőrzi a forrás virtuális gép konfigurációját (memória, CPU, hálózat, lemezkiosztás, stb.). Tiszta migrációt hajt végre, vagyis a migrációs folyamat során letávolítja a VMware Tools-t a gépről, és telepíti a szükséges Hyper-V integrációs komponenseket. Az alábbi forrás VMware platformokat támogatja az MVMC (beleérvte a vCenter cluster-en furó virtuális gépeket is):

vCenter Server 5.0
vCenter Server 4.1
ESXi Server 5.0
ESXi/ESX Server 4.1

Megjegyzés: MVMC támogatja az ESXi/ESX 4.0 host-okat amennyiben azok vCenter 4.1 vagy vCenter 5.0 ből felügyeletek. Ebben az esetben a vCenter 4.1 vagy 5.0 kiszolgálókhoz kell csatlakoztatni az MVMC-t a 4.0 host-ról való virtuális gépek konvertálásához.

Az MVMC az alábbi VMware lemeztípusokat támogatja:

monolithicSparse
vmfsSparse
monolithicFlat
vmfs
twoGbMaxExtentSparse
twoGbMaxExtentFlat
delta disk conversion
Stream optimized disks

Az MCMV konvertálás további előfeltételei:

A virtuális gép futó állapotban van
A VMware Tools telepítve van
A forrás virtuális gép Active Directory tartomány tagja
A távoli elérés WMI-on keresztül biztosított mind a forrás virtuális gép, mind a cél Hyper-V host felé.
Van helyi rendszergazda jogosultsága a forrás virtuális gépen az MVMC-t futtató felhasználónak

Az MCVM egy varázslós felületen keresztül vezeti végig a virtuális gép konvertálás menetét, amely az alábbi lépésekből áll:

Forrás VMware host kiválasztása

Adott host-on levő virtuális gép kiválasztása

Kapcsolódás a virtuális géphez

A konvertáláshoz használt átmeneti terület konfigurálása

A cél Hyper-V host kiválasztása

A fentiek alapján látható, hogy az MVMC alapú migrációs folyamata nagyban hasonlít az SCVMM2012 alapú V2V migrációs folyamathoz.

Mire figyeljünk az OS Deployment során System Center 2012 - Configuration Manager SP1-ben

2013-04-21T11:03:00Z

Az SCCM vezérelt operációs rendszer telepítés első lépése egy WinPE (Windows Preboot Environment) környezet indítása, amely a szükséges komponensek betöltéséért és telepítési szekvenciák futtatásáért felel. Ezt a WinPE környezetet az SCCM 2012 SP1-hez követelményként meghatározott Windows ADK (http://www.microsoft.com/en-us/download/details.aspx?id=30652) komponens tartalmazza, amely kizárólagosan WinPE 4.0-ás rendszert használ. A WinPE 4.0 gyakorlatilag a Windows 8 kernelre épül, ebből adódóan a futtató számítógépen követelményként van meghatározva az NX, PAE és SSE2 processzorfunkciók támogatása (http://msdn.microsoft.com/en-us/library/windows/hardware/hh975398.aspx). Tapasztalat alapján ma a legtöbb környezetében található olyan kliensszámítógép, amely ezeket a feltételeket nem teljesíti. Ezeken a gépeken az operációs rendszer telepítés első lépéseként történő WinPE környezet betöltése nem sikerül, a teljes telepítési folyamat meghiúsul.

Ahhoz, hogy melyik kliens felel meg a követelményeknek azt a CoreInfo-val (http://technet.microsoft.com/en-us/sysinternals/cc835722.aspx) tudjuk lekérdezni. Az eredménynél az alábbi sorok számítanak. Ahol * van, az megfelel, ahol - az nem támogatott. Mindhárom funkciónak támogatottnak kell lennie.

A probléma csak a System Center 2012 – Configuration Manager SP1 esetén áll fent. Jelenleg több kritikus bejelentett eset is van a Product Group-nál, de hivatalosan még nincs állásfoglalás. Egyelőre az alábbi kerülő megoldásokat ajánlják:

Frissítsük a BIOS-t, amely lehet, hogy megoldja a támogatási problémát
Cseréljük a kliensgépeket
Használjunk Microsoft Deployment Toolkit 2012 Update 1-et (http://www.microsoft.com/en-us/download/details.aspx?id=25175)
Használjunk System Center 2012 – Configuration Manager RTM-et

Amint van friss információ a termékfejlesztő csapattól, azt megosztom.

- Marci

Operations Manager adatbázis méretezés

2013-04-19T12:38:24Z

A bevezetések során az egyik legfontosabb tervezési kérdés az adatbázis méretére és teljesítményére vonatkozik. A hivatalos méretezési ajánlás alapján a legtöbb esetben elég jól meg lehet tervezni a rendszert, de akinek pontos számításra van szüksége annak inkább az alábbi képleteket ajánlom.

Adatbázis méret

Az adatbázis méretezéséhez használjuk egész nyugodtan a fenti Sizing Guide-ot. A méretezéshez szükséges paraméterek (adatmegőrzés, agent szám, stb.) egyszerűen megadhatóak az Excel táblában, az eredményként kapott értékek alapján méretezhető az SQL adatbázis.

Szükséges IOPS

Az IOPS-ra csak tól-ig értékek vannak a méretezési ajánlásban. Jellemzően jó értékek vannak, de fontos megjegyezni, hogy ezek csak becsült értékek az ügyfeleknél tapasztaltak alapján. Ha ennél több kell, akkor az alábbi képlet segítségével a szükséges spindle (nem tudom mi a helyes magyar kifejezés erre) számot tudjuk kiszámolni, majd ebből a szükséges diszkek számát.

n = (%R + f (%W))(IOPS)/150

n = diszkek száma

f = 2: RAID-1, 4: RAID-5
%R = olvasási műveletek aránya. Jellemzően 20% az Operations Manager esetén

%W = írási műveletek aránya. Jellemzően 80% az Operations Manager esetén

Példa:

(0.2 + 2*0.8)(1000 IOPS)/(150 IOPS/disk) = 12 spindle

SAS 15k diszkek: 180 RAW IOPS

SAS 10K és SCSI 15K diszkek: 150 RAW IOPS

Ahhoz, hogy meghatározzuk a helyes diszk konfigurációt a rendszerünkhöz és a jövőbeni növekményeknek megfelelően méretezzük a szükséges IOPS értéket javasolt, hogy használjuk az SQLIO-t. Továbbá a diszkek teljesítményének folyamatos monitorozása is javasolt, ugyanis a megnövekedett agent szám, a változó konzol kapcsolatok szám, az új management pack-ek importálása mind-mind olyan művelet, amely jelentősen kihathat a mögöttes SQL adatbázisok teljesítmény igényére.

- Marci

ConfigMgr 2012 SP1 kliens telepítési nyalánkságok

2013-04-18T08:10:00Z

A ConfigMgr 2012 SP1 kliens telepítés során installál egy rakat programot (pl. XML Services, Visual C++), többek között a Silverlight 5.1-es verzióját. A teljes lista itt található:

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

Előfordulhat, hogy nem akarjuk, hogy bizonyos komponensek települjenek, mert nincs rájuk szükség (például a Silverlight csak az Application Catalog eléréséhez kell). Ez esetben a CCMSetup /skipprereq: paraméterével meghatározhatjuk azt a programot, amelyet mellőzni szeretnénk.

Fontos, hogy mivel ez a paraméter a CCMsetup.exe-hez tartozik, ezért a konzolból történő kliens telepítésnél (push install) nem kerül kiértékelésre, használatához kézzel vagy scriptből kell indítani a parancsot.

Amennyiben a Management Point kizárólag HTTPS kommunikációt engedélyez, a CCMSetup.exe-nél az /MP: paraméterhez a protokollt is meg kell adni: CCMSetup.exe /MP:https://kuat.galacticempire.org

Ennek hiányában a kliens nem tud az MP-vel beszélni, és nem kap disztribúciós pont listát, így a telepítés leáll.

A CCMSetup.exe és a Client.msi paramétereit az alábbi cikkben gyűjtötte össze a Product Group:

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

Tamás