Part 3, Deep dive Microsoft Intune Management Extension – Win32 Apps

IntuneWin32ComboLogoMicrosoft made it finally happen and provides an integrated way to deploy Win32 Apps via the Intune Management Extension. This is by far the biggest step forward in the Modern Management field. Until now the community came up with lots of ways to utilize PowerShell scripts to finally install some Win32 Apps. By doing this you need to take care of the content location, availability, distribution, the app install, and verification logic. All this is now available in the enhanced Intune Management Extension. As a short refresh regarding Intune Management Extension, I recommend to read my blog articles about it, where you find a lot of information regarding the architecture, the inner workings, and troubleshooting advises:

Part 1 Deep dive Microsoft Intune Management Extension – PowerShell Scripts
Part 2 Deep dive Microsoft Intune Management Extension – PowerShell Scripts

Both articles are very relevant to this new feature as they all describe the architecture and technical details regarding the Intune Management Extension itself. Exactly this Intune Management Extension is used now for deploying Win32 apps packaged as .intunewin file format. It’s even better, the new functionality can be used to basically transport everything in a package and trigger a certain command line for execution. This is not a end to end walk-through how to use the feature in regards of the Intune portal or on the client itself. For this check out other great articles found in my last section End to end usage walk-throughs?. This is an article all about the inner workings of this new capability, a deep dive into the new technology itself.

Table of content for easy navigation

How do we get packaged apps now?

To get a Win32 apps deployed via the Intune Management Extension we first need to package the content we want to distribute. Microsoft decided to use the same approach like they did for the macOS world, where they provide a small tool to create the packages – Microsoft Intune App Wrapping Tool for macOS. A similar tool to create these packages is available for the Windows world now. This tool is called:

Microsoft Intune Win32 App Packaging Tool

For all of you with ConfigMgr experience, the new feature to deploy Win32 apps with Intune can be compared a little bit with the Packages and Programs functionality within ConfigMgr, but with some additions.

The usage of the Microsoft Intune Win32 App Packaging Tool (IntuneWinAppUtil.exe) is quite simple. We specify a folder and the executable and create then an yourappname.intunewin file. This is our packaged app which we then can upload to the Intune service. The command line of the tool is this:

IntuneWinAppUtil -c  -s  -o  <-q>

To dig a little deeper we inspect the resulting package in detail now. After successful execution it will generate the .intunewin file from the specified source folder and setup file. For MSI setup files, this tool will retrieve required information for later usage in the Intune portal. To explore this a little bit I captured the output and highlighted some important facts there, to gain understanding how the tool is working.

IntuneWin32AppToolOutput

As seen the tool is executed with the necessary parameters to create a package for Google Chrome Enterprise Edition Browser, which is provided as a .msi file. A sub folder called Chrome is in the same folder as the IntuneWinAppUtil. The command line then is:

IntuneWinAppUtil.exe -c .\Chrome -s GoogleChromeStandaloneEnterprise64.msi -o .\ -q

If we look at the green highlighted output now we find some very important information appearing which is exactly describing the workflow:

  1. Compressing the source folder and its files to a sub folder ‘content’ with the new extension .intunewin
  2. Encrypting the compressed file
  3. Computing SHA265 hash
  4. Generating a detection.xml file in a sub folder ‘metadata’
  5. Compressing complete working folder and create again an .intunewin file

As we can see a normal zip compression is used and therefore it is easy to verify all this by opening the generated package with our favorite archive application:

IntuneWinContentRoot

We can see the content folder and metadata folder. Where the content folder stores the encrypted .intunewin file:

IntuneWinContentSubContent

and the metadata folder contains the detection.xml file:

IntuneWinContentSubMetadata

If we now have a look at the detection.xml file we can see the information gathered about the package and msi file:

