ConfigMgr Lab - Adding Ninite Apps

So you have a Personal ConfigMgr lab, but you want to add some app deployments to better simulate your actual environment.  So you add Chrome, Reader, and a couple others (NOT JAVA).  Next Month, they are out of date.  You probably don’t have time to keep your personal lab app deployments updated, so you keep deploying old versions.  How about, you leverage’s ability to dynamically install the latest version of the app every time?  Now you're asking, "Isn't the command line version that supports silent install cost money?"  Yes, yes, it does, to use ninite’s silent install, you need the Pro version.  What, you don't want to pay for pro when it’s your personal lab?  I hear you.  Powershell to the rescue!  It doesn’t make it completely silent, but it will allow you to automate it to work with the ConfigMgr App Model during OSD and Post OSD.

If you're not familiar with, it's pretty awesome.  I've been using it for years, when I get a new computer, or just want to make sure my apps are updated.  Also use it to help setup how many friend's and family's computers. Basically, you go to the website, you check the box next to the app(s) you want, and click "Get your Ninite".  Then run the small stub installer file.  Awesome right?  They figured out all of the command lines. They keep the apps updated. They make it so easy.

Please remember, this is for your personal lab, if it is for anything other than personal use, you’d have to get the Pro version.  With the Pro version, you don't need my work around.

Basically my solution is a powershell wrapper that downloads the ninite stub installer,  runs the installer, waits for it to finish, then kills the installer dialog box.  Why would you want to do this?  Automation, being able to leverage Ninite's Free Personal installers in the context of a Task Sequence or App Model deployment in your Personal ConfigMgr Home Lab.

The Script does this:

  1. You choose the App you want to install from the predefined list built into the script
  2. The script then Downloads the Ninite.exe stub file from
  3. Then launches the Ninite Installer.exe stub file which downloads the actual app installer and launches
  4. Waits for either MSIEXEC.EXE or TARGET.EXE Subprocess of Ninite.exe to start.
  5. Monitors the SubProcess (MSIEXEC.EXE or TARGET.EXE)
  6. Once SubProcess (software install) completes and goes away, Sends “Stop-Process” signal to stop all Ninite.EXE processes
  7. Deletes the file it downloaded
  8. DONE.

