Roberts Blog

The House of ConfigMgr and Intune on Endpoint Management Way

Tag: Autopilot

Delivering CMTrace using Intune during AutoPilot

In this post I’m going to go through the steps needed get the CMTrace tool onto a system during an AutoPilot build, purely so we can pour over logs without the hassle of manually bringing the tool onto the system, or copying the logs onto a remote system with the tool available.

During a failed AutoPilot build, reading the IME (Intune Management Extension) log is a bit of an “art” in of itself, but viewing that log in Notepad is no fun at all; And mapping a network drive so as to copy CMTrace locally is a chore that doesn’t bear repeating often. It’s best if the tool is delivered during AutoPilot.

Whatever we do we’re going to need to lean on Intune’s Win32 app delivery support (not the Line-of-business App which requires an MSI), which affords us the ability to package up multiple files and folders then invoke something in there. In our case the executable for CMTrace and a PowerShell script.

To begin we need to download that IntuneWinAppUtil tool and point it at the folder containing the files, upload the resulting INTUNEWIN file to Intune and deploy that as required to the AutoPilot devices.

There’s two notable ways to go at delivering CMTrace with Intune, firstly just package up the CMTrace executable without a script present and let Intune run a PowerShell command to copy the executable to a destination folder, or package up the executable along with a PowerShell script which does the copying.

You can include a script if for example you wish to do more than just copy the executable to a destination folder, such as associating CMTrace as the handler for the LOG and _LO extensions as EM MVP Jörgen Nilsson does in this excellent post. Or you could put most of it on a single command, but it is worth noting that there is a character limit in Intune for command lines so don’t make them too long.

The two approaches allow for different scenarios during AutoPilot, light and easy with the admin finding the tool and launching when needed, or with no need for an admin to launch the tool before opening a LOG file (file associations set).

In this post I’m going to use the scripted route to only copy the executable to the C:\Windows directory, and leave you to wander over to Jörgen Nilsson’s post if you want to add the file handler associations stuff (just paste his script content into the script created here).

I have a folder structure to build out Intune Win32 applications while using the IntuneWinAppUtil utility. I keep this separate from my ConfigMgr source folder. It has both a folder for the source files and a folder to accommodate the resulting INTUNWIN files that are spewed out by the IntuneWinAppUtil tooling:

  • Source\Intune\<Application Folders>
  • Source\Intune\INTUNEWIN\<Application Folders>

Here goes.

  • Create a build folder for CMTrace in your Intune application source folder, call it CMTrace
  • Copy CMTrace.exe to the build folder
  • Create a new PS1 file in the build folder and call it cmtrace.ps1
  • Open the PS1, pour in the contents below, as usual check that the quotation marks are correct, save the file. Worth running the script in-place to make sure it works before proceeding.

Here’s a basic script to work from:

Copy-Item “$($PSScriptRoot)\CMTrace.exe” -Destination C:\Windows\CMTrace.exe -Force

We now have CMTrace.exe and cmtrace.ps1 in the new build folder.

You can modify this script up with as many modifications as you want, I doubt there would be many for CMTrace, but for other deployments scripting opens a door that allows us to customise delivery as we need.

The IntuneWinAppUtil packaging tool is pretty easy to use, requires three inputs to run for most scenarios of source folder, source file (the exe or the ps1) and the output folder:

IntuneWinAppUtil.exe –c <SOURCE PATH> –s <FILE REFERENCE> –o <DESTINATION PATH>

Here’s the command line to package CMTrace:

IntuneWinAppUtil.exe –C “D:\Source\Intune\CMTrace” –s “D:\Source\Intune\CMTrace\cmtrace.ps1” –o “D:\Source\Intune\INTUNEWIN\CMTrace”

We’re about to run the packaging tool:

Here’s the IntuneWinAppUtil tool after packaging the source folder:

Out pops the INTUNEWIN file:

Now we need to upload this to Intune:

From the Azure Portal or DeviceManagement portal add a new App:

Select the Windows app (win32) option and then click Select

Click on Select app package file, navigate to the INTUNWIN file and select it.

Give it a friendly name and description, I use CMTrace for both. And enter Microsoft as the Publisher:

Now comes the command lines, it is highly unlikely that we’re ever going to uninstall CMTrace, and if we wanted too we just need to issue a Remove-Item command line to do so, or create another PS1 script, instead, I just used the PS1 and ignore uninstall, set Device restart behavior to No specific action:

For uninstall we could do this: PowerShell.exe –executionpolicy bypass –command Remove-Item C:\Windows\CMTrace.exe

  • Install command

powershell.exe -executionpolicy bypass -file cmtrace.ps1

  • Uninstall command

powershell.exe -executionpolicy bypass -file cmtrace.ps1

or

PowerShell.exe –executionpolicy bypass –command Remove-Item C:\Windows\CMTrace.exe

Choose the architecture for your device estate, most are pure 64-bit but if you have a mix select both, then the minimum Windows 10 OS which in my case is Windows 10 1607 so as not to exclude any build versions that show up:

The detection rule is file based, and just looks for C:\Windows\CMTrace.exe.

Choose to manually configure detection rules and select Add:

