Antonius138

Hello all, We have 14 distribution points in our environment including the SCCM server. All 14 points are protected site systems, and all of the update packages are current and refreshed on all of the distribution points. I deployed all of my update lists this morning and I noticed after I deployed the packages that bandwidth utilization is maxing out for all of our 14 sites and we were able to narrow it down to all of the clients communicating with the SCCM server once I deployed the patches. Shouldn't all of these patches be pulling from the local protected distribution points instead of the SCCM server? Any help would be appreciated! Thanks, Anthony

Hello to all, I was wondering anyone was using Forefront Endpoint Protection in a production environment? I just finished installing after working through the fun that is the pre req's. We currently use Symantec Endpoint Protection version 11.x and it was kinda fun watching FEP remove the SEP product on my SCCM server. At first I was a little worried (as I want to test a rollout) that the install automatically attaches itself to all of my system collections but that does not appear to be the case. Anyway looking forward to hearing aout any gotchas or other experiences from the noob crowd. Anthony

Since there was no further help here in the forums, I had to place a call to Microsoft Product Support. So for anyone else having this issue, I discovered that there was a problem in the path for the .wim image which I could hve fixed if I had looked over everything a little mosre closely, the second issue which I would not have found was that the PXE boot files were corrupted and had to be removed, reloaded, and re-distributed. Once those things were fixed, everything worked like a charm. Hope this helps anyone that might have this specific error message. Anthony

Does anyone have any idea on this one? Doing a Google search has only brought up very generic responces some of which I have tried to no avail.

WDS is definitely up and running and the task sequence is available to PXE. I was able to deploy to bare metal machines before in the past, but I havent done it in quite a while. Thanks, Anthony

Hello all, I tried a search but it didnt like PXE in the search field...anyway I have an older and new out of the box Dell Optiplex 980 that I am attempting to run a bare metal PXE deployment to. I am getting the following message: PXE-E51 no DHCP or proxy DHCP offers were received PXE-M0F I have verified that the DHCP server is indeed up and is handing out reservations, I also did get one of the two machines to contact the SCCM server and it started downloading the files but then rebooted and didnt finish the install. I looked at the smspxe.log files and they are a few entries there but they are old. Any help would be appriciated. Thanks, Anthony

Well after further review on a machine that was stuck at "downloading" I went into the ConfigMgr Site info and the config manager agent properties were all blank and the currently assigned site code was blank as well. When I hit discover it came back with "automatic site code discovery was unsuccessful". So do I have to repair this agent in order to get it to re-connect to the site? If so, what heppened to cause this? I also tried to repair the install of the agent but it came back with an error "Setup was unable to create the WMI namespace CCM the error code is 80040154" So are my agents messed up due to the moving of the WSUS server? Anthony

Thanks for the responce. I am definitely starting to think that might be the issue. We had not been able to deploy patches for a long period of time (while I was learning how to use SCCM). And most of our 300+ workstations (at our 14 sites that are pulling all of the updates from one server in one site) had over 60 patches each that were required. Some did not, so I am thinking these are the machines that wereokay and the ones that needed more than 60 are the ones suffering. I will try to release a small batch of updates from the monthly updates list that I created (I think only 4 or 5 updates) and see how that goes. The thing that I am now wondering about is how to make the large group of machines that are having the issues sort of reset and get cleaned up so that I can redeploy. A.

The site information appears to be correct and these are Windows XP SP3 clients that I am referring to. I was not able to locate a smsts.log file on my own Windows 7 client or on the Windows XP client, so I was not able to verify the settings that anywqeb was referring to. The one thing that might be the cause is that we have probably several machines that require over 60 updates (we have not updated in quite a while), so would this cause the issue as mentioned in the link? A.

There is nothing in any of the log files that point to any type of errors and I am starting to get more users who call in to our helpdesk and when I remote in it is stuck at "downloading" for over a day etc. How do I verify that the bounderies and distribution points are configured correctly on the client? Thanks, Anthony

Thanks, am I looking for something specific such as error, I start to get cross eyed when looking through these log files. A.

