Cisco Webex App Deployment Using SCCM (ConfigMgr): MSI Installation, Detection and Updates

Some links on this page are affiliate links: if you buy through them we may earn a commission, at no extra cost to you.

The most reliable way to deploy Cisco Webex App with SCCM—now called Microsoft Configuration Manager (ConfigMgr)—is to create a ConfigMgr Application using Cisco’s tested Windows MSI. For most 64-bit Windows computers, choose the non-localized Webex App-only MSI, install it silently per machine with ALLUSERS=1, detect it by the MSI product code, and pilot the deployment before making it required.

The important qualification is that ConfigMgr may install the baseline without controlling every later version: Webex has its own automatic-update mechanism. Your deployment design therefore needs both an installation plan and an update policy.

What this deployment covers

This procedure is designed for Windows endpoints managed through SCCM/ConfigMgr and uses an MSI-based application deployment. It covers:

• Choosing the correct Cisco Webex package.
• Testing a silent, per-machine installation.
• Creating an Application and MSI deployment type in ConfigMgr.
• Configuring uninstall and detection.
• Deploying safely in pilot and production rings.
• Handling Webex self-updates, per-user installations, WebView2 and common failures.

Cisco’s current Windows installation documentation and Microsoft’s ConfigMgr application documentation should be checked again before each major rollout because package behavior, supported operating systems and update controls can change.

Cisco Webex Windows installation and automatic-upgrade documentation

Microsoft ConfigMgr application deployment documentation

Choose the right Webex MSI

Webex App-only or Webex App and Meetings bundle?

Use the Webex App-only MSI as the default for a normal enterprise deployment. It is the simpler choice when users can obtain meeting components through the internet and the organization does not need the separate Webex Meetings desktop application.

Use the Webex App and Meetings bundle MSI only when there is a documented reason, such as:

• Endpoints cannot download meeting components from the internet.
• The organization still requires the standalone Webex Meetings desktop client.
• A migration or compatibility plan requires both applications.

The bundle is not automatically better. Do not deploy both the App-only and bundle products to the same device unless their coexistence has been tested.

Localized versus non-localized packages

For third-party bulk deployment, Cisco recommends care with localized packages because they may create uninstall problems. The usual default is therefore the non-localized English package, provided that meets your organization’s language requirements.

x64 versus ARM64

Use the x64 MSI for supported 64-bit Intel or AMD Windows computers. Use the ARM64 MSI only for supported ARM64 hardware and operating systems. Cisco identifies supported ARM64 hardware including Qualcomm Snapdragon X Elite/X Plus and Microsoft SQ1 or newer platforms.

Windows N editions require the Media Feature Pack. Cisco also lists Windows 10 and later and Windows Server 2016 among its Windows requirements, but support varies by Webex release. Cisco states that Webex App 45.1 is the last version supporting Windows 10 LTSB 2015 and Webex App 45.10 is the last version supporting Windows 10 LTSB 2016.

Do not deploy the standard desktop MSI to VDI systems without checking Cisco’s separate Webex VDI deployment guidance.

Official download locations

Use Cisco’s documentation page as the authoritative download source. The following stable package paths are useful starting points, but the file behind a versionless URL can change:

• Webex App-only, non-localized x64 MSI
• Webex App and Meetings bundle, non-localized x64 MSI
• Webex App-only ARM64 MSI

Archive every tested MSI in a versioned ConfigMgr source directory and record its product version, architecture, product code and SHA-256 hash. Do not overwrite an existing production source file in place.

Prepare the ConfigMgr source

A practical source structure looks like this:

\CMSourceApplicationsCiscoWebex45.x.x
    Webex_en.msi
    Install-Webex.ps1
    Uninstall-Webex.ps1
    Detection-Webex.ps1
    README.txt

The scripts are optional if the MSI deployment type is sufficient. Keep them available for migration, cleanup or custom detection scenarios.

Before creating the application:

• Confirm the site-server computer account can read the content source.
• Keep each tested Webex release in a separate directory.
• Record the MSI filename, version, product code, architecture and hash.
• Test installation and removal on clean test devices.
• Inventory existing per-user and machine-wide Webex installations.
• Prepare a pilot device or user collection.

Do not use an end-user download location as the ConfigMgr content source. ConfigMgr must be able to copy the content to distribution points reliably.

Test the MSI outside ConfigMgr

Run the exact command you intend to place in ConfigMgr on a clean test computer:

msiexec.exe /i "Webex_en.msi" /qn /norestart ALLUSERS=1 ACCEPT_EULA=TRUE

A more controlled test command is:

