Adaptiva Blog

Using ProgramData to store Win32 Apps Logs

Written by Niall Brady, Microsoft MVP and Endpoint Management Expert | May 21, 2024 3:30:00 PM

How to Streamline Troubleshooting and Reduce Errors with a PowerShell Script

We are excited to welcome Guest Authors and Microsoft MVPs Niall Brady and Paul Winstanley, as guest authors. Stay tuned for additional blogs in our Expert Insights series.

Traditionally deploying multiple Win32 apps from Intune will most likely leave installation files, detection methods and log files in all sorts of places, such as C:\Windows or C:\Windows\Temp.  

That’s all well and good until you or your onsite support staff need to troubleshoot those apps when things go wrong, for example if an app fails, or fails to install.  

Those folders are protected and require Administrative permissions just to browse and if your users are standard users (and they should be) then they’ll need to elevate just to troubleshoot. 

Not only that, but if you place scripts (such as VBS) in temp folders, they will be wiped out when Windows upgrades from one baseline version to another (eg: Windows 10 to Windows 11) causing possible unnecessary errors to the end-user when scripts are no longer found after the upgrade. 

Standardized Installation Paths  

Having all your Win32 apps using a standardized installation path helps cut down on the time/effort to troubleshoot. Using C:\ProgramData (by default hidden) is a great way of doing that. There are no administrative rights needed to browse files in that folder structure so troubleshooting is easy, and as you will deploy all your Win32 apps to this folder structure, it will be standardized. Below is an example of some apps. 

  • C:\ProgramData\CompanyName\AppName1 
  • C:\ProgramData\CompanyName\AppName2 
  • C:\ProgramData\CompanyName\AppName3 
  • C:\ProgramData\CompanyName\AppName4 

Now that we know what we want, let’s try it out.

 

1. Get the template

Download the following ZIP and unzip to somewhere useful.

Note that you’ll need to modify the variables in both the CMD file and the PowerShell sample script.  

Below you can see the three variables in the batch script (install_script.cmd). Please populate the following three variables:

  • Company 
  • Win32App 
  • ScriptToRun

Once done, if your Win32App uses any sort of interaction with the end user, and as this app is deployed in SYSTEM context, you might need to use ServiceUI.exe from the MDT Toolkit. If you need that interaction, copy the x64 version of ServiceUI.exe from the MDT toolkit and place it in this folder.

If you will not be interacting in SYSTEM context with the end user in your app, then remove the reference to ServiceUI in the following section of the batch script.

In the sample.ps1 PowerShell script, you can also modify the following variables: 

  • Company 
  • AppTitle 

2. Implement it in Intune

Now that you’ve got the sample template, you can test it straight away in Intune. 

Get the Microsoft Win32 content prep tool. Download the Win32 content prep tool from here. Copy the IntuneWinAppUtil.exe file to your Win32 apps root folder, it should look like this. 

Open a command prompt and browse to the Sample Win32Afolder structure. Launch the IntuneWinAppUtil.exe file and answer the following. 

  • Please specify the source folder: win32app_source 
  • Please specify the setup file: sample.ps1 
  • Please specify the output folder: win32app_target 
  • Do you want to specify catalog folder (Y/N)? n

Example shown here.

3. Add the Sample Win32 app to Intune

Log into Intune and add a new Win32 App. Below are some screenshots showing how we've configured the app. 

For Select app type, select Windows app (Win32) from the drop-down menu 

 

Click on Select app package file and point it to the sample.intunewin file in the win32app_target folder, fill in some info about the app

 

Fill in the install commands, point it to install_script.cmd 

Fill in the requirements.

For detection rules point it to the detection script in the root of the Sample - Intune files

Skip past dependencies and Supersedence for this test, and deploy it as Available for testing to an Entra ID group that contains the computers that are targeted for this test. 

 

4. Test the app on a device

On a test device, open Company Portal and look for the Adaptiva Sample App. 

 

Click Install. 

 

And after a while it’s installed. This sample app doesn’t really do anything it’s just used to prove how this process works. 

 

Reviewing the results 

Now that the app is installed, let’s look at how the installation folder and files look. In Windows File Explorer, browse to C: and unhide hidden folders.

Once done, browse to the C:\ProgramData\Adaptiva folder 

In there you’ll see the sample Win32 App folder. 

 

Browsing that, you can see the installation detection method file and log file! 

 

Opening the log file reveals details of the app. 

 

Well that’s it for this MVP blog post, please join us in the next Expert Series blog and let us know if there is anything you’d like to learn about next! 

We will also be at the TunedIn: Leeds event on June 21, 2024. Come and network with other IT professionals and learn from the best in the industry. With sessions covering Intune, Windows 365, and more. 

Cheers 

Niall & Paul 

About the Authors:  

Niall Brady has been awarded the title of Microsoft MVP 13 times in a row, and is now a dual MVP, both in Security (formally Enterprise Mobility) and Windows and Devices for IT. He works for a global company doing device management, specializing in Intune, Windows Autopilot, SCCM, OSD, PowerShell and creating innovative solutions. He blogs at https://www.windows-noob.com and https://www.niallbrady.com Connect with Niall on LinkedIn. 

Paul Winstanley is Director of SCCM solutions, an IT Consultancy delivering SCCM/Intune endpoint advice and implementations to the public and private sector. Paul is also a Microsoft MVP in Enterprise Mobility and an expert in SCCM/Configuration Manager architecture, design, implementation, and troubleshooting. Connect with Paul on LinkedIn.