CCMEXEC.COM – System Center blog

CCMEXEC.COM – by Jörgen Nilsson

Browsing Posts in System Center Configuration Manager

I am writing this post as I had two customers that wanted to use alternate Login ID in Azure AD together with Intune and SCCM 2012 in a Hybrid deployment using SCCM as the MDM Authority. I found several blogs and a Wiki that described that this wasn’t supported and that unsupported scripting directly to the database in SCCM 2012.

The background to this is that when using SCCM in a Hybrid deployment as the MDM authority you must use a collection in SCCM containing the users that are allowed to enroll their devices. If you are using different UPN in your On-premise AD and Azure AD SCCM would not be able to match the user in Azure AD and therefor you could not enroll any devices.

One workaround was changing the UPN directly in the SCCM database so it matched the UPN used in Azure AD, for example e-mail address if that was used as UPN in Azure AD.

After some investigation those issues are now resolved by Microsoft and there is no changes required on the SCCM side as Intune tries to match the user using UPN and if that doesn’t work it tries the e-mail address and then it is solved basically.

I have successfully delivered two proof-of-concepts where e-mail address was used as UPN in Azure AD instead of the UPN in the On-premise AD and it has worked just great!

Thanks to Kerim and Saud at Microsoft for verifying and support! :D

One of the Wiki’s that mentioned this: is updated by Saud as well so that the information that there are issues with SCCM+Intune in hybrid using alternate Login IDs is removed as well.


  • There are still some limitations with Office 365 and alternative login ID
  • When using ADFS together with Alternate Login ID in Azure you need to configure ADFS to allow login using e-mail address as well as described here: (it will be updated as well to remove the information that Intune and SCCM has issues

One very appreciated feature in Configuration Manager 2012 when you integrate it with MDT is the background pictures showing OS deployment step, IP Address, MAC Address and so on to the end user och technician deploying the computer.

The first two steps are shown in WinPE only and under Computer Name in the background the generated Minint-3242 is displayed as computer name. I wrote a little powershell script which will simply write the OSDComputername variable to the registry in WinPE so we can read it from there with BGinfo and show both the WinPE name and the OSDComputername. It will look something like this:


I like the flexibility of running the scripts in the Task Sequence instead of modifying the Boot image so I run the script as a Run Powershell Script step in the Task Sequence. Start by doing the following:

  1. Make sure you have the Powershell component included in the Boot Image for the script to be able to run.
  2. Save a Powershell script with the following content.
    New-Item -Path HKLM:\Software -Name OSD –Force
    New-ItemProperty -Path HKLM:\SOFTWARE\OSD -Name OSDComputername -PropertyType String -Value $OSDcomputerName
  3. Save this script in a folder and create a package in SCCM with the folder as source path so we can use it later in the Task Sequence.
  4. In the Task Sequence before the step you are displaying in WinPe add the following step, select the package to run the script from and enter the %OSDComputername% in the Parameters to pass the OSDComputername variable to the script.
  5. After that edit the STEP_02.BGI file by launching your MDT 2013 Toolkit package under \Tools\x86 in your package source directory  by launching Bginfo.exe from that directory.
  6. In BGinfo select File, Open the STEP_02.BGI file, then you will see the information displayed in the background.
  7. Select Custom and add the following value, the path should be HKEY_LOCAL_MACHINE\SOFTWARE\OSD\OSDComputerName
  8. You will see a warning that the registry value doesn’t exist accept that and then we go on and edit the information displayed.
  9. Edit the background to look something like this.
  10. Then save the STEP_02.BGI file. If you are using the State Capture Step do the same with that step or save this one with the STEP_01.BGI filename instead.
  11. Update the MDT 2013 Toolkit package so that the new .BGI files are updated on the DP’s and then you are good to go!

I haven’t tested it with MDT 2012 but I cannot see why it shouldn’t work.

When testing the latest Build of Windows 10 I got an error installing the Configuration Manager 2012 R2 client, it fails installing the Windows Update agent with the following error in the CCMSetup.log file.

“File ‘C:\WINDOWS\ccmsetup\WindowsUpdateAgent30-x64.exe’ returned failure exit code 775. Fail the installation.”

I assume a solution to this error will presented soon, but I cannot wait to get started with my testing of 10049 so installing the SCCM Client with the following command line solves at least the installation error of the Configuration Manager client.

“ccmsetup.exe  /skipprereq:windowsupdateagent30-x64.exe”

Then ccmsetup.exe will skip the installation of the Windows Update Agent and continue the installation anyway. Normally I use the /Skipprereq: command to skip the installation of Silverlight on servers as I don’t want Silverlight installed on my servers. But the command line works great in this case as well.

You will then see this in the ccmsetup.log file on the client which shows that the installation of the Windows Update agent was skipped and that the installation continues.

“Item ‘x64/WindowsUpdateAgent30-x64.exe’ is excluded by the ‘/skipprereq:’ switch. Ignore it.”

God Luck with the testing of Windows 1o!

Update: SCCM 2012 SP2 and SCCM 2012 R2 Sp1 solves the problem so to solve the issue and get OSD working an upgrade is needed. If you just want the client to work and cannot upgrade now, the workaround is valid for newer releases of Windows 10 as well.

One thing that many of my customers both Servicedesk staff, Support staff and administrators complain about with Configuration Manager 2012 Remote Tools is that the client service is set to Automatic (Delayed Start) when installed per default.

When remote controlling a user’s machine and a reboot is necessary, the service doesn’t start immediately and it feels like it takes forever for them to able to remote control the computer again.

Changing the startup to Automatic instead of Automatic (Delayed Start) can be done using a Group Policy and a Group Policy Preference setting. Under Services add the SCCM Remote Control Service and change the startup to “Automatic”



When the Group policy preference is applied, the service startup is changed. Have run it as Automatic for more than a year now, works great.


Next question would be:
“Doesn’t the sccm client remediation task that runs on the clients change it back to “Automatic (Delayed Start)?”
No it doesn’t, actually it will however change it back to “Automatic” if you set it to “Automatic” before setting it to “Disabled” and then run the CCMEval task, so it will work just fine.

Next Question: “Is it supported?”
I guess that could be debated ;-)

I had a scenario at a customer where I needed to set and iOS device in Kiosk Mode with the only allowed app, the Safari browser. Currently in Microsoft Intune Standalone when you select Kiosk Mode you have to select either a Managed App or a Store App when you select the Kiosk Mode option.

Let’s start with the background. To be able to set an iOS device in Kiosk Mode you need to configure it to “supervised mode” which have to be done with the Apple Configurator on an computer running OS X. When the device is in supervised mode enroll it in Intune as you normally would with any device, then we can configure Kiosk mode using Intune.

Create an iOS Configuration Policy with the following settings.

1. Create a new “iOS Configuration Policy”

2.  Enable the “Select a managed app that will be allowed to run when the device is in Kiosk mode:” if you browse you have to select either an application in the App Store or a managed app that you have deployed (.ipa). Instead of browsing simply type “”, then Safari is the app that will be allowed to run in Kiosk mode and no one else. You can also turn off/control if you want to allow screen rotation and so on in the options below.
iOS_Safari13. Save the policy and deploy it to a group, in my scenario a group called “kiosk”



4. As soon as the policy is applied Safari will be launched on the iPad and you cannot close it or do anything else than browse the web using Safari.

If you want it out of Kiosk mode you can do any of these things:

  • Choose to Retire it using the Intune console, it will be removed from Intune if you choose this option.
  • Delete the deployment of the policy that has set it in Kiosk mode
  • Delete it from the group where the policy is applied.

I have a new favorite feature in standalone Intune, custom iOS Policy. This lets you basically deploy a XML file with the supported configuration information you want to set on an iOS device even if it isn’t available in the Intune console, like deploying a Wi-Fi network with WPA2 and a Password.

The easiest way to create a profile file is to use the Apple Configurator, it is only available for OSX so you need a machine running OS X. Notepad can of course also be used ;-) Apple Configurator is available in the App store on OS X. In this example I will create a custom policy using Apple Configurator which configures a Wi-Fi WPA2 SSID with a password and then deploy it using Intune.

  1. Launch Apple Configurator and create a new policy.Apple_conf1
  2. Give the policy a Name and enter your Organization name.Apple_conf2
  3. Select Wi-Fi and click configure.Apple_conf3
  4. Enter the information about the Wi-Fi network, here you can select WPA2 Personal and supply the password which isn’t possible in Microsoft Intune for now at least. Then select Save Apple_conf4
  5. When the policy is created, select it and select Export Profile.Apple_conf5
  6. Save it somewhere where you can access it later and upload it to Intune, I save it to my Onedrive.Apple_conf6

The XML file will get an extensions of .Mobileconfig and it looks like this:

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "">

<plist version="1.0">
















<string>Configures Wi-Fi settings</string>

































More information about valid syntax and settings can be found here:

To deploy the newly created custom iOS policy file do the following:

  1. Login to the Intune console at using a supported browser and platform = Windows Client.
  2. Under Policy and Configuration Policy, select AddPolicy1
  3. Select Create and Deploy a Custom Policy and Create Policy.Policy2
  4. Enter a Name, Name displayed to the user and import the wifi4.mobileconfig file created before. Then select Save Policy.Policy3
  5. A dialog appears that asks you if you want to deploy the policy.Policy4
  6. We then select a group to deploy the policy to, in my case TechX demoPolicy5
  7. On the iOS device, in my case an IPad Mini I can now see that the policy is applied under the Management Profile (yes it is in Swedish)Profile1

The Custom iOS policy is a really powerful tool, wish for it to be available in Hybrid scenarios as well!

As I wrote here before there were some issues with the update of the System Center Endpoint protection client that caused all downloads in Internet Explorer, Firefox, Chrome and so on was blocked with a message that they contained a virus.

A new updated version is now released, where this issue is fixed. It is available through Windows Update and WSUS. The KB that describes the revised System Center Endpoint Protection Client can be found here:


A couple of weeks ago TechX Azure 2015 Sweden took place in Stockholm. I had the great honor to present on how to manage Android and iOS devices using Microsoft Intune. The recording is now available here (in Swedish):…

As Enterprise Mobility Suite is a really hot topic right now here are two great sessions on Azure RMS and Azure AD Premium as well also in Swedish.

Happy EMS weekend!