Skip to main content

PowerShell + SCCM 2012 R2 : Create an Application (from MSI) & Deploy it

This is one of the many posts to follow on my experiments with the new Application Model introduced in Configuration Manager 2012.

In this post will use PowerShell to create a new application, deployment type (from a MSI) and then finally deploy it to a machine. So without further delay.....

Let's get to it 

Create the Application using New-CMApplication cmdlet:


New-CMApplication -Name "Quest Active Roles Managment Shell for AD" -Description "Quest Snapin for AD Admins (64-bit only)" -SoftwareVersion "1.51" -AutoInstall $true

The above will create a Application Object in ConfigMgr which can be used in Task Sequences as well (-AutoInstall $true ). Now let's open the Console and have a peek at the properties of the Application created.




The Set-CMApplication Cmdlet can also be used to set property on the Application Object later. 


Let's create a new App Category and then add the above application to it.


New-CMCategory -CategoryType AppCategories -Name "ADAdministration" -Verbose


Set-CMApplication -Name "Quest Active Roles Managment Shell for AD"  -LocalizedApplicationName "Quest AD Snapin"  -LocalizedApplicationDescription "PowerShell Snapin to be used by AD Admins" -AppCategories "ADAdmins" -SendToProtectedDistributionPoint $true -Verbose

Note the Localized Display Name & Description appears in the Software Center/ Catalog.
Wait ! When you try to run the second cmdlet you would encounter an error
if on the console you have properties opened :




This is by design as Application is one of the globally replicated Objects and before someone tries to edit it they need to request lock on the Object.
Read more about SEDO here and want to know how to request SEDO Locks using PowerShell then go to MVP Kaido's post here

Close the open properties of the Application if any and then try again and the second cmdlet will work.

As a mental note will try to look more into SEDO Locks later.


Create the DeploymentType (Auto from MSI File)

Once the application is created we need to create the Deployment type for it . Note in CM 2012 there can be multiple deployment types targeting various devices but here we will take a look at the default one that gets created when we specify a MSI file.

Now the cmdlet is Add-CMDeploymentType :


Add-CMDeploymentType -ApplicationName "Quest Active Roles Managment Shell for AD" -InstallationFileLocation "\\dexsccm\Packages\QuestADSnapin\Quest_ActiveRolesManagementShellforActiveDirectoryx64_151.msi" -MsiInstaller -AutoIdentifyFromInstallationFile -ForceForUnknownPublisher $true -InstallationBehaviorType InstallForSystem



Note the use of parameter -AutoIdentifyFromInstallationFile and -ForceForUnkownPublisher $True here. These parameters corresponds to what one would normally do when using GUI to create the Application (default way of creating Apps).

This will create the Deployment type with appropriate configuration and if you want to change something later take a look at the Set-CMDeploymentType cmdlet.


Distribute the Content 

Before we start deploying the Application to the Devices, we need to distribute the package to the DP or DP Group. The cmdlet here is Start-CMContentDistribution

Start-CMContentDistribution -ApplicationName "Quest Active Roles Managment Shell for AD" -DistributionPointGroupName "Dex LAB DP group" -Verbose

Now once the Content is Distributed then we can go ahead and deploy the Application.

Create a Collection for the Application and Deploy the Application to it

As a standard practice, I will create a Device Collection by the name of the Application and add members to it where the Application ultimately gets deployed to.

Create the Device Collection to refresh every day at the moment when it is created (that is what New-CMSchedule cmdlet does)

New-CMDeviceCollection -Name "Quest Active Roles Managment Shell for AD" -Comment "All the Machines where Quest AD Snapin is sent to" -LimitingCollectionName "All Systems"  -RefreshType Periodic -RefreshSchedule (New-CMSchedule -Start (get-date) -RecurInterval Days -RecurCount 7) -Verbose



Now Add the machine name to the Collection in a Query MemberShip Rule or Direct MemberShip Rule. For this just using Direct membership rule for now. In the upcoming post will go with Query Membership Rule.


Add-CMDeviceCollectionDirectMembershipRule -CollectionName "Quest Active Roles Managment Shell for AD"  -Resource (Get-CMDevice -Name "DexterDC") -Verbose



Now the collection is created let's deploy the Application to this Collection's member.


Start-CMApplicationDeployment -CollectionName "Quest Active Roles Managment Shell for AD" -Name "Quest Active Roles Managment Shell for AD" -DeployAction Install -DeployPurpose Available -UserNotification DisplayAll -AvaliableDate (get-date) -AvaliableTime (get-date) -TimeBaseOn LocalTime  -Verbose

Done.

Now we can refresh the Machine Policy on the Members of the Collection by using the old WMI way of connecting to the Client machine through WMI and calling the triggerSchedule method or use Client Notification (which is a great new feature) which will ensure that the Application reaches end machine quickly.


Invoke-CMClientNotification -DeviceCollectionName "Quest Active Roles Managment Shell for AD" -NotificationType RequestMachinePolicyNow -Verbose

After all done let's run the Summary of the Deployment:


Invoke-CMDeploymentSummarization -CollectionName "Quest Active Roles Managment Shell for AD" -Verbose

After this we can see the results in the summary of the Deployment:



And the Application does shows up on the end Machine:




Creating various types of Applications & Packages (Classic ones) are the next in my post list.

Below is the consolidated Gist:

Popular posts from this blog

Test connectivity via a specific network interface

Recently while working on a Private cloud implementation, I came across a scenario where I needed to test connectivity of a node to the AD/DNS via multiple network adapters.  Many of us would know that having multiple network routes is usually done to take care of redundancy. So that if a network adapter goes down, one can use the other network interface to reach out to the node. In order to make it easy for everyone to follow along, below is an analogy for the above scenario: My laptop has multiple network adapters (say Wi-Fi and Ethernet) connected to the same network. Now how do I test connectivity to a Server on the network only over say Wi-Fi network adapter?

PowerShell + SCCM : Run CM cmdlets remotely

Today I saw a tweet about using implicit remoting to load the Configuration Manager on my machine by Justin Mathews . It caught my eye as I have never really tried it, but theoretically it can be done. Note - The second tweet says "Cannot find a provider with the name CMSite", resolution to which is in the Troubleshooting section at the end.

PowerShell : Trust network share to load modules & ps1

Problem Do you have a central network share, where you store all the scripts or PowerShell modules ? What happens if you try to run the script from a network share ? or if you have scripts (local) which invoke scripts or import PowerShell modules stored on this network share ? Well you would see a security warning like below (Note - I have set execution policy as 'Unrestricted' not 'bypass' here): Run a .ps1 from the network share Well this is a similar warning, which you get when you download scripts from Internet. As the message says run Unblock-File cmdlet to unblock the script and then run it, let's try it.