SCCM client - SMSSLP value in registry keeps coming back after delete

Question

Our devices have the SMSSLP value present in there registry with incorrect address. I have checked the Client Push Installation Properties. The SMSSLP parameter was indeed there so I deleted it. It also was in the "Setup Windows and Configuration manager" step in our TS's. This parameter is obsolete for a while and besides that we don't need to specify it any more.

Now when I delete this value from registry, it automatically at some point comes back after for example a client push or upgrade of the client.
When i look at the LastSuccessfullInstallParams value under HKLM\SOFTWARE\MICROSOFT\CCMSETUP the SMSSLP parameter with incorrect address is present in that value. This makes me believe that the SMSSLP parameter is stored somewhere else or is gathered from the server. I have no clue as to where this is coming from. That incorrect IP address is not found anywhere else in registry besides the SMSSLP value and CCMSEUP string.

What i do see is failures that relate to that specific address in LocationServices.log.
The incorrect address is read from registry: "Retrieved MP [IP address] from Registry" and errors regarding sending of status and data are observed in log.

Anyone have any clue why this is happening and how i get rid of this SMSSLP value and data?
I have looked in every relevant setting in SCCM but can't find any reference to this SMSSLP and address any more. But still, after client push with uninstall this keeps coming back.....

Answer 1

Hi,

Thanks for posting in Microsoft MECM Q&A forum.

May we know what version of SCCM you are using? The SLP (Server Locator Point) doesn't exist as a discrete role anymore since ConfigMgr 2007 to locate MP or specify site assignment. So while setting the SMSMLP property is technically valid, it's not needed anymore.

We usually check the client installation properties at the two places as what you have done.
1)Task sequence step - Setup Windows and Configuration manager Client - Installation properties
2)Client Installation Settings - Client Push Installation Properties - Installation Properties

So I suggest that you uninstall CM agent completely and then install CM agent with your intended management point. For more information about
About client installation parameters and properties in Configuration Manager

Thanks for your time.

Best regards,
Simon

---

If the response is helpful, please click "Accept Answer" and upvote it.
Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Answer 2

Thanks for your reply.
We are running the latest SCCM version (2010 with all hotfixes).

We have removed al references to SMSSLP property in Task Sequences and Client Push settings.

You advise to uninstall client and install with intented management point. When we do a client install from the console (for testing purposes) we select te option to uninstall first, but this doesn't remove the SMSSLP setting from registry. It keeps coming back. And no, there is no group policy or anything else that sets this setting.

Besides that, is it preferred to set initial MP information during installation of the client or is it preferred to have it auto detect this info (all AD/DNS records are available) and leave the Installation Properties field emtpy?

Edit:
From the ccmsetup.log file i can see that the SMSSLP property is retrieved as an MSI property. Where it is getting that from is not clear for me.
Maybe this value is stored in AD schema? Is it possible and advised to remove this from there to make sure this is not the culprit?

Answer 3

Hi，

Thanks for your reply.

If you have you extended your AD schema when installed SCCM site, yes, the MS-SMS-Server-Locator-Point class will add to your AD schema, as shown below:

However, the SMSSLP attribute is not shown in my lab. Please help check if the SMSSLP property exists in your SCCM site properties under CN=System Management, CN=System, DC=yourdomain.

Thanks for your time.
 
Best regards,
Simon