Roberts Blog

The House of ConfigMgr and Intune on Endpoint Management Way

Tag: Intune (Page 1 of 2)

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.

MEMCM Tenant Attach–Device Upload – TP 2002.2

The management planes merge even further with the announcement of the Tenant Attach feature for ConfigMgr, recently released as Preview in the ConfigMgr Technical Preview 2002.2 Build, which allows you to upload your ConfigMgr clients to Intune, and issues to them some initially very basic management capabilities from the MEMAC portal.

What this boils down to is initially in this early technical preview release bringing to bear basic management-capabilities of a ConfigMgr client, performed from Intune via the MEM Admin Center portal. Telling ConfigMgr to tell one of its clients to perform an activity, that’s some reach!

If you throw in the Client Management Gateway, we can communicate with ConfigMgr devices whether they are on or off the corporate network, as long as they are online we’ll be able to reach them from Intune.

And although the Device Upload feature sits inside the Co-management feature, we don’t have to enable Co-management for Device Upload to work. Enrollment to Intune for Co-managed devices can be disabled, and no work-loads need to be transferred.

There are some prerequisites, so make sure you have this lot ticked off:

The “Has been discovered with Azure Active Directory user discovery bit means that ConfigMgr has discovered the users from Azure AD, this requires Azure Services to be configured.

The “Has been discovered with Active Directory user discovery” bit means AD Connect has replicated the AD User to Azure AD. So you’re going to need AD Connect configured.

I whittled out a diagram shown below to visualise the requirement for Azure Active Directory User sync, used to sync Azure AD Users into ConfigMgr, and AD Connect to sync AD users to Azure AD. We’re not synchronising Azure AD Users into Active Directory quite yet, we just need Azure AD users to show up in ConfigMgr so as to be able to perform client actions:

My lab already has Azure Services configured to enable the Client Management Gateway but you don’t need one, head off and configure Azure Services to onboard your tenant if you haven’t already. Make sure AD Connect is correctly synchronising AD users to Azure AD, and make sure Azure Active Directory User Discovery is enabled and working on the ConfigMgr Site server:

Post-Azure Services onboarding:

Light up the Device Upload (Device Sync, Tenant Attach …) feature

Head on over to the ConfigMgr Console, navigate to Administration and expand the Updates and Servicing node, click on Features.

Find the Microsoft Endpoint Manager tenant attach: Device sync and device actions entry, turn it on:

At this point either restart the server or restart the SMS_EXECUTIVE service as pointed out in the documentation.

Roll on over to Administration, Cloud Services and Co-management, hit that Configure co-management button like a boss:

Give the Sign in button some loving:

Tap in credentials with enough privilege’s in Azure to do this job:

I’ve selected both options below, specifically the Upload to Microsoft Endpoint Manager admin center option is all that is needed to support the Device Upload feature:

Crack on and accept the prompt to register an application in the AAD tenant:

I’m not going to restrict the Device Upload feature in this lab, however as you can see we’re able to handle scoping to define a sub-set of the devices assigned to ConfigMgr by choosing a specific collection:

I’ll let ConfigMgr devices enrol into Intune, select None if you want to disable this feature, its not required for Device Upload to function:

I’ve kept the workloads as-is and not transferred any to Intune so as to light up the Co-management feature:

And I’ve left the workload collections unconfigured as a consequence:

The Summary page is always an exciting place full of trepidation especially on Technical Preview builds while working with preview features …

Looking good, Device Upload should be good to go: