Objective
The goal of this guide is to show how to deploy Cisco Secure Client (formerly AnyConnect) through Microsoft Intune by using the Microsoft Win32 Content Prep Tool to prepare the installer package.
When creating a Secure Client deployment for Windows in Cisco XDR Client Management or Secure Client Cloud Management, the package that gets generated comes out as a .exe file. That’s different from how it worked in the past — before cloud-based client management, customers would normally use the pre-deploy MSI packages to handle installations. Those MSI versions worked fine with tools like Intune or SCCM because they were already in a supported format.
Now, since Intune doesn’t support deploying raw .exe installers (it only supports MSI, MSIX, or Store apps), we have to first wrap the .exe into an .intunewin file. That’s why the Win32 Content Prep Tool is required. . It compresses the installer and supporting files, encrypts them, and generates a manifest file that Intune uses to understand how to install and manage the app.
In the next section, we walk through the process of taking the Cisco Secure Client .exe deployment package and preparing it for delivery through Intune so it can be deployed and updated like any other managed application.
Figure 1 CSC Deployment file downloaded
Microsoft Win32 Content Prep Tool
https://github.com/microsoft/Microsoft-Win32-Content-Prep-Tool
I’ve also downloaded the Microsoft Win32 Content Prep Tool from GitHub. This is Microsoft’s official utility used to convert installers into the .intunewin format required by Intune. The tool is quick to run and easy to follow — it simply prompts for the source installer path, the output location, and optional metadata.
Figure 2 Utility downloaded from Github
Once the inputs are provided, it packages and encrypts the installer, generating a .intunewin file that contains both the Cisco Secure Client EXE and the installation logic Intune needs to deploy and manage it.
The Microsoft Win32 Content Prep Tool (IntuneWinAppUtil.exe) requires three main inputs: a
- source folder,
- setup file
- output folder.
Figure 3 The Microsoft Win32 Content Prep Tool prompts for the source folder, setup file, and output directory before generating the .intunewin package.
After this step, the Secure Client deployment is now fully wrapped and ready for distribution through Microsoft Intune.
Figure 4 Tool completed
The wrapped installer is now in the destination folder and ready to be used by Intune
Figure 5 Wrapped installer now in place for use by Intune
Microsoft Intune Configuration
“Microsoft Intune and Configuration Manager (aka SMS/SCCM) are complementary management solutions. Configuration Manager continues to be supported for on-premises management, while Intune is Microsoft’s cloud-based solution for managing endpoints.”
— Microsoft Learn: Compare Intune and Configuration Manager
This section covers how a Win32 app is deployed through Microsoft Intune. The process starts by selecting Windows app (Win32) as the application type, then uploading the packaged .intunewin installer that was built with the Microsoft Win32 Content Prep Tool. The install behavior is defined using the required install command and, if needed, an uninstall command. Detection rules are added to verify that the installation completed successfully, and requirements such as a minimum OS version can be configured as part of the setup. Once everything is in place, the app can be assigned to the intended devices or user groups for deployment.
In the accompanying video, you’ll see that my first attempt used a registry-based detection rule, and it didn’t validate correctly. That caused Intune to report a failure even though the install actually completed successfully. I switched the detection method to a file-based check and that resolved the issue — Intune was then able to recognize the installation properly. File-based detection tends to be more reliable for Cisco Secure Client because the installer always drops consistent executable and module files, while registry entries can vary depending on which modules or profiles are included in the deployment. |
Begin in the Microsoft Intune admin center and navigate to Home > Apps > Windows.
If applications have been deployed previously, they’ll appear in the list view shown here.
Click Create to start adding a new Win32 app.
Figure 6 Windows Apps
After clicking on Create you will need to select an app type and from the pulldown select Windows App (Win32)
Win32 apps are deployed using the Microsoft Intune management extension (IME) … Support for 32-bit Windows, 64-bit Windows, and ARM64 operating system architecture.” Microsoft Learn
URL: https://learn.microsoft.com/en-us/intune/intune-service/apps/apps-win32-app-management
Figure 7 Select App type - Windows app (Win32)
After selecting the App type, the next step is to select the app package file.
In this step, you’ll browse for and upload the wrapped IntuneWin package that contains your application installer and associated metadata. This file was created earlier using the Microsoft Win32 Content Prep Tool.
Once you click Select app package file, the right-hand panel opens (as shown below), allowing you to navigate to your .intunewin file and upload it to Intune.
Figure 8 Select the App package to upload
At this point, choose one of your deployments that has been packaged using the Win32 Content Prep Tool.
The file type should now appear as an “.intunewin” file — this indicates it’s properly wrapped and ready for upload to Microsoft Intune.
From the file browser window, navigate to the location where your wrapped deployment was saved, select the desired. intunewin package, and click Open to begin the upload process.
Figure 9 Select the wrapped IntuneWin package to upload
Now that the app has been selected and just simply click Ok to continue
When you add a Windows app (Win32) in Intune, you’ll go through a few key setup tabs. The App information tab is where you fill in the basics — name, description, publisher, and so on — so it shows up properly in the Company Portal. The Program tab tells Intune how to install and uninstall the app, including the exact commands and whether it runs as the user or system. The Requirements tab defines which devices are eligible, like picking the right OS version and architecture. And finally, the Detection rules tab tells Intune how to check if the app’s already installed or if the install finished successfully.
In my test for the most part I only entered the required information and none of the optional.
Figure 10 App information
You’ll notice in the next screenshot that the install command simply uses the installer name followed by the -q flag for a quiet, unattended installation.
Because there isn’t a supported command-line uninstall option for Cisco Secure Client, I’ve used a placeholder (fictitious) uninstall command to satisfy Intune’s required field. This command doesn’t perform any actual action—it’s included only so the Intune app configuration can be saved and validated.
The following flags are available for use with both the Network Installer and the Full Installer:
usage: installer.exe [OPTIONS]
OPTIONS:
* -c, --cleanup : Remove the temp directory after install (default is to remove on success and leave on failure)
* -la : List install actions to be run
* -ls : List files in deployment
* -lsjson : List files in deployment (JSON output)
* -q, --quiet : Run the installation silently
Figure 11 Specify the required install command
On the Requirements tab, the only field I needed to specify for this test case was the minimum operating system version. I chose not to restrict the architecture setting, allowing the client to install on any platform.
In hindsight, this wasn’t ideal. If the deployment package were built for AMD64 and pushed to an ARM-based system, the installation would fail. A better approach would be to define architecture-specific requirements and upload separate wrapped installers — one for AMD64 and one for ARM64 — so that each device type receives the appropriate package.
Figure 12 Specifying minimum OS requirements in Intune and reviewing architecture options for deployment targeting.
In Microsoft Intune, when you add a Windows app (Win32), the Detection Rules section is what tells Intune how to figure out if the app is already installed on a device. Basically, it’s how Intune decides whether the install was successful, if it should try again, or if it can skip the install altogether. Without proper detection rules, Intune has no way of knowing what’s actually on the machine — so they’re pretty important.
Figure 13 App Detection Rules (Required)
I did not configure anything in the Dependencies or Supersedence sections. According to Microsoft documentation and the Intune online help (including Ignite resources), these features work as follows:
Supersedence allows you to update or replace an existing Win32 app with a newer version or a different app. It’s used when managing version upgrades or transitions between related applications.
Dependencies define apps that must be installed before the current one. You can choose to have Intune automatically install the required (child) apps before the main (parent) app, or only proceed if those dependencies are already detected. Intune supports up to 100 dependency apps per parent app.
I did not define a scope tag for this application.
Scope tags are primarily used for role-based access control (RBAC) within Microsoft Intune and Entra ID, rather than for actual app deployment. They determine which administrators can see and manage a given app, not which devices receive it.
Because this deployment is managed under a single administrative role, no custom scope tags were required. For more information, see Microsoft Learn: Use role-based access control (RBAC) and scope tags for distributed IT.
Figure 14 I am not defining a scope tag for this app and it seems that scope tags are more important to RBAC in Azure that they are for the actual deployment of the App
App Assignments
The final step in creating a Win32 app deployment is configuring Assignments, which determine who or what devices receive the app. In Intune, apps can be assigned to users or devices, depending on your deployment needs.
In this example, I assigned the app to a user-based group, so any enrolled Windows device owned by a member of that group will automatically receive the installation. Alternatively, selecting “Add all devices” targets every Intune-enrolled device in the tenant, regardless of who signs in — a true device-based assignment.
You’ll notice that Intune allows assignments under Required, Available for enrolled devices, and Uninstall:
- Required forces the app to install automatically.
- Available makes the app visible in the Company Portal for user-initiated installation.
- Uninstall removes the app from targeted devices.
In the screenshots that follow, you can see both Required and Available assignments configured for test groups. Even though some groups appear in both sections (and even as excluded), Intune prioritizes Required assignments — meaning those devices still receive the app.
Figure 15 Assignment configuration in Microsoft Intune showing the Required, Available, and Uninstall sections used to control how the app is delivered to users or devices.
Figure 16 Group selection dialog in Intune where user or device groups can be added to the Required or Available assignments for targeted app deployment.
Here’s a quick summary of the app configuration. You’ll notice that the Assignments section is a key part of this setup. My approach was to assign the app by group, and you may see that both the Required and Available sections include groups with the same name. Microsoft doesn’t actually use group names for targeting — each group is identified by a unique Object ID in Entra ID. In this lab environment, we happen to have duplicate group names, which can make the view appear confusing.
Also, as mentioned earlier, note that in the Available section those same groups appear under Excluded, which might suggest the app wouldn’t install. However, because they’re also listed under Required, Intune prioritizes the required assignment. In short: Required always wins — even if the same group appears as Available or Excluded elsewhere.
Figure 17 App Assignment
To close the loop on the confusing duplicate group names versus unique Object IDs — here I’m in the Entra Admin Center (formerly Azure AD), where all users and groups are defined. As shown, there are no guardrails preventing reuse of a group name. What truly matters is the Object ID, which uniquely identifies each group within Intune and Entra ID, even if the display names are identical.
Figure 18 Entra Groups – Object id’s redacted.
This concludes the Intune configuration portion of the guide.
What to expect on the endpoints
This section outlines what to verify after deployment through Intune. It explains how to confirm that the application installed successfully, where to locate relevant logs on the endpoint, and how to validate activity in XDR Client Management to ensure that Cisco Secure Client is functioning as expected.
On the target Windows 10 system (Desktop1), the Microsoft Company Portal app was installed and used to initiate the Intune enrollment process prior to deployment.
The Microsoft Company Portal is the end-user app that connects a device to an organization through Microsoft Intune. It provides a secure way for users to access company apps, email, Wi-Fi, and other resources while ensuring their device meets compliance and security policies.
When a user signs in to the Company Portal, the device is registered with Microsoft Entra ID (formerly Azure AD) and then enrolled into Intune. This step is critical — it’s what allows Intune to recognize the device, associate it with the user, and begin applying policies, compliance checks, and app deployments.
Once enrolled, users can open the Company Portal at any time to:
- Install available corporate apps
- View their device’s compliance status
- Access company resources configured by IT
Source: Microsoft Learn — Company Portal overview
Figure 19 Company Portal showing Desktop1 successfully enrolled — the device is registered with Intune and meets compliance requirements.
While monitoring the deployment in the Intune Admin Center, I observed the new Windows endpoint enter an Install Pending state shortly after registration. This confirmed that the device and user successfully met the defined requirements, and Intune had queued the app for installation as expected.
Figure 20 Device install status showing Desktop1 in an install pending state — indicating the device met all requirements and the app deployment was successfully triggered.
After switching back to the Windows desktop, the installation took a bit of time to start. To verify progress, I opened Task Manager to monitor activity. The Company Portal process was running as expected, but I was mainly watching for the Cisco Secure Client installer to appear and begin installing the bundled modules — AnyConnect VPN, Secure Endpoint, Umbrella, and Cloud NVM.
Figure 21Task Manager to monitor activity
Figure 22 Installation begins with AnyConnect as expected.
Figure 23 Additional modules begin installation
Intune logs on endpoint
The primary log used to verify Win32 app installations is IntuneManagementExtension.log, located at: C:\ProgramData\Microsoft\IntuneManagementExtension\Logs
Although verbose, this log provides definitive confirmation that Intune has attempted to install an app. Note that app names do not appear here — instead, Intune references each deployment by its App ID (GUID). To confirm an installation, locate the App ID in the Intune portal URL and search for that GUID within the log.
Figure 24 Intune log location
You can find the app id for the file looking at the URL as shown.
Figure 25 Reference the App ID.
You can locate the App ID by examining the URL of the app in the Intune portal as shown above.
If you find a matching entry in the log that references the same .intunewin package and App ID, that confirms Intune has queued and executed the deployment.
For example, the GUID
400e5ba7-c39a-465b-b749-ea61af99b5ff
appears both in the portal URL and within the IntuneManagementExtension.log, confirming that Intune successfully queued the “csc-deploy-full-BostonOffice.exe” package for installation.
This concludes the how to guide
References
https://docs.xdr.security.cisco.com/Content/Client-Management/deployment-management.htm
https://github.com/microsoft/Microsoft-Win32-Content-Prep-Tool
https://learn.microsoft.com/en-us/intune/intune-service/apps/apps-win32-app-management
Video version: https://app.screencast.com/uCDIFbzTIaCFB