msiexec.exe /i "Webex_en.msi" ^
  /qn /norestart ^
  ALLUSERS=1 ^
  ACCEPT_EULA=TRUE ^
  AUTOSTART_WITH_WINDOWS=false ^
  PREVENT_PRELOGIN_UPDATES=1 ^
  INSTALLWV2=1 ^
  /L*v "%WINDIR%TempWebex-Install.log"

Run the command from an elevated command prompt. Confirm that:

• The installer returns exit code 0.
• Webex is installed in the intended machine-wide context.
• Webex launches after a normal user signs in.
• Microsoft WebView2 is available.
• No unexpected restart occurs.
• Outlook integration matches policy.
• Existing Webex installations are handled as expected.
• The MSI product code and installed version can be identified.
• A user can sign in and join a test meeting.

Use /qb instead of /qn during troubleshooting if you need limited visual feedback. Do not move an untested command directly to a required production deployment.

Create the ConfigMgr Application

In the Configuration Manager console, go to:

Software Library > Application Management > Applications

Select Create Application, then:

1. Choose Automatically detect information about this application from installation files.
2. Select Windows Installer (*.msi file).
3. Browse to the versioned Webex_en.msi.
4. Review the imported product name, publisher, version and product code.
5. Complete the application metadata.
6. Review the generated MSI deployment type.
7. Set the installation command to the tested command.
8. Configure uninstall, detection, requirements and user experience.
9. Distribute the content to the required distribution points.
10. Deploy to a test collection first.

ConfigMgr’s MSI application model provides installation, uninstall, detection and requirement settings without requiring a custom wrapper for a straightforward deployment.

Configure the installation command

Use this as the baseline silent installation command:

msiexec.exe /i "Webex_en.msi" /qn /norestart ALLUSERS=1 ACCEPT_EULA=TRUE

For an organization that wants to prevent pre-sign-in update checks and have the Webex installation provide WebView2 when necessary, use a tested variant such as:

msiexec.exe /i "Webex_en.msi" /qn /norestart ALLUSERS=1 ACCEPT_EULA=TRUE AUTOSTART_WITH_WINDOWS=false PREVENT_PRELOGIN_UPDATES=1 INSTALLWV2=1

The final property set should reflect your identity, Outlook, VDI and update policies. Cisco documents the following commonly relevant properties:

Property	Purpose and qualification
ALLUSERS=1	Requests a per-computer installation. Administrative privileges are required; do not assume this alone resolves every per-user installation.
/qn	Runs with no user interface.
/norestart	Prevents an installer-initiated restart.
ACCEPT_EULA=TRUE	Suppresses an interactive EULA prompt.
AUTOSTART_WITH_WINDOWS=false	Disables automatic startup initially. Users may still be able to change the setting unless it is enforced separately.
PREVENT_PRELOGIN_UPDATES=1	Prevents update checks before user sign-in; it does not disable every Webex update.
INSTALLWV2=1	Installs Microsoft WebView2 through the Webex installation process when applicable. Test this against any centrally managed WebView2 deployment.
ENABLEOUTLOOKINTEGRATION=1	Enables Outlook presence integration. Test it with the organization’s Outlook architecture and policies.
EMAIL=$userPrincipalName	Provides the signed-in user’s UPN as a sign-in hint where supported by the identity flow.
INSTALL_ROOT="C:Program FilesCisco Spark"	Changes the installation directory. Update permissions, detection and security exclusions accordingly.
DELETEUSERDATA=1	Deletes user database and logs during installation. Reserve this for a documented reset or cleanup workflow.
DEFAULT_THEME="Light" or "Dark"	Sets the initial theme; users may be able to change it.

Bundle-only properties such as FORCELOCKDOWN=LockWhenCompatible and FORCECLIENTSPCOMPATIBLEVERSIONNO=10 should not be copied into an App-only deployment without confirming that the package supports them.

Do not hard-code an email on shared devices

A command such as:

[email protected] ALLUSERS=1

is inappropriate for shared or multi-user computers because it represents one fixed user. Where a sign-in hint is needed, use a directory-derived value such as:

EMAIL=$userPrincipalName

or omit the property. Validate the variable and identity flow in your environment before production use.

Configure the uninstall command

Use the actual product code imported from the tested MSI:

msiexec.exe /x "{PRODUCT-CODE}" /qn /norestart

Replace {PRODUCT-CODE} with the real product code for this deployment type. Do not copy a product code from another Webex release or package type.

Cisco also documents:

msiexec /x Webex.msi

However, that form requires the referenced MSI to be available at the specified path. A product-code uninstall is usually more practical in ConfigMgr because it does not depend on an end-user path containing the original MSI.

If historical Webex products or per-user installations are present, create a separate cleanup script or migration deployment. ConfigMgr also supports an uninstall deployment, but Microsoft warns that an install deployment takes precedence over an uninstall deployment. Remove conflicting Required install deployments before starting a removal campaign.

Configure reliable detection

Preferred method: MSI product code

For an MSI deployment type, use:

Detection Method: Windows Installer
Product code: {actual-product-code-from-the-tested-MSI}

MSI detection is preferable to checking only whether a directory exists. A directory can remain after an incomplete uninstall, while Webex may also update files independently of the original MSI registration.

If the deployment must enforce a minimum version, configure the MSI detection rule with the version obtained from the tested MSI, or use a tested custom detection script that returns installed only when the required version is present.

File or registry detection

Use file or registry detection only when there is a clear reason not to use MSI detection. Cisco documents the default standard installation path as:

%LocalAppData%ProgramsCisco Spark

This is a per-user path and is unsuitable for a system-context rule when users install Webex under their own profiles. A machine-wide installation with INSTALL_ROOT should be detected using the actual tested location. A file rule should identify a stable executable and verify its version rather than checking only for a folder.

Custom detection scripts

A script may be justified when the deployment must account for multiple installation locations, accepted historical product codes, existing per-user installs or a minimum installed version.

ConfigMgr custom detection scripts must return exit code 0 and write detection data to standard output. A zero exit code with no output is not sufficient.

$paths = @(
    "$env:ProgramFilesCisco Spark",
    "${env:ProgramFiles(x86)}Cisco Spark"
)

$exe = $paths |
    ForEach-Object { Join-Path $_ "Webex.exe" } |
    Where-Object { Test-Path $_ } |
    Select-Object -First 1

if ($exe) {
    $version = [version](Get-Item $exe).VersionInfo.ProductVersion
    if ($version -ge [version]"45.0.0") {
        Write-Output "Webex version $version detected"
        exit 0
    }
}

exit 1

This is a template, not a universal rule. Verify the executable name, path and version format on the selected Cisco package. Also remember that a SYSTEM-context detection script cannot automatically inspect every user profile in the way an interactive user process can.

Set requirements and user experience

Useful ConfigMgr requirement rules may include:

• Supported Windows version.
• 64-bit operating system for the x64 MSI.
• ARM64 operating system for the ARM64 MSI.
• Minimum free disk space.
• Exclusion of servers or VDI devices when the standard desktop package is not intended for them.
• Exclusion of Windows N devices unless the Media Feature Pack is installed.
• Exclusion of unsupported legacy Windows LTSB versions.

For Required deployments, use a maintenance window or deadline suitable for the business. Avoid forcing installation or repair while someone is presenting, calling or attending a meeting.

Configure return codes according to the MSI behavior you observe during testing. Treat a successful installer exit code and successful ConfigMgr detection as separate validations: ConfigMgr considers the application compliant only when its detection rule recognizes the installed state.

Distribute and deploy in rings

1. Distribute the application content to one test distribution point.
2. Deploy it as Available to a pilot user or device collection.
3. Install through Software Center and validate the user experience.
4. Change or create a Required pilot deployment.
5. Expand to a controlled production ring.
6. Monitor failures and detection results before broad deployment.

On a test endpoint, trigger Machine Policy Retrieval and Evaluation Cycle and Application Deployment Evaluation Cycle. The exact console wording may vary slightly by ConfigMgr version and client UI.

Logs to review

C:WindowsCCMLogsAppDiscovery.log
C:WindowsCCMLogsAppEnforce.log
C:WindowsCCMLogsCAS.log
C:WindowsCCMLogsContentTransferManager.log
C:WindowsCCMLogsLocationServices.log

AppDiscovery.log records detection activity, while AppEnforce.log records application enforcement and installation activity. The content and location logs help separate installer failures from distribution-point, boundary-group and download problems.

Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

Choose an update strategy before production

Installing Webex with ConfigMgr does not necessarily mean ConfigMgr controls the version that users run later. Cisco states that Webex’s update mechanism is independent of Windows and can update the app without the operating system installer being aware of it.

Option 1: Allow Webex self-updates

ConfigMgr installs the baseline and Webex updates itself.

Advantages: less packaging work and faster access to Cisco fixes.

Trade-offs: endpoint versions can drift, change control is less precise and support teams may see different Webex versions across the estate.

Option 2: Restrict pre-login updates

Use:

PREVENT_PRELOGIN_UPDATES=1

This prevents Webex from checking for updates before sign-in. It does not disable all post-sign-in updates. Cisco notes that organization-specific update settings can be applied reliably only after the user organization is known following authentication.

Option 3: Repackage approved versions

For strict change control:

1. Place each approved MSI in a new versioned source directory.
2. Create a new application or deployment type.
3. Update the detection rule using the new MSI’s actual product code and version.
4. Test upgrade, repair and rollback.
5. Configure supersedence where appropriate.
6. Deploy in rings.

This provides the greatest ConfigMgr control but can conflict with Webex’s independent updater. Document whether ConfigMgr enforces a baseline, a minimum version or an exact version.

Cisco currently states that a new Webex release takes seven days to roll out to everyone and patches are rolled out within a three-day window. Treat those timings as Cisco’s published behavior rather than a guarantee, and recheck the current documentation before relying on them for change planning.

Handle existing installations and migration

Before broad deployment, inventory:

• Per-user Webex installations.
• Machine-wide Webex installations.
• The Webex Meetings desktop client.
• Webex Productivity Tools.
• Multiple MSI product codes.
• Localized and non-localized packages.
• Stale uninstall entries.
• Existing Cisco Spark directories under user profiles.

A system-context MSI deployment will not automatically replace every per-user installation. A migration workflow may need to:

1. Detect existing per-user installations.
2. Close Webex processes.
3. Remove legacy products where required.
4. Install the approved machine-wide MSI.
5. Preserve user data unless a clean reset is intentional.
6. Validate sign-in and Outlook integration.

Do not add DELETEUSERDATA=1 casually. Cisco documents that it removes user databases and logs during installation, which can erase user state during repair or replacement scenarios.

Troubleshooting common failures

Error 1603

Check for another Webex MSI, a previous installation with a missing source, running Webex processes, insufficient permissions, an inaccessible target directory, a pending reboot or security software blocking the installer. Capture a verbose log:

msiexec.exe /i "Webex_en.msi" /qn /norestart /L*v "%WINDIR%TempWebex-Install.log"

Do not begin by deleting registry keys. Identify the product code and Windows Installer state first.

Installation succeeds but ConfigMgr says Not Installed

• Confirm the detection product code belongs to the MSI actually installed.
• Check whether the installation is per-user while detection runs as SYSTEM.
• Check 32-bit and 64-bit registry redirection.
• Confirm that a Webex self-update has not changed the state your rule expects.
• Review AppDiscovery.log immediately after enforcement.

The application repeatedly reinstalls

This is usually a detection problem. ConfigMgr runs detection before enforcement and again afterward. If the rule never recognizes the installed state, the client continues to treat the application as missing.

Content is unavailable

Review distribution-point status, boundary-group assignment, content transfer, location services and source permissions. An application that never appears may instead have a policy, collection-membership or client-health problem.

Uninstall fails

Verify the product code belongs to the installed deployment type. If you use msiexec /x Webex.msi, confirm that the MSI exists at the referenced path. Also check whether a Required install deployment is reinstalling Webex after removal.

WebView2 problems

Webex requires the Microsoft WebView2 embedded browser. Decide whether WebView2 is owned by the Webex MSI through INSTALLWV2=1 or managed centrally as a separate prerequisite. Avoid two competing ownership models until repair and update behavior have been tested.

Outlook integration does not work

If enabled with ENABLEOUTLOOKINTEGRATION=1, test both Outlook architectures used in the organization, presence behavior and the interaction with Office policies. Cisco’s property defaults to 0.

Production checklist

• Selected App-only or bundle for a documented reason.
• Selected x64 or ARM64 correctly.
• Used the tested non-localized package where appropriate.
• Archived the MSI in a versioned source directory.
• Recorded the exact product code and hash.
• Tested the silent install manually.
• Configured ALLUSERS=1 only with the intended privileged context.
• Tested WebView2 ownership.
• Used MSI product-code detection unless a tested exception is necessary.
• Tested uninstall with the actual product code.
• Inventoried per-user and legacy Webex installations.
• Documented whether Webex self-updates are allowed.
• Validated the application in an Available pilot and a Required pilot.
• Reviewed AppDiscovery.log and AppEnforce.log.
• Prepared a rollback or cleanup deployment.

Bottom line

For most managed 64-bit Windows endpoints, deploy Cisco’s non-localized Webex App-only MSI as a ConfigMgr Application, use a silent per-machine command with ALLUSERS=1 and ACCEPT_EULA=TRUE, detect the actual MSI product code, and roll it out through pilot rings. Treat Webex’s independent updater as a separate lifecycle decision, and resolve existing per-user installations before assuming the machine-wide deployment will replace them.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.