Delivery Optimization Cache Server

Hopefully you have read this blog article about the configuration and features of the Microsoft Connected Cache Server.

https://techcommunity.microsoft.com/t5/premier-field-engineering/modern-content-distribution-microsoft-endpoint-manager-and/ba-p/1148669

I recorded two short videos about how the interaction looks between the DO client and the DO cache server.

• Delivery Optimization with Microsoft Connected Cache (loading Store Apps)

 

 

• Delivery Optimization with Microsoft Connected Cache (loading Windows Updates)

 

 

This is a view of my cache after delivering and caching of two Office channels and the actual 2020/03 patch day.

Happy caching …

 

 

Werbung

Autopilot for existing devices

You might have read about this cool feature here https://techcommunity.microsoft.com/t5/Windows-IT-Pro-Blog/Upgrade-Windows-7-using-Windows-Autopilot-in-Configuration/ba-p/267747.

It is possible to get into the Autopilot starting position with a simple Configuration Manager Task Sequence. This can be used for migrating legacy OS to Windows 10 or just for a new installation of Windows 10.

See this walkthrough after configuring the infrastructure according the blog article.

 

Replace ADFS/WAP SSL certificates

As every year I had to replace the SSL certificates on my ADFS/WAP infrastructure. And as every year I’m searching the internet how to do this 🙂 Usual search results are:

https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/manage-ssl-certificates-ad-fs-wap

https://blogs.technet.microsoft.com/rmilne/2016/03/21/updating-windows-server-2012-r2-adfs-ssl-and-service-certificates/

https://blogs.technet.microsoft.com/tune_in_to_windows_intune/2013/11/13/replace-certificates-on-adfs-3-0/

But unfortunately both are not 100% complete and accurate. Here is my procedure.

On the ADFS Server:

• Import the new SSL certificate in the computers „MY“ certificate store.
• Run a elevated Powershell to get the thumbprint of the certificate.

  cd cert:
  cd localmachine
  cd my
  dir

  Identify the thumbprint in the output. In my case: 1E8B377DD54B7650612C98E4B8816501B4BB4985

• Switch ADFS service communication certificate to the new SSL certificate with this cmdlet

  Set-AdfsCertificate -Thumbprint 1E8B377DD54B7650612C98E4B8816501B4BB4985 -CertificateType Service-Communications

• Set the ADFS SSL certificate with this cmdlet and proof it with netsh

  Set-AdfsSslCertificate -Thumbprint 1E8B377DD54B7650612C98E4B8816501B4BB4985 
  
  netsh http show sslcert

• Verifiy that „read“ access for the ADFS service account was granted on the certificate. Open „certlm.msc“, select the new SSL certificate and select „All Tasks / Manage private keys“.
  Since this is a „Virtual Account“ we can see „NT SERVICE\adfssrv“ should have read access.
  
• Restart the ADFS service

  Restart-Service adfssrv

On the WAP Server:

• Import the new SSL certificate in the computers „MY“ certificate store.
• Configure the WAP service for the new certificate with this cmdlet.

  Set-WebApplicationProxySslCertificate -Thumbprint 1E8B377DD54B7650612C98E4B8816501B4BB4985

• Re-establish the proxy trust with this cmdlet.

  Install-WebApplicationProxy -CertificateThumbprint 1E8B377DD54B7650612C98E4B8816501B4BB4985 -FederationServiceName sts.youradfsservice.com

• This step is missing in most documentations if you have existing WAP published applications. Since every published application is configured seperately with a SSL certificate we had to change every app. All applications in my infrastructure were published with the same certificate, so I’m able to switch all apps to the new certificate with this cmdlet:

  Get-WebApplicationProxyApplication | Set-WebApplicationProxyApplication -ExternalCertificateThumbprint 1E8B377DD54B7650612C98E4B8816501B4BB4985

Defer iOS updates with Intune (now built-in)

You might have read this article where we talked about defering iOS updates with a Apple Configurator profile. Seems that this isn’t necessary anymore since the Intune August update.

Defer iOS updates with Intune

Sometimes companies like to defer iOS updates for the field till they tested it.

Intune native provides an iOS update policy.

But thats not what we need in this case because we are not able to hide the update from the user and prevent manual installation of it.

