We have a single site SCCM 2007 on a Windows 2003 32 bit server and we did not used the AD 'extend schema' when first setup. We push out the client software from the server as we are not allowed to make any changes to AD. Everything has been working fine until this week. I was not involved in the setting up of the SCCM server or how it was configured but am now the administrator of it. This week I noticed that users are no longer getting adverts - everything else seems ok. We can deploy our new images using bootup CD and it finds the image on the SCCM server ok and deploys ok. We push out the clients at same time, they appear in the collections ok and have all the boxes ticked (client, approved, site etc). When I go into the Configuration Manager Propeties on one computers, all the Actions are initiated ok, however when I click the Advanced tab and go to Configure Settings, the site code is shown in the box but when I click Discover, I get this message ' automatic site code discovery was unsuccessful'. This error has only happened occasionally before and if I waited long enough or reinstall the client, it then does discover the site code. Now it seems I can't get it to discover no matter what I try. A change in our environment last week has been replacing of Domain Controllers with new ones. I suspect it might have something to do with this. I am wondering if anyone can help me with tests on how to find out what is wrong. I am using SMS Trace to examine the logs but not sure what to look for. TIA

You need to check the client log files to get more details about the error. To start with, I would suggest you to go through locationservices.log clientlocation.log ...Anoop C Nair - @anoopmannur :: MY Site: www.AnoopCNair.com :: FaceBook: ConfigMgr(SCCM) Page :: Linkedin: Linkedin<

Thanks, there are some interesting errors in the locationservices.log which relate to AD 'LSGetSiteVersionFromSLP : no list verison returned from SLP for site <XXX>' XXX is not my site code! I'll do more investigations. The clientlocation.log is ok.

The SLP is the "Server Locator Point". That is a role you have on your server. The way a client finds that SLP is 1 of three ways (that I can think of off-hand, there may be more): 1) you've extended Active Directory schema, and your primary site server has rights to the SystemsManagement container in AD. If you go look at that container in AD, you see your SLP definition. Clients which are a member of that domain can look up the SLP in AD. 2) You have used WINS entries to populate the entry for the SLP; and clients use WINS to lookup what the name of the SLP server is. 3) You've hard-coded the SLP entry into each clients' registry (this is rarely done; but I'm mentioning it for completeness). Here are some guesses of where to start looking; only 1 of these is the likely cause...I'm mentioning a bunch of things to give you some direction of where to start looking. 1) Since you mentioned the domain controllers were replaced, is it plausible that they were also the WINS servers? Maybe previously you were 100% relying on WINS, and since that replacement, the WINS entries for the SLP are no longer existing? 2) Unlikely, but confirm that the SystemsManagement container still exists in AD, and your primary site servers' computer account still has rights to that container. 3) It could be completely unrelated to the Domain Controller replacement... have you checked that the ServerLocatorPoint component is running / no errors? Check in the console, Site Status. Also, the SLP relies on IIS. It's extremely unlikely; especially if your SLP and MP are on the same server, and the MP is working fine, but perhaps IIS isn't working right on the server hosting the SLP role?Standardize. Simplify. Automate.

I'm thinking Sherry's point #2. I had a situation where a DC was replaced and there was something on it that did not replicate to the new DC. Not sure what it was but it seemed to have been related to the System Management container. The client was finding information in AD, but then failing to gather all of the pertinent information it needed for site assignment. It never fell back to an SLP and so was left in "limbo". We had to unpublish the ConfigMgr site in the boundaries and republish it. After that, everything started working again.John DeVito

Fisrt check Does the WINS servers still exists or decommisioned, does sound like a coincedence this problem started after the dc's were upgraded. LMHOSTS files: LMHOSTS files are text files, similar to the HOSTS files used for name resolution for TCP/IP based networks. The HOSTS files contain host name to IP address mapping. A LMHOSTS file is the lookup table that is much like a HOSTS file, but is used for NetBIOS name resolution. Each computer has to have a copy of a LMHOSTS file. LMHOSTS files can resolve the NetBIOS names of servers that exist on other LANs. LMHOSTS files have to be manually maintained by administrators. This means that they have to be updated by someone whenever the network changes. - This could be the problem.... also DNS replication may also be an issue. Can you ping the sccm server from one of the clients ok, both netbios and fqdn return replies? If the WINS servers still exist did the port 137 get blocked on the firewall(s) stopping communication? Can you tlenet the wins server on this port? Are the clients loggong on to the nearest dc? Type Set L in cmd to confirm this. When replacing the dc's did they just build new machines keeping the old ones they replaced active until they switched over? Reason I ask is the new dc's would have new static ip's. The fact the client is being pushed out and installed plus approved suggests there is no problem with permissions and the server is discovering and communicating with the clients, its the clients reporting back to the mp point or points thats the problem and they dont know where to go. Check the bounadries are all correct with no overlapp IF your imaging from a boot cd ok, when the cd was created you have to specify the location of the distribution point so this is why it is finding it and all working. Really if your just SCCM admin the problem sounds like it belongs with the backend infrastructre or networks team to solve - if nothing has changed in sccm settings since everything worked then it is not sccm you need to troubleshoot. Start by finding out all changes been made on the Domain, Group Policy for clients, logon script, subnet changes and apply process of elimination. I hope it turns out to be an easy one. :et me knwo how you go...

