Need an explanation of how sccm handles client name changes

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

Yes, I know this is an old post, I’m trying to clean up older posts that are unanswered.
Did you ever figure this out? If so how?
 
I bet your AD discovery are getting back logged..  every 5 minutes for a Full discovery is way too often.

5 minutes might very well be too quick. Can it be cause for error or merely cause a delay? 
 
Anyhow, I ran into an interesting situation yesterday. 
Wednesday the 20th I renamed around 80 computers from their old name to the new naming system and added a location info to the description field in AD. I left the computers on to make sure they'd do a discovery data cycle and SCCM would know. 
Thursday the 28th I then redeployed roughly 130 systems and went home. 
Then yesteday, monday the 2nd, I was back to this address to make an interesting find! 
Those systems that I had renamed on the 20th had been reinstalled using their old name but that's not all! They'de reused the old computer account id and thus were in the right containers, but with the description field cleared. However those who's name I'd changed earlier still (a few days after posting this thread) were added to the domain with the right name and description.
 
All of our AD guys are on hollidays or otherwise not available, so I spoke to a few other collegues, and while none of us are experts on AD we agreed that this behavour is odd. I would've thought the system would simply create a new computer object with the 'new' (old) name and be dumped in the default container if the sccm database didn't contain the updated name, and nobody had a theory on why the description field was blank. 
 
Until that observation yesterday I had assumed that in order to make name changes effectuate, what you need to do is wait for the sccm client to connect to the server properly, rename the client and run a discovery data cycle. 
Appearently there's more to it than this.
 
 
As for cycle times - is there a page somewhere detailing what would be good choices? 

Once a day for all AD discoveries is a good choice, if you have R3 then make sure that you enable delta discovery and use the defaults. Remember that Delta discovery only find NEW PCs not old PC or renamed PCs.
 
Until SCCM see the name change via heartbeat discovery, those PCs will continue to display the old name. If you reimage a PC and SCCM still has the old name listed, then it is logical to assume that it will use the old name not the new name.
 
 
I would still look to see if you have a backlog within your inboxes.