Apple integrated a method to defer updates since iOS 11.3. It is documented here:

https://developer.apple.com/enterprise/documentation/Configuration-Profile-Reference.pdf

enforcedSoftwareUpdateDelay / Integer / Supervised only

This restriction allows the admin to set how many days a software update on the device will be delayed. 
With this restriction in place, the user will not see a software update until the specified number of days 
after the software update release date. The max is 90 days and the default value is 30. 
Availability: Available in iOS 11.3 and later and macOS 10.13.4 and later.

 

We are able to set this restriction with a custom profile created with the Apple Configurator tool.

We deleted all other settings from the file but not the „Defer software updates“ part. It looks like this at the end.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
 <key>PayloadContent</key>
 <array>
  <dict>
  <key>PayloadDescription</key>
  <string>Configures restrictions</string>
  <key>PayloadDisplayName</key>
  <string>Restrictions</string>
  <key>PayloadIdentifier</key>
  <string>com.apple.applicationaccess.06D592A7-EBB8-4C39-9BD2-476325C606FE</string>
  <key>PayloadType</key>
  <string>com.apple.applicationaccess</string>
  <key>PayloadUUID</key>
  <string>06D592A7-EBB8-4C39-9BD2-476325C606FE</string>
  <key>PayloadVersion</key>
  <integer>1</integer>
  <key>enforcedSoftwareUpdateDelay</key>
  <integer>10</integer>
 </dict>
</array>
<key>PayloadDisplayName</key>
<string>Untitled</string>
<key>PayloadIdentifier</key>
<string>WS-MacBook-Air.9125F365-4E56-4080-AEE7-083B4C48F069</string>
<key>PayloadRemovalDisallowed</key>
<false/>
<key>PayloadType</key>
<string>Configuration</string>
<key>PayloadUUID</key>
<string>E9114952-B602-407D-B2F7-5F251FBE7F9D</string>
<key>PayloadVersion</key>
<integer>1</integer>
</dict>
</plist>

The deployment of the custom setting is easy with a device configuration profile.

The device shows the resulting setting in the management profile.

Intune Certificate Connector Proxy Issues

We are in the process of implementing the necessary infrastructure for certificate deployment with Intune as documented here.

https://docs.microsoft.com/en-us/intune/certificates-scep-configure

The environment is highly secured, means that the certificate connectors outbound internet connection has to be configured with an outgoing proxy server. So, no problem we thought, since the connectors setup UI has a built-in configuration option for configuring the proxy server.

But the connector status in the Azure portal stays „red“ and there was no communication from the connector to Azure. We started troubleshooting and opened the connector UI again to verify that we entered the correct proxy server.

We wondered why the proxy server name was prefixed with „http: //“ since we didn’t entered that. Seems to be a kind of feature to add it automatically. The connectors configuration in the Windows registry contains this prefix too. We removed the prefix in the registry and restarted the service but it didn’t change the behaviour.

This blog https://ronnydejong.com/2017/05/02/part-2-deploying-microsoft-intune-connector-in-an-enterprise-world-troubleshooting/#more-4326 shows the usual troubleshooting options, log files and tools to format the logs.

The connector log was showing:

Exception in version sync thread: System.ArgumentException: Location Service Error:
https://manage.microsoft.com/RestUserAuthLocationService/RestUserAuthLocationService/Certificate/ServiceAddresses : CN=12343212-1234-4567-6789-123454321234 :
System.Net.WebException: The remote name could not be resolved: manage.microsoft.com
at System.Net.HttpWebRequest.GetResponse

 

Next idea was to try with a system proxy to get all SYSTEM processes in the direction to the proxy.

netsh winhttp set proxy proxysrv:8080 bypass-list="<local>"

Current WinHTTP proxy settings:

Proxy Server(s) : proxysrv:8080
Bypass List : <local>

But unfortunately this changes nothing in the game.

It’s starting to be curious and as a kind of last resort we wanted to check internet access  oneselfs. So we started a browser session with „psexec“.

psexec -s -i "%programfiles%\Internet Explorer\iexplore.exe"

After configuring the proxy settings in the browser session we were able to access the URL „https://manage.microsoft.com“. So we are sure that the connection is possible and all internal rules are inplace and working.

