Intune provides the capability to enable or disable various BIOS features and settings, enhancing device security before the operating system even loads. Among these features is the ability to set or change the BIOS password, which is crucial for securing the boot process and protecting the device against unauthorized changes to BIOS settings. Additionally, Intune allows for the configuration of boot sequence settings, the enabling or disabling of hardware components, and the management of power management settings, among others. This comprehensive control over BIOS settings helps fortify device security and ensures a consistent configuration across the enterprise. As of right now Intune only supports Dell computers.

Create and Deploy the Dell Configuration File

To create a Dell configuration file, follow these preliminary steps to ensure your devices meet the necessary requirements for successful configuration via Intune:

1. Device and System Requirements:

• Ensure the device is a Dell commercial client running Windows 10 or a later version.
• The device must be enrolled in Intune's mobile device management (MDM) system.
• .NET 6.0 runtime for Windows x64 must be installed on the device.
• Install Dell Command | Endpoint Configure for Microsoft Intune (DCECMI) on the endpoint.

2. Creating the Configuration File:

• Download the DCECMI tool from Dell’s official website. Using this tool, you can create a configuration file tailored to your specific needs, including any OEM-supported configuration settings.
• When creating the configuration file, a corresponding Win32 app, provided by the OEM, will be needed. This app acts as an agent that interprets the configuration file and manages BIOS password settings among other configurations.

3. Deployment:

• Deploy the OEM Win32 app to all relevant devices using Intune. This app is crucial as it reads the configuration file and applies the settings, including BIOS passwords, to the devices

Target the BIOS Configuration Policy

To effectively target the BIOS configuration policy, you should focus on a specific set of devices. Here are two options for doing so:

Option 1: Create a Device Group

• Create a group comprising only the devices needing the policy. Assign both the app policy and the BIOS configuration policy directly to this group during creation.

Option 2: Use an Assignment Filter

• Implement an assignment filter based on the device manufacturer, specifically targeting OEM devices. Apply this filter when assigning the app and BIOS configuration policies.

Creating the BIOS Configuration Policy

Now it is time to create the policy itself. Using the Microsoft Intune Admin Center navigate to Devices > Configuration and create a new policy. Select Windows 10 and later as the Platform and select ‘BIOS configurations and other settings as the Profile Type as shown in the screenshot below.

In the Configuration settings, select your hardware OEM vendor from the list of supported OEMs which is currently, only Dell. Next you will configure ‘Disable per-device BIOS password protection’ by choosing No or Yes.

• No: Intune assigns a unique device password to each device. Users must use this password to access and modify the BIOS settings on their device.
• Yes: The BIOS is not protected by a password. Any previously set passwords are cleared, allowing end users unrestricted access to the BIOS settings.

The final step is to point to the configuration file you made earlier with the OEM tool as shown in the screenshot below.

Then assign the profile to the group you designated earlier, and the BIOS settings will be delivered.

One of the features of Intune is the ability to deploy applications across a wide range of devices and users. For this demonstration I want to install RingCentral for my East Coast Sales users, but first there are some prerequisites to complete first. Using a Windows 11 computer you will need to:

1. Download the Microsoft Win32 Content Prep Tool (IntuneWinAppUtil.exe)
2. Download the installer for the designated program.
3. Create the necessary folder structure for the setup files.

Opting for an MSI file when available is recommended for Intune deployments, as handling EXE files require additional steps and configurations. Once completed, you can begin to wrap the designated application for Intune deployment. Using either PowerShell or a Command Prompt, you will use the series of commands as shown below. In this scenario, the IntuneWinAppUtil is located within a folder named "Intune," containing both a "Source" and an "Output" subfolder for organizing the necessary files.

You can also type a single command that will look like this:

IntuneWinAppUtil.exe -c -s -o

In this example, I didn’t need to specify a catalog folder. When required, the Catalog Folder contains any configuration files, scripts, or other resources required by the application during its deployment process. Including this folder ensures that all necessary components are packaged together, facilitating a smoother and more reliable installation process when the application is deployed via Intune to end-user devices.

When you run the command successfully it should look something like the screenshot below.

The purpose of the wrapping process is to create the required ‘.intunewin’ file as shown below:

With the wrapping process complete, you are ready to upload the file to Intune. Using the Microsoft Intune Admin Center, navigate to Apps > Windows and click Add and select Windows app (Win32) from the dropdown menu as shown below.

Then you need to upload the application package file that was created using the Content Prep Tool.

Once I clicked ‘OK’ Intune filled in the required settings under App Information other than Publisher which I provided. In the next screen, Program, Intune then added the install and uninstall commands automatically as shown below.

In the Requirements screen you will need to provide the Operating System architecture as well as the minimum operating system required.

The next screen requires you to create a detection rule for Intune using. You generally define the rule within the Intune application deployment settings to verify if the application is already installed on a device. This involves specifying the path where the application is expected to be installed, and optionally, a file or executable within that path. For example, you might set a rule to check for the presence of an application executable in the "Program Files" directory. If the specified file is found, Intune considers the application installed; if not, it will proceed with the installation. This approach helps prevent reinstallation of applications already present on the device. In the screenshot below I have manually provided the path to the ProgramFiles folder where the RingCentral folder and application resides.

While dependencies and supersendence aren’t necessary here, let’s review what they are. Software dependencies section is for applications that must be installed before this application can be installed. The Supersedence section allows administrators to specify a new version of an application that should replace an older version already installed on devices. By defining supersedence relationships, Intune can automatically update or uninstall the previous version of the app when the new version is deployed, ensuring that users always have access to the latest features and security updates while maintaining a clean and optimized device environment.

Not needing scope tags either, we are ready to move to the final step which was to assign the app deployment policy to the East Sales Users group and then review and create the policy.  Once complete, the designated users will receive the application.

MSIX … What it means for you… and managing those Applications

Do not be alarmed if you see a file with an .msix extension to it.  MSIX is the latest application installer for Windows applications.  Now that you know what it is, the next question is probably, why does the world need another application installer?

Good question.  After all, we already have three installer formats.

The current set of Installer Choices

The former trilogy of application installers include EXE, MSI and AppX packages.  EXE installers are the most recognized and best suited for manual installs.  They incorporate GUI driven wizards that guide users through the installation process.  This allows for customized options such as multiple languages, add-ons and selected file paths.  EXE installers can also detect previous installations.  Because they are so accommodative to customization, they are also complex.   This makes unattended installs challenging.  EXE files also make admins very nervous in a malware world. 

MSI installers are simple, which is why they are best-suited silent unattended installations.  They too use graphical interfaces but do not offer extras or customized options, nor can MSI installers detect prior installations.  Finally, there are AppX installers.  These are used for Universal Windows apps and have similar characteristics to MSI installers in that they are simple and straightforward.  One thing that sets them apart from the other two is that they rely on container technology.  This isolates them from the rest of the operating system.  This makes them much more secure.  Unfortunately, AppX packages can only be used for Windows 10 so legacy machines cannot utilize them.

The new alternative called MSIX

MSIX is the new kid in town.  It is not very popular as of yet as it was just released in 2018.  It is the alternative to the current three and Microsoft intends that the MSIX packaging solution to be the centerpiece of its deployment toolset eventually.  Like many great ideas from Microsoft, new tools and ways of doing things take time for organizations to digest them.  The MSIX installer platform does not have a great market presence as of yet.   That does not take away from its many benefits however.  MSIX has definite improvements over its predecessors as it combines the best features of MSI and APX into a single format.  Basically, it installs like an MSI file, but behind the scenes, installs like an AppX.  You can create MSIX packages with either an interactive user interface or command line sequence.  Let’s look at the advantages associated with this new installer format.

Advantages of the MSIX Installer

One thing common to traditional applications is that tend to leave a footprint.  This footprint consist of AppData files and registry entries that never seem to get deleted after the application is uninstalled.  This clutter then lives on for the lifetime of the hosted machine.  MSIX has alleviated this.  Like AppX, MSIX is based on a containerized model.  This simplifies both the install and uninstall processes.  Uninstalling an MSIX package will remove any files and registry entries created by the app within the AppData folder, reducing machined clutter.

Unlike AppX installers, MSIX installers work on more than just Windows 10 machines and they support 32-bit applications.  Microsoft has released an SDK, which provides all API’s necessary to unpack an app package on multiple platforms.  Its cross-platform compatibility includes iOS, MacOS, Android, Linux and Windows 7.  In addition, the process of converting older applications to the MSIX format is far easier than to AppX.  You can also convert AppX applications to MSIX as well.  MSIX package bundling allows a single package to contain multiple language or device specific items, except unlike EXE installs, they options can be automatically selected by Windows. 

MSIX can also hand over the updating process to the operating system.  This streamlines the updating process by making it more secure and reliable.

Security is at the epicenter of MSIX.  MSIX applications are tamper proof because they must be digitally signed regardless of how the packages are installed.  For software vendors creating MSIX packages to publish in the Microsoft Store, Microsoft will sign the package once the approval process has been is complete.  Organizations intending to publish MSIX for direct download or internal network distribution must sign it with a valid code-signing certificate purchased from a certificate authority.

The MSIX Packaging Tool

You can download the MSIX packaging tool from the Microsoft Store.  The package tool requires Windows 1809 and later.  Microsoft recommends that you create a clean VM for the conversion host.  Keep in mind that the MSIX Packaging Tool will assume the processor architecture of the Windows 10 OS version in which the conversion process is taking place. You must convert your installers in the same environment where you expect to deploy them.  Once installed, simply open the tool to begin the packaging wizard.  You will be first be asked to choose the selected task.  In this example, we are creating a new application package.

You will then choose the desired packaging method.

The packaging tool will perform an assessment of the machine that will handle the conversion process.

You will then set out to create the package.  You need to select the installer you want to package.  Then you must select a signing preference.  Your choices are as follows:

In the example below, we have selected an MSI installer with no arguments.  We are signing using a certificate from a certificate authority with the assigned password.

Next, fill out required packaging information.

Click “Next” and the installation process will begin. During this process, the packager will capture the registry or any files needed to install or configure the app.

At this point, the conversion process will listen for any executables that are triggered at the initial launch of the application.  This is why it is essential use a quiet machine for the conversion process.  Captured executables will be displayed on the screen.  It is here that you will manage any first launch tasks.  You should launch the application at least one time in order to capture any first launch tasks. 

Upon clicking “Next” you will asked to confirm that you wish to culminate the listening process.

Now choose a destination folder for the final package and click Create.

That completes the MSIX packaging process.  Be prepared to see MSIX packages a lot more down the road.