295: ADFS 2012 R2 und Zertifikate

Jeder ADFS Administrator muss irgendwann das SSL bzw. Service Communication Zertifikat seiner ADFS Infrastruktur tauschen. Die aus meiner Sicht beste Beschreibung der Aufgabe ist die hier:

https://blogs.msdn.microsoft.com/vilath/2015/09/02/how-to-update-certificates-for-ad-fs-3-0/

Oft entsteht dabei die Verwirrung, ob das ADFS Dienstekonto Berechtigungen für den „private key“ des Zertifikats braucht. Unterstützt wird das noch durch die Meldung der ADFS Konsole beim Tausch des Service Communication Zertifikats per ADFS MMC.

p00

Schaut man sich die Berechtigungen des „private keys“ vor dem Tausch an, sieht man, dass der Serviceaccount keine expliziten Berechtigungen besitzt. Wie kann der Dienst dann den „private key“ verwenden? Die Antwort ergibt sich wenn man die ACL des Keys anschaut. Wo kommen diese beiden markierten Objekte her und was sind das für Konten? Diese Konten gibt es weder im Active Directory noch in der lokalen SAM.

p022  p02

Es handelt sich dabei um „Virtual Accounts“. Diese gibt es seit Windows Server 2008 R2 und wurden mit den „Group Managed Service Accounts“ eingeführt und sind auch mit ihnen verwandt. Ein gute Beschreibung kann man hier finden:

https://technet.microsoft.com/en-us/library/dd548356(WS.10).aspx

Damit ist alleine der Name des Dienstes ausreichend um Berechtigungen auf ein Objekt zu delegieren. Man muss nur der Notation „NT Service\Dienstname“ folgen. Das Experiment im Filesystem zeigt das ganz einfach:

p03

In diesem Fall wird beispielhaft den selben Diensten Berechtigungen auf eine Datei erteilt wie auf den „private key“ des Zertifikats.

Muss man das beim Tausch des Zertifikats manuell machen?
-> Nein, denn das Powershell Cmdlet „Set-AdfsSslCertificate -Thumbprint thumbprint“, das man bei der Aktivierung des SSL Zertifikats verwendet, übernimmt das.

Also als Zusammenfassung:

Braucht der ADFS/DRS Serviceaccount Rechte auf den „private key“
-> nein

Braucht der ADFS/DRS Service Rechte auf den „private key“
-> ja, die bekommt er automatisch beim Aktivieren des SSL Zertifikats per Set-AdfsSslCertificate

294: Mini „Proof of Concept“ mit Windows Server 2016 Storage Replication

Eines der interessantesten Features des Windows Server 2016 ist die synchrone oder asynchrone Replikation von Festplatteninhalten.

Die möglichen Szenarien und auch ein Leitfaden zur Installation sind hier beschrieben:

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

Interessant sind eigentlich alle Szenarien. Besonders schick finde ich die Replikation in einem „stretched cluster“ für den Einsatz als Hyper-V Platform oder auch als normaler Fileserver.

Der in der Technet beschriebene Aufbau ist „zum Spielen“ aber viel zu aufwendig. In diesem Beitrag ist alles auf ein Minimum reduziert. Aufgebaut wird das Szenario „Hyper-V stretched cluster“. Die Idee ist hier also eine Virtualisierungsinfrastruktur über zwei Standorte auszudehnen und die Storage per Storage Replication (SR) zu replizieren.

Technische Fragen / Bedingungen mussten zuvor mangels klarer Doku praktisch ausprobiert werden. Hier die wichtigsten Spielregeln für die POC Umgebung (gebaut aus Hyper-V VMs)

  • direkt in die Clusterknoten eingebaute Festplatten können nicht für SR verwendet werden. Deswegen werden in dieser Umgebung noch iSCSI Targets eingesetzt.
  • „Storage Spaces Direct“, auch ein neues Windows Server 2016 Feature, scheiden auch aus, weil auf jeder Seite mindestens 4 Maschinen notwendig wären um die Storage abzubilden.

Daraus ist diese Konfiguration basierend auf der Technology Preview 3 entstanden:

  • TDC01 ist DC und Server für zwei iSCSI Targets.
    In jedem Target sind zwei virtual Disks konfiguriert
  • TC01 und TC02 bilden einen Failover Cluster (keine besondere Konfiguration,
    jeder Knoten hat nur eine Netzwerkkarte).
  • Alle Maschinen befinden sich in der selben AD Site.

sr01

Ziel ist es das 100GB Volume mit dem Laufwerksbuchstaben E: von TC02 nach TC01 synchron zu replizieren. Ausgangspunkt der folgenden Bilder ist ein konfigurierter Failover Cluster. Die lokalen Disks sind jetzt noch nicht dem Cluster zugeordnet.

Erster Schritt is es die notwendigen Festplatten zu konfigurieren. Beide Seiten werden identisch eingerichtet. Die E: und L: Laufwerke werden jeweils als GPT partitioniert und ein Volume eingerichtet. E: simuliert das Datenlaufwerk und L: die Logdisk für die Replikation.

sr02

Jetzt werden die Disks zum Cluster hinzugefügt.

Wichtig ist hier, sich die Nummern der Cluster Disks zu notiereren, um später Verwirrungen zu vermeiden. In diesem Fall wird „Cluster Disk 4“ die Quelle und „Cluster Disk 3“ das Ziel der Replikation sein (einfach zu sehen an den Hostnamen im Disk Info Feld).

sr03

Die Quelldisk (in dem Fall „Disk 4“) muss nun in ein Cluster Shared Volume umgewandelt bzw. hinzugefügt werden. Dazu muss die Disk online sein. Das gelingt nur, wenn man das auf dem Clusterknoten durchführt an dem die Disk auch angeschlossen ist. Die Aktion die in im folgenden Bild dargestellt ist wird deswegen fehlschlagen (weil der Owner Node der Falsche ist).

sr04

Das kann einfach durch Verschieben der Platte zum anderen Knoten (in dem die Disk auch steckt) korrigiert werden.

sr05

Danach kann man die „Disk 4“ online nehmen und das Erzeugen des CSV gelingt (dafür gibts kein eigenes Bild). Wichtig für den „Online“ Zustand ist nur die Quell Datendisk. Alles andere spielt keine Rolle und wird durch den Assistent später richtig erkannt und konfiguriert.

Jetzt geht es an die Einrichung der Replikation. Die folgenden Bilder zeigen den Assistenten Schritt für Schritt und sind eigentlich selbsterkärend. Gestartet wird mit rechter Maus auf „Cluster Disk 4“.

sr06

sr07

sr08

sr09

sr10

sr11

sr12

sr13

sr14

sr15

Jetzt startet die Erstsynchronisation die man sehr schön im Task Manager und Eventlog sehen kann.

sr16

sr17

sr18

sr19

Im Cluster Administrator sieht das jetzt so aus:

sr20

sr21

Ich hatte einige Fehlversuche bis das einigermaßen nachvollziehbar lief. Die wichtigsten hier:

  • es passierte, dass man keine Disks dem Cluster hinzufügen konnte. Grund ist, dass noch SCSI Reservierungen von Fehlversuchen da waren. Hilfe „Clear-ClusterDiskReservation -disk 1″ und „Clear-ClusterDiskReservation  -disk 2″ am Besten auf beiden Seiten.
  • Cluster Disks kommen teilweise nicht online -> Windows Search Service muss deaktiviert werden.
  • Beim Einrichten der SR wird keine Zieldisk angezeigt und ein Klick auf „non eligable disks“ zeigt „Partition size does not match“. Grund war bei mir, dass ich dachte, dass die Zieldisk nicht partitioniert sein sollte bzw. müsste. Muss aber 🙂
  • Und manchmal half auch einfach ein Reboot.

Das alles ist auch hier zu lesen: Storage Replica: Know Issues (Lohnt sich reinzuschauen ;-))
https://technet.microsoft.com/en-us/library/mt126101.aspx

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.

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.