In Software Center (Application Model Deployment).  It will Launch the installer, the ninite dialog box will be visible until it is complete. (See video below for demo


In the TS, you can add the Applications like any other.  During at TS, the installers are not visible. (See video below for demo)


Content: One PowerShell Script

Same Command Line Install for each, just change it to match the software.

Detection Method (File Only) - I don't use version number, as it's constantly changing.  If you want to rerun the app, uninstall it first, then rerun to get the updated version.  However, assuming this was a lab, I made the assumption the machines you're installing apps on, probably won't "live" for long before blown away or reloaded.

PS Code



See it in Action

Video (Task Sequence)

Video (Software Center)

Watch the Script in Action:

If you'd like to add other Ninite App options into the script, feel free.  I've found not all of them use the target.exe or msiexec.exe sub processes, so you'd have to account for that (Examples are .Net 4.7.1 and Paint.Net, for my lab, I pulled those out and made separate app scripts).

More info: Terms: "The free version of Ninite is only licensed for home use and as a trial for Ninite Pro. If you get paid for running Ninite (like in an IT department, PC shop, managed service provider, school, non-volunteer helpdesk, etc.) you must upgrade to Ninite Pro. "


Dell PowerShell Provider Install w/ ConfigMgr

I just created an App for the Dell PowerShell Provider 1.3.0, was able to learn what I needed from Mike’s Blog (THANK YOU). I thought I’d add a cmd file install for 1.3.0 and do a more graphical walk through (I’m a visual guy).

To get the download, go HERE (

Download, grab the DellBIOSProvider folder

Copy that to your Source (\\CMSRC\SRC$\Apps\Dell\DellPowerShellProvider\1.3.0\x64)

Install: "Load_DellPowerShellProviders-x64.cmd"

Uninstall: cmd.exe /c rd "%programfiles%\WindowsPowerShell\Modules\DellBIOSProvider" /S /Q


Detection Method:
File Path: %PROGRAMFILES%\WindowsPowerShell\Modules\DellBIOSProvider
File Name: DellBIOSProvider.dll

Requirements: (x64 & Dell) – See previous post on creating Dell Requirement

Once Installed, you can test by launching PowerShell and loading the Module

import-module DellBIOSProvider


I highly recommend reading Mike’s Blog Post from last year when he blogged the install of version 1.1, he goes into additional detail and background.

Manufacturer Global Condition for App Model

Hey, so I recently created apps for Dell’s updated PowerShell Provider & Command Monitor & BIOS updates.  I only want Dell Machines to see them in the software center, and if they are x64, so global conditions is the answer.

I’m not going to recreate the wheel here, there are several good posts on how to create global conditions, like SCConfigMgr’s for creating on for x64 systems.

I’ve created ones for Model, when using Dell Bios, as I describe in detail HERE.

So for Manufacturer

  1. Creating the condition, open the ConfigMgr. administrator console, select Software Library, Application Management, Global Conditions and click Create Global Condition from the ribbon.
  2. Create a condition with these settings:
    Name: Computer System Manufacturer
    Device type: Windows
    Condition type: Setting
    Setting Type: WQL query
    Name space: root\cimv2
    Class: win32_computersystem
    Property: Manufacturer


Then in the Applications:


Remember, you have to use “Contains”, which is similar to “like”, as when you look up the Manufacturer, it’s “Dell Inc.”, but I’ve also seen slightly different variants, but they all contain “Dell”, so that’s what I’m going with to make sure I don’t miss any.


For more ideas, look to Ronni’s blog:

AppV for Windows 10 1607–Update Packages / Enable in Windows

I’m going to cover two topics, both updating your old Packages to install without error on 1607, and how to enable AppV in 1607 with Powershell / AppModel Deployment.

We have a few AppV Packages that we use, when doing inplace upgrade from 1511 –> 1607, it automatically enables the new AppV that’s built into Windows, and the AppV Apps that were previously installed just work, that’s great!

However, when trying to deploy AppV Packages via ConfigMgr to newly installed 1607 clients, we’d get error:
Windows Installer packages (.msi files) generated by the App-V sequencer (version 5.1 and earlier) fail to install on computers with the in-box App-V client  Searching for that error led me to:

I also tried to run the MSI, which showed the error that the MSI couldn’t find AppV Client:


From that TechNet article, I tried to follow the directions to update the MSI for the workaround, but would get this error:

The process outlined worked, just that the script included in the Windows 10 ADK doesn’t.   It has some references to old file locations from older SDKs.  After minor modification to the Update-AppvMsiPackage.ps1 script, we were able to make it work. (Changes shown in Picture below)

You can download our Modified Script HERE – Thanks Mark (@Geodesicz)



When you install the ADK, it will install the Sequencer and add the PowerShell Script, that's the one you need to modify / replace.

Steps to upgrade package

  1. Open Elevated Powershell
  2. Import-Module “Update-AppvMsiPackage.ps1” (Use the modified version you created or downloaded)
  3. Update-AppvMsiPackage –msiPackage c:\folder\appvpackage.msi


Now when you deploy that package to a 1607 machine, it works!

AppV in 1607 -

  • AppV Status: Powershell: get-appvstatus
  • Enable: Powershell: Enable-AppV
  • Corresponding Registry Key:
    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AppV\Client  Enabled = 1

Deploy via Catalog (App Model)



Here’s how to make it:



I have two deployment types, one for the MSI installer & one to activate the built-in 1607
First one will run if build NOT equal 14393, and the second will run if 14393
Only covering the new 1607 method here



Content: You can just put anything, you can probably leave it blank.  I just have it pointed to my folder for the PowerShell Script and documentation.  Just so I remember where to find it.


Program: powershell.exe -Command Enable-Appv

Detection Method = the Registry key I talked about earlier



Requirements: Set to require build 14393 (1607) – You can add this Custom Global Condition by following this awesome guide:


You should now have the ability to use this Application model as a prereq for your AppV Package deployments.

Also, recommend updating your AppV 5.1 Client install to include the detection method for 1607’s.  Consider this Senario.  You have Several AppV Packages you deploy. You have the 5.1 AppV Client as a pre-req for your AppV Package Deployments.  On Windows pre-1607,  it will then install the 5.1 Client.  On Windows 1607, it will fail the install of the client, and not continue with the AppV Package deployment. However, if you already have AppV enabled on 1607 via GPO or OSD, etc, then you can just add the 1607 detection method to 5.1’s install, then when you deploy your AppV Package, it will see the pre-reqs are already installed if 1607, and continue on.



Found a post about an overview of the new AppV in 1607, along with Group Policy info:

Hope you find this useful, took me a day dealing with the incorrect PowerShell Script provided.

Deploy Paint.Net with ConfigMgr Application Model

Recently I’ve been working on Paint.Net, I used to install it using the .exe, however found that it would not install under the SYSTEM context.  It worked when users would install from the Catalog, but I was unable to push updated versions.

Today I was able to resolve the issue by using the /createMsi feature.
I liked using the .exe, as it was only 6MB and would install for both x86 and x64 machines, but if it doesn’t work in all senarios.  So now I’ve switched to using the MSI for consistency.

Offical Documenation:
- Requires .Net 4.6 or above. (with Paint.Net 4.0.9, as used in this example)
- Nice article on deploying .Net using ConfigMgr HERE. (Just replace 4.5.2 with latest version)

Once downloaded, create the MSI: (I have a script here I use that will create the MSI files, that doesn’t care about the downloaded exe name, and copy the MSI to the source)


REM Using FOR Loop to find any EXE file and run it with these arguments
for %%i in (*.exe) do cmd /c %%i /createMsi CHECKFORBETAS=0 DESKTOPSHORTCUT=0 CHECKFORUPDATES=0

REM Copy the 2 Newly created MSI Files to the Source Folder (Assuming you're running this script from the source folder)
xcopy %userprofile%\desktop\PaintDotNetMsi\* .\ /Y



  • /createMsi - Creates the MSI Files and places them on the desktop
  • CHECKFORBETAS=o – Disables checking for Beta Version in the Options
  • DESKTOPSHORTCUT=0 – Will not create a Desktop Shortcut for (Remove this part if you want the icon)
  • CHECKFORUPDATES=o – Disables checking for updates in the Options
  • More options at the Official Documenation link

Example showing use of the Script, which will create the 2 MSI files on the desktop, then I manually move.
Open Elevated Command Prompt, change directory to the Source, and run the CreateMSI_PaintNet.cmd, the Paint.Net installer box will open showing a status bar, and where it has created the MSI files once completed.


Click Finish for the script to Continue, it will then copy the two MSI Files to the Source Folder:

Now that you have your MSI files for deployment…

Create your ConfigMgr Application (I’m only deploying for x64, so I’ve only got 1 deployment type)

image image image image image image image 

Programs: msiexec /i "PaintDotNet_x64.msi"
Detection Method = MSI Info & Version
Requirements = x64

Now you can add an additional deployment for x86, follow the same steps, just change the requirements to x64 condition not exist (Buttom radio button)

Now, once the deployment is installed, there will be no desktop icon, and the boxes to check for updates will not be checked:


Thanks to everyone who develops this great free Photo Editor!