thanks for all your replies. Sherry It would have to be the 3rd options - as we have not been allowed to extend AD nor use WINS. So presume the SLP was hardcoded. I will check through some of the setting to see if I can find anything, John D. I think your idea might be on the right track. I'll check about unpublishing and republishing boundaries. Also elshonno - I do think it is a backend infrastructure related change as its only started happening since the last DC was decommissioned. Anway, thanks to everyone. I've just written to the infrastructure team to try and work out what it could be. I did get some info re LDAP strings so it might be something that I have to change there. I did look through all the settings I could find and did not find any reference to the old DCs hardcoded anywhere.

Long shot... If you can find a machine that has NOT been on the network since before the problems starting happening (i.e., something currently powered off/in a closet) and power it up (again, off the network) just to look at the local log files of the CM client--to see what the log files looked like before the change. It's possible that WINS was used--even though "you weren't allowed". Standardize. Simplify. Automate.

Long shot... If you can find a machine that has NOT been on the network since before the problems starting happening (i.e., something currently powered off/in a closet) and power it up (again, off the network) just to look at the local log files of the CM client--to see what the log files looked like before the change. It's possible that WINS was used--even though "you weren't allowed". Standardize. Simplify. Automate. Good Idea. I know of a couple of laptops in the cupboard which haven't been used in a while I will check and report back.

Hi Arrietty, just for test purpose, do this 2 entries in one of your problematic Client. System32\drivers\etc ..open Lmhost file put this 2 entries, MP_Server_IP FQDN_of_MP SLP_Server_IP FQDN_of_SLP now reboot client and check both locationservices.log and clientlocation.log. Regards, PBC

Well first thing to check is take a healthy machine which is pingable and you are getting replies from it, both sides server to client and client to server. The next thing to check is the boundaries if they are setup correctly and the machine which you are managing has its IP added in the current boundary setup and there are no boundary over laps. Also check IIS and see if you find any errors there or the virtual directories are created properly. Now try to push the client on the machine and check the ccm.log on the sever side and see what messages are you getting there. Then push the desried software and advertise it to the client machine. Initiate the Actions Manaually on the client applet and check for the ccmexec.log on the client machine also check the locationservices.log on the client machine to see if it is actually getting to the MP. SLP would be a hit if your Schema is not extended but in your case it is. I have experinced numerous problems on client end all seems to have there own stories. Also check if name resolution is working fine. I would suggest to try a fresh machine to get a grip on what can be the issue. Also see if you can find anything in the Site Status regarding MP in the Component Service Regards, Amim Muhammad Khan AMIM MUHAMMAD KHAN | CTTCNET USER GROUP LEAD | EVENT SPEAKER, MCT, MCTS, MCITP-ENTERPRISE, MCSA http://amimkhan.wordpress.com

Hi Arrietty, just for test purpose, do this 2 entries in one of your problematic Client. System32\drivers\etc ..open Lmhost file put this 2 entries, MP_Server_IP FQDN_of_MP SLP_Server_IP FQDN_of_SLP now reboot client and check both locationservices.log and clientlocation.log. Regards, PBC do you mean to just put xxx.xxx.xxx.xxx server.domain.com the SLP and MP are the same server.

thanks for all your replies. I am slowly working through all the suggestions. I've tried adding IP addresses to LMhost files. I don't think that is the problem but certainly there are errors in locationservices logs before and after the DC changes but I can't see any pattern that points me to the problem. Sherri - 3) You've hard-coded the SLP entry into each clients' registry - I think this is what was done in our environment. I can see no reference to WINS anywhere so dont' think we used that method and we were not able to create a SystemsManagement container in AD. I will try republishing the boundaries shortly and I have put in some different LDAP settings in the Discovery methods.

I'm going to ask you something slightly ridiculous... but I feel I have to ask. If you launch AD Users and Computers; making sure that if you are in a multi-domain environment, you are looking at the domain to which the ConfigMgr server belongs, then go to the pulldown View, and make sure there is a checkbox next to "Advanced Features"... Now, if you look in the ADUsers/Computers, do you see a container for "System" (when you didn't before) and then within System, a container for "System Management" ?Standardize. Simplify. Automate.

