We have SCCM configured with WSUS and Software Updates configured on a separate server (not the MP) but have only started testing it. At the moment WSUS is handled by another server and this is not used via SCCM, so a GPO is in place to tell workstations which WSUS server to go to. To test the software updates, I created a test group to deploy IE8 to which consisted of 5 computers. I moved the 5 test machines to a separate OU where I blocked inheritance to the WSUS GPO and started a Software Update Scan Cycle and a Software Update Deployment Evaluation Cycle manually. All of them completed the cycles successfully and automatically displayed the balloons to inform users that a software update was available. On 2 of the PCs I started the software update process manually and on the remaining 3 I waited until the deadline was hit and it installed automatically. All 5 computers installed the update successfully and required a restart afterwards. I manually initiated the restart on 2 and waited for the others to restart on their own. They all reported a success on the local UpdateDeployment.log. However, and despite the fact that I can't find any indications as to why it could have failed, when looking at the SCCM console software update deployment status for this particular software update it says 5 machines targeted, 1 machine successfully installed, 4 machines unknown deployment status. I have checked the WSUS Agent Version and it is WSUS 3.0 SP1 on all clients, I checked the ISS logs, WSUS logs, etc and I can't find any errors on either. I cannot figure out why the deployment status is still flagged as unknown after it was successfully installed on all workstations. I tried manually initiating another Software Update Scan Cycle and it completed successfully, saying no updates need installing, but the information is still not reflecting on SCCM. Any help would be appreciated. Cogu

I have seen this issue a few times before, everything is going OK in the client but for some reason status messages are not replicated to the site server. I normally fix the problem by running this script in the clients Option Explicit On Error Resume Next Call RefreshServerComplianceState ' WScript.Echo "Finished" Sub RefreshServerComplianceState() ' Initialize the UpdatesStore variable. dim newCCMUpdatesStore ' Create the COM object. set newCCMUpdatesStore = CreateObject ("Microsoft.CCM.UpdatesStore") ' Refresh the server compliance state by running the RefreshServerComplianceState method. newCCMUpdatesStore.RefreshServerComplianceState ' Output success message. ' wscript.echo "Ran RefreshServerComplianceState." End Sub Kent Agerlund | My blogs: http://blog.coretech.dk/author/kea/ and http://scug.dk/ | Twitter @Agerlund | Linkedin: /kentagerlund

Kents on the money, the SDK is the way to resend these compliance state messages to the MP. http://msdn.microsoft.com/en-us/library/cc146437.aspx

That didn't solve my issue unfortunately. I ran the script as suggested, I can see on the client UpdateStore.log the lines appearing (amongst others ofc): Successfully raised state message for update (eb2d095f-ef0d-438a-b58a-71b12ff5a08a) with state (Installed). Resend status completed successfully. Where eb2d095f-ef0d-438a-b58a-71b12ff5a08a is IE8. However, SCCM refuses to display the correct information for these clients. I ran this about 20m ago so it is not a matter of waiting either. On the WSUS console it states these computers have never reported at all, so it doesn't even know if they need the update or not. I can't think of anything else to check.

At the moment WSUS is handled by another server and this is not used via SCCM, so a GPO is in place to tell workstations which WSUS server to go to. I had to re-read your original text, to see the above which is unsupported. ConfigMgr has to be in control of WSUS, or you don't have the integration taking place. If ConfigMgr is managing Software Updates then you must disable the GPO as this is unsupported. My advice would be to implement this again, but instead create a new WSUS installation and let ConfigMgr control it.

SMS Marshall, I probably didn't explain that part as well as I should :) At the moment windows updates are being delivered through a standalone WSUS server and we have a GPO in place to point computers to the WSUS server. We want to move away from that and start using SCCM to deploy updates. I have build a WSUS server from scratch and added it as the Active Software Update Point to SCCM. Because the (new) WSUS server is not the site server, I also installed the WSUS console onto the site server, as per Microsoft's instructions. I then created a test group of computers to test the new SCCM SUP and moved the workstations to a different OU so that they would not get the WSUS GPO for the old server. That bit works ok, in the same way the SCCM SUP is being able to deploy Software Updates to the test workstations. The problem is, they are not reporting back. Hope this helps explain the situation better. EDIT: I've just created a second test group of 10 PCs and deployed the same IE8 package to them. About an hour after I advertised it to the second test group, all computers that were in the first test group reported this software update as having installed successfully. As it stands at the moment, all 10 PCs in test group 2 have received the update and are waiting for the user to start installation/for the deadline to force it. This means all 10 computers have already evaluated the update and realized it is missing. However, SCCM still says the IE8 package is in "unknown" state for all 10 PCs.

6 of the 10 PCs of test group 2 have now successfully IE8 and restarted. The SCCM console still says the deployment status is still "unknown" for all 10. I am struggling to understand what is wrong here.

can you try to run gpupdate /force and the check RSOP on the client? I've had this issue before only to know that WSUS policy is still in place for the affected computer ---Packie

