Note to myself: When "Enable automatic site-wide client push installation" is not working, just check if boundaries and boundary groups are in place. And even more important, just check "Use this boundary group for site assignment". When manual installation is working and Client Push installation not, this will do the trick!
After that Client Push installation will be doing fine! Progress can be seen in ccm.log in the ConfigMgr Logs folder. Happy! ;)
Showing posts with label Client Push Installation. Show all posts
Showing posts with label Client Push Installation. Show all posts
Tuesday, January 20, 2015
Tuesday, September 9, 2014
Differences between Managing Domain joined and Workgroup systems
Within ConfigMgr both Domain joined and Workgroup systems can be managed. Most prefered way is Domain joined probably, where systems are trusted automatically and updated after every deployment. Still Workgroup systems are used at customers also, where you must think about local permissions and non-trusted systems. Let's have a look at my experiences so far..
When deploying Domain joined systems, the existing object in ConfigMgr is updated everytime. When looking in Resource explorer you will see History of hardware and software specifications. Domain joined systems will be trusted automatically by default. No need to think about local permissions, because ConfigMgr can install the ConfigMgr client remotely or replicate domain account(s) to the Remote Control Users group. Active Directory is used to locate management points which is very handy.
When deploying Workgroup systems, a new object in ConfigMgr will be created everytime by default. The old object will get obsolete and History of hardware and software specifications will be lost. Workgroup systems are not trusted by default, or you must choose to change that in Site Hierarchy settings. You need local permissions for sure because there's no way to install the ConfigMgr client remotely or replicate domain account(s) to the Remote Control Users group. Management points cannot be located by Active Directory.
You need a Network Access account on Workgroup systems:
-This account is used by client computers when they cannot use their local computer account to access content on distribution points. This account might also be used during OS deployment when the computer installing the OS does not have a computer account on the domain.
-For ConfigMgr 2012 R2 only: You can now specify multiple network access accounts for a site. When clients try to access content and cannot use their local computer account, they will first use the last network access account that successfully connected. ConfigMgr supports adding up to ten network access accounts.
Source: Microsoft TechNet
Let's have a look at limitations for Workgroup systems:
-Workgroup clients cannot locate management points from Active Directory Domain Services, and instead must use DNS, WINS, or another management point.
-Global roaming is not supported, because clients cannot query Active Directory Domain Services for site information.
-Active Directory discovery methods cannot discover computers in workgroups.
-You cannot deploy software to users of workgroup computers.
-You cannot use the client push installation method to install the client on workgroup computers.
-Workgroup clients cannot use Kerberos for authentication and so might require manual approval.
-A workgroup client cannot be configured as a distribution point. ConfigMgr 2012 requires that distribution point computers be members of a domain.
Source: Microsoft TechNet
In my opinion it's way better to handle Domain joined systems when management must be done after deployment. More stable and easier for quick communication. There are a few tricks however to get things automated. Just have a look at them for more information:
-Remote Control on Workgroup systems
-Client Push Installation on Workgroup systems
-Support on Workgroup systems
When deploying Domain joined systems, the existing object in ConfigMgr is updated everytime. When looking in Resource explorer you will see History of hardware and software specifications. Domain joined systems will be trusted automatically by default. No need to think about local permissions, because ConfigMgr can install the ConfigMgr client remotely or replicate domain account(s) to the Remote Control Users group. Active Directory is used to locate management points which is very handy.
When deploying Workgroup systems, a new object in ConfigMgr will be created everytime by default. The old object will get obsolete and History of hardware and software specifications will be lost. Workgroup systems are not trusted by default, or you must choose to change that in Site Hierarchy settings. You need local permissions for sure because there's no way to install the ConfigMgr client remotely or replicate domain account(s) to the Remote Control Users group. Management points cannot be located by Active Directory.
You need a Network Access account on Workgroup systems:
-This account is used by client computers when they cannot use their local computer account to access content on distribution points. This account might also be used during OS deployment when the computer installing the OS does not have a computer account on the domain.
-For ConfigMgr 2012 R2 only: You can now specify multiple network access accounts for a site. When clients try to access content and cannot use their local computer account, they will first use the last network access account that successfully connected. ConfigMgr supports adding up to ten network access accounts.
Source: Microsoft TechNet
Let's have a look at limitations for Workgroup systems:
-Workgroup clients cannot locate management points from Active Directory Domain Services, and instead must use DNS, WINS, or another management point.
-Global roaming is not supported, because clients cannot query Active Directory Domain Services for site information.
-Active Directory discovery methods cannot discover computers in workgroups.
-You cannot deploy software to users of workgroup computers.
-You cannot use the client push installation method to install the client on workgroup computers.
-Workgroup clients cannot use Kerberos for authentication and so might require manual approval.
-A workgroup client cannot be configured as a distribution point. ConfigMgr 2012 requires that distribution point computers be members of a domain.
Source: Microsoft TechNet
In my opinion it's way better to handle Domain joined systems when management must be done after deployment. More stable and easier for quick communication. There are a few tricks however to get things automated. Just have a look at them for more information:
-Remote Control on Workgroup systems
-Client Push Installation on Workgroup systems
-Support on Workgroup systems
Wednesday, July 10, 2013
Client Push Installation fails in ConfigMgr 2012
Today I activated Client Push Installation in ConfigMgr 2012 in a existing environment. When looking in CMM.log there was no installation activity seen at all. Looking in the environment I found the following:
Looking at Client Push Installation settings, all was okay. The Client Push Installation account was configured (with Admin permissions), and Installation properties were set.
Ports needed for Client Push Installation were not set in the local Firewall settings published by Group Policy.
By default the following is needed:
-File and Printer Sharing
-Windows Management Instrumentation (WMI)
For Client Push Installation the following is needed also:
-RPC endpoint mapper – TCP 135
-RPC endpoint mapper – UDP 135
-Server Message Block (SMB) – TCP 445
"Use this boundary group for site assignment" was not set on the boundary group. This must be activated to make usage of Client Push Installation.
After making this changes everything went fine again! Looking in CCM.log installation activity was seen for all systems.
Looking at Client Push Installation settings, all was okay. The Client Push Installation account was configured (with Admin permissions), and Installation properties were set.
Ports needed for Client Push Installation were not set in the local Firewall settings published by Group Policy.
By default the following is needed:
-File and Printer Sharing
-Windows Management Instrumentation (WMI)
For Client Push Installation the following is needed also:
-RPC endpoint mapper – TCP 135
-RPC endpoint mapper – UDP 135
-Server Message Block (SMB) – TCP 445
"Use this boundary group for site assignment" was not set on the boundary group. This must be activated to make usage of Client Push Installation.
After making this changes everything went fine again! Looking in CCM.log installation activity was seen for all systems.
Subscribe to:
Posts (Atom)


