recently installed SCCM 2007, All the machines are discovered but almost half of them are not getting client software installed! I am using Push method, I tried to look for the failure reason in CCM.log but there is no record about those machines. also there is no error in ccmexec.log and alientlocation.log I tried to install the client manually on some machines using ccmsetup.exe and it worked with no problem. To isolate the issue I created a new Collection and tried to install client on just those machines and then again checked CCM.log but the log didn't change at all!! For some reason the system is ignoring those machines even though they are discovered. Any Idea?

CM07 will not push to any client that it can’t resolve its name to an IP address. Can you ping the PC by its name from the site server? http://www.enhansoft.com/

Do those systems show as assigned to the site in the console?Jason | http://myitforum.com/cs2/blogs/jsandys | Twitter @JasonSandys

on top of the responses from Garth and Jason, enable the feature to Always install or repair client in the Client push wizard.Kent Agerlund | My blogs: http://blog.coretech.dk/author/kea/ and http://scug.dk/ | Twitter @Agerlund | Linkedin: /kentagerlund

Check the ddm.log on the server to see what the discovery data manager says about the creation of CCR files for the systems.Romano Jerez | http://blog-en.netvnext.com/

Yes all the machines are registered in DNS. I can ping and also browse \\computer name\admin$

they are showing Client: No Approved: N/A Assigned: No

Yes I tried that, no difference! Even without "Always install or repair client " I should see errors, warnings or information in logs about those machine not being deployed but the problem is that I can't find any thing.

This is what I see in ddm.log DDM is configured to synchronize the network config data (NCF) files at startup and every 15 minutes thereafter.CDiscoverDataManager::GetSiteStatus - Registering SQL types, Server = SQL02, Database = REPL08\SCCM_ST1, User =

One thing that I just remembered which might be related to this... Initially I had Network discovery enabled (discover using subnet and DHCP) then I realized that I don't need it and disabled it whiile it already discovered alot of resources. Can this be part of issue? is there a way to remove all the resources that is discovered using Network Discovery and let the other methods re-discover them? I really appreciate your help...

If the system is not assigned to the site, then ConfigMgr will not push the client agent to it. You need to first ensure your boundaries include all of the systems that you want to manage. Are you using IP Address range subnets? If not, stop, go back and change them all to IP Address range boundaries. Anything else is evil. Then rerun discovery.Jason | http://myitforum.com/cs2/blogs/jsandys | Twitter @JasonSandys

Thank you Jason, That was it! as soosn as I changed the boundaries from IP Subnet to IP range it started working. Even though my problem is solved but still I don't understand why it wasn't working before. I had the boundaries defined as IP subnet(classless Subnet \22bit)!!! Maybe SCCM only works with classfull subnets(8bit, 16 bit and 24 bit)?!? Thaks again Jason.

Even though my problem is solved but still I don't understand why it wasn't working before. I had the boundaries defined as IP subnet(classless Subnet \22bit)!!! Maybe SCCM only works with classfull subnets(8bit, 16 bit and 24 bit)?!? No CM will work with any subnet mask, but the issues is that same subnet mask must also be used on clients PCs. So if you have /22 subnet defined, your client must also be using /22 subnet mask. Almost no one will have that big of a subnet mask on clients due to the broadcast domain it creates. http://www.enhansoft.com/

Actually SCCM does not support supernets. Check http://blogs.technet.com/b/configurationmgr/archive/2010/03/22/clarification-on-issues-resulting-from-the-use-of-supernets-in-configmgr-2007.aspx Romano Jerez | http://blog-en.netvnext.com/

The premise for that article is false. The details are correct, but the problem is many layered and comes down to the fact that ConfigMgr is stuck in the pre CIDR world. It's not that super-nets can't work, its just ignorant of them. Also note, the use of the term supernet is incorrect anyway. I can go on for many days here and yes I have DCRs in with the product team and yes I've argued this directly with them. At the end of the day, use IP Ranges and be done with it. IP Subnets and even AD Site boundaries essentially use bad assumptions and logic about the real world of networking.Jason | http://myitforum.com/cs2/blogs/jsandys | Twitter @JasonSandys

So Jason bet me too it but, yes supernets are supported if the boundaries and client subnet marks are identical. There in lays the problem almost no client PCs has a subnet mask greater than 24 bit but people always use a subnet mark of greater that 24 when defining boundaries. To compound the problem, most people do not understand how the same issue also affect AD! To quote from one of my old myITforum mailing list post. http://technet.microsoft.com/en-ca/library/cc754697.aspx “Domain controllers and other servers that use sites publish server objects in AD DS to take advantage of the good network connectivity that sites provide.” “Server objects are created in AD DS by applications or services, and they are placed into a site based on their IP address. When you add the Active Directory Domain Services server role to a server, a server object is created in the AD DS site that contains the subnet to which the server's IP address maps.” “For a client, site assignment is determined dynamically by its IP address and subnet mask during logon.” “Locating domain controllers by site Domain controllers register service (SRV) resource records in Domain Name System (DNS) that identify their site names. Domain controllers also register host (A) resource records in DNS that identify their IP addresses. When a client requests a domain controller, it provides its site name to DNS. DNS uses the site name to locate a domain controller in that site (or in the next closest site to the client). DNS then provides the IP address of the domain controller to the client for the purpose of connecting to the domain controller. For this reason, it is important to ensure that the IP address that you assign to a domain controller maps to a subnet that is associated with the site of the respective server object. Otherwise, when a client requests a domain controller, the IP address that is returned might be the IP address of a domain controller in a distant site. When a client connects to a distant site, the result can be slow performance and unnecessary traffic on expensive WAN links.” So basically if you don’t setup you AD correctly, then your client will authentic with a random DC and it could be over a WAN link. http://www.enhansoft.com/

So Jason bet me too it but, yes supernets are supported if the boundaries and client subnet marks are identical. There in lays the problem almost no client PCs has a subnet mask greater than 24 bit but people always use a subnet mark of greater that 24 when defining boundaries. To compound the problem, most people do not understand how the same issue also affect AD! To quote from one of my old myITforum mailing list post. http://technet.microsoft.com/en-ca/library/cc754697.aspx “Domain controllers and other servers that use sites publish server objects in AD DS to take advantage of the good network connectivity that sites provide.” “Server objects are created in AD DS by applications or services, and they are placed into a site based on their IP address. When you add the Active Directory Domain Services server role to a server, a server object is created in the AD DS site that contains the subnet to which the server's IP address maps.” “For a client, site assignment is determined dynamically by its IP address and subnet mask during logon.” “Locating domain controllers by site Domain controllers register service (SRV) resource records in Domain Name System (DNS) that identify their site names. Domain controllers also register host (A) resource records in DNS that identify their IP addresses. When a client requests a domain controller, it provides its site name to DNS. DNS uses the site name to locate a domain controller in that site (or in the next closest site to the client). DNS then provides the IP address of the domain controller to the client for the purpose of connecting to the domain controller. For this reason, it is important to ensure that the IP address that you assign to a domain controller maps to a subnet that is associated with the site of the respective server object. Otherwise, when a client requests a domain controller, the IP address that is returned might be the IP address of a domain controller in a distant site. When a client connects to a distant site, the result can be slow performance and unnecessary traffic on expensive WAN links.” So basically if you don’t setup you AD correctly, then your client will authentic with a random DC and it could be over a WAN link. http://www.enhansoft.com/