I am using SSCM 2007 SP1. The client is installed on a test PC and working fine....remote control works etc etc. However, when I go into control panel and config manager/advanced and click on DISCOVER I get an error returned saying "Automatix Site Code Discovery Was Unsuccessful" I extended the schema prior to install, and the logs are pasted below from the schema update log; Strangly enough the client does have the correct site code despite the fact we have never told it the site code and did a manual client install without any switches. Our mp test URL says; - <MPList> - <MP Name="ZAMBEZI" FQDN="zambezi.students.blackburn.local"> <Version>6221</Version> <Capabilities SchemaVersion="1.0" /> </MP> </MPList> I'd like to be certain that our schema is extended properly, os this discovery failure is very worrying, as from what I have read this should be working if AD is extended properly. Does anyone know what our next steps should be? <06-11-2008 08:37:28> Modifying Active Directory Schema - with SMS extensions.<06-11-2008 08:37:28> DS Root:CN=Schema,CN=Configuration,DC=students,DC=blackburn,DC=local<06-11-2008 08:37:28> Attribute cn=MS-SMS-Site-Code already exists.<06-11-2008 08:37:28> Attribute cn=mS-SMS-Assignment-Site-Code already exists.<06-11-2008 08:37:28> Attribute cn=MS-SMS-Site-Boundaries already exists.<06-11-2008 08:37:28> Attribute cn=MS-SMS-Roaming-Boundaries already exists.<06-11-2008 08:37:28> Attribute cn=MS-SMS-Default-MP already exists.<06-11-2008 08:37:28> Attribute cn=mS-SMS-Device-Management-Point already exists.<06-11-2008 08:37:28> Attribute cn=MS-SMS-MP-Name already exists.<06-11-2008 08:37:28> Attribute cn=MS-SMS-MP-Address already exists.<06-11-2008 08:37:28> Attribute cn=mS-SMS-Health-State already exists.<06-11-2008 08:37:28> Attribute cn=mS-SMS-Source-Forest already exists.<06-11-2008 08:37:28> Attribute cn=MS-SMS-Ranged-IP-Low already exists.<06-11-2008 08:37:28> Attribute cn=MS-SMS-Ranged-IP-High already exists.<06-11-2008 08:37:28> Attribute cn=mS-SMS-Version already exists.<06-11-2008 08:37:28> Attribute cn=mS-SMS-Capabilities already exists.<06-11-2008 08:37:29> Class cn=MS-SMS-Management-Point already exists.<06-11-2008 08:37:29> Located LDAP://cn=MS-SMS-Management-Point,CN=Schema,CN=Configuration,DC=students,DC=blackburn,DC=local<06-11-2008 08:37:29> Successfully updated class LDAP://cn=MS-SMS-Management-Point,CN=Schema,CN=Configuration,DC=students,DC=blackburn,DC=local.<06-11-2008 08:37:29> Class cn=MS-SMS-Server-Locator-Point already exists.<06-11-2008 08:37:29> Located LDAP://cn=MS-SMS-Server-Locator-Point,CN=Schema,CN=Configuration,DC=students,DC=blackburn,DC=local<06-11-2008 08:37:30> Successfully updated class CN=Schema,CN=Configuration,DC=students,DC=blackburn,DC=local.<06-11-2008 08:37:30> Class cn=MS-SMS-Site already exists.<06-11-2008 08:37:30> Located LDAP://cn=MS-SMS-Site,CN=Schema,CN=Configuration,DC=students,DC=blackburn,DC=local<06-11-2008 08:37:30> Successfully updated class LDAP://cn=MS-SMS-Site,CN=Schema,CN=Configuration,DC=students,DC=blackburn,DC=local.<06-11-2008 08:37:30> Class cn=MS-SMS-Roaming-Boundary-Range already exists.<06-11-2008 08:37:30> Located LDAP://cn=MS-SMS-Roaming-Boundary-Range,CN=Schema,CN=Configuration,DC=students,DC=blackburn,DC=local<06-11-2008 08:37:30> Successfully updated class LDAP://cn=MS-SMS-Roaming-Boundary-Range,CN=Schema,CN=Configuration,DC=students,DC=blackburn,DC=local.<06-11-2008 08:37:31> Successfully extended the Active Directory schema. <06-11-2008 08:37:31> Please refer to the SMS documentation for instructions on the manual <06-11-2008 08:37:31> configuration of access rights in active directory which may still <06-11-2008 08:37:31> need to be performed. (Although the AD schema has now be extended, <06-11-2008 08:37:31> AD must be configured to allow each SMS Site security rights to <06-11-2008 08:37:31> publish in each of their domains.)

The site code is discovered automatically so you if you dont' set it then it will try to find it. What is your boundary setting. If I remember correctly if you have the boundary set to just an AD site then when you click discover it will fail since it doesn't have an IP based boundary.

The boundary is set to an IP range, 172.31.1.1 - 172.31.254.254 the test PC is within that range.

Do you have a SLP registered in WINS? (needed is schema not extended) Is the Systems Management Container in AD and populated? http://technet.microsoft.com/en-us/library/bb632591(TechNet.10).aspx http://technet.microsoft.com/en-us/library/bb633169(TechNet.10).aspx http://technet.microsoft.com/en-us/library/bb680711(TechNet.10).aspx f you do not have an object published for each management point or if the information for the default management point is not correct, review the sitecomp.log file in the <ConfigMgrInstallDir>\logs folder to identify the failure. If the site object is not published or contains incorrect data, review the hman.log file in the \sms\logs folder to identify the failure. Is the Schema extended? http://technet.microsoft.com/en-us/library/bb633121(TechNet.10).aspx look at these logs on the client system32\ccm\logs\locationservices.log clientlocation.log

