locked
SCCM 2012 R2 Automated Client Push RRS feed

  • Question

  • I have a network that I have Client Push working on. This network has a small group of workstations that aren't supposed to get anything from SCCM, not even the client. If I turn on automated client push, it will try to install the client on every computer. Is there a way I can use automated client push and keep it from installing on this small group of workstations? The workstations in question are in the same sub OU and begin with the same naming pattern.

    I should be able to use GPO install to do this but if there's a way to do it with client push, I'd rather do that.

    Thanks for any help.


    Ben JohnsonWY

    Wednesday, March 2, 2016 1:20 AM

Answers

  • If your only method of installing the client agent is client push, then simply deny the client push account any permissions on those systems.

    Alternatively, if all of the client systems fall into a single subnet, you could not include this subnet if your site assignment boundary groups. Aotu client push will not push to clients not assigned to the site.

    Another possible method is to deny read permissions to the OU that these systems are in for the site server's computer account so that System Discovery never picks them up. (This method may or may not work depending upon your AD permissioning and version though so test it if you go down this path).


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

    Wednesday, March 2, 2016 1:46 AM

All replies

  • If your only method of installing the client agent is client push, then simply deny the client push account any permissions on those systems.

    Alternatively, if all of the client systems fall into a single subnet, you could not include this subnet if your site assignment boundary groups. Aotu client push will not push to clients not assigned to the site.

    Another possible method is to deny read permissions to the OU that these systems are in for the site server's computer account so that System Discovery never picks them up. (This method may or may not work depending upon your AD permissioning and version though so test it if you go down this path).


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

    Wednesday, March 2, 2016 1:46 AM
  • Ah so. Yes, makes sense.

    The subnet option won't work for us because lots of other stuff is on that subnet. But the first option, denying the account access, looks very promising. I'll check it out tomorrow.


    Ben JohnsonWY

    Wednesday, March 2, 2016 2:07 AM
  • Got waylaid by other problems. Will work this tomorrow.

    Ben JohnsonWY

    Friday, March 4, 2016 2:34 AM
  • Denying the client push account seems to be working. The puters in question were already in their own OU. We added the client push account to all the user rights that start with "DENY" such as "Deny access from the network". Thanks!

    Ben JohnsonWY


    Monday, March 7, 2016 9:07 PM