This change is recorded in the default user profile (HKU\.DEFAULT) and used for a browser session in system context.

And oh wonder, the certificate connector was connecting successfully to Azure. Seems that this action was the magic change to get it working. It’s not clear at the moment why the proxy configuration setting in the connector properties is not working.

After some digging around we found an easy method to configure the systems proxy with „bitsadmin“ (https://docs.microsoft.com/de-de/windows/desktop/Bits/bitsadmin-tool)

bitsadmin /util /setieproxy localsystem MANUAL_PROXY proxysrv:8080 "<local>"

We will go productive now with this scenario…..

Intune: Rename managed iOS device with Graph

I got the question from the customer about how to rename iOS devices in Intune. We discovered that a rename operation is possible if the device is:

• Company owned
• Supervised

In this case there’s a „Rename“ button in the device property view.

The rename process is straightforward and a short time after resyncing the device, we can see the new name on the device itself and in the Intune portal.

The next challenge started with the question „Can we do this by Powershell?“.

Sure, why not, but how?

First step in getting a picture if this can work, is to use the network analysis (F12) in the browser during the rename operation in the portal.

 

It gets clear that there is a „POST“ method „/setDeviceName“ which triggers the device rename. There is also a JSON file uploaded during POST that contains the target device name. It contains just on line:

{"deviceName":"Wolfgang's iPad NewName"}

So next step is to visit the Intune Graph Sample library on Github https://github.com/microsoftgraph/powershell-intune-samples. After a little bit of searching and trying we found this example „DeviceConfiguration_Import_FromJSON.ps1„.

It seems that the framework of this script can provide the features we need. We have to edit just one line:

line 174 old: $DCP_resource = "deviceManagement/deviceConfigurations"
line 174 new: $DCP_resource = "deviceManagement/managedDevices('c09c5e68-1503-4f22-a4f2-c0724706efee')/setDeviceName"

It’s not so comfortable till now but its just a feasability study at the moment 🙂 We have to include the Intune device ID in the POST method. During runtime we have to provide the administrative context and the name of the JSON file.

We can prove the initiation of the rename process with the Intune portal.

The device renames itself after the next policy interval cycle and the Intune portal reflects the new name shortly after that.

Thanks @davefalkus for the sample Intune Graph library.

 

 

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.

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.

 

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:

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.

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.

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).

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).

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

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“.

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

Im Cluster Administrator sieht das jetzt so aus:

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

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

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.

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“

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.

 

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.

 

 

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.

 

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

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

Der „Resource Explorer“ zeigt weitere Details an.

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.

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.

   

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.

   

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.

   

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

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

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

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.

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.

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“).

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.

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

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.

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:

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“.

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):

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.

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.

Die Installation einer Applikation sieht dann so aus:

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.

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.

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.

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.

 

286: System Center Endpoint Protection Update

Für SCCM 2012 SP1 mit installiertem CU2 gibt es eine neuere Version der Endpoint Protection. Diese wird vermutlich für das kommende Windows 8.1 benötigt. Falls das Update serverseitig nicht eingespielt ist versucht der SCCM Agent trotzdem den SCEP Client zu installieren und scheitert mit folgender Fehlermeldung im „EndpointProtectionAgent.log“.

Detail error message is : [EppSetupResult]
HRESULT=0x8004FF71
Description=System Center 2012 Endpoint Protection cannot be installed on your operating system. 
Windows Program Compatibility mode is not supported by this program.
For information about supported operating systems, see the online Help. 
Error code:0x8004FF71.

Also los gehts. Update hier anfordern: http://support.microsoft.com/kb/2865173. Aus dem heruntergeladenen Hotfix Paket entstehen diese zwei Updatepakete:

• CM12-SP1CU2-QFE-KB2864366-X64-ENU.exe (dieses ist seit dem 10.9. nicht mehr im Updatepaket drin. Es war auch nicht dokumentiert und anscheinend nicht notwendig)
• CM12-SP1CU2-QFE-KB2865173-X64-ENU.exe

Diese werden nach der Installation auf dem Siteserver, wie andere Updates auch, im SCCMDIR\Hotfix Verzeichnis gespeichert, von wo sie z.B. per Updates Publisher ggf. auf weitere Sitesysteme übertragen werden können. Hat man nur einen Siteserver dann ist das schon geschehen und weitere Aktionen nicht notwendig. Die Updates generieren bei einer primären Site einen Site Reset, d.h. es macht Sinn das „sitecomp.log“ zu beobachten ob der Reset fertig ist und ggf. auch einen Blick in das „mpsetup.log“ zu werfen um zu erfahren ob ein Reboot notwendig ist.

Nach den Updates finded sich im SCCMDIR\Client Verzeichnis eine neue „scepinstall.exe“ mit der Versionsnummer „4.3.0215.0“. Diese gilt es jetzt ins Feld zu bekommen. Eine Methode ist hier beschrieben die einwandfrei funktioniert: http://blogs.msdn.com/b/minfangl/archive/2013/08/15/guidance-on-install-anti-malware-platform-updates-for-fep-2010-su1-and-scep-2012-sp1.aspx.

Hier ist nachzulesen wie die Methode genau funktioniert: http://configmgrblog.com/2012/12/03/how-to-update-configmgr-clients-automatically-in-sp1/.  Möchte man also den Zeitraum nicht abwarten reicht es den angelegten Task auf dem Client zu starten um das SCEP Update anzutriggern der das aktualisierte „scepinstall.exe“ ins Verzeichnis „ccmsetup“ herunterlädt.  Im „EndpointProtectionAgent.log“ ist dann folgendes zu sehen (Geduld… :-))

File C:\WINDOWS\ccmsetup\SCEPInstall.exe version is 4.3.215.0
Unable to query registry key (SOFTWARE\Microsoft\Microsoft Security Client), return (0x80070002) means EP client is NOT installed
Sending ack to MTC for task {9BCF7827-E04F-4C3A-8D8C-B943316A2D7F}
SCEP client is not present, SCEP client will be installed with the latest AM policy
Sending message to external event agent to disable notification
Sending message to endpoint ExternalEventAgent
Disable Startup Signature Update equals to false
Add the Disable Startup Signature Update settings to policy xml successfully
Create Process Command line: "C:\WINDOWS\ccmsetup\SCEPInstall.exe" /s /q /policy "C:\WINDOWS\CCM\EPAMPolicy.xml"
Endpoint is triggered by WMI notification
Detail error message is : [EppSetupResult] HRESULT=0x00000000
Description=The operation completed successfully.

Jetzt ist Endpoint Protection installiert bzw. aktualisiert.

285: Kurzes Pass-the-Hash Experiment

Erstaunliche Experimente kann man mit einem kleinen Tool durchführen. Es ist in der Lage im RAM der Windows Maschine nach Kennwort Hashes Ausschau zu halten. Es findet diese auch von anderen, z.B. per RDP angemeldeten Benutzern (weitere Details im MS Whitepaper, auch Dienstekonten oder Task Scheduler Konten sind betroffen). Sollte das ein administrativer Benutzer oder sogar ein Domain Admin sein, kann man sich praktisch als dieser ausgeben indem man dessen Hash verwendet bzw. missbraucht. Im Zweifel kann man sogar das Kennwort in Klarschrift ermitteln.

Einzige Voraussetzung ist, dass man einen lokalen administrativen Benutzer besitzt. Alle anderen Benutzer die sich dann auf der Maschine anmelden, sind dann praktisch gefährdet.

Das Tool heißt „wce.exe“ und kann von der Entwicklerseite heruntergeladen werden. Er erläutert dort auch einige technische Hintergründe. Im Downloadarchiv befindet sich wieder ein Archiv das dann das eigentliche Tool enthält. Also einfach zweimal z.B. per 7-Zip öffnen. Virenscanner oder auch der Defender auf Windows 8 werden jetzt sofort anschlagen. Bei meinen Experimenten hat eine Windows 8 Maschine beim Einsatz des Tools auch sofort rebootet.

Mein Beispielszenario sah folgendermaßen aus:

• Windows Server 2003 Member Server
• Lokaler Benutzer mit Adminrechten: localadmin
• Domänen Admin Benutzer: corp-admin1

Phase 1: Server frisch gebootet und „LocalAdmin“ hat sich angemeldet. Der „böse“ sieht zwei Hashes, seinen eigenen und den des Computerkontos.

Phase 2: Der Domain Admin meldet sich über RDP an und „LocalAdmin“ beobachtet weiter. Er findet nun den Hash des Domain Admins – Schluck!

Phase 3: „LocalAdmin“ zieht sich die „Domain Admin“ Mütze über, indem er den Hash des Domain Admins in seine Sitzung injiziert. Der erste Versuch zeigt eine normale Zugriffsverweigerung für den „LocalAdmin“. Nach der Hash Injektion ist der Zugriff gewährt. In dem Fall handelt es sich um einen DC der Domäne. Der böse Bube könnte jetzt genauso AD Users & Computers oder andere Tools verwenden um weiter zu spionieren und z.B. Kennworte zurücksetzen.

Zugabe: Interessant wäre natürlich auch noch das Kennwort in Klarschrift zu kennen. In dem Fall könnte der böse Bube weitgehend unbemerkt seiner „Arbeit“ nachgehen, da er ja kein Kennwort zurücksetzt und deswegen auch in keinem Security Log eine Fehlermeldung hinterlässt.

oh oh … ich denke es gilt bestimmte Vorgehensweisen und Gewohnheiten im Unternehmen nochmal neu zu beleuchten.

Weitere technische Hintergründe und mögliche Verfahren das Risiko zu minimieren wurden hier dokumentiert:

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

http://www.sans.org/reading_room/whitepapers/testing/pass-the-hash-attacks-tools-mitigation_33283

284: SCCM 2012 SP1 begrüßt neue Freunde

Mit dem „baldigen“ Erscheinen des SP1 für den Configuration Manager halten auch neue Clients Einzug in die Infrastruktur. Wir werden dann die Möglichkeit haben Androiden, iPhones, Windows Phones, Windows 8, MACs und Linuxe mehr oder weniger tief verwalten zu können. Hier ein paar Beispiele zum Aufwärmen:

Deployment Types für verschiedene Plattformen

In dem Bild sieht man sogenannte „Deeplinks“ in die jeweiligen App Stores. D.h. ConfigMgr braucht in dem Fall keinen Distribution Point der für die Geräte erreichbar ist. Die App wird über die konfigurierte URL einfach aus dem App Store gezogen.

Sichtbar ist hier auch der „Deployment Type“ für Mac OS. In diesem Fall steckt wirklicher „Content“ dahinter. Allerdings kann nicht der native Mac OS Installer verwendet werden. Die Applikationsquelle muss auf einem Mac entsprechend aufbereitet werden. Man findet auf dem SP1 Datenträger im Verzeichnis „\SMSSetup\MacOSClient“ ein Image namens „macclient.dmg“ das einerseits den Mac OS Agent und andererseits das Tool „CMAppUtil“ enthält mit dem die Applikation für SCCM „gepimpt“ werden kann. Es wird ein „.cmmac“ File erzeugt, mit dem man einen neuen Depoyment Type anlegen kann.

Unix/Linux Agents

Neben diesen Clients können nun auch diverse Unix bzw. Linux Versionen in die ConfigMgr Infrastruktur aufgenommen werden. Die SP1 Beta Clients finden sich hier: http://www.microsoft.com/en-us/download/details.aspx?id=34609 . Sollte das Experiment in einer Hyper-V VM stattfinden dann benötigt man noch die ICs für das passende Unix/Linux von hier: http://www.microsoft.com/en-us/download/details.aspx?id=29991 . Besonders fies nach der Installation der Integrationskomponenten ist, dass man keine virtuelle CD/ISO mehr mounten kann, das wurde leider wegoptimiert. Also entweder den CM Client vorher draufkopieren (per ISO) oder später per SMB einen Share mounten. So sieht der entpackte Client aus (in dem Fall hatte ich ein Red Hat 6 installiert):

Das Installationsskript packt nun den Agent auf die Maschine.Mitinstalliert wird das Mini WMI „nanowbem“: http://blogs.technet.com/b/port25/archive/2012/06/29/open-management-interface-omi-open-source-implementation-of-dmtf-cim-wbem-standards.aspx.

