View ConfigMgr Application Deployment Requirements Using PowerShell

Do you have a ConfigMgr application deployment type with several requirements? Do you have to keep them documented? I do. They are constantly changing on a few of our applications to ensure we don’t install an application on a machine that will negatively impact that endpoint. At first, I was taking screen captures and pasting them into a webpage, but that got old really quick.

List of Application Deployment Type Requirements – The PowerShell Way

PowerShell is my go-to tool for pretty much everything, so I took a few minutes to find the ConfigMgr PowerShell cmdlets for getting the application deployment type, then I pulled out the requirements.

If you’re just looking for the code and an example, here you go:

$AppName = "Recast - Test-App" 
$AppDTName = "Recast - Test-App AppDT" 
$AppDT = Get-CMDeploymentType -ApplicationName $AppName -DeploymentTypeName $AppDTName 
 
[XML]$AppDTXML = $AppDT.SDMPackageXML 
$AppDTXMLType = $AppDTXML.AppMgmtDigest.DeploymentType | Where-Object {$_.title.'#text' -eq $AppDTName} 
$AppDTXMLType.Requirements.rule.annotation.displayname

How It Works

Now, if you want to know how it works, we can backwards engineer it.

First, I record the name of the application and then the deployment type into variables. In my example, the application is called “Recast – Test-App” and the deployment type is called “Recast – Test-App AppDT”. With a single deployment type, you could actually simplify the code a bit. I was working with apps with multiple deployment types, but only cared about one of them. This could be easily changed to generate the requirements on all deployment types for an application. If you’re trying to do that, and run into a snag, hit me up @gwblok and I’ll lend you a hand, or update this post.

Once you know the App Name and AppDT Name, you can pull that ConfigMgr data via PowerShell into a variable:

$AppDT = Get-CMDeploymentType -ApplicationName $AppName -DeploymentTypeName $AppDTName

So what is in $AppDT? There are several methods (which I won’t get into) and properties which store the data. Using Get-Member and limiting it to properties gives you a list:

If you want to see the data behind it, just run the variable:

Most of the Application DT information is in the XML, including a ton we don’t want, so I need to have PowerShell pull only the part I want. In order to make that data useful to PowerShell, I cast that property as XML and place it in a variable.

[XML]$AppDTXML = $AppDT.SDMPackageXML

It doesn’t look like much, but now we can start to dig down into it.

Digging In

By digging in, we see that there is only one deployment type on the app. For some reason, if there is more than one AppDT, it will list all of them here even though you told the command which AppDT to use. This is why I then have this line to pull out of the XML for only the AppDT we care about:

$AppDTXMLType = $AppDTXML.AppMgmtDigest.DeploymentType | Where-Object {$_.title.'#text' -eq $AppDTName}

That code will place in the variable $AppDTXMLType the AppDT info from the AppDT that matches the name we told it about in the start. The rest of it will be discarded. Now that I have only the AppDT we care about, we can delve deeper.

I’ll show you by digging down layer by layer:

First, I will examine the Requirement Rules. Now there are several, so I selected just two. This gives me enough info about how to dig deeper, while keeping the screen clean for capturing this image.

After that, I delve into Annotation, which gives me Displayname and Description, so I dig into Displayname, and that provided the info I wanted.

We have nearly 20 requirements on our M365 application due to so many compatibility conflicts. If we upgraded the app, we would break currently installed add-ins, so the requirements prevent them from installing and breaking an important business function. To see more about how I’ve deployed M365, check out my M365 blog series.

From here, I can copy and paste or leverage another API to upload into the correct place. For us, it is Confluence.

I hope this also helps show how you can you leverage PowerShell to find nearly any information about an application deployment type in ConfigMgr to use for automation.