locked
Delete clients from SCCM console RRS feed

  • Question

  • Hi all,

    I deleted some clients from SCCM console accidently and did not uninstall SCCM clients Now, these clients re-discovery via SCCM. but SCCM clients status still show "NO". I have wait for 25 hours. What cause that and how can I force a update?

    Thanks.
    Wednesday, September 16, 2009 2:21 AM

Answers

  • They are being "re-discovered" by one of your discovery methods (probably AD discovery). However, the discovery methods merely add an object to the ConfigMgr DB for these systems and do not query them in any way to discover whether or not they have a client -- that's not the purpose of the discovery.

    I'm not sure where the 25 hours is coming from, have you timed this? 25 hours was used in SMS 2003 for legacy clients and SMS 2.0 but to my knowledge has no significance in ConfigMgr. However, the "newly" discovered systems will report in to the console that they indeed have clients once they check in with a DDR (Data Discovery Record) generated by the heartbeat discovery every 7 days by default -- maybe you have lowered the heartbeat discovery interval to every day.

    To force them to update immediately, just run a Data Discovery Cycle from the actions tab in the ConfigMgr control panel applet on the client, wait a minute or two, and then update the collection membership.
    Jason | http://myitforum.com/cs2/blogs/jsandys | http://blogs.catapultsystems.com/jsandys/default.aspx | Twitter @JasonSandys
    • Marked as answer by RogerRen Wednesday, September 16, 2009 3:55 AM
    Wednesday, September 16, 2009 3:11 AM
  • The client will re-register automatically depending on the site configuration.  The easiest way to force a re-register to un-install and re-install the client.  That will force the client to re-register with the site server.
    Gabe Brown, Configuration Manager 2007
    • Proposed as answer by Gabe Brown [MSFT] Wednesday, September 16, 2009 3:20 AM
    • Marked as answer by RogerRen Wednesday, September 16, 2009 3:55 AM
    Wednesday, September 16, 2009 3:19 AM