<ApplicationInfo xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" ToolVersion="1.0.0.0">
  <Name>Google Chrome</Name>
 <UnencryptedContentSize>52284458</UnencryptedContentSize>
  <FileName>GoogleChromeStandaloneEnterprise64.intunewin</FileName>
  <SetupFile>GoogleChromeStandaloneEnterprise64.msi</SetupFile>
  <EncryptionInfo>
    <EncryptionKey>Rj9EtHeHGYMv5HYBpyobrmp0rVg0pzIy0TwO9PnSRg8=</EncryptionKey>
    <MacKey>5kxZeuk6xfeMak+r/9hzbwS0vBUW1jBMhgN10Jy7XBQ=</MacKey>
    <InitializationVector>2AK05qM3tm/5ijDnlFPISA==</InitializationVector>
    <Mac>zI8vragiGb1VtbVRiKo3lPkJldZGZB4juX50MCNrmDw=</Mac>
    <ProfileIdentifier>ProfileVersion1</ProfileIdentifier>
    <FileDigest>Nzl3O6e70W1P0kJDJiWh3eU6gCVOhODNNy7mspfplQA=</FileDigest>
    <FileDigestAlgorithm>SHA256</FileDigestAlgorithm>
  </EncryptionInfo>
  <MsiInfo>
    <MsiProductCode>{A4BC9C54-4589-3A4C-8217-9FA00262F471}</MsiProductCode>
    <MsiProductVersion>67.92.84</MsiProductVersion>
    <MsiUpgradeCode>{C1DFDF69-5945-32F2-A35E-EE94C99C7CF4}</MsiUpgradeCode>
    <MsiExecutionContext>System</MsiExecutionContext>
    <MsiRequiresLogon>false</MsiRequiresLogon>
    <MsiRequiresReboot>false</MsiRequiresReboot>
    <MsiIsMachineInstall>true</MsiIsMachineInstall>
    <MsiIsUserInstall>false</MsiIsUserInstall>
    <MsiIncludesServices>false</MsiIncludesServices>
    <MsiIncludesODBCDataSource>false</MsiIncludesODBCDataSource>
    <MsiContainsSystemRegistryKeys>true</MsiContainsSystemRegistryKeys>
    <MsiContainsSystemFolders>false</MsiContainsSystemFolders>
  </MsiInfo>
</ApplicationInfo>

A detailed review shows us the file and encryption information and in addition the MSI file information. This information is used by the Intune portal to pre-populate some Intune app definitions for us.

The MSI information is only available when a msi file is packaged. If we package a setup.exe for example you will not see the entire section in the detection.xml file.

Why is the .intunewin packaged like this?

This is pretty simple to explain. The portal and the Intune service gets all necessary information to deal with the app (in this case Google Chrome). The msi information listed in the detection.xml is used to simplify the setup within the Intune UI by pre-filling the app form during creation. For example by adding the install and uninstall commands for the msi automatically:

IntuneWin32AppsMSIInstallCommand

The EncryptionInfo is used to store it with your Intune tenant to gain access to the uploaded .intunewin package. The encrtypted .intunewin (located in the content folder) can be distributed safely to the Intune back-end services responsible for content distribution without getting exposed to others, only the tenant who uploaded the file has the EncryptionInfo and can decrypt the file.

Where can I find details of the Win32 App deployment?

The Intune Management Extension tracks some details of the Win32 apps in the registry at: HKLM\SOFTWARE\Microsoft\IntuneManagementExtension\Apps\

IntuneWin32AppDetailsRegistry

The yellow highlighted names provide us the execution commands for install and uninstall and the attempts and results of it.

If we look at the green highlighted GUID at HKLM\SOFTWARE\Microsoft\IntuneManagementExtension\Win32Apps\73d664e4-0886-4a… we can see it matches my Azure AD user object ID. To compare it I got the details via Azure AD PowerShell:

GetAzureADUser

The red highlighted GUID (b0f62b79-e464-4f95-afe2-ed99eb612fe5) is the application GUID which is assigned by the Intune service back-end. This can be easily traced by looking at the graph data with the Graph Explorer from Microsoft:

https://developer.microsoft.com/en-us/graph/graph-explorer

In my example I used this to retrieve the details of my uploaded app:

