293: Kleine Übung mit den SCCM 2012 Compliance Settings

Aktuell stellte sich gerade die Frage „Bei welchen Systemen ist denn das KB2919355 Update installiert?“. Alle die sich mit diesem Windows 8.1 Spring Update auseinandersetzen wissen, dass dafür ein Vorbereitungsupdate notwendig ist bevor dieser erkannt werden kann. Blöd ist nur, dass dieses Vorbereitungsupdate schon einige Mal abgelöst „superseded“ wurde und das letzte davon den KB2919355 nicht mehr hinter sich her zieht.

Also braucht man eine von SCCM bzw. WSUS unabhängige Methode, um festzustellen ob der KB installiert ist, damit man per Software Deployment das Vorbereitungsupdate ins Feld bringen kann. Die notwendigen Daten dafür liefert hier jetzt eine SCCM Compliance Baseline.

Step 1 – Erstellen des Compliance Items

In dem Fall wird ein Powershell Skript verwendet das den Wert „Compliant“ zurückgibt wenn der KB installiert ist. Das Miniskript verwendet das „get-hotfix“ Cmdlet.

$hotfix = get-hotfix -id „KB2919355“
if ($hotfix -eq $NULL) {
$Compliance = „NotCompliant“
} else {
$Compliance = „Compliant“
}
Return $Compliance

sc01 sc02

Die Regel die in SCCM den „Compliant“ Status definiert wird folgendermaßen definiert.

sc03

2. Compliance Baseline und Deployment

Jetzt muss nur noch das „Compliance Item“ einer „Compliance Baseline“ zugeordnet werden. Diese Baseline wird dann „deployed“. In meinem Fall wurde eine Collection angelegt die alle Windows 8.1 und Windows Server 2012 R2 Maschinen enthält. Die Ausführungsfrequenz der Baseline wird im Deployment festgelegt, in meinem Fall einmal am Tag.

sc04 sc05

3. Auswerten der Ergebnisse

Über einen Bericht können die Ergebnisse jetzt dargestellt werden.Dafür zieht man den Report „Compliance and Settings Management \ List of assets by compliance for a configuration baseline heran“

sc06

Die „Non-Compliant“ Maschinen werden jetzt Kandidaten um den Vorbereitungsupdate auszurollen. Über den Report kann man schön nachverfolgen wie der Fortschritt ist.

Advertisements

292: SCCM 2012 und Windows Intune verwalten iOS

Nachdem nun schon Windows Phone 8 und Androiden mit meiner SCCM/Intune Umgebung verwaltet werden, fehlt jetzt nur noch ein iOS Gerät, in dem Fall ein iPad 2. Einzige Voraussetzung hierbei ist ein „Apple Push Notification, APN“ Zertifikat. Dies ist kostenlos und kann sehr einfach über https://identity.apple.com/pushcert bezogen werden. Ein iTunes Konto ist notwendig, aber das hat ja eh jeder der auch ein iOS Gerät hat.

Die Konfiguration der Intune Subscription besteht aus drei Schritten.

  • Erstellen einer Zertifikatsanforderung mit der SCCM 2012 Konsole.
  • Hochladen der Zertifikatsanforderung und Signatur durch die Apple Zertifizierungsstelle.
  • Herunterladen des signierten Zertifikats und Einbau dessen in die Intune Subscription.

pushcert pushcert0 

Jetzt gehts auf dem iPad weiter.

  • Aus dem Apple Store lädt man die „Unternehmensportal“ App und meldet sich an.
  • Danach wechselt das iPad zur Verwaltung der Management Profile und implementiert das Zertifikat.

 1 2

3   4

Im Unternehmensportal sieht man nun die für diesen Benutzer angekündigten Apps, alle seine registrierten Geräte und Möglichkeiten Geräte zu entfernen oder auch zu löschen.

5   6

Die Hardware Inventur wird über die Intune Subscription heruntergeladen und in der SCCM Datenbank gespeichert. Hier ein Ausschnitt des „dataldr.log“ Logfiles.

7

Das iPad ist nun neben den anderen mobilen Geräte in der SCCM Inventur ersichtlich und kann verwaltet werden.

8

Der „Resource Explorer“ zeigt weitere Details an.

9

291: SCCM 2012 und Windows Intune verwalten Windows Phone

Dieses Beispiel zeigt die Kopplung eines Windows Phone 8 mit Intune. Im Unterschied zur Android Anbindung hat man hier eine Hürde vorher zu meistern. Alle Apps, inkl. des Unternehmensportals müssen selbst signiert werden. Dazu muss man ein Signaturzertifikat von einer Symantec Zertifizierungsstelle beziehen und sich vorher als „Phone Developer“ registriert haben. Beides sind ziemlich große Hürden wenn man nur ausprobieren möchte.

