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.

 

Advertisements

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.
    private-key
  • 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.

ios-delay

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.

up-pol01

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.

apple-config

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.

Intune-Profile

The device shows the resulting setting in the management profile.

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

proxy1

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.

proxy2

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.

regedit2

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&#8220;. 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.

regedit1

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

setproxy

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.

Intune-Device-Rename-1

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.

Intune-Device-Rename-2

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.

 

Intune-Device-Rename-3

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.

Intune-Device-Rename-5

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

Intune-Device-Rename-4

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.

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