
HotdogSCCM
-
Posts
31 -
Joined
-
Last visited
-
Days Won
1
Posts posted by HotdogSCCM
-
-
That's why Packages still exist. Applications were not a replace-all, they're an addition to, Packages.
what you outline is completely doable via Packages; don't view Apps as "the only thing", just "another thing".
Every company I've been at, people either:
1) Don't use Apps at all, cause confusing and stuff.
or
2) Never use Packages, because Applications now exist.
Embrace them both.
-
Assuming it's not an issue with you copying and pasting from your Task Sequence to here, the command you have has broken quotes. Re-type the quotes (") around the {000000} string.
My guess is you straight copy and pasted it from one of the many guides, and the quotes didn't translate correctly. You can also kinda see it in your screenshot, the quotes are too "small".
From my experience with this, though, you should first kick off a normal, canned "Install Updates" step. That, if you watch the logs, kicks off a number of events that tells the client to actually be able to do magical things in terms of Software Updates. Let it run through an entire "Install Updates" without the WMIC sorcery, then for the next steps do the "Scan for Updates" steps.
-
Read both these articles first. They're very good:
http://blog.configmgrftw.com/software-updates-management-and-group-policy-for-configmgr-cont/
http://blog.configmgrftw.com/software-update-management-and-group-policy-for-configmgr-what-else/
Those should be followed correctly before anything else.
The GPO you're talking about has to do with the WUA; not SCCM. The SCCM client, if you've configured to NOT suppress reboots, will still pop up the reboot prompt and timer, according to your Client Settings. So the GPO in question is basically useless.
The only way to get around that, the "Eventual countdown that might reboot when someone is logged on", is to suppress reboots completely. Otherwise, the patch will install via SCCM, and the reboot prompt will appear.
You can increase your Client Restart time via the Client Settings->Computer Restart setting.
My suggestion is to follow Sandy's guide on WUA/SCCM configuration, and then configure the Computer Restart setting as desired. Trying to combine the two will lead to crying and tears.
-
Disable your ADR. That will prevent the updates from showing up in the ccmcache.
As for validating, check the WindowsUpdate.log file. It'll show where the files are being stored when they're actually coming from Microsoft/WSUS. Otherwise, your ADR will be being processed, which can be located in the UpdatesDeployment.log and CAS.log, you'll need to correlate those two to validate the files in question.
The CCMCache has a number of write ups about it; for example:
From there:
So, does the cache actually maintain itself? Well, content remains in the cache for at least 24 hours, after that time it’s available to be overwritten by new content if it requires the space. If you configure your packages to persist content in the client cache, the client will not automatically delete the package/overwrite content in the cache. If the client cache space is used by packages that have been downloaded within the last 24 hours and the client must download new packages, you can either increase the client cache size or choose the delete option within the control panel applet of the client to delete contents of the cache. (See screenshot above)
If your CCM cache is set up correctly for your environment, the placing of the SCEP files in there is no different than any other files; be it normal patches, applications, packages, etc; it'll maintain and clean itself as needed.
-
As an added safety bonus, you can add a Global Condition to limit it to hardware.
Name: Hardware Model - Whatever
Device Type: Windows
Condition Type: Setting
Setting Type: WQL Query
Data Type: String
Namespace: root\cimv2
Class: Win32_ComputerSystem
Property: Model
WQL Query: Model LIKE "%Latitude E4300%"
That'll prevent the application from running on anything but Latitude E4300; just assign that Global Condition to your Deployment Type.
But yeah, targeting via Collection will be the best bet; this just adds a layer of protection against unintentional deployments. It also lets you just dump these apps into a single "Install Applications" step via OSD, instead of having to break it out into each individual type via WMI queries, if so desired.
-
1
-
-
Yeah, that link works, but it's very broad; it basically says "make decisions based on stuff!"
Consider the following to help you determine the appropriate number of distribution points to install at a site:
The number of clients that might access the distribution point
The configuration of the distribution point, such as PXE and multicast
The network bandwidth that is available between clients and distribution points
The size of the content that clients retrieve from the distribution point
The setting for BranchCache that when it is enabled, lets clients at remote locations obtain content from local clients
DP logic is based solely on bandwidth/client limit. If you have a lot of bandwidth, there's no need for it... unless you see PXE issues. There are hard limits on DP;
https://technet.microsoft.com/en-us/library/Gg682077.aspx#BKMK_SiteAndRoleScale
But the limit is 4000 clients; so if you only have 1 DP (Primary) serving 4k+ clients, than one "Should" be added if only from the scalability perspective.
I assume you have a fast link between main campus and the branch, so the "bandwidth" issue isn't a big deal. If PXE is truly your only pain point, I'd personally:
1) Tweak any PXE related settings/TFTP settings, ie, http://windowsitpro.com/configuration-manager/speed-sccm-tftp-performance-pxe-clients
2) Open a support case with MS outlining your issue; they may have more guidance.
Assuming those two steps fail, from my perspective, I'd just drop a DP at the site and be done with it. You seem to have already spent a lot of time, both yours and networkings, on troubleshooting it. If you take your hourly rate, plus networkings time, plus time wasted not doing other things, how much has this troubleshooting already cost? 1k? 5k? 20k? Unless your budget is nil or you have a hard and fast "no more server" rule, just set up a DP at the site and be done with it. Some things aren't worth troubleshooting that hard, and this, to me, seems to be one of those.
-
Try newer:
https://support.microsoft.com/en-us/kb/3075851
The .320 is the base WUA they advertise so heavily when searching, but the updates after that add the new/better scanning mechanism that fixed the issue outlined here:
My other suggestion, and frankly it's what I've begun doing as well, is just to utilize WSUS alone instead of attempting to utilize SCCM updates during OSD; I've found the Updates Step to be very flaky, and was only seeing about 1/4 actually kick off; the rest sat there in awkward silence, like that time I told my father I liked One Direction. It honestly seemed to have gotten worse post SP1/CU1; I have yet to open a ticket, mostly since the WSUS steps are just rock solid. You obviously miss out on the SCCM functionality, and have to manage a WSUS instance as well, but the trade off is worth it IMO.
To go off on a tangent, to do that, you'd want to do these steps:
Set Windows Update:
reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" /v WUServer /t REG_SZ /d FQDN:PortofServer /f
reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" /v WUStatusServer /t REG_SZ /d FQDN:PortofServer /f
reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU" /v UseWUServer /t REG_DWORD /d 1 /f
Set Target Groups (Which you'd make and manage in WSUS):
reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" /v TargetGroupEnabled /t REG_DWORD /d 1 /f
reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" /v TargetGroup /t REG_SZ /d OSD /f
Recycle Services:
cmd /c Powershell.exe Stop-Service wuauserv
Powershell.exe -command start-sleep 15
cmd /c Powershell.exe Start-Service wuauserv
Powershell.exe -command start-sleep 15
And then to install updates, run this VBS:
'----- Create Session -----
Set UpdateSession = CreateObject("Microsoft.Update.Session")
Set UpdateSearcher = UpdateSession.CreateUpdateSearcher()'----- Search for Updates -----
Set SearchResult = UpdateSearcher.Search("IsInstalled=0 and Type='Software'")
For I = 0 To SearchResult.Updates.Count-1
Set Update = SearchResult.Updates.Item(I)
Next'----- Quit if No Updates Found -----
If SearchResult.Updates.Count = 0 Then
WScript.Quit
End If'----- Create List of Updates to Download -----
Set UpdatesToDownload = CreateObject("Microsoft.Update.UpdateColl")
For I = 0 to SearchResult.Updates.Count-1
Set Update = SearchResult.Updates.Item(I)
UpdatesToDownload.Add(Update)
Next'----- Download Updates -----
Set Downloader = UpdateSession.CreateUpdateDownloader()
Downloader.Updates = UpdatesToDownload
Downloader.Download()'----- Create List of Updates to Install -----
Set UpdatesToInstall = CreateObject("Microsoft.Update.UpdateColl")
For I = 0 To SearchResult.Updates.Count-1
set Update = SearchResult.Updates.Item(I)
If Update.IsDownloaded = true Then
UpdatesToInstall.Add(Update)
End If
Next'----- Install Updates -----
Set Installer = UpdateSession.CreateUpdateInstaller()
Installer.Updates = UpdatesToInstall
Installer.Install()'----- Quit -----
WScript.QuitAgain, I'm not advocating abandoning SCCM Updates completely, but everywhere I've been, the SCCM updates process in OSD is simply abysmal. Not every environment will allow it either; you lose all content distribution ability that SCCM provides (though you could, if you feel froggy, utilize a central WSUS and BranchCache your way to happiness. You can also then utilize a Microsoft Point to Point VPN to connect up your Contoso clients in Madrid with your home office in Seattle and all use Skype to talk about the upcoming merger and acquisition on your Windows 10 Tablet devices running Office 365). You can follow every guide out there in terms of "Scan for Updates and hold your breath and don't cry cause it'll be over soon", but the consistency of it is simply lacking. MS makes the timings too tight for it to kick off and run in a decent amount of time, and the Task Sequence engine seems to lose its mind every other time it's run.
To make a long story short: Try the newest-and-test WUA, try less updates/remove un-needed updates, and pray. Pray, because OSD Updates are a fickle, fickle thing, and are the sole reason most people use MDT instead.
-
You can use the Windows 10 ADK derived boot image to deploy Windows 7 WIMs. Create your new Windows 10 boot images, and use those instead on the Task Sequence.
-
My first suggestion, right off the bat: Update your Windows Update Agent. You're still on a version from 2012, which, back then, do you know what the top movie was? The Avengers. The Avengers came out the same year your Windows Update Agent did. 7.5.7601.17514 is old. Older than my imaginary, 3 year old son. 3 years ago, he wasn't even alive. That's insane.
That's crazy pants. Crazy. Pants.
But, yeah, update your WUA. Please.
That said, you're literally taking over 30 minutes to scan.
Async searching of updates using WUAgent started. WUAHandler 8/24/2015 2:13:04 PM 196 (0x00C4)
Async searching completed. WUAHandler 8/24/2015 2:37:57 PM 2136 (0x0858)
Successfully completed scan. WUAHandler 8/24/2015 2:42:35 PM 2928 (0x0B70)Update. Package up the newest WUA, install it, make sweet love to it, and try it again.
-
Some of the C++ failed;
<
Thanks!