Resources for IT Professionals >
System Center Configuration Manager Forums
>
Configuration Manager Internet Clients and Native Mode
>
New client installs no longer communicating with MP and not pulling policy
New client installs no longer communicating with MP and not pulling policy
Good morning,
All of a sudden when new clients are being installed, they are not communicating with the MP or SLP properly (I can't really tell which). For example I am using a GPO startup script to install the SCCM client with the appropriate parameters. The client is installed fine but it does not look like any of the parameters took. In the general tab it shows "unknown" for ConfigMgr Connection Type and Site Mode. The site code does not appear in the "Advanced" tab and the actions tab only shows "Machine Policy Retrieval & Evaluation Cycle" and "User Policy Retrieval & Evaluation Cycle". The "Components" tab shows all installed, but none show enabled for the various components. When I initiate a user and machine policy cycle, nothing happens.
Nothing has changed from my end as far as I know. The group policy is still the same and as far as I know nothing has changed with the domain. I can't see any obvious errors in the logs on the SCCM server. Does anyone know what I can check to try and see why this stopped working? It seems that any new clients aren't working properly. Thanks.
Answers
- Carol,
Thanks for the help and suggestions. I had to basically confirm all my stuff was working to get our DNS folks to admit something was wrong. It's working now after they did some cleanup. Can't wait for it to happen again in the future.- Marked As Answer byandyjharper Thursday, November 05, 2009 8:51 PM
All Replies
- I should also note that due to a scheduled power outage my SCCM server was down for 36 hours over the last weekend. Would this cause any issues in the domain?
- My first suspicion is that assignment is failing if existing clients continue to work - so check locationsevices.log for errors. If your native mode clients can't get site information from Active Directory, they will need to be installed with /native:CRLANDFALLBACK or /native:FALLBACK so that they can communicate with the SLP for site assignment, and also SMSSLP. I don't know why it stopped working with GPO but maybe try installing one client manually and see if this works?
- Carol
This posting is provided “AS IS” with no warranties and confers no rights - I'm not sure exisiting clients are still working as I dig deeper. I checked the client log file "LocationServices" on one of my failed machines and I'm seeing a bunch of errors like the schema isn't extended. However, I know it is as it has been working for over a year. What I'm seeing are messages such as:
Failed to resolve 'SMS_SLP' to IP address from WINS
LSGetSLP : Failed to resolve SLP from WINS, is it published
LSGetManagementPointForSiteFromSLP : Unable to get the list of SLPs
Failed to retrieve Default Management Point from SLP
Unable to retrieve default management point from AD, DNS and SLP. Client is in Native mode which prevents failover to WINS for lookup.
It seemed to start after I restarted the server after the scheduled outage as the log file on a machine that was previously working is generating the same messages. Any ideas? I don't think running ExtADSch.exe would do anything since it was already extended. Based on the time of the errors for the machine that was working, it started after I powered the server back on after the outage. Anyone have any ideas? - As an FYI this person was experiencing pretty much the exact same issue:
http://social.technet.microsoft.com/Forums/en/configmgrsetup/thread/d35c86ec-c00d-4254-a163-6c3b22e3879e
I've tried most of the stuff in that thread to no avail. It all checks out. I'm not using client push method so obviously those tips weren't of any use for me. I'm really racking my brains trying to figure out why this quit working all of a sudden. - Your log file is saying that clients cannot find a server locator point - and because in your case Active Directory isn't extended, they need the server locator point for site assignment and finding the default management point. In the other post, Active Directory was extended but there was a problem with the information published there (and specifying the server locator point was a workaround), so I think it's a different problem although it's a good idea to check that the management point is responding.
It looks like this log file sample shows the client failing to find the default management point by using the server locator point. If your Active Directory isn't extended, it is expected that it couldn't find it via Active Directory. Ditto for DNS publishing if you haven't got this configured. Because the client is in native mode, it won't try WINS to locate the default management point. So there's only the server locator point left to find the default management point - but it needs to first find the server locator point. If new clients can't find the server locator point, that would explain why they can't assign to the site.
Flow chart for how clients assign to a site: http://technet.microsoft.com/en-us/library/bb932178.aspx
Flow chart for how native mode clients find the default management point: http://technet.microsoft.com/en-us/library/bb892796.aspx
How are you specifying the server locator point for clients? In WINS or as a CCMSetup option in the ConfigMgr2007Installation.adm? The order in which clients try to find a server locator point is CCMSetup option, then Active Directory, then WINS. Because the log file shows the client checking WINS, this means that it wasn't specified using a CCMSetup option with SMSSLP. The WINS method also fails ("Failed to resolve 'SMS_SLP' to IP address from WINS" & "LSGetSLP : Failed to resolve SLP from WINS, is it published"), and the Active Directory method fails ("LSGetManagementPointForSiteFromSLP : Unable to get the list of SLPs") - which is expected because you haven't extended Active Directory.
Looks like it's worthwhile checking WINS for the SLP record - is the record there, current, and WINS is working for these clients?
More information:
How to Specify the Server Locator Point for Configuration Manager Client Computers: http://technet.microsoft.com/en-us/library/bb694195.aspx
How to Manually Add Configuration Manager Site Information to WINS: http://technet.microsoft.com/en-us/library/bb632567.aspx
How to Provision Configuration Manager Client Installation Properties using Group Policy: http://technet.microsoft.com/en-us/library/bb632469.aspx
Configuration Manager and Service Location (Site Information and Management Points): http://technet.microsoft.com/en-us/library/bb632435.aspx
- Carol
This posting is provided “AS IS” with no warranties and confers no rights - I have extended AD though. I double-checked this to make sure, but I extended the schema over a year ago. In AD Users and Computers I see System > Sytem Management > SMS-MP-<site code>-<Site Server>, SMS-SLP-<site code>-<Site Server>, and SMS-Site-<site code>. I have verified that the site server computer account has full control to all objects.
How can I verify that my computers are able to find/read the published info in our domain? I'm not 100% sure that even though the schema has been extended and it is being published that our machines are finding the info. I just tested a manual install and defined the SLP in the setup via the SMSSLP parameter and I have the smae result (no site code, unknown connection type and site mode, etc. I'm dying here!
On an additional note, I've tried checking the MP via (native requires https, yes?):
https://siteservername/SMS_MP/.sms_aut?MPCert
https://siteservername/SMS_MP/.sms_aut?MPlist
and I get "There is a problem with the website's security certificate" and when I click continue to this site and I get a 403.7 error:
"The page you are attempting to access requires your browser to have a Secure Sockets Layer (SSL) client certificate that the Web server recognizes."
I've made sure that my MP, which resides on my Site Server has the proper certificate by going into IIS and viewing the bindings. Shouldn't I be getting some other result? - Ah - apologies. I misread and thought you said you hadn't extended AD.
Have you checked that a global catalog server is available so that these clients can find the site information in AD? When checking the management point, have you followed the procedures for native mode in http://technet.microsoft.com/en-us/library/bb932118.aspx to export and import a certificate into the browser?
- Carol
This posting is provided “AS IS” with no warranties and confers no rights - Carol,
Thanks for all the help. How do I ensure a global catalog server is available? I don't manage the DCs so I'm not sure how to check that. I'll look at the documentation for the MP certs. Thanks again.
~andyjharper - There are Windows tools to check and verify for the global catalog server - but could be tricky if you don't manage the DCs. Try logging on with a UPN instead of domain\username format (eg user@contoso.com) since resolving UPNs requires a global catalog server (but does require that you know what your UPN is). However, if a log on is successful using this method, you know a global catalog server must be available.
Just to check - when you tried installing manually, did you include /native:FALLBACK before specifying SMSSLP? Did you try it with SMSSITECODE so you can confirm it's not a boundary issue?
Another option at this point if all else fails might be to try uninstalling and reinstalling the management point.
- Carol
This posting is provided “AS IS” with no warranties and confers no rights - Can I just delete the MP and add it again? Or will this screw up anything with IIS? I guess what is the proper way to reinstall since technically this is a live system despite people not being able to connect.
- Carol,
I did use the native:FALLBACK parameter and the SMSSLP=<siteserver> with my manual install. This seems to have worked. Based on this, what would you say it points to problem-wise? My exisiting clients still aren't talking and my GPO install that I have been using for months still does not work. I sppose I could modify the GPO install settings, but that does nothing for the 1000 machines out there and not communicating. I'd like for them to somehow start talking to the server again without a re-install. Thanks for any insight you could provide.
~andyjharper - OK, well that's some positive progress in that you've established the management point and site is functional - and this rules out a problem specific to native mode. Yes, you could delete the management point and reinstall it, but since you've now confirmed it's working, I don't think there's much to be gained from this.
It seems to point to clients not being able to access the information published in Active Directory, or it's not published correctly. Since it was working previously, and you verified the site information in the System Management container, I think it's less likely to be a publishing problem. Have you been able to establish whether a global catalog server is accessible so that clients can access this information in Active Directory?
I agree using the server locator point isn't the solution here - it's a troubleshooting elimination step and/or short term workaround. 1,000 clients are a lot of computers to remain in this state so maybe time to call CSS?
- Carol
This posting is provided “AS IS” with no warranties and confers no rights - Carol,
Thanks for the help and suggestions. I had to basically confirm all my stuff was working to get our DNS folks to admit something was wrong. It's working now after they did some cleanup. Can't wait for it to happen again in the future.- Marked As Answer byandyjharper Thursday, November 05, 2009 8:51 PM
