HotdogSCCM

Howdy hoo! Here's what I'm working with: SCCM 1511 Windows 7->Windows 10 In Place, Zero Touch Task Sequence. Cisco ISE for network authentication. For "normal" Windows 10 builds, thumb drive/PXE builds for bare metal, I have a lovely little batch file that does: copy CERT1.cer X:\OhioBWC-CA.cer /y copy CERT2.PFX x:\BWCCert.pfx /y copy Ethernet.xml x:\Ethernet.xml copy InstallCertsSilently.vbs x:\InstallCertsSilently.vbs copy InstallCerts.bat x:\InstallCerts.bat cmd /c cscript.exe InstallCertsSilently.vbs cmd /c Powershell.exe Sleep 15 cmd /c Netsh LAN add profile filename="X:\Ethernet.xml" interface="Local Area Connection" cmd /c Netsh LAN add profile filename="X:\Ethernet.xml" interface="Ethernet" cmd /c Netsh LAN add profile filename="X:\Ethernet.xml" interface="Ethernet0" cmd /c Powershell.exe Sleep 5 cmd /c Ipconfig /release cmd /c Powershell.exe Sleep 5 cmd /c Ipconfig /renew cmd /c Powershell.exe Sleep 5 cmd /c ipconfig /renew Which, through the magic of love, gives me full ISE access, and authenticates the WinPE environment. I've modified my unattend.xml to do something similar, dropping the certs and XML in the WinPE side of the house: net start dot3svc sc config dot3svc start= auto C:\windows\system32\certutil.exe -addstore root C:\windows\temp\CERT1.cer c:\windows\system32\certutil.exe -f -p SUPERAWESOMEPASSWORDGOTEAMAMERICA! -importpfx c:\windows\temp\CERT2.pfx Netsh LAN add profile filename="c:\windows\temp\Ethernet.xml" interface="Local Area Connection" Netsh LAN add profile filename="c:\windows\temp\Ethernet.xml" interface="Ethernet" Netsh LAN add profile filename="c:\windows\temp\Ethernet.xml" interface="Ethernet 0" REG ADD HKLM\System\CurrentControlSet\services\RasMan\PPP\EAP\13 /t REG_DWORD /v NoRevocationCheck /d 1 /f Which works, so the full Windows OS has access to the network too. In ZTI, however... I'm not sure how to do a "prestart" command. I'm using the MDT Boot image, and I'm unsure of how to "force" something to run before the Task Sequence itself even begins; I basically need to do all the "first" steps, the WinPE stuff, as soon as the box drops into WinPE, from the full session of Windows (starts in Windows, turns off Bitlocker, reboots, USMT, etc). How do I do this? It doesn't look like any of the "normal" things want to work when it's a ZTI; I've tried tsconfig.ini, and I know the winpeshi.ini gets eaten when I make a boot disk. The tsconfig.ini stuff from here: https://sccmdiet.wordpress.com/tag/tsconfig-ini/works, but it doesn't work in ZTI/no "user interaction". I *KNOW* I'm missing something really stupid, but I've never had to do this yet Thanks!

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: http://blogs.technet.com/b/manageabilityguys/archive/2013/05/07/configmgr-2012-client-cache-part-1-overview.aspx From there: 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.

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: http://blogs.technet.com/b/sus/archive/2015/06/09/a-few-notes-on-the-recent-fix-for-the-configuration-manager-update-scan-failure-issue.aspx 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.Quit Again, 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; <![LOG[File 'C:\Windows\ccmsetup\vcredist_x86.exe' returned failure exit code 1603. Fail the installation Remediation of that will be necessary; fix the install, re-install C++, etc etc.