can you try to run gpupdate /force and the check RSOP on the client? I've had this issue before only to know that WSUS policy is still in place for the affected computer ---Packie

Hi, This issue can be caused by the AD computer records in question have a different FDQN in DNS. Therefore when discovery runs and tries to check the AD records against DNS this fails. In that situation ConfigMgr should then fall back to checking the NetBIOS name, however that is not happening as expected. You may refer to the following KB article to check if the hotfix works: The Active Directory system discovery process cannot detect a client if the DNS suffix of the client differs from its DNS domain name in System Center Configuration Manager 2007 SP2 Regards, Sabrina This posting is provided "AS IS" with no warranties or guarantees, and confers no rights. |Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

can you try to run gpupdate /force and the check RSOP on the client? I've had this issue before only to know that WSUS policy is still in place for the affected computer ---Packie Packie, if that was the case they wouldn't even install the update. They are installing the update.

Hi, This issue can be caused by the AD computer records in question have a different FDQN in DNS. Therefore when discovery runs and tries to check the AD records against DNS this fails. In that situation ConfigMgr should then fall back to checking the NetBIOS name, however that is not happening as expected. You may refer to the following KB article to check if the hotfix works: The Active Directory system discovery process cannot detect a client if the DNS suffix of the client differs from its DNS domain name in System Center Configuration Manager 2007 SP2 Regards, Sabrina This posting is provided "AS IS" with no warranties or guarantees, and confers no rights. |Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. That KB is something I have been meaning to install anyway, as AD System Discovery sometimes fails when attempting to resolve a computer by it's FQDN and does not fallback to NetBIOS (which I know it should). Unfortunately haven't had a chance to install that yet. But I can't see how that would affect software updates, seeing as the client is healthy, communicating properly with the SCCM server and has accepted (and successfully installed) the software updates I deployed. Back to the issue at hand, I just noticed when I came in today that the IE8 package still shows a deployment status of unknown for the 10 machines in test group 2, despite the fact that *I know* it has installed successfully. However, the percentage of compliant clients has gone up from 46.82% to 47.03%. Something tells me that around 13:30~ today the report will update itself properly (which will be in 2 hours time). If that's the case, then it is taking 24h to refresh. And if that's the case, my question then becomes: why and how to I change the cycle? Also, notice that this has nothing to do with the clients: I forced all of them to refresh the compliance state which I can see in the log files they did successfully. It is not like the information is not getting to the server, it's just that the server is not refreshing it properly. cogu

OK, try opening the Offsum.log and seeing what it is doing with the summarization of offers (advertisements). Any indication its not sane?

Not entirely sure how to interpret that log, but everything looks fine there. Also, I just refreshed the software update and it is now reporting the correct information for test group 2, 24h~ after I advertised it.

Not entirely sure how to interpret that log, but everything looks fine there. Also, I just refreshed the software update and it is now reporting the correct information for test group 2, 24h~ after I advertised it. I am still having the same problem I originally described: it takes a full 24h~ to show the updated information, I was expecting it to be pretty much instant after the workstations send the update status back to the server.

It should be with you far quicker than 24hr, Is there any indication whether your site is under performing? I'm shooting blind, I don't have a solution, but I do recall something about this years ago, maybe search over this forum and see if you can bring anything up. Something is not right in your environment, obviously, I wonder if WSUS has been "tweaked" via it's console and not left at defaults? Not sure sorry.