Hello all, Even after removing the GPO's and steering all of our clients and workstations towards the SCCM server for their WSUS needs, I am still having a few machines that are still stuck in the "downloading" phase even after a reboot. Here is a sample of the windowsupdate.log: 2011-01-27 10:05:49:211 5896 a28 Misc =========== Logging initialized (build: 7.4.7600.226, tz: -0800) =========== 2011-01-27 10:05:49:211 5896 a28 Misc = Process: C:\WINDOWS\system32\cscript.exe 2011-01-27 10:05:49:211 5896 a28 Misc = Module: C:\WINDOWS\system32\wuapi.dll 2011-01-27 10:05:49:211 5896 a28 COMAPI ------------- 2011-01-27 10:05:49:211 5896 a28 COMAPI -- START -- COMAPI: Search [ClientId = <NULL>] 2011-01-27 10:05:49:211 5896 a28 COMAPI --------- 2011-01-27 10:05:49:227 1792 a48 Agent ************* 2011-01-27 10:05:49:227 1792 a48 Agent ** START ** Agent: Finding updates [CallerId = ] 2011-01-27 10:05:49:227 1792 a48 Agent ********* 2011-01-27 10:05:49:227 1792 a48 Agent * Online = Yes; Ignore download priority = No 2011-01-27 10:05:49:227 1792 a48 Agent * Criteria = "IsInstalled = 0 and IsHidden = 0" 2011-01-27 10:05:49:227 1792 a48 Agent * ServiceID = {00000000-0000-0000-0000-000000000000} Third party service 2011-01-27 10:05:49:227 1792 a48 Agent * Search Scope = {Machine} 2011-01-27 10:05:49:227 5896 a28 COMAPI <<-- SUBMITTED -- COMAPI: Search [ClientId = <NULL>] 2011-01-27 10:06:10:309 1792 a48 PT +++++++++++ PT: Synchronizing server updates +++++++++++ 2011-01-27 10:06:10:309 1792 a48 PT + ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, Server URL = http://ourserverhere:8530/ClientWebService/client.asmx 2011-01-27 10:07:06:674 1792 a48 PT +++++++++++ PT: Synchronizing extended update info +++++++++++ 2011-01-27 10:07:06:674 1792 a48 PT + ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, Server URL = http://ourserverhere:8530/ClientWebService/client.asmx 2011-01-27 10:07:06:752 1792 a48 PT WARNING: Cached cookie has expired or new PID is available 2011-01-27 10:07:06:752 1792 a48 PT Initializing simple targeting cookie, clientId = a6ebb018-e427-4a29-b76f-6b7f5e562081, target group = , DNS name = clientpcnamehere 2011-01-27 10:07:06:752 1792 a48 PT Server URL = http://ourserverhere/SimpleAuthWebService/SimpleAuth.asmx 2011-01-27 10:07:36:082 1792 a48 Agent * Found 0 updates and 55 categories in search; evaluated appl. rules of 1090 out of 2034 deployed entities 2011-01-27 10:07:36:548 1792 a48 Agent ********* 2011-01-27 10:07:36:548 1792 a48 Agent ** END ** Agent: Finding updates [CallerId = ] 2011-01-27 10:07:36:548 1792 a48 Agent ************* 2011-01-27 10:07:36:564 5896 13f8 COMAPI >>-- RESUMED -- COMAPI: Search [ClientId = <NULL>] 2011-01-27 10:07:36:564 5896 13f8 COMAPI - Updates found = 0 2011-01-27 10:07:36:564 5896 13f8 COMAPI --------- 2011-01-27 10:07:36:564 5896 13f8 COMAPI -- END -- COMAPI: Search [ClientId = <NULL>] 2011-01-27 10:07:36:564 5896 13f8 COMAPI ------------- 2011-01-27 10:07:41:504 1792 a48 Report REPORT EVENT: {55ADC4F6-5D17-4AAC-9491-BB5F336BF816} 2011-01-27 10:07:36:533-0800 1 147 101 {00000000-0000-0000-0000-000000000000} 0 0 Success Software Synchronization Windows Update Client successfully detected 0 updates. 2011-01-27 10:07:41:504 1792 a48 Report REPORT EVENT: {D04FE02C-8183-4696-9888-CF5FA6E875C5} 2011-01-27 10:07:36:548-0800 1 156 101 {00000000-0000-0000-0000-000000000000} 0 0 Success Pre-Deployment Check Reporting client status.

So the steps that I took last night was to remove WSUS off of the SCE 2010 server, and install it on the SCCM server. I then removed SCE 2010, and created a new GPO that only has the setting of Disabled for the "Allow Automatic Updates" setting with all of the other settings set to "not Configured", finally I unlinked or removed all the other GPO's. I am hoping that this will clean things up a bit and the patching should run a little smoother. I will report back if I have any troubles. Do you think it is okay to have the GPO that I have in there with the not configured for everything except allow set to disabled? Thanks, Anthony

Hey anyweb, I think I might have found part of the problem. We have both a System Center Essentials 2010 Server (which is the WSUS server) and our SCCM 2007 R2 server. When the SCCM server was originally installed we just used the WSUS that SCE was using. Both our servers as well as the workstations had a SCE agent on them. When we started rolling out the SCCM server we discovered that the SCE and SCCM agent didn't play very nicely together, so we removed all of the SCE agents on the workstations. We recently decided to remove the SCE server (we ran into that 50 server limit that was sort of a deal breaker). The SCE server installs three GPO's that are installed by default some of which relate to WSUS, as well as a GPO that we created that pointed to our stand-alone WSUS install that was on the server before we installed SCE. So I was looking through the forums and noticed that you had posted that there should be no GPO's related to WSUS as the SCCM agent takes care of that itself. So, should I remove the GPO's that relate to Windows Updates? When we were first installing SCE we removed the old WSUS GPO and all of the machines pointed themselves back to Microsoft for their patches which was disasterous for us, but all of our workstations and servers have a SCCM agent installed so they should be okay correct? Below is one of the windowsupdate logs that you requested: 2011-01-25 08:38:39:012 1852 e7c Misc =========== Logging initialized (build: 7.4.7600.226, tz: -0800) =========== 2011-01-25 08:38:39:012 1852 e7c Misc = Process: C:\WINDOWS\system32\CCM\CcmExec.exe 2011-01-25 08:38:39:012 1852 e7c Misc = Module: C:\WINDOWS\system32\wuapi.dll 2011-01-25 08:38:39:012 1852 e7c COMAPI ------------- 2011-01-25 08:38:39:012 1852 e7c COMAPI -- START -- COMAPI: Search [ClientId = CcmExec] 2011-01-25 08:38:39:012 1852 e7c COMAPI --------- 2011-01-25 08:38:39:090 1852 e7c COMAPI <<-- SUBMITTED -- COMAPI: Search [ClientId = CcmExec] 2011-01-25 08:40:32:846 1436 c0c PT +++++++++++ PT: Synchronizing extended update info +++++++++++ 2011-01-25 08:40:32:846 1436 c0c PT + ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, Server URL = https://ourservernamehere:8531/ClientWebService/client.asmx 2011-01-25 08:41:13:033 1436 c0c Agent * Found 0 updates and 56 categories in search; evaluated appl. rules of 863 out of 1730 deployed entities 2011-01-25 08:41:13:330 1436 c0c Agent ********* 2011-01-25 08:41:13:330 1436 c0c Agent ** END ** Agent: Finding updates [CallerId = AutomaticUpdates] 2011-01-25 08:41:13:330 1436 c0c Agent ************* 2011-01-25 08:41:13:346 1436 c0c Agent ************* 2011-01-25 08:41:13:346 1436 c0c Agent ** START ** Agent: Finding updates [CallerId = CcmExec] 2011-01-25 08:41:13:346 1436 c0c Agent ********* 2011-01-25 08:41:13:346 1436 78c AU >>## RESUMED ## AU: Search for updates [CallId = {5598EE4E-DA4B-4E74-81B8-73EF38C226D6}] 2011-01-25 08:41:13:346 1436 c0c Agent * Include potentially superseded updates 2011-01-25 08:41:13:346 1436 78c AU # 0 updates detected 2011-01-25 08:41:13:346 1436 c0c Agent * Online = No; Ignore download priority = Yes 2011-01-25 08:41:13:346 1436 c0c Agent * Criteria = "(DeploymentAction=* AND Type='Software') OR (DeploymentAction=* AND Type='Driver')" 2011-01-25 08:41:13:346 1436 c0c Agent * ServiceID = {5598EE4E-DA4B-4E74-81B8-73EF38C226D6} Managed 2011-01-25 08:41:13:346 1436 c0c Agent * Search Scope = {Machine} 2011-01-25 08:41:13:346 1436 78c AU ######### 2011-01-25 08:41:13:346 1436 78c AU ## END ## AU: Search for updates [CallId = {5598EE4E-DA4B-4E74-81B8-73EF38C226D6}] 2011-01-25 08:41:13:346 1436 78c AU ############# 2011-01-25 08:41:13:346 1436 78c AU Featured notifications is disabled. 2011-01-25 08:41:13:346 1436 78c AU AU setting next detection timeout to 2011-01-26 12:47:36 2011-01-25 08:41:13:346 1436 78c AU Setting AU scheduled install time to 2011-01-26 11:00:00 2011-01-25 08:42:09:692 1436 c0c Agent * Added update {374E0100-CAA7-41BC-90A6-DFBAC8D1EA5E}.102 to search result 2011-01-25 08:42:09:692 1436 c0c Agent * Added update {BA040C00-B7D6-4EC5-A29B-2D2EAB504BC8}.102 to search result 2011-01-25 08:42:09:692 1436 c0c Agent * Added update {36B59501-1963-455B-9985-81E6AF53AE0E}.103 to search result Ton of the above but I edited them out so the post wouldn't be too long... 2011-01-25 08:42:09:802 1436 c0c Agent * Found 216 updates and 56 categories in search; evaluated appl. rules of 713 out of 1730 deployed entities 2011-01-25 08:42:09:802 1436 c0c Agent ********* 2011-01-25 08:42:09:802 1436 c0c Agent ** END ** Agent: Finding updates [CallerId = CcmExec] 2011-01-25 08:42:09:802 1436 c0c Agent ************* 2011-01-25 08:42:09:833 1852 c28 COMAPI >>-- RESUMED -- COMAPI: Search [ClientId = CcmExec] 2011-01-25 08:42:09:848 1436 c0c Report REPORT EVENT: {BEBD9579-4603-413B-B3F2-704FDC6D4BEA} 2011-01-25 08:41:13:330-0800 1 147 101 {00000000-0000-0000-0000-000000000000} 0 0 AutomaticUpdates Success Software Synchronization Windows Update Client successfully detected 0 updates. 2011-01-25 08:42:09:848 1436 c0c Report REPORT EVENT: {B068B5B1-0E3F-4B5A-B3BD-969D1C385301} 2011-01-25 08:41:13:330-0800 1 156 101 {00000000-0000-0000-0000-000000000000} 0 0 AutomaticUpdates Success Pre-Deployment Check Reporting client status. 2011-01-25 08:42:09:848 1436 c0c Inv ############# 2011-01-25 08:42:09:848 1436 c0c Inv ## START ## Inv: Inventory Collection 2011-01-25 08:42:09:848 1436 c0c Inv ######### 2011-01-25 08:42:09:848 1436 c0c Inv # Talking to WSUS server = https://ourserverhere:8531 2011-01-25 08:42:09:911 1436 c0c Inv # Downloading Rule file from = https://ourserverhere:8531/Inventory/InventoryRules.cab 2011-01-25 08:42:10:083 1852 c28 COMAPI - Updates found = 216 2011-01-25 08:42:10:083 1852 c28 COMAPI --------- 2011-01-25 08:42:10:083 1852 c28 COMAPI -- END -- COMAPI: Search [ClientId = CcmExec] 2011-01-25 08:42:10:083 1852 c28 COMAPI ------------- 2011-01-25 08:42:10:145 1436 c0c Misc Validating signature for C:\WINDOWS\SoftwareDistribution\Inventory\InventoryRule\InventoryRules.cab: 2011-01-25 08:42:10:145 1436 c0c Misc Microsoft signed: Yes 2011-01-25 08:42:10:192 1436 c0c Inv # Inventory Rule id = 8226C3A1-70D4-4848-B441-1555AC820A23, version = 1.0 2011-01-25 08:42:25:040 1436 c0c Inv ######### 2011-01-25 08:42:25:040 1436 c0c Inv ## END ## Inv: Inventory Collection 2011-01-25 08:42:25:040 1436 c0c Inv ############# 2011-01-25 08:42:30:036 1436 c0c Report REPORT EVENT: {E1A68DA9-2C13-4C7E-89DB-580E14385228} 2011-01-25 08:42:25:040-0800 1 126 104 {00000000-0000-0000-0000-000000000000} 0 0 InventoryEngine Success Inventory processing Inventory: Successfully collected the inventory data 2011-01-25 15:42:44:182 1436 50c AU AU received policy change subscription event

Wow the only way to resolve this issue was to manually update all of the clients? I mean 4 or 5 out of 100 is not too bad, but what it you had 300 or a 1000? I have been a few calls and people noticing that their status has it listed as "downloading" but nothing ever finishes downloading and it never makes it to the "installing" state. Anthony