AutoPackager V3: Winget to Intune Automation

AutoPackager v3: Winget to Intune Automation

Purpose:

To assist others in reducing toil in packaging and deploying applications in Intune that are available within Winget. To allow them to take advantage of the code provided and inspire new functionality and features. This is made available without warranty or support. Use at own risk.

Problem:

Packaging applications within Intune and keeping them regularly updated can take a significant amount of time, especially if you host a large software catalog. I wanted to create a workflow that would assist, standardize, and automate this process as much as possible while keeping to native Intune application deployment mechanisms.  There are others that have tried to do Winget integrations, but I feel this one allows for the greatest customization and work within the Intune deployment processes best.

Solution:

I created several PowerShell scripts that when ran together simplify and automate many of the tasks needed to keep an application catalog up to date with minimal effort. Currently these scripts can only help automate what is in the Winget repository database. It works by creating recipe files for each of the applications you wish to import into your application catalog.

Prerequisites:

1.      Create a Microsoft Entra App Registration

a.      Give the API permissions DeviceManagementApps.ReadWrite.All and DeviceManagementConfiguration.ReadWrite.All for Application type.

                                                              i.      Grant Admin Consent for these new permissions.

b.      Create a new Client secret

                                                              i.      Ensure you keep track of the Secret ID and the Value as these will be needed later.

2.      Create a GitHub PAT Token (will be needed or you will hit api limits with GitHub when running AutoPackager)

3.      Download all AutoPackager V3 files from my GitHub

a.      Read the Readme and SystemConfigReadMe.txt

b.      Update AutoPackager.config.json

                                                              i.      Required areas to update are the AzureAuth section and GitHubToken

1.      AzureAuth should work with CertificateThumbprint but I have only used and tested Client Secret.

                                                            ii.      Remember: This is a json file. If you are adding network paths, you have to double the \ in your path.  Example: \\\\server.server.com\\share name\\folder name

c.      Launch AutoPackager.GUI.ps1 and run the Prerequisite checker (Install any modules or fix any issues it finds)

4.      Setup Automation

a.      Scheduled task on a workstation or server that will run Autopackager and read the recipes nightly.

5.      Automation Account

a.      Create a local windows account or domain service account that can be used as the account for the scheduled task.  System may work too, but if you do not choose a domain account you will not be able to archive to a network folder (setup in the autopackager.config.json file.

How it works:

Searching Winget and testing installer

After completing all prerequisites, it is best to start with AutoPackager.GUI.ps1. On the Winget tab the GUI allows you to search the Winget repository for the application you want to automate. Once found, you can show the Winget application YAML file for the latest installer URLs and the types of installers available (x64, x86, arm, exe, msi, etc.). Once you determine what installer you want to use update the Winget tab further with the installer type wanted and click download installer.  This will allow you to test the installer manually and figure out what switches and options are needed to make it a silent install.  Be sure to keep track of these switches as they will be needed later in the recipe section. For silent uninstall, it is recommended to look in the registry for the Uninstall string of the newly installed application under the following locations;

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\

HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\.

Once the uninstall string is found test different switches to determine how to make it uninstall silently and record for the recipe step later. Remember only the switches will be needed for the Recipe section later.

Create stub Intune applications

On the Intune App(s) tab you will need to create two Intune applications. Ensure you pick your icon prior to creating the applications. The icon is what will be used in Company Portal. The Primary application will be for what is made available or as a required application to your user population. The other Required Update application will have a suffix of – Required Update and will be used in the future to keep any devices with a previous version updated. These two buttons will only create a stub record and will not deploy to anything.

Create your Recipe

On the Recipe tab, fill in all the information you can from your testing and the application stubs. There is a lot of options on this page, please refer to the help tab if you have questions on them. If you followed the process up to this point you should have the Winget ID, PrimaryAppId, Required Update AppId, Architecture, Installer Type, Installer Scope (Should always be machine), InstallArgs, and UninstallArgs filled in at this point. InstallArgs and UninstallArgs are just the switches you found earlier in your testing. DO NOT give full paths to the exe/msi or the full uninstall string found in the registry. ONLY the switches. If you know other areas, you can update them as well. Once complete click Create New Recipe, and it will create it in the Recipe location stored in the autopackager.config.json file. You will update the recipe further as the process continues.

Run AutoPackager in Package Only and Full Run modes

On the Run tab you should see two modes. Ensure Package Only mode is selected and ensure your recipe file is in the target box then click Run AutoPackager. This will do all the automated functions to package up and do all the steps except for uploading to Intune. Once Package Only mode is ran, you will find all of the output files and scripts in the Working folder. From there you will be able to test the install.ps1 and uninstall.ps1 scripts.  You will also need to test and ensure that the Requirement and Detection scripts respond with TRUE when the application is installed. The scripts also log to C:\ProgramData\Microsoft\IntuneManagementExtension\Logs so you can validate. If all scripts work and report back properly it is time to Run in Full Run mode.  This will upload all the files and scripts to the application stubs created earlier.

Test deployment with Intune

Find your new application in Intune and assign some test groups.  Validate the install and uninstall work properly. If something doesn’t work and the recipe needs to be updated and tested again you will need reset the stub applications before updating the recipe and testing again.  To Reset the applications back to original stub states then go the to Reset tab and ensure the correct Primary AppId and Required Update AppId are populated and then click the Reset buttons.

Finalize Recipe

Once you have your recipe file set the way you want, and your deployment ring groups set for the required updates then it is time to move the recipe to your automation server.

Automation

Once AutoPackager is configured on your local machine and verified that things are working with a single recipe, it is best to copy your local directory to an automation machine (Windows Server or another Windows workstation). You will want to create a scheduled task to run everything. 

Task Scheduler Setup

1.      General tab

a.      Select your account

b.      Run whether user is logged on or not

c.      Run with highest privileges

2.      Triggers tab

a.      Begin on a schedule

b.      Daily (Pick your time)

c.      Enabled (checked)

3.      Actions tab

a.      Start a program

b.      Program/Script: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe

c.      Add arguments: -NoProfile -executionpolicy bypass -file ".\autopackagerv2.ps1" -fullrun -allrecipes

d.      Start in: (Directory you copied the AutoPackager files)

Closing:

I hope this helps others. I will most likely keep developing this to be more feature rich and will update my GitHub page as new updates are made.  I will not be active in my responses but feel free to leave comments if you wish.  I do check them occasionally and will respond as time allows. If you take this code and develop it further, please leave a comment on where you make it available and what updates you made.  I would be interested to see where this can go.

Modern Driver Management - Task Sequence

Modern Driver Management – Task Sequence

Problem

I wanted to update my drivers only once and have it update all my task sequences that use drivers.  Usually each of my task sequences for operating system deployments or operating system upgrades had their own driver sets in the sequences.

Solution

I created was a new task sequence that would hold all the drivers for all our known hardware models.  This TS would be called from our deployment or upgrade task sequences.  This sequence will utilize a TS variable to identify if the hardware model is known or not and Download Package Content tasks. You will need a separate Driver Package or Package with the driver files for each hardware model.  You will also need an “empty” Driver Package or Package so the OS Deployment and OS Upgrade sequences can work correctly.  In your empty package you will need to place something in it as it will not want to replicate unless it has something in it.  Either a small text file if you made a package or a small driver if it is a Driver Package.  Keep reading to see how this works. 

Inspiration

The below link seemed like it made this a lot harder to implement.  I did not try it so I cannot speak to the difficulty, but it was a lot of info. https://deploymentresearch.com/configmgr-driver-management-in-just-four-steps-by-matthew-teegarden/

Process

Create the new driver task sequence

1.      Create two task sequence variable tasks called OSDKnownModels

a.      The first TS variable should have a value of NO

b.      The second TS variable should have a value of YES and Options tab should have WMI queries

2.      The Known PC Model Upgrades group should have a condition of TS Variable OSDKnownModels = YES

3.      Each Driver model needs to be setup as a Download Package Content task along with a wmi condition for the driver model under the Known PC Model Group.  It also needs to have the following options selected

a.      Place into the following location: Task sequence working directory

b.      Check – Save path as a variable: Driver Pack

4.      Unknown PC Models group needs to have a TS Variable condition of OSDKnownModels = NO

5.      Place your Unknown Model driver package or package in the Unknown PC Models group.  This package does not need to have any conditions.  It also needs to have the following options selected

a.      Place into the following location: Task sequence working directory

b.      Check – Save path as a variable: Driver Pack

Operating System Upgrade Task Sequence

1.      Your OS Upgrade Task needs to have two tasks to work successfully.

2.      Create a new Run Task Sequence task and browse to your Model Drivers Task Sequence

3.      Create a new Upgrade Operating System task

a.      Select your Upgrade Package and Edition

b.      Check – Provide the following driver content to Windows Setup during upgrade

                                                    i.     Select Staged content: type %DriverPack01%

1.      DriverPack is the variable from the driver TS but 01 is because the driver was the 1^st package in the Download Package Content task.

Operating System Deployment Task Sequence

1.      After the Apply Operating System Task and while still in Windows PE add a new task

2.      Create a Run Task Sequence task and browse to the Drivers Task Sequence you created above

3.      Create a Run Command Line task to inject the drivers into the Windows Install

a.      Command line should be: DISM.exe /Image:%OSDISK%\ /Add-Driver /Driver:%DriverPack01%\ /Recurse

b.      %OSDISK% is the variable we use in our Format tasks as well as Apply Operating System tasks

c.      %DriverPack01% is the variable that is created from the Driver Task Sequence

Conclusion

Please ask if there are any questions.  I will try to answer as time permits.

Windows 10: Customize and Deploy Start Menu

Windows 10: Customize Default Start Menu

Purpose

To help others in creating a default start menu layout that can then be deployed via imaging solution.

Table of Contents

Purpose. 1

Scope. 1

Procedure. 1

Create Start Menu Modifications. 1

Export Start Menu Layout 1

Apply Start Menu Layout 1

There are two options to apply the change. 1

Option 1 (Microsoft Articles) 1

Option 2. 2

Deployment 2

 

Scope

Customize Start Menu for deployment

Procedure

Create Start Menu Modifications      

1.       Update Grouping Lables, Pinning or UnPinning applications, and reorder any Pinned applications to create your custom start menu.

Export Start Menu Layout

1.       Once your modifications are complete open powershell

2.       From Powershell run

a.       Export-StartLayout –path <path you have access to>\CustomLayout.xml

                                                               i.      ***Ensure the path exists before you start or the export will fail

Apply Start Menu Layout

There are two options to apply the change

Option 1 (Microsoft Articles)

1.       Launch Powershell as Administrator

a.       Run “Import-StartLayout –layoutpath <path you saved the xml>\CustomLayout.xml –MountPath C:\”

b.      All New Profiles created on the system will have the new Start Menu layout and users will still be able to customize it.

Option 2

1.       Rename CustomLayout.xml to LayoutModification.xml and copy to C:\Users\Default\AppData\Local\Microsoft\Windows\Shell

a.       All New Profiles created on the system will have the new Start Menu layout and users will still be able to customize it.

Deployment

1.       You can deploy this by creating a script to copy the xml file or run the import-startlayout command during a task sequcne step within MDT or ConfigMgr or Caputre a new .WIM for deployment as part of your base image.  You could probably also deploy the customization as a group policy preference. 

PeopleSoft Journal Import MSXML fix

PeopleSoft Journal Import MSXML fix

Problem

The Macro distributed by PeopleSoft for Journal Import fails to work on Windows Vista, 7, and 8/8.1.  With Windows 7 and Vista the solution was simple.  Copy the MSXML.dll file from the C:\Windows\System32 folder from a Windows XP machine and place it in the C:\Windows\System32 and/or C:\Windows\SysWOW folder on the Vista/7 machine.  This may have also worked on Windows 8/8.1 x86 but it does not work on Windows 8/8.1 x64.  For 8/8.1 there are a few modifications to the JRNLMCRO.xla file that are needed. (this was done for Windows 8/8.1 running Excel 2013)

Solution

You have to modify the JRNLMCRO.xla file to include the Microsoft XML v6.0 dll and also modify two lines within the macro code.

Prerequisites

1.       Temporarily Trust Macros in Excel

2.       Ensure the Developer Tab is enabled in Excel

a.       File -> Options -> Customize Ribbon -> (Check) Developer Tab

Process

Open JRNLMCRO.xla

1.       Click Developer Tab

a.       Click Visual Basic

                                                               i.      Highlight Jrnlmcro from the Tree view

                                                             ii.      Click Tools Menu

1.       Click References

a.       Find and check Microsoft XML, v6.0 from the Available References list

b.      Click OK

                                                           iii.      Expand Modules from the Tree view

                                                           iv.      Double Click mImportControl

1.       Within the Code window for mImportControl search for MSXML2.DOMDocument

2.       Replace the two instances of MSXML2.DOMDocument with MSXML2.DOMDocument60

                                                             v.      Save the macro, exit Excel and try to run your Journal Import normally.

ConfigMgr: Install Fonts as an Application without Local Admin

ConfigMgr: Install Fonts as an Application without Local Admin

Purpose

To document a process on how to utilize a software delivery system like ConfigMgr to install Fonts so users do not need local admin rights.

Table of Contents

Purpose. 1

Scope. 1

Summary. 1

Prerequisites. 1

Script Modification before ConfigMgr Setup. 1

ConfigMgr Application Setup. 2

 

Scope

To help other Admins limit user rights on machines deployed

Summary

Download DetectionMethod.zip and FontsInstall.zip from the Prerequisite area and follow the steps below. These scripts are written in PowerShell so PowerShell is a requirement.  After the application is run you can check your results by looking at the log file that is created at c:\temp\fontinstall.log.  The DetectionMethod.ps1 can be modified to have a different timespan which is how it determines if it can run again.  It is currently set to 5 minutes.

 

Prerequisites

DetectionMethod.zip

FontsInstall.zip

PowerShell

Script Modification before ConfigMgr Setup

1.       Create a new source folder for the scripts in the prerequisites section, download and extract the scripts

2.       Edit FontsInstall.ps1

a.       $FromPath needs to be updated in FontInstall.ps1 script to be the path your users will save the fonts to.  The script will pick the fonts up in this location and install them into c:\windows\fonts.  By default I have $FromPath set to c:\Fonts

Detection Method script needs to be updated to the directory you specify the log file to be written in the FontInstall.ps1 script

ConfigMgr Application Setup

1.       Open ConfigMgr Console and navigate to \ à Software Library àOverview à Application Management àApplications

a.       Right Click Applications and select Create Application

                                                               i.      General

1.       Manually specify the application information

2.       Click Next

                                                             ii.      General Information

1.       Fill out as necessary

2.       Click Next

                                                            iii.      Application Catalog

1.       Fill out as necessary

2.       Click Next

                                                           iv.      Deployment Types

1.       Click Add

a.       General

                                                                                                                                       i.      Type: Script Installer

                                                                                                                                     ii.      Manually specify the deployent type information

                                                                                                                                    iii.      Click Next

b.      General Information

                                                                                                                                       i.      Fill out as necessary

                                                                                                                                     ii.      Click Next

c.       Content

                                                                                                                                       i.      Content Location: <UNC PATH> of the FontsInstall.ps1 file

                                                                                                                                     ii.      Installation Program: Powershell.exe -executionpolicy bypass -file FontsInstall.ps1

                                                                                                                                    iii.      Click Next

d.      Detection Method

                                                                                                                                       i.      Click Use a custom script to detect…

                                                                                                                                     ii.      Click Edit

1.       Script Editor

a.       Script Type: PowerShell

b.      Click Open

                                                                                                                                                                                                               i.      Browse to where you saved DetectionMethod.ps1

                                                                                                                                                                                                             ii.      Click Open

c.       Click OK

                                                                                                                                    iii.      Click Next

e.      User Experience

                                                                                                                                       i.      Install for System

                                                                                                                                     ii.      Whether or not a user is logged in

                                                                                                                                    iii.      Click Next

f.        Requirements

                                                                                                                                       i.      Click Next

g.       Dependencies

                                                                                                                                       i.      Click Next

h.      Summary

                                                                                                                                       i.      Click Next

i.         Completion

                                                                                                                                       i.      Click Close

2.       Click Next

                                                             v.      Summary

1.       Click Next

                                                           vi.      Completion

1.       Click Close

b.      Distribute the Content

c.       Deploy the Application