In dem Beispiel sieht man den eigentlichen Agent und ein Beispiel wie die „Action – Policy Refresh“ durchgeführt werden kann.

Da es sich hier um eine Art „Workgroup“ Betrieb handelt muss der Agent ggf. bestätigt werden. Hier sind alle Schritte sehr schön dokumentiert: http://myitforum.com/myitforumwp/2012/09/18/configmgr-2012-sp1-beta-linux-client/ .

Ab nun berichtet der Agent seine Inventur zum Management Point. Hier ein paar Beispiele:

Weitere Tests müssen noch folgen …

282: Server Summit 2012 – Exchange Troubleshooting II

Die Sache mit der Exchange Management Shell (s.u.) ist leider immer noch nicht gelöst und schon passieren weitere dubiose Dinge in meiner Exchange Umgebung. Mehrere Benutzer bekommen auf einmal diesen Unzustellbarkeitsbericht beim Senden einer Mail. Der NDR wird intern produziert, es hat also nichts mit der Zustellung an externe SMTP Server zu tun.

Was geht denn hier ab?

— Update 1 —

Christian wirft einfach so die Begriffe „legacyexchangeDN/X500 Adressen“ ein. Ja, ok, das streift das Thema. Der Admin (in dem Fall ich) schwört, nicht mit Adsiedit, ldp oder ähnlichem „gepfuscht“ zu haben. Er ging einfach seinem Admin Job wie jeden Tag nach 🙂 Wie kanns also zu so einem Verhalten kommen? Und vor allem, kann der Admin selber etwas zur Problemlösung beitragen? Oder muss er seine Benutzer informieren etwas Bestimmtes zu tun? Hmm??

— Update 2 —

Das Verhalten ergibt sich in folgender Situation:
– Ein Benutzer verwendet einen im AD angelegten Kontakt zum Senden einer Email
– Dabei wird die Kontaktadresse in seinem Nickname Cache gespeichert. Hier wird allerdings nicht die SMTP Adresse verwendet sondern das Attribut „LegacyExchangeDN“ des Kontakts (und das wird gleich zum Problem)
– Der Admin löscht nun den Kontakt während Aufräumarbeiten. Damit ist dessen „LegacyExchangeDN“ nicht mehr im AD vorhanden
– Der Benutzer verwendet den Nickname Cache zum Senden einer neuen Email und Voilá -> es kommt dieser NDR

Hier ein Bild des im Postfach gespeicherten Nickname Caches:

Mögliche Workarounds:

– Benutzer informieren damit die den Nickname löschen.
– Outlook 2010 hat dafür einen Knopf in den Email Optionen oder einen Kommandozeilenoption
– http://aspoc.net/archives/2010/05/04/how-to-clear-the-autocomplete-list-in-outlook-2010/

– den alten „LegacyExchangeDN“ kann man auch als X500 Adresse bei einem anderen Emfpänger als weitere Empfangsadresse hinzufügen. Bei dem könnte man wiederum den Abwesenheitsassi einstellen mit dem man dem Sender eine Hilfestellung zukommen lassen kann.

281: Server Summit 2012 – Exchange Troubleshooting I

Der MS Partner Server Summit ist nur noch zwei Wochen entfernt. Im Exchange Troubleshooting Vortrag werden wir einige Beispiele für „Trouble“ sehen bzw. herausfordern.

Zum Beispiel das hier, beim Start der Exchange Management Shell passiert folgendes. Was könnte der Grund sein?

Sachdienliche Hinweise gerne als Kommentar 🙂

— Update 1 —
Walter tippt auf DNS. Ein „nslookup“ für den Exchange Server und DC plus ping zeigt folgendes an. Sieht also ganz gut aus. Wir müssen also weiter troubleshooten.

— Update 2 —
Weitere Hinweise von Walter.

http://technet.microsoft.com/en-us/library/cc775100(v=WS.10).aspx
Ergebnis: WMI ist in Ordnung.

http://technet.microsoft.com/en-us/library/dd351136.aspx
Ergebnis: Respektable Liste aber kein Punkt trifft zu.

http://joetrombley.wordpress.com/2011/03/12/the-windows-powershell-snap-n-microsoft-exchange-management-powershell-e2010-is-not-installed-on-this-machine/
Ergebnis: Registry ist in Ordnung.

