Need an explanation of how sccm handles client name changes

[Neiro]

A couple days ago I posted the following on myitforum with a total of zero replies. A friend then suggested I try here, so that's what I'm doing.

We want to redeploy a couple hundred computers over the summer hollidays, and I've yesterday started doing so. I just can't figure out why SCCM does what it does (read: as slowly as it does).

 

Our observations:

• If we redeploy a system and afterwards change its name, we have to reinstall the sccm client. If we do not, it seems to have simply lost the connection to the server and never tries to recover. We tried leaving it like that for a week.
  

• If we rename a system before redeploying, we have to wait for the discovery data cycle to complete. Despite this being scheduled to run once every hour, we still see roughly 11.5% systems not being shown by their new name in the sccm console after 16 hours.
  Turns out power management puts computers in sleep mode after 10 minutes once working hours end. I made that test roughly 70-90 minutes before it would enter sleep, so those claimed 16 hours were really just 1-1½ hours.
  

• Forcing the discovery cycle to run works on 75% of the systems that haven't updated within 30 minutes or so of initiating.*
  

• When a system is renamed, the ad object that is discovered appearently isn't merged with the client object in the collection view, meaning everything's there twice. AD object isn't approved however. After some hours the ad object is removed from the listing. Exact amount of time unknown, but less than 20 hours.
  

• When a system is redeployed, the collection view lists both the new and old client object data. It has marked the correct ones as obsolete.
  

 

* I've seen one machine that the sccm console still listed with the old name still get the new one after redeployment. Not sure if it had sent discovery data just before rebooting or if sccm just takes time to clean up the database.

 

 

Now what I want to know is what makes the name change process take so tortourously long to take effect. Even when forced it seems to take an eternity in terms of working hours.

We don't know what steps to take to reduce the delay between a change happening and the system center knowing it's happened.

 

Discovery cycles:

Heartbeat every hour.

AD user discovery every 30 minutes.

AD system discovery every 5 minutes. (might be a mistake, will check with a collegue later)

AD system group discovery every 5 minutes. (same as above)

AD security group discovery not anabled.

Network discovery not enabled.

 

Client cycles:

Hardware Inventory once a day.

Software Inventory every 3 days.

Desired configuration every 7 days. (don't think we use this)

Software metering every 7 days.

Software updates every 7 days.

Computer Client Agent Polling every 30 minutes.

Computer Client Agent State messages every 15 minutes.

Mobile Client Agent polling every 30 minutes with 5 retries 3 minutes apart.

 

 

System specs:

A single SCCM 2007 server (4.00.6487.2000) acting as everything. Local SQL server, local distribution point.

A single Windows DC forrest with just under 2600 computers.

Most client computers use SCCM client verison 4.00.6487.2157 while some older installations still run on 4.00.6487.2000

The connection between locations and systems are provided by layer 3 switches and an MPLSlike connection provided by a local ISP. Minimum bandwidth is something like 600Mbit

[scambler]

Neiro

 

If you rename a client and it has a record in ConfigMgr, it has to run a heartbeat discovery cycle and the DDR then has to be processed. - Heartbeat runs weekly by default.

once Heartbeat has run it will match the client guid so a new client record is not created.

However, if you have AD System Discovery enabled and it runs before the heartbeat discovery, the system name that has been changed in AD will be discovered, there will be no matching GUID, therefore a new record is created with client = no when in fact a client is installed.

Eventually when heartbeat runs and updates the record you will see client = yes, you will then end up with two records. One = no and one = yes.

I would try updating your heartbeat to once a day, or as often as AD System Discovery.

 

HTH

 

Why are you renaming systems?

[Andreas Dalman]

We encounter the same issue in our organisation.

 

Is there any way to force a 'heartbeat' check on demand (from the SCCM Console or the target machine)?

 

I have found sometimes running Client Notification > Collect Discovery Data from the SCCM console from right click menu on a device host entry or the ConfiMgr Actions on the target host forces SCCM to recognise the new name, but not always (I understand the Device Discovery Action does the trick, but on endpoints when I do this I tend to run them all as well as the compliance checks in the 'Configuration' tab of the ConfMgr client applet in the Control Panel).

Why this does not work 100% of the time interests me. The devices I am doing this on appear connected (green tick) on the SCCM console, so I assume the endpoint clients are active/seen.

 

Why we rename

• We lease computers and they need to be changed when the leases expire.
• On-prem machines have names that suit their location. These do not change (but the hardware does).
• In high profile spaces (used often/hard to book out) where the machine uptime needs to be near 100% we rename the old ones adding a letter to indicate it is being swapped imminently.
• Once the old ones are renamed, new machines can be imported to SCCM with the correct names, then imaged and software deployed in our IT office/work area and then replaced when the target location has an opportunity window.
• Renames are done manually on the old/outgoing target machines (AD and Intel EMA Server entries update immediately).

  Andreas

Edited December 7, 2023 by Andreas Dalman

[GarthMJ]

Do you have SW inventory enabled? How often is it enabled? What do the log say when you trigger the Heartbeat discovery on the client?