GopherRob

No. It's a mix of GX620, Optiplex 745, 755, and 960 machines. Some are also dual boot iMacs. Quite a mix. Can I use ccmdelcert.exe in combination with tranguid.exe and possibly get them working? In theory, I imagine this process "Should" work. -Delete SMSCFG.INI (located in C:\Windows) -Run CCMDELCERT.EXE -Stop the "SMS Agent Host" service (needed to restart the SCCM client to generate a new SMSCFG.INI file) -Start the "SMS Agent Host" service -Run TRANGUID.EXE (this is what will regenerate the GUID and force the SCCM client to talk to the server)

I'm at a loss. Even after removing and reinstalling the client, the newly generated SMS Unique ID is identical to what it was before. Why on earth is it generating the same UID? I know for a fact these machines were ghostwalked and given new SIDs when deployed, so I can't for the life of me figure out why they are constantly generating duplicate IDs. Any thoughts?

So after some more digging, the problem seems to be duplicate SMSUIDs from imaged machines. Testing now on deleting the smscfg.ini file from "C:\windows\" and restarting the CCMexec service. I deleted the old entry from the SCCM console for the computer and set AD discovery to run as soon as possible. I'm hoping this does the trick.

Is there something I can run on the client to get it talking right? I guess that doesn't matter until I can get the MP to start accepting policy requests?

One boundary, where the domain is the boundary. We had an SMS 2003 site, but the site name was not the same and it has since been decommissioned and all entries removed from the AD system management container. It appears that the client installed successfully on most machines, but the MP is rejecting them for some reason. IS the problem here with the MP or the clients?

Any ideas about this? I think I am going to try to move the database to a remote server, as the server is running at 80% memory utilization non stop with the database being on a local SQL 2008 instance. I'm not sure if it will help or not, but I've seen several articles that list resource utilization as a possibility for this error. If anyone else has any input it would be greatly appreciated.

So I tried pushing the client manually today and it seems to be working...except it only did half the machines that I sent it to, and now is giving me the following warning for the component SMS_MP_CONTROL_MANAGER: MP has rejected a policy request from GUID:GUIIDofMachineHere because it was not approved. The operating system reported error 2147942405. Access is denied. This is occuring frequently, almost non stop.

No, I did not. I'm not sure how that would help if the client machines with the old SMS 2003 clients still are not seeing the new site.

Just out of curiosity, I tried manually installing the client on another machine with the following command: ccmsetup.exe /mp:SCCM SMSSITECODE=XXX, where SCCM is our Site Server and MP, and XXX is our sitename, and it went and uninstalled the old client, installed the new one, and now reports to the site properly. In the systems management container of AD, it looks like everything is right. It lists: -SMS-MP-XXX-SCCM -SMS-Site-XXX -SMS-SLP-XXX-SCCM I even tried re-publishing the site, and all 3 attributes returned shortly after doing so. So the question is, why won't machines on the domain see it?

the new site is an active directory site with the site name as our domain name.

I think I found our problem. When the client is going to install it is looking for the sitename Default-First-Site-Name, which is how our SMS 2003 server was setup. HOwever, that is not how the boundary is set in SCCM 2007. How do I point it at the right place? Why is it going after the old site? I verified that SCCM published properly to AD's system management container.

SP3

I totally agree with you. I would much prefer to be able to manually push the client out in several waves, but I am yet to find a way to add WMI as a firewall exception on windows XP clients. I did find this link, but it didn't seem to work when I first tried it. http://support.microsoft.com/kb/875605

I think I have hit all of those pages along the way except for the one about configuring ports. As for configuring the SCCM client install policies via Group policy, I didn't think that was necessary since we already extended the AD schema. I thought since that was done, we didn't need to use a the template, but I haven't seen where else I could specify the installation settings. What other methods would you advise for deploying the client? I tried client push, but could only get it to work by disabling the firewall on client machines, which is not an option for us. That is why we are attempting to use the SUP method, which I think we are close to getting working, except for I made some port changes and the WSUS component completely stopped working last night, so I am reinstalling that now, using the default website, which I think may have been an issue initially, because I chose custom and then had the incorrect ports. Hoping this sorts it out, but we'll see. As a side note, it is beyond ridiculous that client push won't work without taking the firewall down on clients.

After checking out the ccmsetup log, it gives me this. Notice the port numbers for CCMport are 80 and 443...I am thinking that is why it isn't installing, since originally I did not have the port numbers correct. How can that package be updated?