Some clients reporting "No Status" for an advertisement

I'm having a problem with machines receiving an advertisement.
 
The initial issue was that around 1/3 of machines were not receiving the FEP advertisement and were reporting back “No Status." All other machines received the advertisement and processed it.

o   All these machines appeared fine in all other reports such as hardware and software inventories
o   I discovered that on a sample selection of machines their logs still showed HQG (the old SMS site code) instead of MON (the new SCCM07 site code). I checked this against what the ConfigMgr server and the ConfigMgr console, on the server, said and they all show as being MON.
o   Using the SCCM Right-Click tools addon as well as a Client Actions Tool program I began forcing the clients to change the site code to MON. Being as the machine has to be on and connected to the network in order to force this change it has been slow going.
o   On the sample selection of machines I watched their logs while making the change in site code. They both accepted it and shortly thereafter processed the FEP advertisement.
o   I then relaxed and began running the previously mentioned programs to update the site codes on the remaining machines as they connected
 
After a few days I noticed that many machines still reported as having “No Status.” This time when looking into a new sample selection of machines (as my previous sample selections had all worked) I saw that they were properly getting the new site code of MON. The only errors I can find in their logs now are in ccmexec.log:
o   OutgoingMessage(Queue='mp_[http]mp_policymanager', ID={86F63D02-045B-4DB5-AE99-484B7E2E1B82}): Will be discarded (expired).
o   Request failed: 403 Forbidden
o   When I use the SCCM Client Actions Tool program to “Get management point” it comes back saying the correct management point.
 
As background info clients are on either XPx86 SP 2 (yes... still a few of them), XPx86 SP 3, or W7x64. Some are connected on LAN some only connect occasionally over a VPN and any type of connection they can find, worst case being a mobile datacard. We moved from SMS 2003 -> SCCM 2007 R3 about 2 years ago. And... my brain is slightly fried from dealing with this so I can't anticipate anymore of your questions but will respond to them as quickly and intelligently as I can.
 
This is as far as I’ve gotten with troubleshooting and I really don't know where else to look. Any help is greatly appreciated.  

Just as a test, I have no idea is this would be a good long term solution or not--if it even works--but using Roger Zanders' Client Center, if you do a hard policy reset, does that kick any 1 specific client into working?

I will try that tomorrow.
 
As additional info the SMS server is no longer active and I have defined boundaries based on AD site.

boundaries: once a client is joined to the sitecode, it won't move or reassign to another site based on boundaries, not automatically.  ADSite boundary definitions are fine, although I've heard that IP Ranges can be a lot more reliable (NOT IP Subnets, IP Ranges, I want to be clear about that).
 
SMS Server is no longer active?  you mean the old one? that's fine.

I performed the hard policy reset from the SCCM Client Center tool and it does not seem to have made a difference. I am still seeing these errors in the ccmexec.log
 
OutgoingMessage(Queue='mp_[http]mp_policymanager', ID={80408F4E-1111-46A2-854C-143690540463}): Will be discarded (expired). Request failed: 403 Forbidden
 
I don't know, but I don't feel like this is a boundary issue. The initial issue of clients not getting the correct site code may have been a boundary issue, but that is mostly fixed. Now I keep running into this 403 error.
 
 

Yes, I agree, it's not a boundary issue; you mentioned that you modified your boundaries so I didn't want you to follow that, thinking it meant something.  In this case, I don't think it does.
 
the "outgoingMessage"--that's outgoing.  I know you did a full policy reset, but after you did that, did you want policyagent.log?  and see a ton of policies arrive?  does the box do heartbeat, hardware and software inventory (inventoryagent.log)?  If it does, does that "make it" to the management point?  (look at the logs on the MP, like mp_hinv.log)
 
one possibility...do you have a firewall on this box?  what if you disable it?  Maybe it's just as simple as firewall misconfiguration.

I wouldn't say a "ton" of policies but the user policy and machine policy did refresh. Heartbeat and software inventory work fine.
 
The mp_hinv.log doesn't have any records from the one computer I'm currently monitoring regarding this issue.
 

 

I had begun to think that it was a certificate issue and had our network admin check it out, as I know nothing of certificates.
He said that the cert is fine but the problem now appears to be that the clients with problems are not communicating on port 443, only port 80.

 
Any ideas on how to move them over to port 443?

Check this first...On a working client, if you use Roger Zanders Client Center, query the HTTP Port (the magnifying glass next to it).  Is a working client using 443?
If so, connect to a non-working client; and query that one.  If it says 80, not 443, then go ahead and overwrite it, and hit the save button.
 
PS: I know how to do this 1 by 1 in client center; I would guess it can be automated to change the port, but I'm not sure how (because I've always worked for companies that communicate via port 80, so I've never had to care).

I checked this and on a working machine it is set to 80.
 
Though before this I took a step back and looked at the problem from the top down and realized that I made a foolish assumption. All the clients that are having these issues were not upgraded to SCCM. They are showing version 2.50.4160.2000 instead of version 4.00.6487.2000.
 
So now the question turns to why they were never upgraded. Since SCCM was installed (by a consultant) there has been a collection of Systems needing client upgrade and a deployment of the client upgrade package targeted to them. I've also just done a client push installation to that collection and it seems to have had no effect thus far. Any ideas of where to start looking?

That seems to be working. Thanks!