wilbywilson

You have a couple of options. Ideally, your previously approved patches should still be in effect, until they expire. A lot of people also make a package for older patches, just to catch any machines that come into the environment, which are out of date. For instance, you could have a package for Windows 7 security updates in the year 2012. Another package for 2013. And then, each month in 2014 will have a package, which is still applicable/active, and will get pushed to the newly joined machine. Make sense? The other alternative is for your HelpDesk guys to run full Windows Update as they're deploying the machine, which I think is a pretty good thing to do.

Agree with Benoit. If I was deploying it from scratch, I would use the very latest available. That's what I did when I rolled out R2 with CU1. Since then, I haven't upgraded to CU2 or CU3 (we're not having any major issues), but if I was starting from scratch, I'd use CU3.

It's my understanding that if you just push the client through the SCCM console, it will pick the proper version to send down. That's the way I'm currently rolling out my environment, and so far, it just seems "smart enough" to pick the right x86/x64 version, depending on the target machine's architecture.

Yes, that's normal. I'm not sure the reasoning behind it (maybe not all of those components have been updated by Microsoft)? Anyway, what you are seeing is correct/typical.

Correct, the content will be on the local distribution point, and clients will not have to traverse the WAN when getting the source files.

You're probably going to have run a few different reports. One that will help you right away is "Inactive Client Details." Another one could be "Computers Discovered by a Specific Site" (you can then sort this report, to see which clients haven't reported in a while, thereby differentiating active versus inactive clients.) I'm not aware of anything called "Windows Update group". That's not really how updates are targeted within SCCM. Rather, updates/applications are targeted to an SCCM collection. If you push your updates out each month to "All Workstations", just run a report showing you the members of that group. If you typically push updates to another SCCM collection, just run a report on that specific collection name. Hope that helps...

How are you installing the SCCM clients? Manually? Or via the SCCM console?

I'm not sure I fully understand your question, but I think what you're asking about would be accomplished through an SCCM Distribution Point. Do you have a Distribution Point installed in each of your 6 offices? If so, make sure the SCCM boundaries are configured for each office. Then, when you distribute an SCCM application out to the distribution points, clients within that site are "smart" enough to grab the content locally. You don't need to mess with UNC paths or DFS; an SCCM Distribution Point removes those complexities. Make sense?

No, WSUS only needs to be installed on the Primary site. When you build your monthly security package, you then distribute that package (which has all of the Windows updates) to your SCCM distribution points. Assuming that your SCCM boundaries are configured correctly, your clients will use their local distribution point to retrieve their Windows Updates. By the way, you shouldn't need to use Group Policy to do this through SCCM. You actually run the risk of Group Policy and SCCM "stepping" on each other. http://social.technet.microsoft.com/Forums/systemcenter/en-US/9432fe57-826d-4a4e-8dc4-1747645918ba/wsus-group-policy-in-sccm-?forum=configmgrsum

I'll agree with Garth on this one; you don't need a full lab to test out your packages/applications. Just build a few VMs (whichever operating system/architecture you want to test on), and get them into your SCCM environment. Then, make a collection within SCCM called "App Testing", which includes these specific VMs. Now, you can simply advertise your application/package to this collection, and test away. This is actually common/best practice. You never want to deploy stuff in your environment without prior testing. And if you set it up as described, there should be no risk of affecting the "live" environment during your testing.

I'm not aware of anything within SCCM that will do that. You may need to look into a 3rd-party piece of software (some sort of file/registry monitoring software might work.)

I could be wrong, but I don't think what you're asking for is possible.

Alternately, you could try using a 3rd-party product for Adobe/Apple/FireFox/Chrome updates. I've been using Shavlik Patch with SCCM 2012, to keep my systems patched, and it's been working very well. They provide the patches, along with all of the detection/evaluation methods, so that you don't have to fiddle around with this stuff. Might be worth looking into: http://www.shavlik.com/products/patch/

Have you seen this article? Looks like someone went through something pretty similar, and it lists the steps that they took to get OSD working over HTTPS: http://ittherapist.net/2014/01/16/sccm-2012-r2-os-deployment-with-pki-https/

Potentially there is something that's not configured right. When you installed SCUP, and did the "Test Connection", everything worked OK? Also, when you launch SCUP, I believe that you should logged in as the same user that installed it originally, and "Run as Administrator." It's a funny little program... I can't answer your questions about the CAS/PSS, simply because I don't know. Sorry.

Did you re-sync All Software Updates after checking that box? It definitely sounds like one of your "categories" isn't checked. I did the same thing that you're currently doing a few months ago, and I can't recall with 100% accuracy, but I believe I had a box called "Adobe Systems" or "Adobe" that I had to check. Also, just so you know, I found the Adobe catalog to be sorely lacking. The detection rules said that every machine in my environment needed Flash (instead of just the machines that had pre-existing versions of Flash.) I've since moved to a third-party product called Shavlik Patch, that offers so much more. Check it out: http://www.shavlik.com/products/patch/#/overview/ Installation and configuration is pretty simple, and it's working well for us. Pricing is reasonable too.

I'm not aware of anything that will email you return codes, successes, or errors for application deployments. I think your best bet would be to look in the "Monitoring" tab. There is a "Compliance" percentage there, and you can dig further into by clicking on "View Status" in the bottom pane. From here, you can see which machines were already compliant, which successfully installed it, which had errors (usually with some type of error code.) For really detailed errors and such, you'll either need to look at the Event Viewer on the machines in questions, or the log files that were generated (assuming you specified logs to be created with your application command line.)

Have you configured the SCCM client to install during the imaging process? Or afterwards, once it's already joined to the domain, and sitting in its new AD container? Regarding your certificate question, that is likely happening through group policy. If you look in the MMC on a problem machine, and go to the certificate snap-in for the local machine, are there any certificates there? Based on what you're saying, this may be a problem in AD/group policy, rather than SCCM....

Good find. I wish there was a KB that could be approved for the Windows 7 machines (similar to Windows 8), because that would make things much easier. But at least there is a good write-up of how to accomplish the task through a somewhat more "manual" method. Thanks for posting.

I believe that I've read that offline servicing of the Windows Updates can sometimes cause issues, unfortunately. But, the offline servicing process should have made a ".bak" file of your original WIM. Can you revert to that original WIM and see if the TS works?

Have you configured boundaries and boundary groups correctly?

I think your method/logic is fine (using a package to run a batch file.) It's likely that while your batch file works fine locally, it's not executing properly through SCCM. And it may say 100% compliant because the program itself executed...the batch just didn't work as expected. I would look more closely at the placement of quotes in your batch script. It looks to me like there are some spaces in there, where more quotes would be required for remote execution of the script. CD C:\Users\Public\Desktop del "DFSystem 4.3.lnk" CD "C:\ProgramData\Microsoft\Windows\Start Menu\Programs\DataFax 4.3" del "DFSystem.lnk" CD "C:\Program Files (x86)\Clinical DataFax Systems Inc\DataFax 4.3" del "DFSystem.exe" Hope this gets you on the right track.

I think your method/logic is fine (using a package to run a batch file.) It's likely that while your batch file works fine locally, it's not executing properly through SCCM. And it may say 100% compliant because the program itself executed...the batch just didn't work as expected. I would look more closely at the placement of quotes in your batch script. It looks to me like there are some spaces in there, where more quotes would be required for remote execution of the script. CD C:\Users\Public\Desktop del "DFSystem 4.3.lnk" CD "C:\ProgramData\Microsoft\Windows\Start Menu\Programs\DataFax 4.3" del "DFSystem.lnk" CD "C:\Program Files (x86)\Clinical DataFax Systems Inc\DataFax 4.3" del "DFSystem.exe" Hope this gets you on the right track.

Yes, I'm sure that you can create a custom package for IE11. But Microsoft provides an automated way to deploy it (via Software Updates), plus the built-in detection logic that figures out which machines need it installed. If you need special/custom settings for IE11, I guess a package may make the most sense. Otherwise, I just think it's easier to deploy it through Software Updates.

Yeah, we did follow a couple of blog posts about fixing WMI, to no avail. In the past (Windows XP), I've had decent luck repairing WMI. It's my understanding that WMI was totally reworked by Microsoft starting with Windows 7, and corruption should occur much less frequently. I have little to no experience with trying to repair WMI on Windows 8.1. If there are recommended instructions out there, in case we run into this issue again, I'd love to see that article.