Kazi

Does your install account have Administrator access? From your logs, there are access issues with the registry. "RegQueryValueExW is unsuccessful for Software\Microsoft\SMS\Task Sequence, SMSTSEndProgram" and "Failed to open key Software\Microsoft\SMS\47006C006F00620061006C005C007B00350031004100300031003600420036002D0046003000440045002D0034003700350032002D0042003900370043002D003500340045003600460033003800360041003900310032007D00\SMSTS" tell me that the key doesn't exist or the account doesn't have access to that area in the registry. Check to see if the key does actually exist. If it does, then it's a permissions issue - if it doesn't then it's something in your task sequence.

I wasn't sure if ConfigMgr was trying to remove expired or superseded updates, but these updates are from April 2014 patch Tuesday - so none of them should be expired and/or superseded. I downloaded and created the deployment jobs on April 9 and I deployed to test groups that evening without and issue. On Friday I downloaded all Office updates and when I went into the UPDATES folder to create the OfficeUpdates-April2014 folder is when I noticed that all my folders in there were missing... I never cleaned them up - I just left them alone in there, so all of last year's folders were in there as well. I went into Download Packages, right clicked on the package name and Show Members. I highlighted them all and clicked on Download. SCCM provisioned them very fast but did not download them, probably because it believes they were already downloaded for that job. I had to create new Deployment Packages and Software Update Groups to get them downloaded again. Once I had them downloaded, I deployed to my next group on Saturday with success. I came in today and checked the UPDATES folder but all the folders inside of there are gone again. I checked the SMS_DISTRIBUTION_MANAGER because it has a warning ! in front and it reports that the Distribution Manager failed to process the package "Windows Updates for Servers - April 2014" with the list of possible causes, (not having access, no drive space, etc.) but I checked the Deployments and it is reporting 100% compliant - that's why I was wondering if once the package is distributed to the distro point, does it need to be in the \\ServerName\CM_DSL\Updates folder anymore? I really don't have any idea what is causing these folders to disappear, but it worries me that something is wrong and this is just the beginning of issues to come.

Thanks for the info Peter. Any clue as to what could be removing the folders? I am going to create new software update deployments (again) in hopes that they will stay. I have workstation updates that should be deployed this evening.

Clear your cache on the computers you are trying to deploy to. Recreate everything - your SUG's, Deployment Packages, etc. and make sure you are choosing full downloads of the updates you want to deploy. After you get everything downloaded, set your deployment time to As Soon As Possible or a date in the future. Also, are all of your clients updated to R2?

Firstcom, have you tried adding your WSUS server name to the Administrator's group on the WSUS server? Also have you installed the WSUS Administration console on your site server?

Hello everyone, I have a question regarding Software Update folders in SCCM 2012 R2 but first let me give you a little background about my environment. We are running R2 and have been for about 3 months now. I have one Primary server which has WSUS and SCCM on. I use SCCM to deploy all Windows Updates to both servers and workstations. When I need to download and distribute Windows Updates, I go into All Software Updates and use my saved searches that I have created. First I search for Windows Updates for servers and select all the ones that apply to my environment. I then right click and choose DOWNLOAD which requires me to create a Deployment Package. I create the new deployment package (ex. Windows Updates for Servers - April 2014) and when it asks me for a download path, I download them to \\ServerName\Updates\ServerUpdates-April2014 and let them download. After the download is complete I create my Software Update Group and set up my deployments. I do the same thing for workstations, I just create a folder in Updates named WorkstationUpdates-April2014 and do the download for the workstations into that folder. Last week Friday, I went into the \\ServerName\Updates folder and saw that there were only 2 folders in there. One of them was for my automatic Endpoint definition updates and the other is a folder with a GUID for a name. Since I had server updates to be deployed on Saturday, I created a new Deployment Package, downloaded the Windows Updates again, recreated a Software Update Group, picked my distribution point and set my deployments. This created the folder in \\ServerName\Updates and everything appeared to be good. Today (Monday) I checked the \\ServerName\Updates folder and all the folders in there are missing again with the exception of the folder for automatic Endpoint definition updates and the folder with the GUID for a name. I checked the Windows Update deployment that was scheduled for Saturday and it shows 100%. In the past these folders were not removed and I cannot figure out what changed in SCCM that is causing them to be removed now. I don't have the deployment set to expire and this is the "usual" way I deployed them in the past. I have checked with other admins here and they have all told me that they have not deleted anything on the server. There is only one other admin that has full access to SCCM like I do and he swears he didn't remove anything. Right now I'm scratching my head trying to figure out where these folders have gone and if I need them or not since the job was deployed to the DP. As long as I don't update the deployment package then my update deployments should deploy without a problem, correct? Thanks in advance to any information anyone can provide. I read thought this thread: http://www.windows-noob.com/forums/index.php?/topic/9077-my-content-is-deleting-itself/ but there wasn't any type of resolution given.

