Test Low Disk Space / Create Large Test File

So I stole this code from my friend Keith G, who provided it to assist with testing scenarios to see if our safe guards would work.
Basically, the 1 line command will check your drive, then create a dynamically sized file to leave “XX” GB remaining.  In my command, I leave only 15GB Free, which is low enough to trigger a failure on our in place upgrades.  Then I can test to make sure the the IPU TS fails the way I expect, running the proper remediation steps, and records the metrics for reporting.

Code: (run in elevated PowerShell Console)

So I made it into an App, I’ve added a few items into the app model to allow me to “install” it quickly on a machine to test failure scenarios.

App Code:

Read more

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 ninite.com’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. Read more

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 (DellCommandPowerShellProvider1.3_259.zip)

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: https://www.ronnipedersen.com/wmi-query/

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:https://technet.microsoft.com/en-us/itpro/windows/manage/appv-release-notes-for-appv-for-windows

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 - https://technet.microsoft.com/en-us/itpro/windows/manage/appv-enable-the-app-v-desktop-client

  • 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: http://ccmexec.com/2016/08/using-windows-10-build-numbers-as-global-condition-in-configmgr/


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.