All replies

  • They are being "re-discovered" by one of your discovery methods (probably AD discovery). However, the discovery methods merely add an object to the ConfigMgr DB for these systems and do not query them in any way to discover whether or not they have a client -- that's not the purpose of the discovery.

    I'm not sure where the 25 hours is coming from, have you timed this? 25 hours was used in SMS 2003 for legacy clients and SMS 2.0 but to my knowledge has no significance in ConfigMgr. However, the "newly" discovered systems will report in to the console that they indeed have clients once they check in with a DDR (Data Discovery Record) generated by the heartbeat discovery every 7 days by default -- maybe you have lowered the heartbeat discovery interval to every day.

    To force them to update immediately, just run a Data Discovery Cycle from the actions tab in the ConfigMgr control panel applet on the client, wait a minute or two, and then update the collection membership.
    Jason | http://myitforum.com/cs2/blogs/jsandys | http://blogs.catapultsystems.com/jsandys/default.aspx | Twitter @JasonSandys
    • Marked as answer by RogerRen Wednesday, September 16, 2009 3:55 AM
    Wednesday, September 16, 2009 3:11 AM
  • The client will re-register automatically depending on the site configuration.  The easiest way to force a re-register to un-install and re-install the client.  That will force the client to re-register with the site server.
    Gabe Brown, Configuration Manager 2007
    • Proposed as answer by Gabe Brown [MSFT] Wednesday, September 16, 2009 3:20 AM
    • Marked as answer by RogerRen Wednesday, September 16, 2009 3:55 AM
    Wednesday, September 16, 2009 3:19 AM
  • DDR's don't work the same way in ConfigMgr 2007 as they did in SMS 2003.  These were deprecated in favor of registration messages.  See ClientIdManagerStartup.log for more details.

    Gabe Brown, Configuration Manager 2007
    Wednesday, September 16, 2009 3:20 AM
  • Thanks for all your reply to make clear for this process :)
    Wednesday, September 16, 2009 3:55 AM
  • Wouldn't it be easier to force the Heartbeat discovery to occur?

    You could use the right-click tool to make that happen and that would be a lot less work and network traffic then a client re-install.
    http://myitforum.com/cs2/blogs/rhouchins/archive/2008/04/09/sccm-right-click-tools.aspx
    http://www.enhansoft.com/
    Wednesday, September 16, 2009 3:14 PM
  • Heartbeat discovery would just find the client via discovery again which he has already done, it would not cause it to re-register. 
    Gabe Brown, Configuration Manager 2007
    Wednesday, September 16, 2009 4:30 PM
  • What do you mean by re-register? Isn't heartbeat that re-registering process? Can you point us to a Doc article?
    http://www.enhansoft.com/
    Wednesday, September 16, 2009 4:38 PM
  • Registration is a different process than discovery in SCCM 2007. 

    MyITForum has a good article on it.
    http://www.myitforum.com/articles/42/view.asp?id=10773
    Gabe Brown, Configuration Manager 2007
    Wednesday, September 16, 2009 4:44 PM
  • I agree that's a good article, but it is very short on details of the registration process. We're not disagreeing, we just want more information. My searches have turned up very little about things like when registration occurs? Does it recur? Is there a way to manually initiate it? What information does a registration provide to the server? The SDK has some details, but most are implementation specific and not operationally relevant.
    Jason | http://myitforum.com/cs2/blogs/jsandys | http://blogs.catapultsystems.com/jsandys/default.aspx | Twitter @JasonSandys
    Wednesday, September 16, 2009 5:18 PM
  • I agree Registration documentation could use some additional articles.  We've got a few more articles were hoping to get publshed.

    Registration occurs on the client once its first installed and the details on status are stored in System32\CCM\Logs\ClientIDManagerStartup.log.  All activities are blocked until the client can successfully register with the Management Point.  It does re-occur when the client detects that it needs to re-register (varies between native and mixed mode).  There is not an easy way to manually initiate registration without running a vbs script to edit WMI and restart the client.  To see clients that are registering on the MP, look at the MP_RegistrationManager.log
    Gabe Brown, Configuration Manager 2007
    Thursday, September 17, 2009 1:38 PM
  • It does re-occur when the client detects that it needs to re-register (varies between native and mixed mode). 
    Thanks Gabe. Can you expand on the above statement a little? (or should we be patient and wait for the document updates, or better yet can you get Garth and I draft copies via Wally :-) )

    Jason | http://myitforum.com/cs2/blogs/jsandys | http://blogs.catapultsystems.com/jsandys/default.aspx | Twitter @JasonSandys
    Thursday, September 17, 2009 2:03 PM
  • I would be happy with the VB script too and what to look for in the respective log files. <Grin>


    http://www.enhansoft.com/
    Thursday, September 17, 2009 2:46 PM
  • In native mode, the client detects that it must re-register on the next policy assignments request.  In mixed mode, the client detects that it needs to re-register when it requests policies containing sensitive data.  I'll put up a blog post in a few weeks that covers the topic more in depth.

    Gabe Brown, Configuration Manager 2007
    Thursday, September 17, 2009 3:11 PM
  • The subject of registration is something that Gabe & I have been discussing for a while.  You won't find information about this in the product documentation because it's supposed to be transparent to the administrator - it's a process that happens under the covers at the end of succeesful site assignment and there's nothing for the administrator to configure.  As such, the product group made the decision that it doesn't require documenting, and exact details of how this works might change from version to version if changes are needed for additional reliability or security, or to accommodate new features in the product. 

    However, we have been getting a few customer questions about this when they encounter client problems and see references to registration errors in log files - and hence the decision for a blog post to help customers who want to understand what's going on.

    We'll post this to the System Center Configuration Manager team blog (http://blogs.technet.com/configmgrteam/default.aspx) and update this thread when it's available.


    - Carol


    This posting is provided “AS IS” with no warranties and confers no rights
    Friday, September 18, 2009 4:33 PM
  • I notice this post is a little outdated and was hopeful to see an update from Carol.  I searched the SCCM team blog and did not find any updated documentation regarding client registration.

    I am new to SCCM and recently inherited an existing 2007 R2 installation.  I have a similar scenario as Roger started this thread with.  I have about 1% of my clients that have a status of Client=No (value=0) in the console (and I have no historical knowledge as to why).  I can resolve most of these with an uninstall/reinstall of the client as mentioned in this thread.  That is a little time consuming and through monitoring of the client logs I have noticed that many of the clients think they are registered:

    "ClientIDManagerStartup.log "

    • RegTask - Executing registration task synchronously.
    • Reg Task: Client is registered, exiting.

    After performing the client uninstall and then a fresh install I see the following entries:

    • RegEndPoint: Received notification for site assignment change from '<none>' to 'MED'.
    • RegTask: Client is not registered. Sending registration request...
    • RegTask: Client is registered.

    It would be nice to have a more efficient mechanism to force the registration or in this case the "re-registration" of the client.  That being said here is my question.  If the client "thinks" it is registered and the console thinks it is not, who wins?  Is the client really in an unmanageable state?

    Thanks,

    Todd

    Thursday, July 1, 2010 3:34 PM
  • Todd, to address your first point - unfortunately Gabe is no longer with this product group (why no blog post to date) but this request is not forgotten and we're looking into finding an alternative source to provide more information about registration.
    Monday, July 12, 2010 7:56 PM