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:

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

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

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" "">
<plist version="1.0">
  <string>Configures restrictions</string>

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.

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 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: : CN=12343212-1234-4567-6789-123454321234 :
System.Net.WebException: The remote name could not be resolved:
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 „;. 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“ (

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

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.

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:

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:

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