locked
SCCM Client Not Being Pushed Automatically RRS feed

  • Question

  • We are experiencing an issue of "Non-Client" systems (i.e. SCCM Client is not being pushed automatically on a lot of systems after joining with domain-AD, whereas on half of the total systems it is being pushed automatically). 

    1) While investigating, I found that almost 30 percent of those computers ("Non Client" computers) have no entry in DNS server (Hostname to IP is not being resolved). Can that be one such reason?

    2) What is the role of DNS server for any updates (OS updates or SCEP-Antimalware Updates)? (In my opinion for those computers whom have no entry in DNS, will not be able to receive any aforementioned updates, Am I Right?)

    3) More investigation showed that group policy is not being updated fully on client machines (after joining with domain-AD). Si this group policy update is related to DNS issue also?.

    As a result of above all, we have to do the troubleshooting/re-installation manually (of SCCM Client) on each client machine. Which is very time consuming and resource intensive.

    Can anyone please help?

    Thanks

    Fakhar


    Fakhar ul Hassan

    Friday, December 11, 2015 3:59 AM

Answers

  • 1. Yes. Its impossible to communicate with a system by hostname if you can't get its IP address -- this goes for anything done on a network.

    2. None really as clients initiate all communication in ConfigMgr (except client push which is why the clients must be resolvable for that scenario). For all other client activity, only the server name must be resolvable.

    3. Probably not. Group Policy is also not a push mechanism, its client pull mechanism similar to ConfigMgr and thus the clients themseleves do not need to be resolvable. Having group policy issues is potentially indicative of many other issues though so fixing this is also important and possibly related to your other issues.

    Without actual technical details, like log file dumps, there's not much more that can be said though.

    Here's a nice KB that details troubleshooting client push: https://support.microsoft.com/en-us/kb/925282. It may help with your efforts.


    Jason | http://blog.configmgrftw.com | @jasonsandys

    Friday, December 11, 2015 1:24 PM
  • Once DNS naming resolution rectified, your clients will get routed toward correct direction to get it's mandatory client installation files - Usually from Management Point.

    This is not correct. Client installation files from DPs -- MPs can be used as a fallback, but that's generally not a good thing to allow happen. This really has nothing to do with the ability to resolve client names via DNS either since its the clients that initiate this either. The initial push by the site server is where clients must be resolvable via DNS because that's simply how modern IP networks work (unless you deal purely in IP Addresses which is fool-hardy at best when dealing with hundreds, thousands or more clients).

    If group policy not being updated fully then you've to work on it as well because default domain Policy is much more effective/powerful to control all the clients then SCCM.

    Huh? Not sure where you draw that conclusion from. Group Policy is certainly nice and can do a lot of things, but ConfigMgr can do nearly all of them also and usually in a much better fashion all with accountability which group policy has zero of.

    Jason | http://blog.configmgrftw.com | @jasonsandys

    Friday, December 11, 2015 1:29 PM

All replies

  • Looks like you've different AD sites and based upon that above situation is coming - Few have sccm client installed and other have not pertaining to DNS availability into it.

    You need to first make sure your DNS naming resolution work fine, it should resolve host to IP, on AD site where sccm client is not getting installed.

    Once DNS naming resolution rectified, your clients will get routed toward correct direction to get it's mandatory client installation files - Usually from Management Point.

    If group policy not being updated fully then you've to work on it as well because default domain Policy is much more effective/powerful to control all the clients then SCCM.


    Raman Katoch TechNet Clean Energy



    Friday, December 11, 2015 5:42 AM
  • 1. Yes. Its impossible to communicate with a system by hostname if you can't get its IP address -- this goes for anything done on a network.

    2. None really as clients initiate all communication in ConfigMgr (except client push which is why the clients must be resolvable for that scenario). For all other client activity, only the server name must be resolvable.

    3. Probably not. Group Policy is also not a push mechanism, its client pull mechanism similar to ConfigMgr and thus the clients themseleves do not need to be resolvable. Having group policy issues is potentially indicative of many other issues though so fixing this is also important and possibly related to your other issues.

    Without actual technical details, like log file dumps, there's not much more that can be said though.

    Here's a nice KB that details troubleshooting client push: https://support.microsoft.com/en-us/kb/925282. It may help with your efforts.


    Jason | http://blog.configmgrftw.com | @jasonsandys

    Friday, December 11, 2015 1:24 PM
  • Once DNS naming resolution rectified, your clients will get routed toward correct direction to get it's mandatory client installation files - Usually from Management Point.

    This is not correct. Client installation files from DPs -- MPs can be used as a fallback, but that's generally not a good thing to allow happen. This really has nothing to do with the ability to resolve client names via DNS either since its the clients that initiate this either. The initial push by the site server is where clients must be resolvable via DNS because that's simply how modern IP networks work (unless you deal purely in IP Addresses which is fool-hardy at best when dealing with hundreds, thousands or more clients).

    If group policy not being updated fully then you've to work on it as well because default domain Policy is much more effective/powerful to control all the clients then SCCM.

    Huh? Not sure where you draw that conclusion from. Group Policy is certainly nice and can do a lot of things, but ConfigMgr can do nearly all of them also and usually in a much better fashion all with accountability which group policy has zero of.

    Jason | http://blog.configmgrftw.com | @jasonsandys

    Friday, December 11, 2015 1:29 PM
  • I have further investigated the "Non Client" systems and found

    1) 21 percent systems are whom are not registered in DNS (no entry in DNS... Hostname to IP not being resolved).

    2) When checked through " SCCM => Deployment => Client Push Installation Details ". 65 percent of the systems (65 % of "Non Client" systems), have only one error 53 (Error code 53).

    For this error, I checked this link

    https://social.technet.microsoft.com/Forums/en-US/13592508-dde7-44fd-a425-19616e6d3ec8/sccm-2012-client-push-installation-error-53-in-sccm-console?forum=configmanagerdeployment

    Which means I again have to do manual working to check remote or target computers services. But the problem is that, the target systems are in thousands, I don't like to do the manually working on each computer to check its services issues (not possible as it will cost us more man-hours). Would you recommend me to write some script (in powershell for example) to handle this error code of 53 or should I further investigate this issue?

    Regards

    Fakhar


    Fakhar ul Hassan

    Saturday, December 12, 2015 3:18 AM