locked
Preventing SCCM Client Push by IP Address RRS feed

  • Question

  • In my environment, the choice has been made to distribute the SCCM client by utilizing Client Push.  Generally, this works okay.  However, I've run into a snag and am seeking advice on how to work around it.

    When a computer is targeted, the client configuration manager first attempts to connect to it by name.  If it cannot connect by computer name, it tries to resolve the computer name into an IP address and then connect using that IP address.

    In my environment, computers are on and off the network frequently (a highly mobile workforce).  This results in DNS records getting left behind for computers even though they may not be on the network.  There is a difference in DNS scavenge time vs. DHCP lease time.  Normally, this isn't a huge deal except for SCCM.

    Under these conditions, SCCM is told to install the client on computer X.  Computer X is not on the network, so attaching via \\X\admin$ fails.  However, the DNS record for X still exists.  It just so happens that computer Y is now using that IP address.  When SCCM turns X into an IP address, it gets the address for Y and then connects to \\10.0.0.5\admin$ (which is now computer Y).  It then finishes up and says "boy, I just installed on computer X" (slight paraphrase).

    Is there a registry setting or configuration change available in SCCM to prevent the step of trying to deploy to IP addresses (i.e., just use the computer name only)?  The DNS problem is (typically) due to clients politely issuing a DHCP release but not following up with a DNS removal. 

    Tuesday, December 11, 2012 5:31 PM

All replies

  • Hi,

    No, there is no way to force that, it will Always try to resolve the IP Address using DNS. I would recommend instead the you use a startup script in a Group policy to assign the client instead of client push.
    Then you will have less load on your Pirmary site server trying to push the client to non-existing computer, and your problem above is solved as well.

    I would recommend that you have a look at this great script from Jason Sandys:  http://blog.configmgrftw.com/?page_id=349

    I would also report the issue to Microsoft as it should not install the client on a computer with the "wrong" computername.

    Regards,
    Jörgen


    -- My System Center blog ccmexec.com -- Twitter @ccmexec

    Tuesday, December 11, 2012 5:53 PM
  • Unfortunately, most of my client systems tend to hibernate or sleep their computers as they disconnect / reconnect from their docking stations.  Some are rarely on a wired network connection at all.  Getting computer startup scripts to run is a rare (and wonderful) event in my environment, thus, we went with Client Push as the primary method.


    Jeff Huston

    Tuesday, December 11, 2012 6:22 PM
  •  "boy, I just installed on computer X"

    Why is this problematic though? ConfigMgr does not do any specific tracking of client push installation and makes no association between a successful client push and whether or not a client resource is managed. Client systems are not managed unless/until the client agent is fully installed and successfully communicates back to the site. If the client is already installed on the target system, it won't be installed again so presumably, that target system needed the client agent installed anyway.

    Also note that the process you've described above isn't really what's happening. When ConfigMgr or any process attempts to connect to a resource, it must *always* resolve the hostname to an IP Address. This is basic networking and cannot be avoided. If your DNS does not accurately reflect the IP address of a hostname, that is a DNS issue and will/could affect any application/service/process attempting to communicate with that system by hostname. There are times when ConfigMgr will explicitly create a DDR for an IP Address, but this has nothing to do with a failure to communicate with the host via hostname and only occurs (to my knowledge) when using network discovery.


    Jason | http://blog.configmgrftw.com

    Tuesday, December 11, 2012 6:53 PM