Choose a rule type of File, then for the path punch in C:\Windows, for File or folder enter CMTrace.exe: and choose No for Associated with a 32-bit app on 64-bit clients:

As you can see below, the detection rule is ready:

Go through the rest of the wizard and assign as required to your AutoPilot AAD group and you are done here.

Now, the CMTrace tool will show up on your AutoPilot builds on a well-known path (C:\Windows), and can be invoked from a command line during parts of the AutoPilot build (Shift F10) just by typing in CMTrace.

Intune–Autopilot–Quick and Easy walkthrough–Part 1

If you’re starting out from scratch with Intune’s Autopilot, this run through should help get the key elements established so that you get a build result to look over, and a platform rigged for further exploration.

Some things needed:

  • Azure Premium
  • Windows automatic enrolment

Go get an EMS E5 evaluation\trial, and get your tenant up and running, handle the DNS (CName), and if you want, use AD Connect to join it to an existing lab-based on-premise AD.

Let’s get going.

Retrieve the VM for AutoPilot information

I chose Windows 10 Build 1809 used for this run through.

Build yourself a VM with enough CPU cores assigned, and 2GB of memory as a minimum.

Let it boot off your Windows 10 ISO and push through setup.

You have to choose to domain join, then let it go through the setup of a local administrator account.

Once you’re at the desktop you can run the Get-AutoPilotInformation PowerShell script authored by Michal Niehaus. The script captures the Device Serial Number and Hardware Hash needed by Intune to identify the VM (device) when it calls in, more properties can be supplied such as Order ID and Purchase Order ID, but these two are all we need for testing with our own VM’s (Product ID is obsolete as noted by Michael in the comments on the scripts download page).

To ease the pain when introducing new Windows 10 VM’s to AutoPilot, I jotted down the steps I need to go through to run the script, so that I can copy\paste them into the VM when needed.

I paste this little lot into a bat file and run it in an administratively elevated command prompt:

Powershell.exe

Set-ExecutionPolicy Bypass

Net use Z: \\<IP of device where script resides>\<drive letter where script resides>$
/user:<IP>\administrator <Password>

MkDir C:\Temp

Copy Z:\*.ps1
C:\Ttemp

CD C:\Temp

.\Get-WindowsAutoPilotInfo.ps1
-OutputFile ($(Get-WmiObject Win32_Computersystem).name + “.csv”)

Copy
($(Get-WmiObject Win32_Computersystem).name + “.csv”) Z:\

Net use Z: /D

The steps are to map a network drive, and then copy and execute locally the information gathering script from Michael Niehaus which can be found here.

When run on a VM we get the CSV needed for import into Intune’s AutoPilot:

That CSV file needs to be available for a browser file dialog to select, so make sure you copy it to wherever that is.

Import the device information into Intune AutoPilot

To link the device to the service, we need to import that CSV containing the Device Serial Number and the Hardware Hash.

When OOBE runs on a device and you’ve chose the region and keyboard, it will call back to the Intune service. All Windows 10 devices performing a build will try to talk to Microsoft, this is so that they can verify if they are registered with Autopilot and initiate the work-flow if needed. If a user is assigned to the device, they will be welcomed and prompted for their password, otherwise a prompt for their username will show.

To import this device, visit the Azure portal and navigate your way to Intune.

Once there, navigate into Device Enrollment, Windows Enrollment, then click on Devices:

The ribbon should show the Import option, select it:

Choose the CSV obtained from the VM.

If it passes the verification check you’ll get a green tick, click Import:

Onboarding devices into Intune splits between setting up for new devices and setting up for existing devices.

For existing devices, you can as just one option hybrid join them to Azure AD, which automatically enrols them into Intune, and then put those devices into an Intune security group, so that Intune automatically converts them to AutoPilot enabled devices.

If you don’t want to enrol the devices into Azure AD first, and instead want to reset them so that their workflow ends up joining them to AAD and enrolling into Intune, then you’re going to need to retrieve identity information from all those existing devices, and perform the import of that meta into Intune manually.

For new devices you can hand crank the import process yourself if you have devices shipped to the local talent before delivery to users, or, you can get your box shifter to crank the handle for you.

Note the 175 device limit for CSV import. You’ll have to batch things when onboarding new devices into the production environment.

So, new devices coming in will need to have their identity extracted by the onsite talent, or if you have a box shifter providing you with equipment they can hand over this CSV whenever kit is allocated to you, and the local talent imports into Intune, or whoever sells you the devices can import the CSV directly into your tenant if you have that relationship setup with them.

If the local talent isn’t doing it, it all costs money, not much per device, and from what I hear most customers are happy adding the additional cost on for this service.

Quite a lot of small to medium sized businesses have already outsourced the maintenance\management and delivery of client devices to their users, from the big boys like HP, Dell, IBM and Microsoft (Surfaces) down to smaller resellers providing a managed service.

These resellers and OEM’s are pretty much prepared for Intune AutoPilot, if not then they are seriously lagging behind the wave of technological progress taking place right now.

Once you click Import it will notify you that the device is being imported:

Behind the scenes your Azure Tenant has a dedicated Hamster ready to begin processing any workloads assigned to the tenant, this is my one, its responsible for all the magic taking place for my configmgr2012.com tenant: