This blog is owned and operated by the ANZ ConfigMgr Premier Field Engineer team.
Ian BartlettMatt ShadboltGeorge Smpyrakis
When you distribute content to a Distribution Point in ConfigMgr 2012, a check is done against the Content Library to confirm that any of the source files being referenced in your application/package do not already exist in the Content Library. Ie. There is only one copy of every file stored on a DP regardless of how many packages reference that one file.
The ConfigMgr 2012 Content Library (SCCMContentLib) consists of 3 subfolders:
1. PkgLib 2. DataLib 3. FileLib
In the Package Library folder you will find a PackageID.ini file for every package. The PackageID.ini file for each package will give you the details for the Data library content and what file you will need to look for.
In the Data Library folder you will find a PackageID.ver.ini file for each package and a PackageID.ver folder. The folder is a “copy” of the exact package folder structure but without any of the real files. For each file in the original package you will find a corresponding .INI file with information about the original file. To find the HASH value for the file you are interested in, open the relevant .INI file and make a note of the first 4 digits of the HASH value, this will be needed to find the data in the FileLib directory
The File Library folder is where you will find the actual files that are used in the different packages. All files are grouped together in a folder. The folder for each file uses a 4 digit pre-fix of the HASH value of that file found in the DataLib. The FileLib is where the nuts and bolts of the application are stored. You will see three files under each folder:
1. A file with no extension (FILE), the actual file named is the HASH value. This file contains all of the source files for that part of the application. If the application only had a single .EXE or .MSI file to execute than you could copy the file to a location such as the Desktop, rename it to the original file name, ie .EXE, .MSI and start the installation
2. Hash.ini file contains a link between the file and the packages that uses the file. If you have multiple packages referring the same file, you will just see an entry for each package ID.
3. Hash.sig. It contains the original package signature
For this example I will use my Microsoft Office 2010 package which has Package ID IBC0000B.
1. Navigate to the SCCMContentLib directory on your DP.
2. open the PkgLib directory
3. Open the configuration file referencing your Package ID, ie IBC0000B, and make a note of the ContentID it is referencing, ie Content_30b777f9-be…………..
4. Navigate to SCCMContentLib\DataLib and open the directory that was referenced in your package configuration file, ie Content_30b777f9_30b777f9-be51-484b-8327-77bf2ef75169.1
Notice that folder Content_30b777f9_30b777f9-be51-484b-8327-77bf2ef75169.1 holds reference to all files in your source location, ie you will see all the Office 2010 files being referenced. NOTE: These files do not contain any of the actual source data, only references to the HASH values for each
5. Open any of the configuration files referencing a file in your package to gain the HASH value to the actual content. For this example I will use the setup.exe file as the example.
6. Take note of the first 4 digits in the hash, so for the setup.exe file it will be “97E6”
7. Navigate to SCCMContentLib\FileLib\<4 digit hash> - eg SCCMContentLibrary\FileLib\97E6
8. The file with extension ‘FILE’ is the actual content for the setup.exe file in our source content. To confirm this we can see the size of this file is 1075KB, the same as our setup.exe file from our source location.OriginalSource Files
9. As this Office is an application made up of many components, ie Word, Excel etc, they all share common files; to see what packages require the setup.exe file you could open the “Configurations Settings” file to see the package IDs of all packages that require the setup.exe file. For applications that are compiled to one executable, eg Adobe Reader, you could follow this process and simply copy the FILE file to a desktop, set the file extensions accordingly, ie .EXE and you could simply run this file and it would execute and install as it would contain all source files…
THAT’S IT… GOOD LUCK…
The ConfigMgr 2012 Package Conversion Manager (PCM) tool allows administrators to convert their legacy SCCM 2007 packages and programs into the new ConfigMgr 2012 Application and Deployment Types. This applies for all legacy packages apart from virtual APP-V packages that will automatically be converted to the new application model during the migration process. Once your legacy packages have been migrated and you have installed the Package Conversion Manager utility, then it is just a matter of analysing your packages in order to determine which readiness state it is in, and then converting your packages.
There are still a number of bugs in the RTM version of the PCM tool but all in all it works well.
It is worth noting that any legacy packages that have been configured to run another program first will only create the CM2012 Application Dependency if the program is in a different source Package ID. IE. “ Package with program dependent upon another program in the SAME package will not have that dependency converted” (from TechNet). To get around this you can just manually create the dependencies once you have converted your packages to Applications.
For this demonstration I am using an Adobe Reader X Package/Program with Package ID CEN0001A
We need to Analyse a package to determine whether our package is in an appropriate state to be migrated to the new Application model or whether some remediation work will be required to prepare the package to be converted to an Application and more importantly into a Deployment Type.
Expect to see either results after you have analysed your legacy package:
1. Automatic – Your package is in a state that will allow for a successful migration to an Application
2. Manual – Some remediation work on your legacy package is required before it can be successfully migrated to an Application Deployment Type.
Once the analysis is done you will see the readiness state under the Summary tab of your Package
If your legacy package returns an Automatic readiness state, than you can simply select the Convert Package option (This option will be GREYED out if Automatic is not returned) to convert your package to an Application.
If your legacy package returns a Manual readiness state, than some work needs to be done to fix some issues before you can convert it to a CM 2012 Application.
So we can see that my Adobe Reader package is not quite ready to be converted to a CM 2012 Application due to the Readiness state indicating Manual and the issue provided is because no Detection Method has been defined.
NOTE: Application Detection Methods are mandatory for any CM 2012 Application so expect this as a common issue.
So how do we fix this issue so my Adobe Reader package can be converted to a Application??? We use the Fix & Convert Tool to add the required information.
Wizard Screen Shots…
THATS IT, WE’RE DONE!!
So if we now have a look under Applications we will see that we have an Adobe Reader X Application with a Deployment Type created for us.
AS SIMPLE AS THAT… GOOD LUCK!!
Dynamic Collection Updates and Delta Discovery were features introduced in SCCM 2007 R3 and promised a lot. Finally, admins thought they could limit their full Collection updates to 1 per day, their AD System Group Discovery to 1 per day and use the Dynamic Updates/Delta Discovery to run every 5 minutes to pick up changes. Problem is, Dynamic Collection Updates/Delta Discovery do not work as we had hoped. In the end, Dynamic Collection Updates only worked on *newly* discovered systems… whether that’s a first time AD System Discover, OSD or manual client install. And hey, that’s great if your doing OSD!
If you want your Advertisements to be available as soon as a machine has been built, then Dynamic Collection Updates are for you. But for alleviating the need to run your collection schedules every 15 minutes (against MS Best Practice) for software distribution, Dynamic Updates didn’t hit the mark.
I’m happy to say that ConfigMgr 2012 now does Dynamic Updates and Delta Discovery in the way we had all hoped!
And here’s the proof.
Firstly, lets look at enabling CM12 Delta Discovery, creating a new group, adding a computer to the group and letting ConfigMgr 2012 do its thing:
CM12 AD Group Discovery Settings
SCCM 2007 AD System Group Discovery Settings
Before Delta Discovery is run:
SELECT * FROM v_R_System_SystemGroupName
From the Computer Object in SCCM
After Delta Discovery is run:
And for final proof – the adsgdis.log
So that’s great news! The Delta Discovery now works with System Group membership!
One last thing we need to check – whether or not the Dynamic Collection Membership now picks up changes to existing machines… not just new objects created by DDRs. To check this, we’re going to create a Collection with a membership query looking for an AD group. If all goes well, within MAX 10 minutes, the computer should become a member of the new Collection.
This time, we’re going to watch two logs – adsgdis.log and colleval.log and we should see the updates pretty soon.
And now, within about 6 minutes we can see the Collection is now populated with the object!
My last post on ConfigMgr 2012 Collections (I promise!). I wanted to go over Include and Exclude Collection Rules.
Include and Exclude collection rules are a new feature in ConfigMgr 2012 and I think you’ll find them most useful. They basically allow us to add or remove resources from a collection without having to write a complex membership rule.
Let’s say we have five collections: Finance Accountants, Finance Banking, Finance Bookkeeping, Finance Insurance and Finance Interns. Each of these collections will have their own Deployments targeted at the users in the collections. If we wanted to target an application at all of these collections, we would need to have 5 deployments.
Or we could create a collection with an Include Collection setting
Now we can just target the application at the Finance – All collection and we’ll get all three members.
Exclude collections are even cooler. Let’s say we have a collection for all computers who need Office 2010. Normally we would just deploy our application to the collection and hope for the best. We can use an Exclude Collections rule to be a little smarter in our deployments and remove all clients who are in an ‘unhealthy’ state.
First, we’ll create our Unhealthy Clients Collection. Our membership rule will be any looking for any client who’s client status is NULL or the client activity is NULL. This should get any computer that hasn’t got the client installed, or any computer with the client installed that isn’t active. (this is a *really* basic query for unhealthy clients. You can write a more complex one to find those clients who are truly unhealthy)
I’ve got 4 systems in my lab hierarchy – only one of which is healthy (oh, and the two Unknown Computer objects – but they don’t count)
So when I update the membership of my Office 2010 membership, I will only get the healthy client.
Using this exclusion method has a few benefits – firstly, you have a collection full of systems in which you have to repair the ConfigMgr client. Secondly, you’re software deployment statistics should be a lot cleaner as you’re not getting failures on the unhealthy clients. Finally, as the collection is dynamic, as soon as you remediate the unhealthy clients, they will receive the Office 2012 deployment!