Um überhaupt einen Test zu ermöglichen wurde das „Support Tool for Windows Intune Trial Management of Window Phone 8“ Tool veröffentlicht. Mit Hilfe dessen können die Unternehmensportal App und zwei weitere Demo Apps, die im Download enthalten sind, signiert werden. „Deep Links“ in den Microsoft Store sind ebenfalls machbar, denn da muss ja nichts signiert werden.

Die Implementierung des Tools ist auf der Downloadseite ganz gut beschrieben. Auch andere Blogs erläutern das recht verständlich. Hier die beiden entscheidenden Aufrufe in meiner Testumgebung.

  • Auslesen der GUID für die Unternehmenportal App. Diese wurde zuvor mit der „ssp.xap“ Application in SCCM angelegt.
  • Implementieren des Signaturzertifikats.
  • Das Windows Phone 8 Management in der Windows Intune Subscription wird durch das zweite Kommando automatisch aktiviert.

wp1-copy

wp2-copy

in1

Dann kanns mit dem Windows Phone 8 weitergehen. Die Bilder zeigen die Vorgehensweise.

Im „Einstellungen“ Menü öffnet man „Unternehmens-Apps“. Dort wird Benutzerkonto und Kennwort konfiguriert. Je nach DNS Domäne kann Intune automatisch discovered werden oder nicht. In meinem Fall arbeite ich mit einer „onmicrosoft.com“ Adresse. Deswegen musste ich den Management Server mit „manage.microsoft.com“ statisch konfigurieren.

wp_ss_20140227_0006-copy  wp_ss_20140227_0007  wp_ss_20140227_0008-copy

Nach kurzer Zeit (ca. 10 Minuten) kann man sich an der Unternehmensportal App anmelden.

  • Aufrufen der Unternehmensportal App und Anmeldung.
  • Ansicht der angekündigten Apps oder „Deep Links“.
  • Installieren einer der Demo Apps.

wp_ss_20140227_0009-copy  wp_ss_20140227_0011  wp_ss_20140227_0010

In der Unternehmensport App sieht der Benutzer alle von ihm registrierten Geräte mit einigen Details.  Er kann ggf. von dort aus ein anderes oder dieses Gerät von Intune trennen oder es remote löschen lassen.

wp_ss_20140227_0002  wp_ss_20140227_0012  wp_ss_20140227_0013

Über die Intune Subscription wird die Hardware Inventur heruntergeladen und in der SCCM Datenbank gespeichert.

dataldr

Das Windows Phone 8 ist jetzt in der SCCM Konsole sichtbar und kann von dort verwaltet werden.

in2-copy

Der „Resource Explorer“ zeigt wie gewohnt weitere Inventardetails an.

in4

290: SCCM 2012 und Windows Intune verwalten Android

Im Moment experimentiere ich mit der SCCM 2012 Kopplung zu Windows Intune. Nachdem die Umgebung eingerichtet war (Artikel folgt noch) habe ich einige mobile Geräte in Intune registriert. In diesem Beispiel sieht man den Ablauf der Registrierung für ein Android Smartphone.

  • Unternehmensportal aus dem Play Store laden und installieren.
  • Mit dem Intune Benutzerkonto anmelden. Damit die Registrierung gelingt muss der Benuter in einer speziellen SCCM Collection sein.
  • Die Geräteadminstrator Rolle akzeptieren. Dadurch kann der Benutzer oder auch der SCCM Administrator das Gerät löschen oder wieder aus der Infrastruktur befördern.

Screenshot_2014-02-23-10-42-54 Screenshot_2014-02-23-10-35-51 Screenshot_2014-02-23-10-37-10

Die nächsten Bilder zeigen:

  • alle registrierten Geräte des Benutzers (maximal fünf).
  • Apps die dem Benutzer in SCCM angekündigt wurden. Das können „deep links“ in den Google Play Store sein oder auch selber entwickelte Apps in .apk Form sein wie im Beispiel der „WS First App“.
  • Kontaktmöglichkeiten des Benutzers mit der IT Abteilung um Hilfe zu finden.

Screenshot_2014-02-23-10-38-00 - Kopie Screenshot_2014-02-23-10-55-04 Screenshot_2014-02-23-10-38-05

Nachdem Inventur an Intune übermittelt wurde lädt SCCM diese von dort herunter und speichert die Informationen in der SCCM Datenbank. Das erledigt der standardmäßige Prozess für das Laden von Inventurdaten in die Datenbank (hier ein Beispiel aus „dataldr.log“).

in13

Danach sind die Daten in der SCCM Konsole verfügbar. Hier eine Collection die alle mobile Geräte selektiert. Interessant ist hier auch, dass Geräte als „Personal“ oder „Company“ klassifiziert werden können.

in09 - Kopie

Die Inventur wird wie gewohnt über den „Resource Explorer“ angezeigt.

in10

Ein besonderes Interesse hatte ich noch an der Inventur. Ist es möglich festzustellen ob ein Gerät „gerootet“ oder „gejailbreakt“ ist? Ich selber habe kein solches Gerät, aber eine kurze Umfrage in meiner Spielerfraktion ergab zwei Freiwillige mit denen ich das testen konnte. Danke nochmal für das Vertrauen dafür. Immerhin hätte ich ihre Smartphones zurücksetzen können.

Tatsächlich kommt diese Information in der SCCM Datenbank an. Im Bild sieht man, dass das Gerät „gerootet“ ist.

in14

289: SCCM 2012 R2 Unternehmensportal

Schon seit letzem Jahr gibt es eine interessante neue Darstellung des SCCM 2012 „Application Catalogs“. Dessen Inhalte können in einer Windows 8 App angezeigt werden. Dort sind noch mehr Möglichkeiten vorhanden, Anwendungen zu gliedern oder auch neue Anwendungen besonders hervorzuheben (als „Featured App“).

Die Bereitstellung erfolgt folgendermaßen:

1. Zuerst müssen die Windows 8 oder 8.1 Systeme für die Ausführung des Unternehmenportals vorbereitet werden. Dazu sind zwei Registryeinträge notwendig. Der erste erlaubt es dem Betriebssystem auch Apps aus anderen Quellen als dem Windows Store zu installieren. Der zweite Eintrag erlaubt die Kommunikation des SCCM Agents mit der Company Portal App.

Beide Einstellungen macht man am besten per Gruppenrichtlinie. Für die erste Einstallung „Allow all trusted apps to install“ ist standardmäßig im GPO Template gesorgt. Für die zweite Einstellung habe ich quick & dirty ein Template gebaut. Norbert macht das garantiert viel eleganter.

CLASS MACHINE

CATEGORY "SCCM 2012 Company Portal"

    KEYNAME "SOFTWARE\Policies\Microsoft\CCM"
    POLICY "Enable Installation of SCCM 2012 Company Portal"
    PART "Predefined String" EDITTEXT
        VALUENAME "PortalPackageFamily"
        DEFAULT "Microsoft.CorporateAppCenter_8wekyb3d8bbwe" 
          END PART
    END POLICY

END CATEGORY

Die Gruppenrichtlinie sieht dann so aus:

copo1

2. Jetzt kann die App von: http://www.microsoft.com/en-us/download/details.aspx?id=40795 heruntergeladen werden. Danach installiert bzw. entpackt man eigentlich nur den Download. Aus dem Inhalt produziert man eine SCCM 2012 Application mit einem Deployment Type vom Typ „.appx package“.

copo0

Diese gilt es dann per Softwareverteilungsmethoden auszurollen. Das muss ich ja nicht beschreiben.

3. Nach dem Deployment der App sieht man die Kachel auf dem Startbildschirm bzw. bei 8.1 holt man sie aus der Liste aller installierten Apps. Das sieht dann so aus (s. rechts oben):

copo00

Direkt nach der Installation dauert es ca. 15 Min bis der SCCM Agent und das Company Portal miteinander kommuniziert haben. Danach werden alle „Applications“, die an Benutzersammlungen angekündigt sind, hier angezeigt.

copo02

Besondere Applikationen kann man im Bereich „Featured Apps“ herausheben, Applikationen können zum besseren Auffinden kategorisiert werden und im rechten Bereich können Kontaktinformationen hinterlegt werden. All diese Infos stammen aus den SCCM Applications. Die Kontaktinformation kommt aus einer ggf. vorhandenen Windows Intune Subscription.

copo020

Die Installation einer Applikation sieht dann so aus:

copo03

copo04

Das ist eine sehr schöne Methode dem Benutzer zu ermöglichen selber Software installieren zu können. Wenn der SCCM Application Catalog sowieso schon implementiert ist dann ist die Bereitstellung des Unternehmensportals eigentlich ein Klacks.

288: SCCM 2012 SP1 CU3 Stolperstein bei der Installation

