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.