The AD container is there (it was already there thanks to SMS2003), the security has been set, and 2007 has created objects correctly in there. SCM2007 is set to publish to Active Directory (check box ticked). I've had a look at sitecomp.log but cant see any issues, although the site objects do seem to be published ok in AD. Its a huge file and to be honest Im not sure what I'm looking for but cant see anything glaringly obvious..... as is the case with hman.log I have checked the last document you referenced; http://technet.microsoft.com/en-us/library/bb633121(TechNet.10).aspx We haveTWO of the three objects it mentioned SMS-Site-xxx SMS-MP-<site code>-<site server name> But we do not have SMS-SLP-<site code>-<site server name> This is because we do not have the Service Locator Role installed on the server.....which you are not supposed to use if you are publishing the site to AD. I can paste my hman.log file and sitecomp.log if it might help to identify the problem? Many thanks for your help.

Having spoent the last 2 hours playing around with this...just managed to resolve it. I added EVERYONE to the security of the System Management portion of AD, giving them READ. Instantly fixed the issue and discovery now works

Awesome.

Hi College, Can you describe what steps you tool in resolving the issue. Thanks,

Hi Collage Guy,can you describe the steps you have followed to resolve the"automatic site code discovery was unsuccessful". since i am also facing the same problem in my site. Actually it was working fine suddenly the problem arose. I am still seeking internet. I found this problem when i am trying to pushing the software patches.Kindly update me, it ll very useful to me.Thanks in advancce.Thanks and regardsBabu

Hi, I am new to sccm, i had the similar problem. what i did was to join the computer to the domain and then i ran the site discovery and it was successfull.thanks

The site code is discovered automatically so you if you dont' set it then it will try to find it. What is your boundary setting. If I remember correctly if you have the boundary set to just an AD site then when you click discover it will fail since it doesn't have an IP based boundary. Thnx! This solved my problem.... Removed all AD sites in my boundaries and added them as IP subnets. Is this a bug in SCCM? Is it gonna be fixed in a new release? (I Know this is a old post, but it solved my problem in SCCM 2007 R2)

This is not a bug; auto-discovery of the sitecode works even when AD boundaries are used.

Are you sure about this???? I created the container System Management, Gave the SCCM server Full Controle (this object and all descendant objects), gave everyone read (this object and all descendant objects), published the SCCM site in Active Directory Domain Services (and saw the objects in the System management Comtainer), Created some Active Directory Sites, and bound them to their corresponding subnet. On the client I opened configuration manager, Advanced, Configure settings, Discover, and it gave me an error "Automatic Site Discovery was unsuccessful". After removing the Site from the boundary and adding it as an IP subnet, the error was gone (The discovered site is the same as the currently assigned site)

Old thread, but I am in agreement with SjoredvW - this is happending to me now, on ONE system, so it is a BUG! Why on God's green earth would I have to CHANGE the system OU permissions, just because ONE system gets this error? All my other systems discover the site 'flawlessly.' Double-checked DNS on the client that is unable to discover; DNS is fine; mask is fine; i can ping the main site server from this client, and vice-versa; firewall is off; no Antivirus; nslookup & reverse nslookup of the main site sever works fine. verified computer name and domain info - joined properly, etc. So, it's very odd these people are saying "Oh, great, your change (of permissions) fixed it" - but WHY is it broken in the first place? Why only on ONE system (in my case)? And WHY is nobody saying, "Yes, you are RIGHT - permissions need to be set to allow Everyone Read, List, Execute on the System Management container?" To me, this is quite scary - it's like a "guessing game." Also, note: I believe you do NOT have to specify to apply that permission change to all sub-containers, because all of those sub-containers within the System Management container are set for "Inherit Permissions from Parent" - so, if you "apply to all sub-containers," then you actually could potentially hose something.

Okay, I was indeed given WRONG info. ip/mask of the remote client should have been 10.45.x.x with mask 255.255.255.0 but I was previously told 10.45.x.x with 255.255.0.0 - and that is a HUGE difference, but STILL, I was able to ping the main site server and dir \\main-site-server\smsclient and so forth, so you would think the SCCM client also would be able to get back to (and 'discover') the site server... but, it's amazing when you're given wrong info and then, when you fix it, it actually corrects the issue. Live and learn. I still say it comes down to being 'buggy' - i.e., sccm client should have at least enough intelligence to say, "Hey, your network info must be screwy, because I can't get back to the 'mother ship.' " (which, in vague terms, I suppose it said that, but "cannot discover site" is incredibly vague"). Bottom line, though, it did come down to network and/or DNS issue - which was the initial feeling, even though everything looked pretty much normal - again, I was told the 255.255.0.0 was 'normal' and that it should be left that way but, upon comparing to other systems, the way the network is segmented, it needed to be 255.255.255.0 (more of a class 'C') - and back at the switch/router, it may also make a big difference in allowing/disallowing certain 'lookups' and/or 'broadcasts,' so it does almost make sense. If anyone can shed more specific light, I would be grateful, because I am not the ultimate network warrior just yet. Thanks! All of this info, even the info that "does not" answer the specific questions, is invaluable! Cheers!