To answer your questions: Yes. WMIC /namespace:\\root\ccm path sms_client CALL TriggerSchedule "{00000000-0000-0000-0000-000000000113}" /NOINTERACTIVE However, I wouldn't recommend doing that. I'd personally recommend (and we have done this on ~8k machines, with zero issues): 1) Use PowerShell App Deploy 2) Download all the MSUs you need; Windows 7, Windows 8, IE8, 9, 10, etc. 3) Use the Install-MSUpdates command to install the MSUs: If ($Is64Bit) { Install-MSUpdates -Directory "$dirFiles\Updates\x64\First" Install-MSUpdates -Directory "$dirFiles\Updates\x64\Second" } else { Install-MSUpdates -Directory "$dirFiles\Updates\x86\First" Install-MSUpdates -Directory "$dirFiles\Updates\x86\Second" } Basically, I've placed all of the "Cumulative" update, depending on architecture, into the Updates\<Architecture>\First folder. The MSU will be installed if it's not present. It'll then go onto the next folder, the "Second", and install the MSU for the OOB update there. This ensures they get installed (if needed) in order. You can use App model to determine applicability by utilizing the Get-Hotfix command: Get-HotFix | Where-Object {$_.HotfixID -eq 'KB3087985'} Voila. Package it up, deploy it, and be happy. You could also, if you don't like using PSAppDeploy, just chain together two wusa installs of the individual MSUs depending on architecture/OS/IE revision, but that's a lot of work.

How about if you just hit "F8", launch Powershell.exe, and type something goofy? Bomb out from there as well? My off the cuff suggestion would be to make a new boot media, re-add Powershell/whatever-other-optional components, and give it a whirl again.

Before you kick off the Task Sequence, as in, before you even hit "Go", have you tried: F8 Diskpart select disk 0 clean I know you shouldn't *have* to, but in my career, unless I'm attempting to retain data, I've always added some manual steps (ie, Powershell, batch file) to completely wipe the drives. If I don't, I see random, weird issues like that. I won't say it'll fix it, but I'd give it a shot and see if it clears something up.

FWIW, I don't believe SP1/CU1 addressed the issue with Apply Driver Packages actually working. It's a limitation of the version of DISM available in Windows 8.1 ADK's WinPE. While that error *DOES* look a little different, the DISM of your boot image, unless you've done magical things, is still going to be sub 10, which will cause it to fail. I still had to utilize these instructions: http://deploymentresearch.com/Research/Post/443/Beyond-unsupported-Deploying-Windows-10-preview-including-drivers-with-ConfigMgr-2012-R2 To get Apply-Drivers to work. Unless you install Windows 10 ADK and re-make your boot media, which is the "better" option.

From Reddit, found a reason: If you open up SMSProv.log and watch it when you go to Offline Service, you see: ExecQueryAsync: COMPLETE select * from SMS_UpdateCategoryInstance where LocalizedCategoryInstanceName like '%Windows vNext Preview%' Oh SCCM, you so silly!

No problem. MS isn't staying up on keeping the hotfix article up to date, unfortunately. They're still referencing https://support.microsoft.com/en-us/kb/3050265 when in fact it's been updated several times; we're obviously up to August now. The 3050265 will obviously fix the issue, but it'll need to be updated again to August, so it'd make sense just to hop to August. They should add a disclaimer in the original link to be like "Going forward, download the most up to date Windows Update Agent client patch", instead of linking to a quickly-out-of-date monthly-updated patch.

There's a weird time zone bug; change the deployment "available" time back a few hours. Voila, like magic, it'll show up.

Sounds a lot like this: http://blogs.technet.com/b/configurationmgr/archive/2015/04/15/support-tip-configmgr-2012-update-scan-fails-and-causes-incorrect-compliance-status.aspx I'd personally, on an impacted box (assuming the deployment is correct, etc, etc), install the best/current Windows Update Agent, manually, available from here: https://support.microsoft.com/en-us/kb/3075851 Reboot it, bounce it, etc etc, then do a rescan for updates. The "Stuck in Complaint" comment makes me think it's that, more than a deployment issue in and of itself.

Watch a box right after it installs IE11; if you get a: Scheduled non mandatory reboot from agent UpdatesDeploymentAgent RebootCoordinator 8/11/2015 10:12:20 AM 6976 (0x1B40) That means that SUG didn't want a reboot; that at least rules it out. As for the other updates, when exactly they'd install depends on the logic of the Software Update. Best way to check would just to be to run it on a VM; let your SUG take place, watch the logs, kick off a Software Update Scan, see if more come down with a forced reboot.