https://graph.microsoft.com/beta/deviceAppManagement/mobileApps/b0f62b79-e464-4f95-afe2-ed99eb612fe5

This is the detailed information about the uploaded Win32 .intunewin app:

{
    "@odata.context": "https://graph.microsoft.com/beta/$metadata#deviceAppManagement/mobileApps/$entity",
    "@odata.type": "#microsoft.graph.win32LobApp",
    "id": "b0f62b79-e464-4f95-afe2-ed99eb612fe5",
    "displayName": "Google Chrome (new)",
    "description": "Google Browser",
    "publisher": "Google",
    "largeIcon": null,
    "createdDateTime": "2018-09-21T09:38:11.4343585Z",
    "lastModifiedDateTime": "2018-09-21T09:39:16.2037636Z",
    "isFeatured": true,
    "privacyInformationUrl": null,
    "informationUrl": null,
    "owner": "",
    "developer": "",
    "notes": "",
    "uploadState": 1,
    "publishingState": "published",
    "committedContentVersion": "1",
    "fileName": null,
    "size": 52284512,
    "installCommandLine": "msiexec /i \"GoogleChromeStandaloneEnterprise64.msi\" /q",
    "uninstallCommandLine": "msiexec /x {A4BC9C54-4589-3A4C-8217-9FA00262F471} /q",
    "applicableArchitectures": "x64",
    "minimumFreeDiskSpaceInMB": null,
    "minimumMemoryInMB": null,
    "minimumNumberOfProcessors": null,
    "minimumCpuSpeedInMHz": null,
    "msiInformation": null,
    "setupFilePath": null,
    "minimumSupportedOperatingSystem": {
        "v8_0": false,
        "v8_1": false,
        "v10_0": false,
        "v10_1607": true,
        "v10_1703": false,
        "v10_1709": false,
        "v10_1803": false
    },
    "detectionRules": [
        {
            "@odata.type": "#microsoft.graph.win32LobAppProductCodeDetection",
            "productCode": "{A4BC9C54-4589-3A4C-8217-9FA00262F471}",
            "productVersionOperator": "notConfigured",
            "productVersion": null
        }
    ],
    "installExperience": {
        "runAsAccount": "system"
    },
    "returnCodes": [
        {
            "returnCode": 0,
            "type": "success"
        },
        {
            "returnCode": 1707,
            "type": "success"
        },
        {
            "returnCode": 3010,
            "type": "softReboot"
        },
        {
            "returnCode": 1641,
            "type": "hardReboot"
        },
        {
            "returnCode": 1618,
            "type": "retry"
        }
    ]
}

Intune Management Extension Agent working folders?

If we have a look at the file system at:

C:\Program Files (x86)\Microsoft Intune Management Extension\Content

we can find some interesting folders where the agent is downloading the content and detection scripts and stores the actual MSI log files:

ItnuneWin32AppsFolders

Agent execution context when processing .intunewin files?

The agent is bound to the same restrictions during execution like we know them for PowerShell scripts, meaning the calling process (the Intune Management Extension agent) is a 32-bit process. This can result in some unexpected behavior. For example when trying to package a simple .ps1 file within a .intunewin and trying to execute cmdlets in this scripts which are only available in a 64-bit environment. We then have to use a technique to restart the PowerShell script as a 64-bit process. This is described in my previous articles and I have built a Intune PowerShell script template to simplify the start for this, which can be found on my GitHub here https://github.com/okieselbach/Intune/blob/master/ManagementExtension-Samples/IntunePSTemplate.ps1. This can also affect installers packaged as .intunewin when they assume a 64-bit environment!

If no restart technique is used keep in mind that environment variables must be handled with care from 32-bit processes. For example if you like to target the %windir%\System32 environment from a 32-bit process you have to use %windir%\Sysnative otherwise you will land in %windir%\SysWOW64. Visit the linkt to read more about the file system redirector: https://docs.microsoft.com/en-us/windows/desktop/winprog64/file-system-redirector

What are the retry and execution intervals?

The agent has default values for retry and execution:

  • max. of 3 retries
  • interval between the retries is 5 min.
  • max. execution run time is 60 min.

these limits are not adjustable at the moment.

Current Limitations (as per date Oct-2018)?

  • No user context app installation (added 22th of Oct)
  • No system context installation without user logged on (added 22th of Oct)
  • No dependency support
  • No supersedence
  • No support for Delivery Optimization
  • No integration into Enrollment Status Page, no wait for Win32 app installs
  • No notification suppression
  • No ordered installations, sequencing like .NET Framework install before App X
  • Current application size is capped at 2GB 8GB per app (changed 22th of Oct)

End to end usage walk-throughs?

Good walk-throughs on how to use the feature with the Intune portal and the end user experience can be found here:

Deploy Win32 Applications with Microsoft Intune
http://www.scconfigmgr.com/2018/09/24/deploy-win32-applications-with-microsoft-intune/

Deploy customized Win32 apps via Microsoft Intune
https://www.petervanderwoude.nl/post/deploy-customized-win32-apps-via-microsoft-intune/

Intune – sidecar for Win32 apps revealed
http://gerryhampsoncm.blogspot.com/2018/09/intune-sidecar-for-win32-apps-revealed.html

Intune Win32 App deployment – A gamechanger
https://ccmexec.com/2018/10/intune-win32-app-deployment-a-gamechanger/

Official documentation can be seen here

Intune Standalone – Win32 app management
https://docs.microsoft.com/en-us/intune/apps-win32-app-management

Remember to check back frequently as Intune progresses and the feature will be enhanced in short cycles. I will update the article accordingly.

Happy packaging, deploying and troubleshooting Win32 apps with Intune!

Ignite 2018 – My wrap up

First of all, what an amazing experience to attend Microsoft Ignite 2018 in Orlando. All started off with a keynote by Satya Nadella followed by general announcement sessions and technical deep dive sessions. The key message was about “Tech Intensity”. This is described by changing your cultural mindset and your processes. Ultimately leading to a better digital transformation by tearing down silos in your organization and bringing teams and technology closer together. Creating close feedback loops to generate advantage of valuable insights. Technology will cover every aspect of our life sometime and it is time now to start to align yourself to this. Time to disrupt yourself, modernize your own business model. Everyone has to find ways to leverage technology to optimize their businesses otherwise others will have a significant advantage in a short amount of time. It’s time for a culture of adoption.

The biggest announcement for me as an Enterprise Mobility MVP is by far the Win32 app support in Microsoft Intune.

IntuneWin32Announcement

Microsoft delivers the functionality to wrap your apps (all kind of installers like setup.exe etc) in a container (zip) format and allows distribution via Intune. This is a game changer for Microsoft Intune as it was one of the missing parts and blocker for customers to fully adopted the modern management approach. Customers who are wiling to modernize and are going for a full modern management approach are now able to install their Line-of-business applications directly via Intune. This functionality is powered by the Microsoft Management Extension (see my deep dives Part 1 and Part 2) which was used for PowerShell script execution with Intune already in the past. I will provide some technical deep dive insights into the Win32 capabilities in the following days.

For Windows Autopilot they announced Hybrid Azure AD join and the capability to harvest Autopilot data. The Hybrid Azure AD join might be good for some people but I really encourage everyone to check out Azure AD join as it also supports accessing local AD resources with Kerberos authentication. Harvesting Autopilot information of existing devices in an easy way is great and simplifies the steps to a modern infrastructure where all devices even in a reinstall/reset scenario are using a simplified setup powered by Windows Autopilot. For Intune they delivered great Sessions regarding the availability of Intune Security Baselines and Desktop Analytics. The Intune Security Baselines are provided to fill configuration gaps which companies currently see when transitioning from a local AD and Group Policy environment to a Azure AD/MDM environment. The goal is to have all required security settings available in the MDM environment to easily transition. In addition to the Security Baseline settings, Intune gets support for Administrative Templates to further simplify the configurations of policy settings for Office and Windows. It frees us to handle the complex way of admx ingestion by providing the most needed settings in the portal. Not only the settings administration is made simple they also released the Intune PowerShell SDK to easily automate tasks within Intune. With Desktop Analytics we get tighter integration of the telemetry data from Windows Analytics into Intune to build piloting rings based on telemetry to ensure good coverage of your LOB apps in the piloting rings.

A lot of changes happening in the IT world right now and Microsoft builds out his platforms to be even more mature to support us in every aspect. This starts with the Microsoft 365 story by bringing real cross platform functionality like Information Protection availability in every product like Outlook, Word etc. for Windows, iOS/macOS, and Android. They also announced the OneDrive feature “Files on Demand” for macOS now. There is a very big focus on Security on everything what Microsoft is doing right now. More than 3500 full time security professionals are working at Microsoft to power the security platforms also with the help of AI to generate insights for the Intelligent Security Graph. To fight the world of passwords they announced Azure AD password less sign-in. A very good simplification of the portals is coming up also to provide consistency in the handling. This simplification includes a common URL scheme like devicemanagement.microsoft.comadmin.microsoft.com, security.microsoft.com, or compliance.microsoft.com. Even a Windows Virtual Desktop in the cloud was announced. Another highlight to mention is that Microsoft will bring up a new offer called Microsoft Managed Desktop where Microsoft will completely manage your devices. In the Office world we got Microsoft Ideas which helps you to find great layouts and even the interesting data in your Excel spreadsheet powered by AI.

Beside these great announcements I’ve taken the chance to meet with a lot of the Product Group members and had great conversations with them. Also I met a lot of my fellow MVPs which was a great experience. Really looking forward for the next one in Orlando at November 4-8. If you like to pre-register follow this link.

See you in Orlando next time! 👍

 

 

Deep dive Microsoft Intune Management Extension – PowerShell Scripts

Microsoft made a big step forward in the Modern Management field. Limitations like custom configurations or even Win32 App installs can be addressed now. Microsoft developed an EMS agent (aka SideCar) and released it as a new Intune feature called Intune Management Extension. This agent is able to manage and execute PowerShell scripts on Windows 10 devices and it does this quite well.

IntuneManagementExtensionMSIProperties

We can simply upload our own PowerShell scripts for device configuration:

PowerShellScriptsIntune

Part 2 of this article answers common questions I’ve seen, when working with the Intune Management Extension – Part 2, Deep dive Microsoft Intune Management Extension – PowerShell Scripts.

Part 3 of this series will dive into the Microsoft Intune Management Extension – Win32 Apps deployment capabilities – Part 3, Deep dive Microsoft Intune Management Extension – Win32 Apps

 

How do we get the agent installed on the devices?

The ability to deploy basic MSI packages via MDM OMA-DM channel, is provided by Microsoft since the beginning of Windows 10. This is achieved by using the EnterpriseDesktopAppManagement CSP.

Microsoft is using this mechanism to deploy the agent to Windows 10 devices. Beginning with Windows 10 Version 1607 we have support of the Intune Management Extension now. The device must be AAD joined and the automatic MDM enrollment must be enabled (see Prerequisites).

The workflow is basically like this. If a PowerShell script is assigned to a user group (device groups are not supported since 22th of Oct.) and the agent is not installed, it will be pushed down automatically to the device via EnterpriseDesktopAppManagement CSP by Intune. This can be verified and traced in the “Advanced Diagnostics Report” of the MDM management.

Open Settings > Accounts > Access work or school > Connected to TenantName’s Azure AD > Info > scroll down to the bottom and click “Create report”

AdvancedDiagnosticsReportNow you get an report about all MDM configurations including the desktop app installations. Here we can see the EnterpriseDesktopAppManagement msi install of the EMSAgent with the ProductCode: {25212568-E605-43D5-9AA2-7AE8DB2C3D09}

EMSAgentInstallReport

./device/Vendor/MSFT/EnterpriseDesktopAppManagement/MSI/%7B25212568-E605-43D5-9AA2-7AE8DB2C3D09%7D

The instruction can be translated into more human readable form with ProductCode and curly brackets, as the yellow marked resource uses URL encoding and here %7B = { and %7D = }