Just follow up on this issue. I checked the registry but the clients did not appear to be in provisioning mode. I was able to reinstall the CU3 upgrade remotely using a PowerShell script I wrote reading my computer names from a text file. This allowed the client to run any and all evaluation / reporting cycles but my SCCM server continues to flood the network for some reason. My current project is what you mentioned Rocket Man - I'm upgrading to R2. I'll let you know how it turns out.

Great find! Glad you have it working.

Try including your Router, DNS Domain Name, Boot Server Host Name (but list the IP and not the name), Bootfile Name, and DNS Servers in your options.

If you are using Cisco routers, try adding an IP Helper, otherwise make sure your Boot Server Host Name is an IP address and not a server name.

What are the steps you are doing prior to your TS?

Are you mapping as the user account you are using in SCCM to deploy the software packages? Just curious if that account has access to the file location?

If ACL's have changed, I'd check that first. If you updated the distro point but you are getting the error that the system cannot find the file specified, it may be due to a permissions issue, especially if you had access to the file location in the past. Can you manually path out to the file location as the user ID you are using for SCCM deployments?

Thanks for the reply Rocket Man... What I have done is I created a PowerShell script to reinstall the CU3 upgrade client. I have the computer names in a text document and I copy the .msp file from one of my servers to the local computer and then run the .msp file after it has been copied. Success is not 100% due to some computers with WinRM issues, but I would say I'm in the 90% success rate. To be honest I wasn't sure of the benefits of going to R2 instead of CU3... Maybe I'll try what you suggested after I get the CU3 mess straightened out and go from there.

Hello everyone, I have a single primary site server running Windows 2012 Server and SCCM 2012 SP1. We recently started imaging Windows 8.1 so I upgraded to CU3 in order to have Windows 8.1 support. I rolled the CU3 client to small test group for both the x64 and the x86 clients and it installed successfully. I only have about 350 total computers with multiple offsite locations connected via T-1 so after I verified all was good to go I deployed the CU3 upgrade to the x64 and x86 computers respectively. Since then I have had nothing but problems. I'm not sure if the CU3 .msp file somehow got corrupted during the push but 90% of my computers will not check in to the server. When I remote to a workstation or server and try to do a machine policy retrieval, I get the error message that the selected cycle cannot start. When I do a CTRL - ALT - DELETE, many times I see both processes "ccmsetup" and "ccmrepair" running. If I End Task on both of those processes and I run the .msp file manually, the CU3 update appears to install and the client becomes active again. Since the clients are communicating with the server, I can't push the client again. Any ideas on what went wrong and how to fix it are greatly appreciated. I've been fighting with this for a few days now and I don't believe there is an easy solution. Thanks in advance.

What do you wish to remove, just the SCCM client or is this server your SCCM Management/Distribution Point?

Hello everyone - I just wanted to give an update on this issue. This last weekend, I came in off hours to do Windows Updates on this server manually. After I installed Windows Updates and rebooted I got some WMI errors on different software. Although risky, I rebuilt WMI just like I did on the "close to retirement server" mentioned above. This fixed the issues I was having with the software I had issues with after the reboot but my Configuration Manager was still blank at that time. I got an error message during the WMI rebuild but I really wasn't thinking about the Config Manager. When I came in this morning, I thought I'd check it just to see if anything changed. Low and behold, the Configuration Manager is no longer blank and is showing ACTIVE in the SCCM Console again... Why it worked on this server and not the other one that is close to retirement is beyond me. I just wanted to share with everyone that WMI was the issue and once it was rebuilt, the Configuration Manager information is back and talking with SCCM again. Thanks to everyone who looked at this and thought about what could be wrong. I appreciate it.

This should be pinned.

Do you see Endpoint updates in WSUS at all? How do you have your Client Settings set up in the Endpoint Protection section? Do you have Manage Endpoint Protection client on client computers enabled?

Sorry to bump this thread - I'm still looking for anyone with ideas on how to fix this? I don't know what else to try. Thanks in advance.

Are you getting this error on both servers, or just one? Sorry for all the questions, I'm trying to get a mental picture of your environment and when the errors occur.

Is this a single or multi server environment? Are you attempting to update remote distribution points or do you have 1 server that is your management point and your distribution point?

Thanks for the reply Garth. Yes, I checked that as well - and the Default Namespace is root\cimv2. That's why I have been pulling my hair out... I obviously MUST be missing something, yet I feel that I tried everything. When I go into the Configuration Manager in the Control Panel, like I said before, all tabs are blank. If I go to the site tab and click on Find Site, it successfully finds the site code without me having to enter it, but when I click APPLY, I get an error that ConfigMgr cannot update the site. See below:

More updates on this - I tried to rebuild WMI on the server that is "close to retirement" and install the client again, but the install never completes. I get the following error in the CCMSetup.log: MSI: Action 13:33:32: CcmRegisterWmiMofFile. Compiles MOF files that were queued by CcmRegisterWmiMofFilesInit. ccmsetup 8/8/2013 1:33:32 PM 3128 (0x0C38) MSI: Setup was unable to compile the file UpdatesAgentSchema.mof The error code is 8004100E ccmsetup 8/8/2013 1:33:45 PM 3128 (0x0C38) MSI: Action 13:33:45: Rollback. Rolling back action: ccmsetup 8/8/2013 1:33:45 PM 3128 (0x0C38) File C:\WINDOWS\ccmsetup\{1AF71F68-6089-4211-ADDC-06DF40606141}\client.msi installation failed. Error text: ExitCode: 1603 Action: CcmRegisterWmiMofFile. ErrorMessages: Setup was unable to compile the file UpdatesAgentSchema.mof The error code is 8004100E ccmsetup 8/8/2013 1:34:03 PM 3128 (0x0C38) Client installation has failed too many times. Ccmsetup will try again after the next reboot. ccmsetup 8/8/2013 1:34:03 PM 3128 (0x0C38) Sending Fallback Status Point message to 'SCCM12.INT.LAN, STATEID='313'. ccmsetup 8/8/2013 1:34:03 PM 3128 (0x0C38) Params to send FSP message '5.0.7804.1000 Deployment ExitCode: 1603 Action: CcmRegisterWmiMofFile. ErrorMessages: Setup was unable to compile the file UpdatesAgentSchema.mof The error code is 8004100E ' ccmsetup 8/8/2013 1:34:03 PM 3128 (0x0C38) State message with TopicType 800 and TopicId {6F6AE20B-3397-4A33-8E81-6DF265A2C333} has been sent to the FSP FSPStateMessage 8/8/2013 1:34:04 PM 3128 (0x0C38) ccmsetup is shutting down ccmsetup 8/8/2013 1:34:04 PM 3128 (0x0C38) Shutdown has been requested ccmsetup 8/8/2013 1:34:04 PM 3128 (0x0C38) InstallFromManifest failed 0x80004004 ccmsetup 8/8/2013 1:34:04 PM 3128 (0x0C38) CcmSetup failed with error code 0x80004004 ccmsetup 8/8/2013 1:34:04 PM 3084 (0x0C0C) I've looked up StateID=313, ExitCode 1603, error codes 8004100e, 0x80004004... I just can't seem to pin point the problem.

You could use those switches on a PC/Server you need the client installed on using the command prompt. CCMSetup.exe is the .exe file /mp:<ServerName> is your Management Point Server /logon stops the install if the client is already installed, so I'm not sure if I'd use that in your instance. Check out the list here: http://technet.microsoft.com/en-us/library/gg699356.aspx