During debugging of ConfigMgr deployment, I started tracking down specific reasons why some of the clients were not deploying. This list is an attempt to be comprehensive of gotcha’s to be aware of when deploying ConfigMgr agents based upon what I saw during my deployments:
Site boundaries – If a client does not exist within boundaries which are defined for the site it will not deploy. The only exception to this that I have found is when you do a client push from the ConfigMgr console and choose to deploy outside of client boundaries.
SLP record – For our environment, we used WINS to provide the SLP record information versus storing it in Active Directory. While this works most of the time, if a client does not have a WINS server defined it cannot lookup the SLP record and therefore will not work correctly once the system is attempting to be deployed.
Macintosh systems – Logical enough eh? Not a Windows based OS, but since it can be joined to Active Directory ConfigMgr attempts to deploy the agent to it.
Client push account disabled – If the client push installation user account is disabled, no clients will be able to deploy because the credentials will fail. If you find that no agents are deploying in the environment, this is a good thing to double-check.
Client push account permissions – The client push installation account needs the access rights to perform the installation (which means basically local administrator access or domain administrator access).
Name Resolution on the ConfigMgr Server – DNS and WINS name resolution need to be configured correctly on the ConfigMgr server.
Servers with multiple names – Servers which have multiple names defined for them will fail to install on the second name. It will fail with an error 5 “The client is not accessible”.
Manual installation failing – Most likely needs to be rebooted.
Operating System Requirements – Operating System or Service Pack NOT supported (such as Windows Server 2003 with no service pack)
Old Computer Records – Old computer records which still exist in Active Directory will attempt to be installed by ConfigMgr. Since the system is no longer online it can never succeed of course. Proper cleanup of AD records will work to avoid this situation.
The ones which I had identified prior to this (http://cameronfuller.spaces.live.com/Blog/cns!A231E4EB0417CB76!897.entry) also still apply. These include:
Disk space: Low disk space on the client (in this case 5 mb of free space)
DNS: has name and IP address but it doesn’t own the IP/another system does. Caused by non-scavenged DNS. Message was that a duplicate name exists on the network. Removed the incorrect DNS entry.
Security: Domain administrators not in the local administrator account on the workstation.
Time: Workstation time was not in sync with the domain (in this case the date was a week off). This generally should not be an issue because AD should be forcing synchronization within an environment.
Reboot: System had the ccmsetup service disabled and marked for deletion