./device/Vendor/MSFT/EnterpriseDesktopAppManagement/MSI/{25212568-E605-43D5-9AA2-7AE8DB2C3D09}

If the device encounters any error during installation of the agent, we can troubleshoot this with the eventlog:

Start event viewer > Applications and Services Logs > Microsoft > Windows > DeviceManagement-Enterprise-Diagnostics-Provider > Admin

An example where the agent installation went wrong with an error event id 1924 looks like this:

Event ID 1924, Error

EnterpriseDesktopAppManagement CSP: An application install has failed. 
Examine the MSI log (C:\Windows\system32\config\systemprofile\AppData\
Local\mdm\{25212568-E605-43D5-9AA2-7AE8DB2C3D09}.log) for more details. 
Install command: ("C:\Windows\system32\msiexec.exe" /quiet /l*v 
C:\Windows\system32\config\systemprofile\AppData\Local\mdm\
{25212568-E605-43D5-9AA2-7AE8DB2C3D09}.log /qn /i "C:\Windows\system32\
config\systemprofile\AppData\Local\mdm\
{BD19E4D8-D6C9-48B2-A53C-579D03B29FE9}.msi" ), 
MSI ProductCode: {25212568-E605-43D5-9AA2-7AE8DB2C3D09}, 
User SID: (S-0-0-00-0000000000-0000000000-000000000-000), 
Result: (User cancelled installation.).

Here we can see the original MSI install command including logfile path for further analysis:

C:\Windows\system32\config\systemprofile\AppData\Local\mdm\ {25212568-E605-43D5-9AA2-7AE8DB2C3D09}.log

The agent will get installed in the 32-bit Program Files path:

C:\Program Files (x86)\Microsoft Intune Managment Extension

IntuneManagementExtension

 

How does the agent gets it’s policy?

