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.....
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.
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.
Now the cmdlet is Add-CMDeploymentType :
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.
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.
Now the collection is created let's deploy the Application to this Collection's member.
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.
After all done let's run the Summary of the Deployment:
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:
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
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: