Take a look here:  https://support.microsoft.com/kb/2922875

You can download the eBook for free from here.

This post is all about something we use everyday, but probably don’t spend too much time managing or monitoring in our enterprise:  the Configuration Manager Client Cache!  This is an all up post, meaning I’ve got example code to make changes, and then we follow-up with inventory and reports to validate the settings in our environment.

First, an intro to the Configuration Manager client cache.  It’s used for a large number of Configuration Manager operations – by default, whenever a client needs to grab content for an action (think Application Management and Software Updates), the client will download to a temporary location.  This “download and execute” behavior is what gives us the ability to use BITS to move content to a client,  allows us to be clear of network requirements while running setup.exe, and allows clients to re-execute an application with out re-downloading any content. 

Let's get started in the lab.  We'll start with our script below  – in this case, we’re going to use the Configuration Manager COM object to interact with the Configuration Manager client.  I encourage everyone to poke around with this – much of the client automation work you’ll see in the SDK is geared around COM, so this is a great skill to add to your scripting repertoire if you are a Configuration Manager admin!

#Initialize our CCM COM Objects
 $CCM = New-Object -com UIResource.UIResourceMGR
 
 #USe GetCacheInfo method to return Cache properties
 $CCMCache = $CCM.GetCacheInfo()
 
 #Get the current cache location
 $CCMCacheDrive = $CCMCache.Location.Split("\")[0]
 
 #Check Free space on drive
 $Drive = Get-WMIObject -query "Select * from Win32_LogicalDisk where DeviceID = '$CCMCacheDrive'"
 
 #Convert freespace to GB for easier check
 $FreeSpace = $Drive.FreeSpace/1GB
 
 #Check Sizes and set Cache
 If ($Freespace -ge 5 -and $Freespace -lt 15)
 {
 #Free space moderate
 $CacheSize = 5120
 }
 If ($Freespace -ge 15)
 {
 #Plenty of space
 $CacheSize = 10240
 }
 
 #Set Cache Size
 $CCMCache.TotalSize = $CacheSize
 
 Write-Host (Get-WMIObject -namespace root\ccm\softmgmtAgent -class CacheConfig).Size
 

Here you’ll see a couple of things take place:

1. Initialize the ConfigMgr UI COM Object
2. Get the drive holding the current cache
3. Check the free space (notice, we tell it to divide by 1GB)
4. We determine the size of the cache and then set the new cache size
5. Finally, we check that the setting took by checking the cache size via the CacheConfig class in the CCM\SoftMgmtAgent namespace - more on this below.

Cool!  We’ve got a PowerShell script that will change the Configuration Manager client cache size without restarting the Configuration Manager client.  Where would this be useful?  We could send this out via package and program to set it once, maybe even with a recurring schedule.  I’m a huge fan of Compliance Settings within Configuration Manager, and this sounds like a perfect use case for Configuration Manager Compliance Settings!

Here, we’ll wrap this up in a Compliance Setting Configuration Item.  This Configuration Item will use a script to detect and set the state, then we’ll check the outcome of the script as our measure of compliance:

Great, now we’ve got a CI that will enforce client cache configurations, and since it’s a CI, we can set an easy recurrence pattern and get basic information back out of the script.

Now that we’re able to manage the cache on the client, we’ll probably want to be able to report on this configuration, so we’ll need to do a bit of work to make this happen.  We’ll be using Hardware Inventory to pull back the Configuration Manager Cache Configuration – in this case, we’ll need to use the nifty new MOF-free editor in System Center 2012 Configuration Manager to go grab the class we’re after.

Lets start by connecting to the appropriate namespace on a client – we’ll have to run the console as Admin (Right click, “Run As Administrator”).  We’ll navigate to root\ccm\SoftMgmtAgent namespace, then select the CacheConfig class:

While we’re modifying hardware inventory, a great attribute to add to an existing class is “Free Space” in the Logical Disk class.  This will be used later for the reports below.

Cool, now that we have hardware inventory reporting back, we should be able to build a few reports that reference the V_GS_CacheConfig.  I won’t go into too many details, as the reports are available below, but we’ll make use of our newly created inventory class to report on the current state of the client cache enterprise wide. 

If we click through each of the cache sizes, we can dig into a detailed view for each client in that state.  This could easily be adapted to a “I need to deploy a 10GB package – which clients can handle it?” type of report!

 All of the sample files are available here, via TechNet.  I debated splitting this into two posts, but I wanted to make sure the entire solution is available for folks, and the nice thing is you can choose to use all of the components (Script, reports, inventory changes) or the individual pieces (report/inventory info OR cache script).  Maybe you’ll use this as a starting point for your project, maybe you’ve had issues with a standardized client cache in the past – either way, let me know how you use this or any questions or comments below! 

Now, you may be asking yourself “Heath, client notification has been around for a while, why is it relevant now?”.  Great question!  This post comes straight from work I was doing with a customer this week where we were trying to take make clients evaluate policy in an automation scenario.  Sure, we have always been able to use WMI to start a machine policy polling cycle, but here’s the thing:  that method has always required us to have all of the ports open to each individual client device.  There was no throttling, no mechanism to track the status, and overall, it worked. But it was lacking.

Enter Fast Channel Notification and Client Notification.  I won’t jump into all the details, as the Configuration Manager Team blog has a great write up (Here), but the key takeaways are that client notification removes the need for huge network access and permissions on the remote box.  Instead, Configuration Manager Fast Notification (Client Notification) use either port 10231 or port 80 to notify clients that new Machine Policy, User Policy, or System Center Endpoint Protection actions need to be taken.

Another really cool, but unknown, feature of Client Notification is we maintain a current state for all clients in the hierarchy.  What does this mean to you?  Well, if we haven’t seen a client online in the past 20 minutes, we mark it as offline so we can definitively know the status of our PCs. So, as we are automating, we can intelligently handle clients that are offline.  That’s pretty cool!

Using Client Notification via the console is a pretty easy task, though overlooked by many folks I talk with.  We’d simply grab a collection of devices or a single device, right click, select Client Notification and then select Download Computer Policy:

One new feature you’ll see is that in R2, we also have the ability to notify a device that we want it to grab user policy.  This is pretty handy in workstation scenarios, as we push to user-centric software deployment, we may want to tell the PC to check for new apps deployed to that user.

So, let’s jump to R2 PowerShell lab and take a peek! One of the new features in PowerShell for R2 is the ability to interact with client operations, starting with the Invoke-ClientNotification cmdlet.  As usual, let’s start by getting help on the cmdlet in question:

Get-Help Invoke-CMClientNotification

Easy enough, looks like we really just need to specify two things:  (1) Which collection or device we want to notify and (2) the action we want to take.  In my lab, I’ve created a collection with one member, so we’ll use my “Client Notification Test” collection.  Let’s give it a try:

Invoke-CMClientNotification -NotificationType RequestMachinePolicyNow -DeviceCollection (Get-CMDeviceCollection -Name "Client Notification Test")

Awesome, with any luck, we should be able to watch for a couple of things to happen.  First, on the site server, we can watch BGBServer.log and we can see a new Client Notification request.  We could also watch for activity in the CCMClientNotification.log on clients.  On the server side, you’ll see traffic like this in BGBServer.log indicating the push was started:

Now, that is great – we’ve notified clients in a notification that they need to fetch policy and start doing stuff.  We can track it through the console in the Monitoring workspace, under “Client Operations”:

The console is great, but what happens if we are wanting to automate this?  We’ll need to use Powershell, and luckily the product team has made it easy for us with a Get-ClientOperations cmdlet.  We’ll start by getting help:

Get-Help Get-CMClientOperations

Looks like we don’t get a lot of options, but we’ll fix that up in a bit. 

For now, let’s just see what we get from Get-CMClientOperations: 

Get-CMClientOperations

Hmm.  Interesting, I pushed it to a collection with 5 clients, but I don’t see any client counts yet.  Why’s that?

Well, the data we pull from behind the scenes, SMS_ClientOperationStatus, isn’t real time.  The data we see above is from a summarized task that takes place.  So, we need to invoke the summarization task.  We do track the summarization status, and if you’ll notice above, LastSummaryTime is blank.  How can we summarize that data?  We can do it through the console, but lucky for us, there’s a new cmdlet that does it for us:  Invoke-CMClientOperationSummarization:

Invoke-CMClientOperationSummarization
 
Get-CMClientOperations
 

Ah, much better – I am seeing accurate statistics on my recent client operation:

Now, you’re probably saying – but Heath, in my automation example, I want to wait for all online clients notified before I take the next step and clean it up afterwards.  Let’s string together everything we’ve learned in this post into a nice bit of PowerShell to do exactly that!

 #Define the Collection we'll use for notification 
 $DeviceCollection = "Client Notification Test"
 
 #Invoke the Client Notification process against my designated collection 
 Invoke-CMClientNotification -NotificationType RequestMachinePolicyNow -DeviceCollection (Get-CMDeviceCollection -Name $DeviceCollection)
 
 #Summarize data, wait for summarization to complete, then get latest stats and wait some more. 
 Do 
 { 
 Invoke-CMClientOperationSummarization 
 Start-Sleep -seconds 30 
 $ClientOps = Get-CMClientOperations | where TargetCollectionName -eq $DeviceCollection 
 If ($ClientOps.CompletedClients + $ClientOps.OfflineClients -ne $ClientOps.TotalClients) 
 { 
 $AllClientsAccountedFor = $True 
 Write-Host (Get-Date).ToString("HH:mm") - $ClientOps.TotalClients clients notified. 
 Break 
 } 
 Write-Host (Get-Date).ToString("HH:mm") - Waiting for $ClientOps.FailedClients clients to complete notification. 
 }
 
 While ($AllClientsAccountedFor -eq $False)
 
 #Once we're complete, clean up our client operation 
 Remove-CMClientOperation -id $ClientOps.ID -force
 
 #Let everyone know we're complete 
 Write-Host (Get-Date).ToString("HH:mm") - Removed Client Operation $ClientOps.ID for $ClientOps.TotalClients clients within collection $ClientOps.TargetCollectionName
 

This very basic example will invoke a client notification task, and then repeatedly summarize and monitor it until we’ve accounted for all clients, and finally, delete the resulting Client Operation.  Pretty handy!  

As a recap, client notification is a huge improvement over previous methods, especially as we look to integrate Configuration Manager into automated data center operations.  Maybe you want to wrap this up into your own PowerShell function, maybe you want to use it in an Orchestrator Runbook, the automating client notifications brings a near real-time capability to Configuration Manager.

I hope this blog post gave you a good intro into what is required to programmatically start, summarize, monitor and delete Client Notification operations with PowerShell.  Do you have planned uses for Client Notification or are you currently using Client Notification for automation tasks?  I’d love to hear about it or any other feedback in the comments below!

Thanks!

This post comes from a question I received this week.  We’re going to focus on interacting with the Configuration Manager folder structure using Powershell.  What’s that?  Folders?  Configuration Manager? 

That’s right.  Starting with Configuration Manager 2012, folders are used for organization within the console, creating logical placeholders for all sorts of content.  Most object nodes within the console will allow you to create folders.  One of the benefits to folders is they are extremely useful when selecting a large number of objects, during RBA operations for instance:

Alright, now that we all know folders are a great way to keep our consoles organized, how can we mirror the folder management functionality in the console with PowerShell?  We’ll begin our investigation with Powershell provider for Configuration Manager.  When you open a Powershell session using the Configuration Manager module, we load a provider that allows us to interact with Configuration Manager via Powershell.  We can take a look at the providers loaded by using Get-PSProvider:

Get-PSProvider

Notice my prompt, PS P20:\>.  This is telling me any command I issue will be handled by the Configuration Manager provider, just like any other provider.  Also notice the other providers such as FileSystem, Registry, etc.  This will be important.

Move-CMObject is a new cmdlet, but part of new PowerShell functionality in Configuration Manager 2012 R2.  While Move-CMObject allows me to move objects within the folder hierarchy, new functionality allows me to interact with my Configuration Manager site just like the good ol' file system!

Let’s start by taking a look at our CMSite:

Get-ChildItem

Awesome!  So we can use Get-Childitem to take a deeper look at our site.  A little known fact, in PowerShell, “Dir” is actually just an alias for “Get-ChildItem”:

dir

Next, let’s figure out how to navigate within this hierarchy.  In Powershell, we can use the Set-Location cmdlet to navigate within any of the locations from each provider.  For instance, on my file system, I may want to navigate to my home directory using Set-Location, which would look like this:

Set-Location C:\Users\

This same functionality will also work in Configuration Manager:

Set-Location .\DeviceCollection

You might say, “Hey Heath, that looks a lot like the Change Directory (cd) command from older command shells!” To that, I’d say you’re correct, we can navigate the Configuration Manager objects just like a file system!

cd .\DeviceCollection

Awesome.  So, we’ve figured out how to navigate the folder structure of our site.  We can also create a new folder, using the “New-Item” cmdlet.  Let’s try it:

New-Item “Heath’s New Folder”
Get-ChildItem | fl –Property Name
 

We can also make folders using an alias more of you might be familiar with.  “MD”, is an alias for MKDir, which will create a new item in this path.

md “Heath’s Second Folder”
get-childitem | fl –property Name
 

Finally, we can use the new “Move-CMObject”  cmdlet in System Center 2012 R2 Configuration Manager to move objects around the console.  Let’s start by getting help:

Get-Help Move-CMObject

Alright, Move-CMObject will use two parameters, InputObject defines the object we are going to move, and FolderPath defines the location we’ll move to.  Easy enough, let’s create a new device collection and then move it to the OSD folder:

$NewCollection = New-CMDeviceCollection -Name "Windows Server 2012 R2" -LimitingCollectionName "All Systems"
Move-CMObject -FolderPath .\DeviceCollection\OSD -InputObject $NewCollection
 

Which has moved the newly created folder to the path we specified:

Hopefully this post has helped you understand the new ability to interact with folders in System Center 2012 R2 Configuration Manager.  I’m excited for the ability to programmatically organize objects in the Configuration Manager console, as this could be an automated task to move certain objects to a specified path automatically, keeping our console nice and tidy.  Feedback is always appreciated, let me know if you have any questions or comments below!

What’s that?  How is this related to System Center 2012 R2 you ask?  Well, with System Center 2012 Configuration Manager R2 we get a whole lot of new cmdlets available for our use.  Unlike the magazines at the doctor’s office, however, it isn't always easy to spot the differences in cmdlets between versions of products.  Also, unlike the magazines at the doctor’s office, we can use PowerShell to find the new cmdlets available!

First off, we need a reference machine.  Ah yes, my older System Center Configuration Manager 2012 SP1 CU2 site will serve nicely.  Here, we’ll export the cmdlets from the Service Pack 1 Configuration Manager module to a CSV for consumption later:

 Get-Command -Module ConfigurationManager | select Name | export-csv <path to CSV>

Great.  Now, we need to compare this to a newer version of the Configuration Manager Powershell module.  I'll copy the CSV we created in the last step to my shiny new System Center 2012 R2 Configuration Manager site server, and with a few lines of Powershell, we can compare to two and find new cmdlets!  Note, this won’t tell us any cmdlets that have changed, but it will tell us what is a new addition to System Center 2012 R2.

 $NewCmdlets = @()
 $CM12SP1Cmdlets = Import-CSV "E:\Output\CM12SP1CU2Cmdlets.csv"
 $CM12R2Cmdlets = Get-Command -module ConfigurationManager | select Name
 
 ForEach ($Cmdlet in $CM12R2Cmdlets)
 {
 
 If ($CM12SP1Cmdlets.Name -NotContains $Cmdlet.Name)
 {
 $NewCmdlets += $Cmdlet.Name
 }
 } 

Cool!  Now if we look at the values of $NewCmdlets, we have an array of cmdlets that are new to System Center 2012 R2 Configuration Manager!

 Copy-CMClientAuthCertificateProfileConfigurationItem
 Copy-CMRemoteConnectionProfileConfigurationItem
 Copy-CMTrustedRootCertificateProfileConfigurationItem
 Copy-CMVpnProfileConfigurationItem
 Copy-CMWirelessProfileConfigurationItem
 Get-CMAccessLicense
 Get-CMClientAuthCertificateProfileConfigurationItem
 Get-CMClientOperations
 Get-CMDeviceVariable
 Get-CMInitialModifiableSecuredCategory
 Get-CMMaintenanceWindow
 Get-CMRemoteConnectionProfileConfigurationItem
 Get-CMRemoteConnectionProfileConfigurationItemXmlDefinition
 Get-CMTrustedRootCertificateProfileConfigurationItem
 Get-CMVhd
 Get-CMVpnProfileConfigurationItem
 Get-CMWirelessProfileConfigurationItem
 Invoke-CMClientNotification
 Invoke-CMContentValidation
 Invoke-CMDeviceRetire
 Invoke-CMDeviceWipe
 Move-CMObject
 New-CMClientAuthCertificateProfileConfigurationItem
 New-CMDeviceVariable
 New-CMMaintenanceWindow
 New-CMRemoteConnectionProfileConfigurationItem
 New-CMTrustedRootCertificateProfileConfigurationItem
 New-CMVhd
 New-CMVpnProfileConfigurationItem
 New-CMWirelessProfileConfigurationItem
 Publish-CMPrestageContentTaskSequence
 Remove-CMClientAuthCertificateProfileConfigurationItem
 Remove-CMContentDistribution
 Remove-CMDeviceVariable
 Remove-CMMaintenanceWindow
 Remove-CMRemoteConnectionProfileConfigurationItem
 Remove-CMTrustedRootCertificateProfileConfigurationItem
 Remove-CMVhd
 Remove-CMVpnProfileConfigurationItem
 Remove-CMWirelessProfileConfigurationItem
 Set-CMAssignedSite
 Set-CMClientAuthCertificateProfileConfigurationItem
 Set-CMDeviceOwnership
 Set-CMDeviceVariable
 Set-CMMaintenanceWindow
 Set-CMRemoteConnectionProfileConfigurationItem
 Set-CMTrustedRootCertificateProfileConfigurationItem
 Set-CMVhd
 Set-CMVpnProfileConfigurationItem
 Set-CMWirelessProfileConfigurationItem
 

No matter the technologies you have to support on a daily basis, this example code or variations of this example code can be used to find new Powershell Cmdlets across all Microsoft products.  Have you found an interesting new Powershell Cmdlet?  Let me know in the comments below!

This post is part of a series that will cover what’s new in R2.  I’m sure we’ve all seen the awesome news from our product teams on this, but I’m going to take a different spin and put a focus on little improvements that make our lives as administrators easier.  This post is going to focus on our ability to add Maintenance Windows using PowerShell in R2.  This is a pretty welcome addition, as I’ve seen the code that goes into making Maintenance Windows a reality in previous releases, and it’s certainly much more than one line.  This is also amazingly powerful for automation scenarios, as we can programmatically control when clients will perform actions.

Side note here, while on the subject of Maintenance Windows, one other thing I am really excited for in R2 is the ability to define maintenance window usage.  With System Center Configuration Manager 2012 R2, we can now define separate Maintenance Windows for Software Updates, Operating System Deployment, and everything else.  Why is this important?  Picture the scenario:  I want my clients to install software updates during Maintenance Window A and applications to install during a Maintenance Window B.  In the past, the same maintenance window would have allowed both actions, which could lead to undesirable consequences.  In R2, I can define separate maintenance windows for each type of activity.  Pretty big deal, right?

Back to the subject, with Configuration Manager 2012 R2, we have new cmdlets to interact with Maintenance Windows.  Here, we’ll use the Get-Command cmdlet to find all Configuration Manager cmdlets that contain the word “MaintenanceWindow”:

Get-Command –Module ConfigurationManager | where Name –like “*MaintenanceWindow”

Which gives us this: 

 Cool, now we've got an idea of the commands that are available.  Following the normal naming standard, each Powershell cmdlet follows Verb-Noun syntax.  Next up, let’s get some help on interacting with the New-CMMaintenanceWindow cmdlet using Get-Help:

Get-Help New-CMMaintenanceWindow

It appears we need to give it a name and a CollectionID to bind the maintenance window to.  This seems easy enough – but wait, what’s that Schedule it’s looking for?  Well, as it turns out it’s looking for a ScheduleToken, which we can quickly create using New-CMSchedule cmdlet:

Get-Help New-CMSchedule

Easy enough, looks like I just have to feed it a start and end time., though I do have to do just a bit of formatting to make sure I feed it a start and end date.  In this case, we’ll take the easy road and let .NET do the formatting for us:

 #Use the DateTime.Parse() Method to parse in date to a DateTime 
 $StartTime = [DateTime]::Parse('2013-10-20 05:00') 
 $EndTime = [DateTime]::Parse('2013-10-20 08:00')
 
 #Create The ScheduleToken 
 New-CMSchedule -Nonrecurring -Start $StartTime -End $EndTime

Scream it from the mountain tops, we have a schedule token!  Next, let’s pull it all together and create our maintenance window:

 #Parameters 
 $CollectionID = "P200000A"
 
 #Use the DataTime.Parse() Method to parse in date to a DateTime 
 $StartTime = [DateTime]::Parse('2013-10-20 05:00') 
 $EndTime = [DateTime]::Parse('2013-10-20 08:00')
 
 #Create The ScheduleToken 
 $Schedule = New-CMSchedule -Nonrecurring -Start $StartTime -End $EndTime
 
 New-CMMaintenanceWindow -CollectionID $CollectionID -Schedule $Schedule -Name "Heath's Sunday Maintenance"
 

When we run the example above, we end up with this:

Hopefully this post has armed you with the knowledge you need to programmatically create maintenance windows.  Can you think of scenarios where this code can be used for new automation abilities?  Do you have an awesome use case in mind or feedback?  Let me hear it in the comments below!

Quite a few fixes, check this link out for more details:  Description of Cumulative Update 3 for System Center 2012 Configuration Manager Service …

HeLaw

A little bit about me:  I'm a System Center Premier Field Engineer based in Kansas City, Missouri.  My role is pretty cool in that I get to work with customers on a daily basis doing everything from supporting existing installations to helping them plan and deploy the newest greatest tech.

I promise as I find my rhythm in blogging I'll aim towards at least one solid solution-oriented blog update a month, and hopefully this will also serve as a staging area for other cool, interesting stuff I find along the way.

Stay tuned!