I inherited the SCCM as it is and I've only started looking at it now. It has a few issues and I feel like I've only hit the tip of the iceberg, so there might be something that is causing the issue underneath. As far as WSUS goes, the SCCM I inherited already had Software Updates configured. I completely uninstalled it from the server it was in before (SCCM Site Server) and did a new installation on a separate server, so I know the WSUS was installed properly. I did not, however, manage to get rid of the existing metadata. To answer your question more specifically: it is under performing in a few fronts, but this should not be one of them, specially taking into account I completely reinstalled WSUS on a new server. WSUS has not been touched at all and left as default so that SCCM could take over. I am sure the answer to this is going to be something really silly, but I'm just not quite sure where to start looking. I don't have any issues with re-installing WSUS as a whole, even formatting the server it is currently installed on to start afresh (it's a virtual server anyway) if there is anything to be gained from doing so. However at the moment I don't see any advantage in doing that, seeing as I installed it just last week and left it as default. On the other hand, I cannot see the problem being anywhere else, no matter how many issues SCCM has at the moment. It could be that deleting the existing metadata could help, but I could not find any instructions on how to do that (I even found a thread where someone asked that and no one could answer at the time). cogu

I don't think anyone on here is brave enough to suggest culling data from the SU tables directly as it isn't really supported! :-( That'd be something CSS would work with you to solve. So, you have just a single Primary, WSUS, and defaults lead to your 24 hour delay? Hmm ... are you sure the GPO's for WSUS are not presented to the clients? That can stop the SU agent from functioning, it doesn't make sense that if it was configured, that you'd have to wait 24hrs ... could be that the client sets it, then GPO is applied a while later, but before it does the payload is sent up to the correct WSUS server. I've seen the SU agent become disabled simply because the GPO is overriding the WSUS server, even though the override introduces the same server names ...

Single, primary WSUS, yes. It can't be the GPO's. The clients I am applying these software updates to are in an OU that doesn't have any GPOs for WSUS, so they revert back to "not configured" (which I agree is a lot better than trying to configure it to be the SCCM server). I've done a RSOP to confirm that and the WSUS settings are set to "not configured" on those clients. When they weren't, I wasn't even able to deploy any software updates to them at all since GPO was overwriting it. I can deploy software properly and I can see that the clients are sending the update information back to the server without any errors, which leads me to believe that the problem is not on the client. When I ran the script on Kent Agerlund's post the logs on the client say it succeeded in refreshing the compliance state (which leads me to assume it also succeeded in sending it to the server). cogu

I had a chance to do some more testing today. Up until now I was not too sure whether the 24h delay started counting from the time I advertised a certain software update, or if it was that the information would only update once every 24h, always at the same time of the day, regardless of the software update that I deploy. Today I deployed IE8 to 100 PCs at 12:00. About 2h later I checked it again and it said 48PCs had already installed it successfully - which means it only updates the information once every 24h, regardless of when the software update was distributed. Though something we can live with, it is not ideal... However I'm confused about something: I thought that it would be the WSUS server to receive the compliance state, rather than the SCCM SUP directly. And that the SCCM SUP would then query the WSUS server database for information about client compliance. If this is the case, then the problem might be somewhere between WSUS and SCCM (specially seeing as they are on different servers). cogu

However I'm confused about something: I thought that it would be the WSUS server to receive the compliance state, rather than the SCCM SUP directly. The result of the scans are sent to the MP using state messages. No WSUS involved. Torsten Meringer | http://www.mssccmfaq.de

If that's the case, then I can't see how the delay could have anything to do with the WSUS config: the updates are definitely being delivered from the SUP and the client logs say the compliance states are being sent to the MP. The only problem is the information only updates every 24h... If the data is sent to the MP, it would be saved onto the SCCM database, any chance you'd know which table to look at to do a manual query and see if the information is being written to the DB? cogu

This is still only updating once every 24hours, though it doesn't seem to have an exact to the minute hour for refreshing. It's somewhere between 13:30 and 15:00, haven't been able to narrow it down any further yet. Does anyone have any idea on which table the compliance state messages are saved? I'd like to do a manual query to make sure the data is actually there...

This is still only updating once every 24hours, though it doesn't seem to have an exact to the minute hour for refreshing. It's somewhere between 13:30 and 15:00, haven't been able to narrow it down any further yet. Does anyone have any idea on which table the compliance state messages are saved? I'd like to do a manual query to make sure the data is actually there...

Found the table that holds the information about software updates and ran the following query directly on the database: select Name0, title from v_R_System a left join v_Update_ComplianceStatusAll comp on a.ResourceID=comp.ResourceID join v_UpdateInfo ui on comp.CI_ID=ui.CI_ID where comp.Status = 0 and ui.ArticleID = 944036 and a.ResourceID IN (SELECT MachineID FROM CollectionMembers WHERE SiteID = 'XXXXXXXX') ORDER BY title comp.Status has 4 possible values apparently: 0 - unknown 1 - not required 2 - required 3 - installed With the query above I came to the following results (total sample 109 PCs): 22 computers with status 0 5 computers with status 1 10 computers with status 2 72 computers with status 3 However, the SCCM deployment status shows different results: 23 computers with status 0 4 computers with status 1 9 computers with status 2 72 computers with status 3 The results vary on different levels: the database query returns a total of 109 computers, whereas the SCCM deployment status says there's only 108. Also the computers with status 0, 1 and 2 differ. In other words, the information seems to be in the database, SCCM just happens to only fetch that information once a day. Right clicking refresh on SCCM does nothing. This still an issue and I'd appreciate any help you can give me to solve it.

http://technet.microsoft.com/en-us/library/bb694051.aspx: "run homepage summarization"Torsten Meringer | http://www.mssccmfaq.de

Thanks Torsten, I had the feeling updates were not immediate. This partially solved the problem. Forcing a "run homepage summarization" updates the status of all computers known to SCCM, but does not update the status of computers in my deployment package. Here's an image that better explains what I mean: http://imageshack.us/photo/my-images/269/sccmdeploymentstatus.jpg/ Is there a way of forcing the deployment status of my deployment package to update any faster? It's still taking 24~ hours or more.

This is still an issue, at the moment I'm being forced to run queries directly on the database to find out the compliance state of my deployment group. Can anyone help shed some light on this? Let me know if you need more information as well.

If you haven't managed to fix this, I would suggest logging a call with CSS who will be able to help you further.