Deploying InTune through SCCM Task Sequence

We’ve been consolidating systems at work and were faced with scrapping our asset management system in favour of our new case management system, Cherwell. Previously we used Alloy for inventory, and Alloy had no problem reporting hardware data during task sequence, even for machines that aren’t going to be connected to our network. We’ve got a few so-called “Open-PC’s” that won’t be on our network, aren’t connected to the domain and thusly won’t be reporting any hardware inventory to SCCM. I spent a long time trying to force a hardware inventory within the task sequence, but it doesn’t seem to be possible. One method would be to create a script and a scheduled task to remove the machine from domain some time after image having been applied, but this would just be annoying on a day-to-day basis. And it wouldn’t be reliable.

Thus my eyes fell to InTune, which doesn’t require a domain connection and will deliver inventory details, which we can pull to our case system. (For insurance reasons.) I tried many different methods of accomplishing this, and kept getting stuck because InTune and SCCM client inherently are incompatible with one another. InTune will simply refuse to be installed where the SCCM already exists.

I ended up creating a task sequence structure that accomplished what was required through scripts and SCCM PostAction.

  • Pre-requisites:
  • Create a package pointing to a directory where you’ll keep your source files. We’ll use this later. Throw your Intune .msi and certificate in this directory.
  • Create Install-IntuneClient.ps1 file containing the following(Thanks to Peter for most of the powershell script.):

    #Define variables
    $NewPath = “C:\Temp”
    $CertificateName = “MicrosoftIntune.accountcert”
    $UninstallPath = “C:\Windows\ccmsetup”
    $UninstallerName = “ccmsetup.exe”
    $UninstallerArguments = “/Uninstall”
    $InstallerName = “Microsoft_Intune_X64.msi”
    $InstallerArguments = “/qb!”
    #SCCM Uninstall
    Start-Process -FilePath “$UninstallPath\$UninstallerName” -ArgumentList $UninstallerArguments -Wait -PassThru
    #Waiting time introduced to ensure that msiexec is ready.
    Start-Sleep -s 160
    #Uninstall of MS Policy Platform, since InTune will think this version will work, but it won’t. You will get the client but it’ll get policy errors if you don’t do this step.
    Start-Process -FilePath “C:\Windows\System32\msiexec.exe” -ArgumentList “/X{6549B04F-E826-4E0A-8C3F-388540F08541} /qn”
    Start-Sleep -s 160
    #Intune Install
    Start-Process -FilePath “$NewPath\$InstallerName” -ArgumentList $InstallerArguments -Wait -PassThru
    #Folder Cleanup.
    Remove-Item $NewPath -Force -Recurse
    #Giving InTune a few minutes to talk to the server.
    Start-Sleep -s 160
    #Optional step – shuts down computer after finishing. Uncomment if you want it.
    #Stop-Computer

  • Create .cmd file containing the following:

    @echo off

    md c:\Temp
    copy /Y “%~dp0Microsoft_Intune_X64.msi” c:\Temp
    copy /Y “%~dp0MicrosoftIntune.accountcert” c:\Temp
    copy /Y “%~dp0Install-IntuneClient.ps1” c:\Temp

  • Task Sequence Steps:
  • Run Command Line containing: cmd /c “yourfilenamehere.cmd”
    I chose to point this at the package to pull the file from the server. You can of course do this in other ways, but this is my personal preference.
  • Set Task Sequence Variable: SMSTSPostAction
    Value:

    PowerShell.exe -ExecutionPolicy ByPass -File “C:\Temp\Install-IntuneClient.ps1”

And you’re done.

Deploying hotfixes during SCCM Task Sequence

It’s been a while since we built our initial Windows 10 image, and it’s fallen quite a bit behind the times. We didn’t want to spend time updating the image until we were ready to go in to production, and WSUS seemed to have issues installing some of the updates, resulting in systems that wouldn’t update properly unless manual update packages were installed.

To fix this I deployed a package to the task sequence containing this script:

$scriptPath = split-path -parent $MyInvocation.MyCommand.Definition
$folder = $scriptPath
$total = gci $folder *.msu | measure | Select-Object -expand Count
$i = 0
gci $folder *.msu | foreach {
$i++
WUSA ""$_.FullName /quiet /norestart""
Write-Progress -activity "Installerer hotfixes" -status "Installerer $_ .. $i af $total" -percentComplete (($i / $total) * 100)
Wait-Process -name wusa
}

Credit to this fella for the source: http://www.applepie.se/apply-hotfixes-during-task-sequence

Essentially this will run within the package directory, installing all .msu’s found within. Currently it’s just throwing on kb3213522 – which enables WSUS to take over from there, but it could potentially save people who don’t have WSUS some serious hassle.

Add the package to task sequence and point it at the powershell script and you’re golden. Modify the text displayed within ” ” to your liking.

Deploying Adobe Reader DC via SCCM

I recently had to update our corporate Adobe Reader installation, as it was getting old and throwing off errors.

This proved to be somewhat more complex than initially anticipated, due to how Adobe has decided to handle it’s versioning process. Essentially they have released one master version to which they release update packs. During my research I saw a thousand different ways people had chosen to go about it, but I think this method is the simplest by far – and it doesn’t require any scripts at all. First of all you need to sign up for an Adobe distribution agreement: https://distribute.adobe.com/mmform/index.cfm?name=distribution_form&pv=rdr

Once this is done you will be supplied with links to all the pertinent software. I can’t share these publicly accessible links, as that violates their terms of use, brilliant as that is. So sign up, get approved and come back.

  • Grab Adobe Customization Wizard and install it http://supportdownloads.adobe.com/detail.jsp?ftpID=6104
  • Get your source .msi package from Adobe. This will be the earliest version number you can find in continuous track.
  • Customize it with Customization Wizard to automate the setup steps and generate an MST File.
  • Create an application in SCCM which points to the .msi file for uninstall information. I refer to this as the “base” install. Set it up with the following for installation program:
    msiexec.exe /i AcroRead.msi /quiet /norestart TRANSFORMS=AcroRead.mst
    Uninstall is left at default.
    Detection method I set to .msi product code. Detection methods are key in this deployment.
  • Distribute this application to your distribution points and test that it works in a small deployment. Make sure it’s set to uninstall and supercede any prior versions of Reader, as they seem to keep the same GUID.
  • Create a new application and point it at the latest .msp update file available from Adobe. Don’t use an incremental though.
  • Make sure you target the uninstall for the “base” MSI file, not the .msp file or anything else. This will make sure you get the correct uninstall codes in to SCCM, should you need them later.
  • Set detection method for the update for the version number of the .exe file once the update has been applied. So install the update manually, check the version number of the exe and use that for detection.
  • Installation method is simply msiexec so no worries there.’
    msiexec.exe /Update AcroRdrDCUpd1502320056_MUI.msp /quiet /norestart
  • Make sure that the update is set up with a dependency on the Reader Base installation.
  • Deploy the update to a test group to verify proper handling.

Short and sweet.

With this method, I can supersede older versions of Reader with a new .msp file, keeping the base installation as is. As the .msp updates can be applied on top of each other, there are no concerns at all maintaining the reader application using this method. When an update is released, repeat the update steps and supersede the old application and you’re done. Could not be simpler.

If anyone’s found a simpler way of making all this work, I’d love to hear it. But every single option I have found, heard of or seen has been much more complex. Some requiring .ini file hacks, some requiring powershell scripts, vbscripts etc.

This works within the method Adobe has decided to go with, and it takes minutes to deploy the updated application.

Feel free to share your thoughts.