Here are some tips on speeding up testing of deployments. Although I’ll be demonstrating creating a package, the same information will apply to applications and updates. In order to move things along, it helps to understand what is going on in the background, so we will focusing on that. I will assume you already have an understanding of creating packages and will not go into much detail there.

Introduction

When you first create the package, you have two parts (usually). You have what I’m going to call the metadata, which is everything you put in the console. All this information ends up in the SCCM database and is sent to the clients as part of their policy via the Management Points (MP’s). Anytime you make a change to the metadata, it is automatically updated after just a minute or two to the MP’s and the clients just need to update their machine policy (if the deployment is to a device collection) or their user policy (if the deployment is to a user collection). Remember, the default policy poling interval on the clients is 60 minutes, so if we don’t intervene, it may take up to an hour before we see our changes show up on the client.

The second part, is the data source, the bits which is distributed out to the Distribution Points (DP’s) for the clients to grab. Anytime you make a change to the bits, that needs to be propagated out to the DP’s before it can be tested. So, if you make any changes to the source files, you will need to update the distribution points, and monitor the progress to make sure it get’s to the DP’s. After that, you will then need to update either the machine or user policy so they are aware of the new version of bits available.

Creating the package

OK, so let’s start. First we need to create a package. I’m going to assume this is something you are familiar with so, just like that, here it is!

Now, we need to distribute the content, so I’m going to do that next. Again, I’m assuming you are already aware you right-clicked the package and chose distribute content. We can watch this by looking at the content status. We wait for this to go green, just remember, the console does not auto refresh, you’ll have to press the F5 key once in a while to watch. You will also want to right-click the field names on top and add the Source Version column to the list. This is important when checking logs to see if the correct version of the package downloading. Right now, we are at version 1, so it’s just a matter of getting it out to the DP’s before we test.

Creating the deployment

During this time, we can also create our deployment, I’m assuming you are already comfortable with that, so I won’t go much into that other than to say that I would suggest you do an available deployment instead of required. This will allow you to control when the package is installed, and more importantly, reinstalled to facilitate your testing.

Getting ready to test

Once the deployment is created, and the content has been distributed to the DP’s, we are ready to test! Now we just need to make sure the client has the information so it will show us the package in Software Center. To do this, we now switch to the client machine and we need to watch some logs and force some policy retrievals. Using CMTrace, we open the following logs on C:\Windows\CCM\Logs:

execmgr.log

policyagent.log

CAS.log

On the client, open the Configuration Manager control panel applet (shortcut, start -> Run -> Control SMSCFGRC) run a machine policy update (or user policy if the deployment is user based) and watch the policyagent.log. One thing I did was configure CMTrace to highlight the packageID I created (Tools -> Highlight). We are watching to see policy come down that includes our package ID (you could also use the deploymentID, I’m just partial to the packageID). If you see a message that there was 0 policy updates, and haven’t seen your packageID go by, it may be that the policy hasn’t made it to your MP yet. Wait another minute and try again. This shouldn’t take more than a few minutes.

You will also see an entry pass by in the execmgr log file. Once you see this, you should see the deployment in software center. At this point, you should be able to run the deployment and see if it works.

Making changes

If the package doesn’t work, do not despair! If it’s a problem with the metadata, just go into the console and correct the mistake you have made! If the source files (the bits) need to be changed, go to your source directory and add/change what needs updating.

Once you’ve made your updates to the source directory, update the distribution points. You should see the version number increment here. This may take a few minutes, depending on your system. Remember, the console does not auto refresh, so you will have to use the F5 key to refresh your screen.

Wait until the version number increments, and you should notice the status go to yellow (in progress). Wait until it completes updating the DP’s and then we are ready to update the client.

Now that the change has completed on the server-side, we are ready to update the client. We run the machine policy update and watch the policyagent log.

We should see some new updates come down for our package. It will have a new version number, but this will not necessarily be the same as the package version number. But, as long as this number has incremented, we know we are getting an updated policy. One way we can be sure we have the latest policy is when we run the deployment from software center. If we get an error saying the package can’t be found, check the CAS log, look for the packageID.

It is in the format of PackageID.SourceVersion. If the source version is lower than what we see in the console, we need to refresh policy and get the correct version. Otherwise, it should download and we should be good to go!

Finishing up

Now, once the package is installed, if you are tracking this by some inventory, you will need to run the Hardware and/or Software inventory cycles from the control panel applet. Within a few minutes, you should see the results on any reports you are using to track!