Das Troubleshooting geht also weiter.

–Update 3 —

Es ist im Endeffekt „nur“ eine Kleinigkeit. Ich bin leider selber darüber gestolpert bzw. habe das Problem einmal selber verursacht als ich den Exchange Server „so gut wie möglich“ auf eine Update Rollup Installation vorbereiten wollte. Da kämpft man doch gerne mit einer bestimmten Sache rum, oder nicht?

— Update 4 —

Ulli tippt in Richtung Zeitsynchronisation und Kerberos. Gute Idee. Aber die folgenden Tests in Bezug auf Zeitsync und DC Zugriff verliefen trotz des Problems erfolgreich.

— Update 5 —

Henning verdächtigt die Powershell „ExecutionPolicy“ und das PS Remoting. Die ExecutionPolicy stimmt mit anderen Servern überein. Allerdings ist ein ähnliches bzw. dasselbe Problem auch beim PS Remoting Test zu sehen -> the servername cannot be resolved, nslookup, ping usw. sind aber ok – hmmm

— Update 6 —

Alex tippt auf nicht gestartete Dienste. Aber alle Dienste die notwendig bzw. auf Startart „Automatic“ konfiguriert sind, sind auch gestartet. Die Lösung ist auch ähnlich einfach, nur im Bereich „Namen“ bzw. „Protokolle“ zu finden 🙂

— Update 7 —

Alex will nochmal den IIS checken. Der sieht aber gut aus. Alle Websites laufen und es gibt keine Crashs.

Die Auflösung kommt nächste Woche. Dann wird jeder sagen „Oh mann“ 🙂

— Update 8 —

Also das Problem war, dass ich einen Proxy für SYSTEM konfiguriert hatte und dabei vergessen hatte die korrekten Ausnahmen zu konfigurieren. Das ist sehr einfach nachzuvollziehen:

Problem erzeugen:
netsh winhttp set proxy unbekannterhost

Problem lösen:
netsh winhttp reset proxy

279: Bald kein Vertrauen mehr zu Schlüsseln unter 1024 Bit Länge

Wir verwenden den System Center Updates Publisher (SCUP) zur laufenden Aktualisierung von Adobe Reader und Flash Player. Im Prinzip funktioniert das Tool folgendermaßen:

• der Herstellerkatalog wird mit SCUP in den WSUS integriert und Clients können dagegen scannen und z.B. feststellen, dass Flash aktualisiert werden muss.
• der Admin verwendet die SCUP Konsole um das Update im WSUS bzw. im SCCM bereitzustellen.
• dabei wird das Update vom Hersteller heruntergeladen und mit einem eigenen Signaturzertifikat signiert. Das Zertifikat kann durch den SCUP selbst signiert sein oder man verwendet ein Codesignatur Zertifikat einer eigenen CA.
• am Client muss das Zertifikat (der öffentliche Schlüssel) in den „Trusted Root“ und in den „Trusted Publisher“ Bereich des Zertifikatsspeichers importiert werden.
• während des Update Deployments prüft Windows ob es dem Zertifikat „traut“ bevor das Update installiert wird.

Soweit alles ok und funktioniert(e) auch prima. Nachdem nun einige Windows 8 Maschinen in der Domäne auftauchten fiel auf, dass durchweg die per SCUP bereitgestellten Updates fehlschlagen. Im Normalfall sind 90% der Probleme beim SCUP auf Zertifikate zurückzuführen. Eine Überprüfung ergab, dass alle Bedingungen auf Windows 8 Maschinen identisch zu Windows 7 oder XP Maschinen waren. Warum funktionierts dann aber nicht?

Das Zertifikat wird auf einer Windows 8 Maschine so dargestellt:

Das Zertifikat wurde damals der Einfachheit halber vom SCUP selbst signiert. Merkwürdig: Es ist nicht abgelaufen, der öffentliche Schlüssel der CA befindet sich im „Trusted Root“ Speicher. Trotzdem vertraut Windows 8 dem Zertifikat nicht.

Beim Recherchieren bin ich auf diese beiden Blogeinträge gestoßen:

http://blogs.technet.com/b/pki/archive/2012/06/12/rsa-keys-under-1024-bits-are-blocked.aspx

http://blogs.technet.com/b/pki/archive/2012/07/13/blocking-rsa-keys-less-than-1024-bits-part-2.aspx

Offensichtlich soll jetzt im August ein Update veröffentlicht werden das dazu führt, dass Schlüssel mit einer Schlüssellänge unter 1024 Bit nicht mehr vertrauenswürdig sind. Dieses „Feature“ ist wohl bei Windows 8 schon eingebaut. Und tatsächlich enthält das vom SCUP ausgestellte Zertifikat einen nur 512 Bit langen öffentlichen Schlüssel.

Ich habe dann in meinem Fall ein Zertifikat vom Type „Code signing“ mit 1024 Bit Schlüssellänge von der eigenen CA angefordert. Kleiner Nachteil war dabei, dass alle Updates nochmal neu signiert werden und der Schlüssel noch in die „Trusted Publisher“ der Clients verteilt werden musste.

Was mit SCCM Software Deployment kein Act ist:

certutil.exe -addstore TrustedPublisher "%~dp0scup-codesigning.cer"

Im Blog sind andere Workarounds beschrieben mit denen die Anforderung auf min. 1024 Bit wieder heruntergeschraubt werden kann. Die funktionieren auch, aber an sich ist das „Anziehen der Schraube“ schon eine gute Sache. Bin gespannt wo noch überall kurze Schlüssel auftauchen.

278: Klappe die Zweite

Nach den ersten Versuchen vor zwei Jahren folgt nun das nächste Video. Der Schnipsel zeigt kurz eine neue Funktion des Windows 2012 Server. Mein Kollege Phil Schman und ich werden in den nächsten Wochen einen Windows Server 2012 Seminar „Teaser“ produzieren in dem einige Demos in der Art zu sehen sein werden. Ich sag dann Bescheid wenns soweit ist 🙂

Hier der Vorgeschmack:
Windows Server 2012 – Live Migration: http://www.youtube.com/watch?v=C3Jkivuutps
Windows Server 2012 – Domain Controller Snapshot: http://www.youtube.com/watch?v=FfYMu8ObrqM

277: Exchange 2010 DAG Maintenance

Während Wartungsarbeiten an DAG Clusterknoten verwenden Administratoren die Skripte „Start- und StopDAGServerMaintenance.ps1“. Das „Start“ Skript sorgt dafür, dass der DAG Knoten von aktiven Datenbanken befreit, der Cluster pausiert und die Datenbank Aktivierung blockiert wird.

Nun gab es einen unschönen Effekt, der in bestimmten Szenarien einen erfolreichen Einsatz des Skripts verhindert hat. Sollte die DAG aus MEHR als zwei Knoten bestehen, und Datenbanken „nur“ zwei Kopien besitzen, bricht das Skript mit folgender Meldung ab:

„The following objects are hosted by Mailbox Server, before attempting to move them off: `n(Database=<Mailbox Database>, Reason=’Copy is critical for redundancy according to Red Alert script‘))“

Das ist hier dokumentiert:

http://blogs.technet.com/b/timmcmic/archive/2011/09/26/exchange-2010-sp1-startdagservermaintenance-ps1-fails-on-databases-that-have-only-two-database-copies.aspx

Im KB Artikel zum Update Rollup 1 für den SP2 findet man einen Hinweis auf eine Korrektur des Skripts.

http://support.microsoft.com/kb/2585649

Nur, die Autoren des Artikels waren ein wenig faul und beschreiben nicht wie man mit dem neuen Skript erfolgreich den Server in Wartung nimmt. Macht aber nix, die Hilfe zum Cmdlet gibt den entscheidenden Hinweis auf eine neue Kommandozeilenoption „-overrideMinimumTwoCopies“.

D.h mit .\StartDAGServerMaintenance.ps1 -Server Name -overrideMinimumTwoCopies klappt das jetzt wieder prima.

276: Lync Mobile für die Apfel Fraktion – erster Eindruck

Seit wenigen Stunden ist Lync Mobile auch fürs iPhone bereit zum Herunterladen. Hier ein paar „Quick & Dirty“ Eindrücke ohne viel ausprobiert zu haben.