- 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
<message edited by Neiro on Tuesday, June 12, 2012 3:48 AM>
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).