Are any other updates getting installed, post install of the IE11 SUG? IE, do you have a standing update group, that's deploying IE11 Cumulative updates (or anything else that might get installed after the IE11 SUG), that might be hitting the boxes and forcing the reboots? IE11 is an ugly beast of a SUG. My personal suggestion would be to Package it like a Package; utilize Powershell AppDeployment Toolkit and use the Install-MSUpdates command, to chain together all the pre-req updates and then DISM /online the IE11 itself. This gets it out of the awkward-to-manage-at-times SUG, and into a more "recognizable" and fun to play with Package/App. I'd also recommend not leaving the system in a weird, non-rebooted state; I know users hate logging off, but leaving them in a post-old-version of IE, pre-new-version is just asking for trouble down the road. When I make a SUG looking just like yours, and deploy it, my RebootCoordinator looks like: Entered ScheduleRebootImpl - requested from 'UpdatesDeploymentAgent'. set Rebootby = 0. set NotifyUI = True. set PreferredRebootWindowType = 4 Scheduled non mandatory reboot from agent UpdatesDeploymentAgent RebootCoordinator 8/11/2015 10:12:20 AM 6976 (0x1B40)

SCUP always seemed like overkill for Adobe Flash. It's a dead-simple app to package and deploy. We typically just use Collections to detect old versions, and an Application to deploy + drop the mms.cfg file to disable updates. You're going to have to deploy the mms.cfg anyways, whether you use SCUP or manually updating, so it's just an extra step if you don't use an App/Package each time.

The biggest problem is you're totally going into a weird, unsupported methodology. Management, if nothing else, should disagree with you, if only because you're unsupported and bizarre. If you're walking across the street tomorrow, not in a crosswalk, since that's a normal, supported thing to do, and you get hit by a bus. Why would you walk down to a crosswalk? THERE'S ROADS RIGHT HERE! Bam. No more you. So your management calls in MCS, to support your infrastructure you've been torn away from, by the sweet, sweet embrace of death. What's the first thing they're going to do? Set up a single DP to handle all of your content. And you'll be known as "the weird guy who didn't use DPs". They'll tell stories about you at MCS meetings, and PFEs across the nation will reference you as "the weird guy who didn't use DPs". MMS and Ignite participants will speak about you while drinking beer. You'll be a legend in your death. I wish you luck.

Howdy folks. Systems: SCCM 2012 R2 SP1 CU1, Windows 10 ADK. I've gone ahead and captured a Windows 10 WIM, we're deploying it, etc etc; it all works. I did do these steps here on the WSUS side: http://titlerequired.com/2015/07/22/windows-10-on-wsus-shows-as-windows-vista/ Otherwise the Windows 10 patches weren't showing up as Windows 10. However, now they are; they're showing up, they're deployable, everything is happy. However, when I go to offline-service the Windows 10 image, it shows zero updates as being available. It just sits there with the little red exclamation point, and never shows any selectable. Now, granted, I literally only have two updates available: KB3081424 and KB3074683. I'd like to, however, inject KB3081424, since it adds time to OSD. Is anyone else seeing updates available when they go to offline service? Or is something hosed up on my end? Or, possibly, are there just not enough updates/types of updates out yet to even populate the list? I'll know more today obviously, since it's Patch Tuesday, but just wanted to know what others saw. Thanks!

I understand you're using a Domain Controller per site, which in and of itself isn't a good idea (IIS on a DC = not recommended), but that's just a lot of MPs for that tiny of a site. From a flat recommendation, unless you're very bandwidth limited, or constrained by network some other way (ie, ports), just do MPs in a "datacenter", and let clients transverse the WAN for policy. Much easier. That said, if you DO want to make MPs follow boundary groups, you need to: 1) Install CU1 for SP1. There's a known issue with SP1 that doesn't let the "Preferred MP" checkbox work in a stand alone primary site. "The "Clients prefer to use management points specified in boundary groups" setting is not honored on a stand-alone primary site." https://support.microsoft.com/en-us/kb/3074857 2) Enable "Clients prefer to use management points specified in boundary groups" under "Hierarchy Settings". Then assign the MPs to the boundary groups, and in theory, magic should occur and clients will follow the specified option. Personally, I ended up using a CI to assign workstations to MPs via the AllowedMPs registry key, due to network configuration at my company; they had multiple DMZes that made client rotation incredibly bad.