The agent will start to figure out the service endpoint via Service Discovery. A common approach in Microservices architecture in modern cloud platforms. After getting the Intune Service URL (https://somemssubdomain.manage.microsoft.com/SideCar/StatelessSideCarGatewayService) the agent can start to communicate and will receive its assigned policies.

All this can be traced in the logfiles here:

C:\ProgramData\Microsoft\IntuneManagementExtension\Logs

IntuneManagementExtensionLogs

The agent will start to download and execute the assigned PowerShell script here:

C:\Program Files (x86)\Microsoft Intune Managment Extension\Policies\Scripts\UserGUID_ScriptGUID.ps1

and the results are written here:

C:\Program Files (x86)\Microsoft Intune Managment Extension\Policies\Results\UserGUID_ScriptGUID.output|.error|.timeout

After successful execution the script and results are cleaned up and nothing is left on the device. Corresponding registry entries for the assigned scripts and execution results are here:

HKLM\SOFTWARE\Microsoft\IntuneManagementExtension\Policies\UserGUID\ScriptGUID

IntuneManagementExtensionRegistry

 

How often does the agent check for new policies?

The default is every 60 minutes.

 

What are the PowerShell script execution options?

We can execute scripts in system context or user context. Optional we can enforce a signature check.

ScriptSettings

The current file size limit is 10KB for ASCII scripts and 5KB for unicode scripts. The current file size limit is max. 200KB.

 

How do I enforce next agent check for policies?

Simply restart the Windows Service “Microsoft Intune Management Extension”.

IntuneManagementExtensionWindowsService

 

Is there a particular order in which multiple scripts are executed?

No, they are executed in random order.

 

What can be done with the PowerShell script execution?

Some examples and potentially pitfalls with the usage of the Intune Management Extension are listed below:

Install Win32 application

Install Win32 applications can be done easily by using a web request to get sources for the installation and finally execution of the sources. This technique is used a lot in the Chocolatey space. A simple example with 7-zip is shown below and can be modified to your needs:

# Author: Oliver Kieselbach
# Date: 11/28/2017
# Description: Download executable or msi and execute to install.

# The script is provided "AS IS" with no warranties.
$url = "http://www.7-zip.org/a/7z1701-x64.msi"
$filePath = "c:\windows\temp\7z1701-x64.msi"
$ProgressPreference = 0
Invoke-WebRequest $url -OutFile $filePath -UseBasicParsing
& $filePath /quiet

To use Chocolatey you should follow the install instructions from the Chocolatey website:

iex ((New-Object System.Net.WebClient).DownloadString('https://chocolatey.org/install.ps1'))

After Chocolatey Framework installation you can use choco.exe install Package in additional PS scripts to install Chocolatey software. An excellent post from Peter van der Woude regarding Chocolatey and Intune Management Extension can be found here: Combining the powers of the Intune Management Extension and Chocolatey

 

Write registry keys in x64 hive and not WOW6432Node

As the agent is an 32-bit agent every PowerShell script execution will be in the 32-bit agent process. If we write a registry key on a x64 device from a 32-bit process it will be redirected to the WOW6432Node in the registry. This is often not the desired behavior. To solve this we can restart the script as a 64-bit process for script execution. An example to write a registry key to the x64 hive with this technique is shown below:

# Author: Oliver Kieselbach
# Date: 11/28/2017
# Description: Write to registry and ensure execution from x64 process environment.

# The script is provided "AS IS" with no warranties.

Param([switch]$Is64Bit = $false)

Function Restart-As64BitProcess
{
 If ([System.Environment]::Is64BitProcess) { return }
 $Invocation = $($MyInvocation.PSCommandPath)
 if ($Invocation -eq $null) { return }
 $sysNativePath = $psHome.ToLower().Replace("syswow64", "sysnative")
 Start-Process "$sysNativePath\powershell.exe" -ArgumentList "-ex bypass -file `"$Invocation`" -Is64Bit" -WindowStyle Hidden -Wait
}

Function New-RegistryKey
{
 Param([Parameter(Mandatory = $true)]
 [string]$Key,
 [Parameter(Mandatory = $true)]
 [string]$Name,
 [Parameter(Mandatory = $true)]
 [string]$Value,
 [ValidateSet("String", "ExpandString", "Binary", "DWord", "Multistring", "QWord", ignorecase=$true)]
 [string]$Type = "String")
 try
 {
 $subkeys = $Key.split("\")

foreach ($subkey in $subkeys)
 {
 $currentkey += ($subkey + '\')
 if (!(Test-Path $currentkey))
 {
 New-Item -Type String -Path $currentkey | Out-Null
 }
 }

Set-ItemProperty -Path $currentkey -Name $Name -Value $Value -Type $Type -ErrorAction SilentlyContinue
 }
 catch [system.exception]
 {
 $message = "{0} threw an exception: `n{0}" -f $MyInvocation.MyCommand, $_.Exception.ToString()
 Write-Host $message
 }
}

if (!$Is64Bit) { Restart-As64BitProcess }
else
{
 # Enable Potentially Unwanted Application protection
 New-RegistryKey -Key "hklm:\SOFTWARE\Microsoft\Windows Defender" -Name "PUAProtection" -Value "1" -Type DWord
}

Please see my GitHub account for Intune Management Extension Samples for a enhanced and maintained PowerShell Template (IntunePSTemplate.ps1) which takes care of x64 restarting, logging and so on!

 

Execute in user context and show dialog

To show a simple example to execute scripts in user context we can use the following script to present a Message Box to the user:

 Add-Type -AssemblyName PresentationFramework
 [System.Windows.MessageBox]::Show('Hello World from Sid-Car!')

HelloSideCar

 

I hope this explains the technical implementation of the Microsoft Intune Management Extension and the extension addresses some road blockers you might have in the past with Intune regarding advanced configurations.

See also my follow up post Part 2, Deep dive Microsoft Intune Management Extension – PowerShell Scripts for even more details and common questions around architecture and troubleshooting.

Part 3 of this series will dive into the Microsoft Intune Management Extension – Win32 Apps deployment capabilities – Part 3, Deep dive Microsoft Intune Management Extension – Win32 Apps