RLC-Andrew

Have you reviewed your boundaries and confirmed that your servers belong or fit into one of the "boundary groups"? Also, on one of your servers check the registry location below. Are the WUServer and WUStatusServer keys set to your SCCM server? HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\

When I set this up years ago, all updates that were available were put into one of the "Base Set of Updates" groups and an underlying associated deployment package. So these hold mostly old updates at this point, as I do not add to them. Each month, the Patch Tuesday ADR described in my original post runs and create a new group (Patch Tuesday - 2019-01-18) as last months example. As it stands now, this group contains anything released or changed in the last month. This Group that is created is deployed to the various collections (Test Groups, Servers, Workstations etc.) Every few months, I move the updates contained in those ADR monthly groups into the "Yearly - Current Year" group to keep things cleaned up. I set this up based on some published instructions that were available online at that point in time (2015). I was curious if anyone had setup a similar style for the patching process.

I have a Patch Tuesday ADR than runs late in the day EST on the 2nd Tuesday of each month. This ADR grabs all the various update classifications I selected (critical, security, Service Packs, Update Rollups, Updates) for the "Last 1 Month". The "Last 1 month" is a hard coded setting from the drop down box. It downloads all the updates that match the criteria and last 1 month into my deployment package, and then creates a new software update group. I'll ask this question first: Is this generally how most have this set up for the patch Tuesday process?

Did a quick search, and didn't see anything pop out at me. I noticed today that I have "Domain Computers" in the "Operations Administrator" Security Role group inside SCCM. I'm assuming this is a default or was done by SCCM, as I was not the one who did this. Can anyone verify if they also have the "domain\domain computers" in that group?

I believe that would only work for definition updates, not the monthly patch Tuesday software updates we deploy using SCCM. I just want to use SCCM to manage the update process and for reporting, but I want the clients to first look to MS update via the internet to download the updates. As of now...they would look to the distribution point (over the VPN) to download them.

I have a remote site with 15-20 computers (St Louis). There is no distribution point or SCCM server in that location. These clients currently look to another remote site as their distribution server (NY). Someday, we'll deploy a full DP at the St Louis site. But for now, I want to distribute windows updates to the St Louis site but have them NOT download updates from the NY DP server. I could install a DP in St Louis, with essentially no content on it. Point the clients to that DP. Then deploy windows updates to those clients and choose the first "Download software updates from DP and install" and then choose the "Do not install software updates" from the 2nd section of deployment options. While leaving the checkbox for "if software updates are not available on dp in current.......download from ms updates". Is there another way to do this, without creating the empty DP in that location? That site doesn't have the storage space to hold the updates. Its only got a small DC at the moment.

I had this issue today. For me, it was (apparently) because I copied and pasted a task sequence. To fix, I just had to re-type the credentials in the configuration of the sequence. The creds had not changed, but I suppose they are lost during the copy and paste process.

Just following up: I followed the instructions from itrider and had no issues. Our server does not have secure boot enabled, and we did not see the known issues.

I currently have "Windows Assessment and Deployment Kit - Windows 10" version 10.0.26624 installed on my SCCM version 1702 Server. I believe when moving from 2012 to 1511, there was specific instructions at that time to install the version of ADK I'm running. Possibly, because the newest version at that time had bugs related to win 10. Everything is running fine, patching works, OSD still works. All is well. So should I leave the old ADK version alone, or should I update it? I cant claim to fully understand what its used for or how its works in conjunction with SCCM. Was hoping someone could provide some insight.

Figured it out, for anyone who cares. I decided to use the Windows 10 1607 DVD I had burned a while back to just manually get it updated for now. When I got to the wizard, hit next to go to the first step....it complained about the product key being invalid. Turns out, someone put or had Win 10 "Pro" installed. We only use enterprise products, and I've only configured SCCM for the Enterprise feature updates. This explains why the Feature update came back as "compliant". I think maybe a status of "not needed" would be better than compliant in this section, but it is ... what it is.

I just dropped a 1511 PC into the collection, and within a few minutes it detected the feature update as needed and started the installation. Both computers are in the same AD OU

I have a "Windows 10 Servicing CB Test Group" collection that I manually drop clients into to begin the servicing update to 1607. Update is required. I have previously used this (say, over a month ago). I have a Surface Pro laptop that "winver.exe" shows as having 1511 10586.679. The Config Mgr Client version (recently uninstalled/reinstalled) 5.00.8412.1007 In the deployment status, after running a "run summarization" ... this client shows as "compliant". Essentially, when trying to force the 1607 feature update to this laptop....The server side SCCM Console is reporting that the client is already compliant for the deployment.

I ran a hardware and software inventory report on my PC today, and noticed it had data going back to 2014. Can someone point me in the right direction for telling SCCM I only wish to store inventory data for a certain length of time? This default is set. But either its not working....or the key word would be "inactive data". And my data never becomes "inactive"? https://technet.microsoft.com/en-us/library/bb680423.aspx?f=255&MSPPError=-2147217396

Are there any errors in the locationservices.log?

Are both machines reachable from the SCCM server? Do they both have the firewall enabled? Do both machines have the "Network Location Awareness" service running?