Während der CU3 Installation werden auch Änderungen an der SQL Datenbank durchgeführt. Der Setup Assistent verwendet dazu das SQL Skript „update.sql“ aus dem SCCMDIR\hotfix\KB2882125 Verzeichnis. Nun ist es schon einige Male vorgekommen, dass das SQL Skript aus verschiedenen Gründen nicht oder nur teilweise ausgeführt wurde. Der Setup Assistent quittiert das mit einer Warnung und schließt die Installation trotzdem ab. Jetzt was tun mit dem abgebrochenen SQL Skript? Die Dokumentation weist darauf hin, dass das Skript auch ganz einfach per SQL Management Studio gestartet werden kann.

Ok, also „update.sql“ im Management Studio öffnen und mit „Execute“ gegen die CM Datenbank laufen lassen. Das Skript bringt einige Fehlermeldungen. Diese hier ist im Prinzip die Entscheidende:

CREATE ASSEMBLY failed because it could not read from the physical file '[[SMS_ROOT]]\bin\x64\MessageHandlerService.dll': 50(failed to retrieve text for this error. Reason: 15105).

Nachdem in einer Hierarchie CAS – Primäre Site – Sekundäre Site vor Ausführung des Skripts eigentlich noch alles wunderbar funktioniert hat, ist jetzt Schluss mit SQL Replikation. Die SQL Replikationlinks von und zu dieser Site gehen kurz danach auf „Link failed“ und so bleibts erst einmmal.

Das „rcmctrl.log“ sagt etwas von:

Rcm control is waiting for file change notification or timeout after 60 seconds.
DRS change application started.      SMS_REPLICATION_CONFIGURATION_MONITOR
Launching 2 sprocs on queue ConfigMgrDRSQueue and 0 sprocs on queue ConfigMgrDRSSiteQueue.
The asynchronous command finished with return message: [Could not find stored procedure 'spDRSActivation'.].
The asynchronous command finished with return message: [Could not find stored procedure 'spDRSActivation'.]. 
There are 2 Drs Activations sprocs running. DRS sync started.

Ürgs, da hats wohl mindestens eine lebenswichtige Prozedur gelöscht. Die Lösung (nachdem ich das Problem in zwei verschiedenen Umgebungen durch Wiederherstellung erst einmal umschifft hatte) wurde vor kurzem dokumentiert.

http://blogs.technet.com/b/configmgrteam/archive/2013/09/27/now-available-cu3-for-system-center-2012-configmgr-sp1.aspx

Das „update.sql“ Skript enthält den Pfad zur angemeckerten DLL nur als Variable „‚[[SMS_ROOT]]\“. Der Assistent ersetzt den Programmpfad richtig aber bei der puren Ausführung im SQL Management Studio macht das natürlich keiner. Nachdem man den Pfad im Skript auf die eigenen Gegebenheiten angepasst hat läuft das SQL Skript auch fehlerfrei (SMS_Executive vorher stoppen).

Grrrrrr

287: Ab wann gilt eine Antivirus Signatur als veraltet?

Das frühere Windows Security Center oder jetzt das Action Center enthält ja Informationen über den aktuellen Zustand des Virenscanners. In einer aktuellen Fragestellung in einer NAP Integration in Verbindung mit System Center Endpoint Protection 2012 stellte sich die Frage wer dies ermittelt bzw. festlegt. Der folgende Screenshot zeigt den Normalbetrieb. Aus Sicht des Action Centers ist im Moment also mit dem Virenscanner alles ok.

scep01

Zuständig für die Einstufung „Signatur ist alt“ ist nicht das Action Center sondern der Virenscanner selber, der diese Information dem Action Center zur Verfügung stellt. Wie groß ist denn nun der Zeitraum? Das bestimmt wiederum der Virenscanner. Im Falle SCEP 2012 sind das 7 Tage. Der Wert „AVSignatureDue“ steht standardmäßig auf diesem Wert.

scep02

Wir hatten die Anforderung diesen Wert anzupassen. Über die Endpoint Protection Policy im SCCM 2012 lässt sich dieser Wert leider nicht bestimmen. Es gibt allerdings mit FEP 2010 einen Group Policy Ansatz für FEP Einstellungen. Diese sind ebenfalls für SCEP 2012 gültig. Hier erhält man ein GPO Template für die Einstellungen („fepserverrolepoliciesforusewithgpo.exe“):

http://www.microsoft.com/en-us/download/details.aspx?id=13088

In der GPO kann der Zeitraum definiert werden. In dem Beispiel wurde er auf einen Tag heruntergesetzt.

scep03

Und wunderbar, nach kurzer Zeit nach dem Anwenden der GPO reagiert SCEP 2012 darauf und stuft die erst 3 Tage alten Signaturen als „veraltet“ ein. Ebenfalls „quietscht“ das Action Center. Damit kann nun die NAP Infrastruktur auf einen individuellen Zeitraum eingestellt werden.

scep04

scep05