Wait you mention WINS is no longer installed right? And you havent extended the ad schema then there is your answer. What doesnt make sense is that you said the clients are discovered from ad and then approved, for this to happen they must be talking with the primary site because the primary site code is assigned to the client once showing as approved in the sccm console - not the secondary site code. Can you create a new machine account in a discovered OU and see if sccm shows it after a discovery is manually run, then rejoin a computer to the domain with the newly created computer account and wait to see if sccm shows client is installed and approved. Youll also have to delete the old record out of sccm before doing the above as it will use the same guid. Id be interested to see if this works. Read below - firewall can break all of this by the way, make sure the ports are open on any firewall on the network, usually port 80 and 443, also turn of the firewall on the client itself as this will block communication to the mp. A good point form this article - http://technet.microsoft.com/en-us/library/bb632435.aspx Clients locate their default management point using the following mechanisms in the order specified: Active Directory Domain Services - You dont have enabledDNS - Please read the point in the article above about how to configure dns for management point locating - this is probably your best bet for a solutionServer locator point - have a look at this also as its worth understanding how it all worksWINS - You say this is gone now so no need. A great tool to use to troubleshoot clients worth installing - http://sourceforge.net/projects/smsclictr/ this will allow you to dig down deeper into a problem client, I use it all the time its excellent help. You should be loaded up now with enough information to sort it out.

I'm going to ask you something slightly ridiculous... but I feel I have to ask. If you launch AD Users and Computers; making sure that if you are in a multi-domain environment, you are looking at the domain to which the ConfigMgr server belongs, then go to the pulldown View, and make sure there is a checkbox next to "Advanced Features"... Now, if you look in the ADUsers/Computers, do you see a container for "System" (when you didn't before) and then within System, a container for "System Management" ? Standardize. Simplify. Automate. Sherry Nothing is too rediculous to ask. appreciate your help. I always have the advanced features enabled in AD, and our site has never had a system Mangement folder in there, however I see that the central IT sys admins have created a new folder on for their test SCCM server and a MP with their site code (BBB). This is the site code which is coming up in the logs locationservices.log When I go to advance tab of the Config manager client properties one any my of PCs now and press the 'discover configMgr Site - the correct 3 letter code is in there but I get error message 'auto site code discovery was unsuccessful' . In the smscliui.log I get "Current Assigned Site : XXX [my site code] Attempt to auto discover site has failed . Error 0X40002" In the Ccmexec.log everything seems fine and ther FQDN hostname is correct of the SCCM server. However the locationservices.log hass errors "LSGetSiteVersionfromSLP : no site version returned from SLP for site <BBB> [not my site code but the central IT one] LSGetSiteVersion : failed to get Site Version from AD and SLP" It appears to be looking at AD for the SLP even though we've never published it in AD.

Wait you mention WINS is no longer installed right? And you havent extended the ad schema then there is your answer. What doesnt make sense is that you said the clients are discovered from ad and then approved, for this to happen they must be talking with the primary site because the primary site code is assigned to the client once showing as approved in the sccm console - not the secondary site code. Can you create a new machine account in a discovered OU and see if sccm shows it after a discovery is manually run, then rejoin a computer to the domain with the newly created computer account and wait to see if sccm shows client is installed and approved. Youll also have to delete the old record out of sccm before doing the above as it will use the same guid. Id be interested to see if this works. Read below - firewall can break all of this by the way, make sure the ports are open on any firewall on the network, usually port 80 and 443, also turn of the firewall on the client itself as this will block communication to the mp. A good point form this article - http://technet.microsoft.com/en-us/library/bb632435.aspx Clients locate their default management point using the following mechanisms in the order specified: Active Directory Domain Services - You dont have enabledDNS - Please read the point in the article above about how to configure dns for management point locating - this is probably your best bet for a solutionServer locator point - have a look at this also as its worth understanding how it all worksWINS - You say this is gone now so no need. A great tool to use to troubleshoot clients worth installing - http://sourceforge.net/projects/smsclictr/ this will allow you to dig down deeper into a problem client, I use it all the time its excellent help. You should be loaded up now with enough information to sort it out. Elshonno the MP and SLP are the same name and we sent them to the client using the client push install with switch : ccmsetup.exe /logon SMSMP=SERVERNAME SMSSLP=SERVERNAME SMSCACHESIZE=5000 SMSSITECODE=XXX I checked the link you posted and don't think its a DNS problem because although the above SMSMP name is not FQDN if I run dnslookup on the client PC using the above servername it responds with the FQDN. Sorry if I mislead you but you said that I said : the clients are discovered from ad and then approved". I dont' believe this is the case. We join them to domain as per usual but they have to have the configuration manager client which we push out via GPO or manually using above switch. Then the objects are discovered in the System Collection. I am about to test the above tool which I have downloaded.