Client Push Installation change in Configuration Manager 2012 and how to take advantage of this change for troubleshooting purposes.


Yesterday while enjoying a lazy afternoon read through the Configuration Manager 2012 TechNet documentation, I came across this gem which was at the time news to me –

  • Client push installation starts and tracks the installation of the client by using the Configuration Manager database and no longer creates individual .CCR files. When you enable client push installation for a site, all discovered resources that are assigned to the site and that do not have a client installed are immediately added to the database, and client installation begins.

TechNet Source – http://technet.microsoft.com/en-us/library/gg682132#BKMK_DeployClientComputers

This could potentially be a new and very cool data point to be used when troubleshooting client push installation. Could the days of scanning through CCM.LOG for client installation failures be over? The following is just a quick post summarizing how to inspect this new data and potentially use it for client push installation troubleshooting purposes.

First thing first CCM.LOG looks relatively intact (as known from 2007) – This is fine by me and can still be very helpful in this process (more on that later).

How about the new data? There is a new view in the DB named v_CP_Machine (Found in a primary site DB where client push installtion is enabled or being manually executed). Here we can find information about the client push installation process (for non-clients) such as when the initial installation request was submitted, when the last attempt was made, How many attempts have been made, and a listing of the last error code.

Putting it to the test

So while I am working in a relatively small lab, I’ve been able to ‘break’ client push installation, creating some real data that pretty accuratley simulates what could be seen in a working production environment. For my test I’ve changed the client installation account to one which does not have administrative rights on my target machines. I’ve then triggered client installation towards a collection containing all non-clients. As assumption would have it, the data found in v_CP_Machine was updated to reflect the situation or misconfiguration that I had introduced into the environment. Several machines had an error code of 5 (Access Denied).

SQL Query

SELECT

Name,

LatestProcessingAttempt,

LastErrorCode

From v_CP_Machine

Order By LastErrorCode

Obviously this will work well beyond just an access denied error code 5, however how shall we correlate Error Code to actual issue? Fortunately CCM.LOG continues to detail the installation process up to point at which an error is thrown and for the most pat will accurately detail the issue including the error code. So while we may no longer need to scan through CCM.log for individual installation errors it continues to be a source of good information.

So for Error Code 5, tracing through CCM.LOG produces the following (click image for better view).

And if we were interested in Error Code 53 (as pictured in the SQL query results) we could find the following in CCM.LOG (click image for better view).

 

Generate CCR Tool –

Shortly after publishing this blog post my friend and fellow PFE Heath Lawson sent me an email regarding the Generate CCR tool. This tool is located at Adminconsle\Bin\ClientPushGenerator.exe and aids in client push installation by accepting a text file containing computer names for targeted installation. This tool may be an easy way to introduce a specific list of computers into the client push installation queue without having to rely on resource discovery / collection targeting.

For my demonstration I have created the following text file.

Set up the Client Push Generator like so and the cliked “Push”.

And as expected these ‘Machines’ have been added to the client push installation queue as can be seen in the database. As these two machine are not valid they error out with an error code of 53 which we already understand equates to ‘machine cannot be found on network’.

Closing –

So there you have it – I had not come across these changes in the past and found them to be quite cool and potentially very helpful. It is amazing the amount of work that has gone into this new product even beyond the great highly visible features such as the introduction of the CAS, Application’s, Compliance Settings, etc.

 

Comments (11)

  1. Very cool post. Thanks Neil.

  2. Shiladitya says:

    I am trying to figure out the way to Push client using powershell any help..?

  3. Lars Halvorsen says:

    To Shiladitya: why would you use PS to push out the client? Why not just use CM?

  4. Anonymous says:

    Normal
    0

    21

    false
    false
    false

    PT-BR
    X-NONE
    X-NONE

  5. Daniel del Moral says:

    Hi Neil,
    Thanks for such a nice article. I have a permissions issue regarding clietnpushgenerator with a full administrator for a site (configMgr R2) in a CAS + 2 primary sites architecture. no delegation here as of yet. When using the cliet push generator tool by the
    CAS full admin account it does work. when running the tool using the primary site full admin it throws a permissions error whenever clicking the push buttom. Please Help me, pls.
    Daniel

  6. Daniel dm says:

    it was an issue about permissions, (specifically scopes), oops

  7. Anonymous says:

    Reference Links:

    1. ConfigMgr 2012 Support for Azure Virtual Machines:
    https://support.microsoft

  8. Scott says:

    I have machines that are in the Site but never show up on this list.

  9. Jeff L. says:

    This is a great post however I’m still looking for a SCRIPTED way to push the client out to systems that *don’t* already exist in SCCM. The Install-CMClient cmdlet seems to require the client to already be in the database and unfortunately it doesn’t appear
    that this tool has command line options for accepting the file and site code. Any scripting tricks for pushing clients that aren’t already discovered by ConfigMgr? Thanks!