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?

So I pointed the intranet location in the windows update GPO to the correct site, http://WSUSServerName:8530, and now it seems to see the site, but the install of the client fails.

And that's the problem, is getting the client out initially. Is that not possible to do with a software update point? Most of the machines have the old SMS 2003 client on them, but need to be upgraded and client push is not working, without taking the firewall down completely on XP client machines. As for the WSUS install, I believe that was 8530 and 8531. Is it normal for there to be 2 websites as follows? I know Default Website always exists, but it seems to have alot of the SCCM related materials under it. That one is port 80 and 443, and the "WSUS Administration" site that I can't really browse is 8530 and 8531.

I changed the ports for the SUP in the general tab of the component config to 80 and 443 and it then causes the SMS_WSUS_CONFIGURATION_MANAGER to generate error ID 6600. "SMS WSUS Configuration Manager failed to configure upstream server settings on WSUS Server "Servername".

Ok, I did that and now it looks like the computer is looking towards microsoft updates to get updates. How do I get client machines to use the SUP? I had the "Configure Automatic UPdates" specified to point to the server, but turned that off. Am I missing something here? The client machines don't have the SCCM 2007 client yet, so I am at a loss as to how they are pointed at the SUP to get the client and updates.

Allright. I disabled the old WSUS GPOs and opened the ports in the firewall that are needed. Hope this works. On a side note, I also noticed that in IIS there is a "Default Website" as well as a "WSUS Administration WebSite". Should both of these be present? when I go to the default site in a browser at http://servername:80 it works and displays the general "IIS 7" page, but I get access denied when trying to go to http://servername:8530. Could this be the issue? Under the "software update point" general tab, the port numbers are set to 8530 and 8531. Should those be changed to 80 and 443???

We recently installed a fresh SCCM 2007 site on our existing WSUS 3.0 SP1 server. To get SCCM to properly exist with WSUS, we also did a fresh install of WSUS 3.0 SP1 and cancelled at the config screen as instructed. We don't want to disable the windows firewall or open a broad range of ports to install the new SCCM client, so we are having issues pushing the client. This caused me to look at deploying it through the SUP, but ever since performing the fresh install of WSUS on the SCCM server, client machines (with the old SMS 2003 client) are not commuticating with the WSUS portion of SCCM. On client machines I am seeing the following error messages in the Windowsupdate.log file. I have changed our GPO for WSUS from http://WSUSServerName to http://WSUSServerName:8530 since port 8530 is what the SUP is configured to use, where our old WSUS was using 80. Despite forcing a group policy update and running wuauclt.exe /detectnow, this error persists. Any ideas and input would be appreciated, as we need to get the new sccm client out on the domain ASAP. Thanks!

We recently installed a fresh SCCM 2007 site on our existing WSUS 3.0 SP1 server. To get SCCM to properly exist with WSUS, we also did a fresh install of WSUS 3.0 SP1 and cancelled at the config screen as instructed. We don't want to disable the windows firewall or open a broad range of ports to install the new SCCM client, so we are having issues pushing the client. This caused me to look at deploying it through the SUP, but ever since performing the fresh install of WSUS on the SCCM server, client machines (with the old SMS 2003 client) are not commuticating with the WSUS portion of SCCM. On client machines I am seeing the following error messages in the Windowsupdate.log file. I have changed our GPO for WSUS from http://WSUSServerName to http://WSUSServerName:8530 since port 8530 is what the SUP is configured to use, where our old WSUS was using 80. Despite forcing a group policy update and running wuauclt.exe /detectnow, this error persists. Any ideas and input would be appreciated, as we need to get the new sccm client out on the domain ASAP. Thanks!