severina
Established Members-
Posts
10 -
Joined
-
Last visited
severina's Achievements
Newbie (1/14)
0
Reputation
-
There was an update back in February that screwed up the default apps settings for everyone and so it's taken our Windows 10 deployments by storm. So I know that we can deploy a registry fix to set it so that it doesn't reset your default apps, but it seems to only work when you go into control panel afterwards and set the default app manually. Is there a way through SCCM that I can push a fix this for the machines that we have already deployed Windows 10 to? This is the worst bug and users are upset. Wondering if I can even do this in the post processing of the task sequence, but I'll also just accept a post install push. Thanks!
-
There is no variable set there for packages that don't need any drivers injected. That step is for desktops and they upgrade fine since I'm not passing anything. I have found something interesting since I posted my original issue: I added another set of drivers for another laptop. It keeps setting the location (variable) to c:\driver and not c:\driver\packageID no matter how many steps I add with the driver variable. The task sequence fails because when I pass %driver01% it doesn't see "01" because it's setting it to just c:\driver and nothing further. Maybe this has changed in 1602 vs 1511? My next step is to just pass %driver% instead of %driver01% to see if this is indeed the case.
-
I'll post that later when I'm at work. Should be able to get that by later tonight. Thank you!! In the old task sequence before, when I was running SCCM 2012 R2 SP1+ I was doing the XCOPY and had multiple ones for different laptops and they were working fine, but I was manually passing the information when I was runing the /installdrivers part. Just seems like this new task sequence isn't passing the variable properly or setting it properly. I was using the same packages so it doesn't seem a problem with the package itself. I also verified that it does copy the package to the right place. I'll get you as much info as I can later.
-
Posted this on the technet forums, but I'm getting nowhere there. Maybe someone here can help! Running current branch (1602), OS upgrade task for Winx64 1511. In task sequence, I have a task to download package content for a 6470 package (it does download fine, and I see it downloaded to c:\driver\package#)- Custom Path: C:\driver Save Path as Variable: driver OS Install piece: Provide the following driver content to Windwos Setup during upgrade: -Staged Content: %driver01% When looking at the task sequence it seems to set the variable to c:\driver and not c:\driver\package# where it actually stages the content to. See here: Download package S0100219 to c:\driver\ successful OSDDownloadContent 6/1/2016 9:53:12 AM 5476 (0x1564) Setting the custom destination variable 'driver' to 'c:\driver\' OSDDownloadContent 6/1/2016 9:53:12 AM 5476 (0x1564) Adding driver to the list of paths that needs to be remapped on reboot (based on drive configuration). OSDDownloadContent 6/1/2016 9:53:12 AM 5476 (0x1564) Download packages action completed OSDDownloadContent 6/1/2016 9:53:12 AM 5476 (0x1564) Here is the end result: (It doesn't seem to actually pass the proper info, because it's passing the actual %driver01% instead of what should be the variable. Content successfully downloaded at C:\_SMSTaskSequence\Packages\S010022C. OSDUpgradeWindows 6/1/2016 9:57:18 AM 7756 (0x1E4C) Command line of Windows Setup upgrade: '"C:\_SMSTaskSequence\Packages\S010022C\SETUP.EXE" /auto Upgrade /quiet /noreboot /postoobe "C:\WINDOWS\SMSTSPostUpgrade\SetupComplete.cmd" /postrollback "C:\WINDOWS\SMSTSPostUpgrade\SetupRollback.cmd" /installdrivers "%driver01%" /DynamicUpdate Disable' OSDUpgradeWindows 6/1/2016 9:57:18 AM 7756 (0x1E4C) Command line for extension .EXE is "%1" %* OSDUpgradeWindows 6/1/2016 9:57:18 AM 7756 (0x1E4C) Set command line: "C:\_SMSTaskSequence\Packages\S010022C\SETUP.EXE" /auto Upgrade /quiet /noreboot /postoobe "C:\WINDOWS\SMSTSPostUpgrade\SetupComplete.cmd" /postrollback "C:\WINDOWS\SMSTSPostUpgrade\SetupRollback.cmd" /installdrivers "%driver01%" /DynamicUpdate Disable OSDUpgradeWindows 6/1/2016 9:57:18 AM 7756 (0x1E4C) Executing command line: "C:\_SMSTaskSequence\Packages\S010022C\SETUP.EXE" /auto Upgrade /quiet /noreboot /postoobe "C:\WINDOWS\SMSTSPostUpgrade\SetupComplete.cmd" /postrollback "C:\WINDOWS\SMSTSPostUpgrade\SetupRollback.cmd" /installdrivers "%driver01%" /DynamicUpdate Disable OSDUpgradeWindows 6/1/2016 9:57:18 AM 7756 (0x1E4C) Process completed with exit code 2149851149 OSDUpgradeWindows 6/1/2016 9:57:35 AM 7756 (0x1E4C) Windows Setup completed with exit code 2149851149 OSDUpgradeWindows 6/1/2016 9:57:35 AM 7756 (0x1E4C) ulExitCode == 0, HRESULT=80004005 (e:\nts_sccm_release\sms\client\osdeployment\upgradewindows\upgradewindows.cpp,168) OSDUpgradeWindows 6/1/2016 9:57:35 AM 7756 (0x1E4C) Windows setup failed, code 2149851149 OSDUpgradeWindows 6/1/2016 9:57:35 AM 7756 (0x1E4C) upgrade.Run(), HRESULT=80004005 (e:\nts_sccm_release\sms\client\osdeployment\upgradewindows\upgradewindows.cpp,678) OSDUpgradeWindows 6/1/2016 9:57:35 AM 7756 (0x1E4C) Exiting with code 0x80004005 OSDUpgradeWindows 6/1/2016 9:57:35 AM 7756 (0x1E4C) Process completed with exit code 2147500037 TSManager 6/1/2016 9:57:35 AM 6672 (0x1A10) !--------------------------------------------------------------------------------------------! TSManager 6/1/2016 9:57:35 AM 6672 (0x1A10) Failed to run the action: Upgrade Operating System (Laptops). Unspecified error (Error: 80004005; Source: Windows) TSManager 6/1/2016 9:57:35 AM 6672 (0x1A10) Set authenticator in transport TSManager 6/1/2016 9:57:36 AM 6672 (0x1A10) Going nuts. Can't update my laptops to windows 10 because the NIC drivers apparently don't have a good windows update version of them. At a standstill with certain laptops because of this. If I remove this and let them upgrade normally they end up with me having to go in and update the nic driver, and since the NIC driver doesn't work when it boots back up, I can't even progress in the task sequence to add the package later
-
Actually, just found this: It may not be 100% good since now it breaks when you do refresh/install from within windows, but we don't really do those. I'm curious though if this messes up the Windows 10 upgrade package since that happens from within Windows? I guess it's time to test. http://ccmexec.com/2015/11/windows-10-adk-10-0-10586-solves-the-powershell-net-bug-in-winpe/