Yes, this support article worked. I had previously done all of the steps mentioned in the article, except for this one listed below. // delete files from tbFile table declare @NotNeededFiles table (FileDigest binary(20) UNIQUE); insert into @NotNeededFiles(FileDigest) (select FileDigest from tbFile where FileName like '%14393%.esd' except select FileDigest from tbFileForRevision); deletefrom tbFileOnServer where FileDigest in (select FileDigest from @NotNeededFiles) delete from tbFile where FileDigest in (select FileDigest from @NotNeededFiles)

Going through this today. It at least has a new step not previously published. Fingers crossed. https://support.microsoft.com/en-us/kb/3194588

I had some other issues...recorded in a different post. Having said that, I have finally reached this error message and this point in my troubleshooting. From a Social.TechNet discussion, I have also come to the conclusion that I need to reinstall the SUP. I really don't want to have to do it...but there is compelling reason to believe it will work (knowing that I have tried all the other options). Back when my SCCM environment was smaller and unused for production, I remember having to do the remove and add the sup role and it fixed the problem that day. I'm not sure what gotchas and/or side-effects are involved now. I know you basically remove the roll. Watch the sup log till its done. Reboot?. Then Add the role back in and configure it as you had it configured before. What I don't know is...what else needs done (or re-done). How will doing this effect the existing software updates, groups, packages etc.

Yes, I had it set in the default client policy. If you configure the Client Cache Settings to NO....and do a manual Machine Policy retrieval on the client....wait a minute or two and you will notice the button is usable again. I think they intended for this to button be unusable if the policy is set, but possibly forgot about still giving us the ability to manually empty the cache via the GUI. I really only ever go in there to empty when I'm testing or troubleshooting, so its just a minor annoyance for me.

I did have the referenced update installed. I installed it back on 8/19 and did the manual instructions. But just in case, I followed the instructions https://blogs.technet.microsoft.com/wsus/2016/01/29/how-to-delete-upgrades-in-wsus/ (had to change the version/build from the article to reflect the 1607 release) I manually verified the update content was removed, and then re-synced. Unfortunately, the results are the same. Error code 0x8000FFFF. Anymore ideas or logs that could help that I might be missing? It appears that if you did the sync before the update, the error code would be different or more specific (0x8007007E), at least from one user on the internet.

Figured this out. In a recent release, they gave us the ability to configure our maximum cache size via "Client Cache Settings". If you set the "configure client cache size" to YES and configure a maximum cache size, then you will not be able to access the "configure settings" option on the "cache" tab. At first thought, this appears it could be a bug.

Just an FYI: I ran into this same issue on a fresh install of Win10 1607 enterprise. I used the "Create Task Sequence Media Wizard" and used the "Capture Media" option to create a USB thumb drive for capturing the image.

I have this client version. When I open up Configuration Manager Properties from the control panel, navigate to the Cache tab. The configure settings button is grayed out. It is grayed out when I am logged in as the local administrator. It is also grayed out when I open it with the run as administrator option. I'm curious if anyone else has this? I was heading in there to manually empty or clear the cache.

Created a CB service plan and ran it. It populated the Package and created the Software update group. The contents of the SUG is "Feature update to Windows 10 Enterprise, version 1607, en-us". It shows downloaded and deployed. On the client side, the client sees the update and downloads it. The contents of the ccmcache folder are these two files: "WindowsUpdateBox.exe" and a rather long filename ending in "CLIENTENTERPRISE_VOL_x64fre_en-us.esd" Client is current on Win10 Build 10240. When in software center, it begins to install but will fail almost immediately. The software change returned error code "0x8000FFFF" (which seems to be a catastrophic failure). The WUAHandler.log shows this: Going to search using WSUS update source. Synchronous searching started using filter: 'UpdateID = 'af57b397-b222-494e-ab73-17ddddd6e44e' AND DeploymentAction = *'... Successfully completed synchronous searching of updates. 1. Update: af57b397-b222-494e-ab73-17ddddd6e44e, 200 BundledUpdates: 1 Update: 08b35ebf-a5f1-416f-8785-ae2ed3feb8e7, 200 BundledUpdates: 0 1. Update (Missing): Feature update to Windows 10 Enterprise, version 1607, en-us (af57b397-b222-494e-ab73-17ddddd6e44e, 200) Async installation of updates started. WUAHandler 8/29/2016 8:18:04 AM 1700 (0x06A4) Update 1 (af57b397-b222-494e-ab73-17ddddd6e44e) finished installing (0x8000ffff), Reboot Required? No Async install completed. Upgrade installation result indicates that commit cannot be done. Installation job encountered some failures. Error = 0x80240022. Commit Result = 0x00000001. Installation of updates completed. Things I have tried: Removed the update group, package and Service Plan and then re-created them and re-downloaded the Win10 feature update.

Are these clients 32 bit clients by chance? I had this same issue. Kind of an interesting issue if you research the reasons why...but nonetheless....the follow link has the hotfix that will fix it. https://blogs.technet.microsoft.com/configurationmgr/2015/04/15/support-tip-configmgr-2012-update-scan-fails-and-causes-incorrect-compliance-status/