Using the Intune Management Extension, on a 64-bit platform, for a very happy New Year!

Let’s start the New Year with a quick tip about the Intune Management Extension, which is used for running PowerShell scripts, in combination with a 64-bit platform. The Intune Management Extension is 32-bit and will run PowerShell scripts in a 32-bit environment. This is not always the desired behavior. Actually, many activities and/or cmdlets, require a 64-bit environment. In this blog post I’ll provide a simple workaround, to run the PowerShell scripts in a 64-bit environment, and I’ll show the behavior of that simple workaround.

The (example) script

Now let’s start by looking at that simple workaround. That workaround is actually a simple addition to a script that starts the same script, by using the 64-bit environment of PowerShell. This is achieved by starting with the following assumptions:

  • The script  doesn’t have to deal with parameters – This saves me from doing difficult with providing parameters to it;
  • The script should only switch on a 64-bit platform running a 32-bit process – This makes sure that it won’t break on a 32-bit platform. That can be achieved by using $ENV:PROCESSOR_ARCHITEW643. That environment variable is set when running a 32-bit process on a 64-bit platform;
  • The script needs the right location of PowerShell – This makes sure that this time the 64-bit environment of PowerShell will be started. That can be achieved by using SysNative. That alias is used to point a 32-bit process to C:\Windows\System32;
  • The script needs the right location of the script – This makes sure that the same script is started again. That can be achieved by using $PSCOMMANDPATH. That automatic variable contains the full path and file name of the script that is being run.

These four assumptions bring me to the following small script snippet that can be added to the top of any script. For looking at the results, I’ve added an additional line at the beginning and the ending of the script snippet. Those additional lines write the environment of the process to a file.

Begin: $ENV:PROCESSOR_ARCHITECTURE” >> “C:\Windows\Temp\Test.txt”
If ($ENV:PROCESSOR_ARCHITEW6432 -eq “AMD64”) {
     Try {
         &”$ENV:WINDIR\SysNative\WindowsPowershell\v1.0\PowerShell.exe” -File $PSCOMMANDPATH
     }
     Catch {
         Throw “Failed to start $PSCOMMANDPATH”
     }
     Exit
}

“End: $ENV:PROCESSOR_ARCHITECTURE” >> “C:\Windows\Temp\Test.txt”

Important: The Intune Management Extension will only report over the initial script. To also report over the newly started script, you might want to look into building something smart that will monitor the newly start script before exiting the initial script. The example above simply exits the initial script.

The (example) results

Let’s end this post by looking at the example script, mentioned above, when deployed via Microsoft Intune. The example script writes, at the beginning and the ending, an entry to a file named Test.txt. After a successful execution, it contains the following three entries:

  1. 64-resultThe first entry is related to the beginning of the initial script, which is triggered by the Intune Management Extension. At that moment it’s started as a 32-bit process;
  2. The second entry is related to the beginning of the newly started version of the script, which is triggered by the initial script. At that moment it’s started as a 64-bit process;
  3. The third entry is related to the ending of the newly started version of the script. At that moment it successfully went through the complete script as a 64-bit process.

More information

For more information about automatic variables in PowerShell, refer to the documentation About Automatic Variables.

Combining the powers of the Intune Management Extension and Chocolatey

A bit more than a week ago the Intune Management Extension was added to Microsoft Intune to facilitate the ability to run PowerShell scripts on Windows 10 devices that are managed via MDM. That addition opens a whole new world for managing Windows 10 devices via MDM. Looking at app deployment specifically, this enables the administrator to look at something like Chocolatey for deploying packages. That would make the app deployment via Microsoft Intune suddenly flexible. In this blog post I’ll start with a little introduction about the Intune Management Extension and Chocolatey, followed by the configuration of a PowerShell script to install Chocolatey packages. I’ll end this post by looking at the end result.

Introduction

Let’s start with a short introduction about the awesome Intune Management Extension. The Intune Management Extension supplements the out-of-the-box MDM capabilities of Windows 10. It will be installed automatically on Windows 10 devices, that are managed via MDM, and it simply enables administrators to run PowerShell scripts on Windows 10 devices. Those PowerShell scripts can be used to provide additional capabilities that are missing from the out-of-the-box MDM functionality. The first scenario that the Intune Management Extension enabled, for me, is super easy app deployment via Chocolatey.

Chocolatey is a global PowerShell execution engine using the NuGet packaging infrastructure. Think of it as the ultimate automation tool for Windows. Chocolatey is a package manager that can also embed/wrap native installers and has functions for downloading and check-summing resources from the Internet. Super easy for installing application packages on Windows 10 devices.

Configuration

Now let’s have a look at the configuration. The configuration contains 3 steps. The first step is to create the required PowerShell script, the second step is to upload the PowerShell script to Intune and the third step is to assign the PowerShell script to an Azure AD group.

Step 1: Create PowerShell script

The first step is to create a PowerShell script that will check for the installation of Chocolatey, and that will install Chocolatey if it’s not yet installed. Once Chocolatey is installed the PowerShell script will install the required Chocolatey packages. Now let’s walk through the PowerShell script that I’ll use to do exactly that. The first thing that the script uses, are 2 variables. The first variable $ChocoPackages contains an array with the required Chocolatey packages and the second variable, $ChocoInstall, contains the default installation directory of Chocolatey (see below).

$ChocoPackages = @(“googlechrome”,”adobereader”,”notepadplusplus.install”,”7zip.install”)

$ChocoInstall = Join-Path ([System.Environment]::GetFolderPath(“CommonApplicationData”)) “Chocolatey\bin\choco.exe”

The second thing that the PowerShell script does is verifying the existence of the installation of Chocolatey. This is done by simply testing for the existence of choco.exe by using the $ChocoInstall variable. When choco.exe is not found, the online installation of Chocolatey will be triggered (see below).

if(!(Test-Path $ChocoInstall)) {
     try {

         Invoke-Expression ((New-Object net.webclient).DownloadString(‘https://chocolatey.org/install.ps1’)) -ErrorAction Stop
     }
     catch {
         Throw “Failed to install Chocolatey”
     }      
}

The third and last thing that the PowerShell script does is triggering the installation of the Chocolatey packages. This is done by running through the Chocolatey packages in the $ChocoPackages variable. For every package the installation will be triggered by using Chocolatey (see below).

foreach($Package in $ChocoPackages) {
     try {
         Invoke-Expression “cmd.exe /c $ChocoInstall Install $Package -y” -ErrorAction Stop
     }
     catch {
         Throw “Failed to install $Package”
     }
}

Now put these three pieces together in one script and save it as a PowerShell script (.ps1).

Step 2: Upload PowerShell script

The second step is to upload the created PowerShell script in Intune. To upload the PowerShell script, follow the next 5 steps.

1 Open the Azure portal and navigate to Intune > Device configuration > PowerShell scripts;
2 On the Device configuration – PowerShell scripts blade, click Add script to open the Script Settings blade;
3

Intune_AddPowerShellScriptOn the Add PowerShell script blade, provide the following information and click Settings to open the Script Settings blade;

  • Name: Provide a valid name for the PowerShell script policy;
  • Description: (Optional) Provide a description for the PowerShell script policy;
  • Script location: Browse to the PowerShell script.

Note: The script must be less than 10 KB (ASCII) or 5 KB (Unicode).

4

Intune_ScriptSettingsOn the Script Settings blade, provide the following configuration and click OK to return to the PowerShell script blade;

  • Run the script using the logged on credentials: No;
  • Enforce script signature check: No;

Note: Configure Run the script using the logged on credentials to No means that the PowerShell script will run in SYSTEM context;

5 Back on the Add PowerShell script blade, click Create.

Step 3: Assign PowerShell script

The third and last step is to assign the PowerShell script to an Azure AD group. To assign the PowerShell script, follow the next 5 steps.

1 Open the Azure portal and navigate to Intune > Device configuration > PowerShell scripts;
2 On the Device configuration – PowerShell scripts blade, select the uploaded PowerShell script and click Assignments to open the {ScriptName} – Assignments blade;
3 On the {ScriptName} – Assignments blade, select the required Azure AD group and click Save.

Note: Keep in mind that the Intune Management Extension synchronizes to Intune once every hour.

Result

Now let’s end this post by looking at the end result. Yes, I can show the installed applications, but it’s better for understanding the process to look at some log files. From an Intune Management Extension perspective, the most interesting log file is IntuneManagementExtension.log. That log file is located at C:\ProgramData\Microsoft\IntuneManagementExtension\Logs. Below is an example, in which I would like to highlight 2 sections:

  1. The first section shows that the first time a PowerShell script arrives on a device, as a policy, the complete script is shown in the log file;
  2. The second section clearly shows the configuration of the PowerShell script, by showing the configuration of the signature check and the context (as configured in step 2.4);

IME_Chocolatey_Result

From a Chocolatey perspective, the most interesting log files are choco.log and choco.summary.log. These log files are located at C:\ProgramData\chocolatey\logs. To show the most interesting information, I would like to highlight 2 sections from the choco.summary.log below:

  1. The first section shows the detection of a Chocolatey packages that is already installed;
  2. The second section shows the installation of a Chocolatey package;

Choco_Chocolatey_Result

The nice thing about Chocolatey is that it already contains a lot of intelligence. A simple example of that is that it checks for the installation of the packages, before starting the installation. That enables me to use one script for installing the packages by simply adding new packages to the $ChocoPackages variable. When the script runs on the client, only the newly added packages will be installed.

Note: Keep in mind that you can also use Chocolatey for updating the installed packages.

More information

For more information about the Intune Management Extension and Chocolatey, please refer to the following articles: