Kops

It looks like I was able to resolve the issue thanks to this article https://support.microsoft.com/en-us/kb/2894518 I added a "Set Task Sequence Variable" task just before the Install Software Updates task, and set the value to 600. After doing this, it looks like images are deploying OK and without the _SMSTaskSequence folder being left over afterwards.

Thanks for lending a hand, Anyweb. If I disable the Software Updates step, the C:\_SMSTaskSequence folder does not exist. When I captured the Windows 7 image, I basically installed Win7 in a VM, install all windows updates, and captured to .wim. Should I avoid installing updates in the VM, and only apply them using SCCM afterwards? Or is my approach OK? I have used SCCM to inject any available updates into the .wim, however there are about 20 updates that will not seem to inject into the image, despite it showing Successful in the console. Event viewer has some errors that I will begin looking in to....I'm guessing there might be some relationship between certain updates failing during OSD and these updates failing to inject? On 2016-11-09 10:05:26 AM, component SMS_OFFLINE_SERVICING_MANAGER on computer RISCCMP2 reported: Offline Image Servicing Manager started applying updates on image with ID CM2000D3. On 2016-11-09 10:05:26 AM, component SMS_OFFLINE_SERVICING_MANAGER on computer RISCCMP2 reported: Offline Image Servicing Manager does not support image with ID CM2000D3 (image index 1) and therefore will not process this image. On 2016-11-09 10:06:26 AM, component SMS_OFFLINE_SERVICING_MANAGER on computer RISCCMP2.DBRI.LOCAL reported: Offline Image Servicing Manager failed to apply update with ID 16778571 on image with ID CM2000D3 (image index 2).

OK - I was able to narrow this down a little bit. It is only happening on devices where I captured the image from a VM. If I built the image using a physical reference machine, the C:\_SMSTaskSequence folder doesn't exist. This could possible be because the VMs are built by installing Windows, applying all available updates, and capturing the image to .wim. I thought that was best practice but maybe this is causing some issues?

Bump for help? Still can't figure out why this folder isn't being deleted =/

I've started to notice that after an OSD completes, there is a folder C:\_SMSTaskSequence that is left over, containing packages that were applied during OSD, totaling anywhere from 5-10gb. I started with the SMSTS.log file and found a few errors right near the end of the TS. The 0x87D01012 errors lead me to a few articles about using the "Retry" option in the Install Software Updates task. I've enabled the retry and set it to retry 5 times, but the _SMSTaskSequence folder still exists and the errors are still there as well. If I run a TS without Software Updates it runs fine and doesn't leave any leftover folders. I've also tried integrating all available updates into the OS Image, but the issue still remains. I've attached a copy of my smsts.log file, can anyone help identify why this folder is leftover after OSD? Also - why do I always have 2 smsts.log files (one with a date/timestamp)? smsts.log smsts-20161020-202855.log

Our organization recently bought some Lenovo X1 Yoga laptops and wanted them to be rolled out with Win10, so I've started to look at building Win10 images and have had tons of problems. I've worked through a bunch of them, but I'm having problems with the reference images. I originally tried installing the OS on the laptop, booting into audit mode, running windows updates, created a couple local accounts, and capturing the image using SCCM's image capture media. If I deploy this via SCCM everything looks OK except the Folder Redirection/Offline Files GPO does not work properly (folders get redirected but no sync partnership is set up). I opened a call with Microsoft about it and am waiting to hear back on that. In the meantime I decided to try to capture a reference image in VMware as I've seen some people suggest. What's strange is that if I build the reference image in VMware, the Group Policy issue disappears, but my task sequence starts failing out halfway through. I've looked at the SMSTS logs and see lots of driver errors but I'm not quite sure why as the drive pack works fine for images captured on physical machines. I've included the SMSTS files here in case someone can assist with that. Can someone advise the best practice for building/capturing reference images? Should I use Build and Capture? Should I use MDT? Both seem to be much more complicated than what I've done in the past but I can spend time trying to go down these paths if its worth the time and effort. smsts.log smsts-20160817-134321.log

Worked like a charm, I really should have explored my options a little bit more before making this thread. Thanks for knocking some sense into me Garth.

Hey Garth, Not sure I follow. Are you recommending making a Package/Program for this? I could do that...but I think that I would end up creating a program that runs a script to perform the same operations. Would you expect that to be successful where the 'run cmd line' task might fail? If you meant something else maybe you can elaborate for me? I'll try to whip something up using packages/programs while I await some clarification.. Thanks for the input!

I would like to add a step to my task sequence to copy a couple of files from the SCCM distribution point to the C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Accessories folder. This should be a fairly easy task but this can only be done using an elevated (run as administrator) command prompt. The command looks something like... copy "\\SCCM\Sources\Shortcuts\Internet Explorer.lnk" "C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Accessories" Is there an easy way to do this that I'm missing? I'm open to other ideas. I've even tried mounting the .wim file using DISM and trying to add the files that way, but I can't seem to browse the folder structure even once the .WIM is mounted.

Just providing an update... I was not able to get the above script to properly install/deploy as a part of the task sequence. SMSTS wasn't showing any errors or failures, but the registry edits were not being applied. What I have done instead was this... - Installed Win10 on reference PC (virtual or physical) - Enter Audit Mode by pressing CTRL+SHIFT+F3 - Ran the above script which customizes the default profile - Ran Windows Updates - Captured Image - Deployed This is working. I can't make every customization I wanted but 95% of them are working and after dealing with this for a week already thats better than nothing. Hopefully some more long-term and reliable solutions will become available as Win10 matures. Thanks again everyone for your help, and if anyone has any other methods please do post them!

Thanks again for chiming in YPCC. I'm surprised that I haven't been able to find more workarounds online, I can't be the only one trying to customize user profiles in Win10? Took a little digging around but I was able to make (almost) all the customizations I wanted in HKCU. For this case, I guess what I'll want to do is load the NTUser.dat from the default profile, and make the edits to HKU:\DefaultProfile instead of HKCU - sound about right? A couple things to note... - You cant use Powershell with HKU:\ directly, Powershell can't access that hive by that name....I have to write it as Microsoft.Powershell.Core\Registry::HKEY_Users, but this works so thats fine. - The command to include This PC on the Desktop and Hide Touch Keyboard failed because the two keys preceding keys don't exist, had to include command to create them first (shown above in blue.. not sure if that will still give desired end result)

Thanks for the input everyone. Sounds like there is some area for improvement in my image building process . Just for my knowledge, when CopyProfile = True (in Win10 or Win7), which profile does it copy to the default? Does it use the account that is created during Windows install, or does this only work when using CTRL+SHIFT+F3 to enter Audit Mode? There are certain things I'd like to have set to the default profile so that these settings apply to all users who login, just not sure how to set them anymore with Win10... - Disable item checkboxes in Windows Explorer (can be set with reg keys but must it is a 'current user' setting, how would I apply these to all users that login in the future?) - Configure some default desktop icons - Hide on-screen-keyboard and language settings in taskbar - Customize the taskbar notification area

Hey everyone, We recently built a new SCCM 1602 site to replace our aging SCCM 2012 server and migrated all clients/resources. Everything went pretty smooth . We have now received a new batch of Lenovo X1 Yoga laptops and have decided to do a Windows 10 pilot/rollout along with this. A colleague is looking into the backend Windows 10 requirements (some new group policies and a few other things) and I am to prepare SCCM for Windows 10 deployments. I approached this the same way I approached Windows 7 imaging/deployment in the past... - Installed Windows 10 on laptop - Made some small customizations (disable 'item checkboxes' in file browser, show 'This PC' on the desktop, set sleep/power options, create local user accounts, show/hide certain taskbar icons, perform windows updates, etc) - Captured reference image - Created unattend.xml file using Windows SIM on a different PC - Uploaded reference image/drivers/unattend file to SCCM, distributed content - Build task sequence - Deployed The image deployed but with a few issues.. - Local and Domain Users are not getting the customizations I made (item checkboxes were enabled, did not show 'This PC' on desktop, not showing/hiding proper taskbar icons). - Start Menu would not open My questions for you all..... - Am I deploying Windows 10 right? - Can someone provide some resources for creating answer files in Windows 10? - Best practice for creating user profile customizations like listed above, and have them applied to all user accounts who log in? (CopyProfile not working in Win10?) I investigated MDT a little bit but I think that these basic functions should be achievable in SCCM without the added complexity of MDT. If MDT is truly the better way to go, any advice on learning to use that tool? Your help is much appreciated

Hey YPCC, thanks for chiming in! I think we're on the same page - that is the approach I ended up taking. I still have Software Update Groups created to package/collect all updates into groups per year, but I only deployed 2015 and 2016 updates as my reference image was created in 2016.

Bumping for thoughts - anybody have any recommendations other than applying all available updates?

I have been re-assigning clients in my site by creating device collections in my new SCCM, then simply doing right click > install client on that collection. There are some options, like if you want to force uninstall the old client first (yes), or always install client (yes), but that has been working well for me so far. I also posed this question in another thread and a member provided a VBScript that could be run to migrate clients to new sites as well. I haven't tried it yet, but it may be worth a shot. https://www.windows-noob.com/forums/topic/12899-migrate-confimgr-2012-r2-to-new-server/?p=53171

I have been creating images using the following process, and it has worked fairly well for me in the past. - Install Windows 7 x64 on PC - Install all updates, do some very basic configuration - Capture .WIM file - Upload to SCCM - Create Task Sequence (Install apps, and all software updates) However, even though I completely updated Windows 7 x64 prior to capturing the WIM, during OSD I am still seeing 60-70 updates being installed as a part of the Task Sequence. Perhaps this is because Office 2013 only gets installed during the TS, and then updates are required for it? I know that it is possible to inject updates into the image, but when I go to do that there are 400+ updates available that can be added to the image. Some date back as far as 2009, and if I fully updated the image before capturing, why would I inject these old updates? Should I just inject all of these updates anyways? None of them are expired/superseeded (as per my SUP rules), but I just didn't feel like adding 400+ updates to the image was the right approach. Also - would it even make sense to inject updates for Office 2013 into the image, when Office 2013 isn't even installed yet? How is everyone here managing updates in their image?

Hey everyone, I'm looking for some help on how I can install an application that requires multiple configuration steps. I'd like to: - Install a .MSI application - Run a Powershell script to create/edit some shortcuts created by the .MSI If the Application is removed, I'd like it to: - Run a Powershell script to remove and cleanup the shortcuts - Uninstall the .MSI I thought about using Dependencies, but I think that would be kind of backwards. I would have to create an Application for "Update shortcuts" and have the dependency as "install the MSI" first. From there, I'm not even sure how the uninstall would look. I could put this all into a Powershell script, and have the script call the .MSI installation, edit the shortcuts, etc. Then create another Powershell script to remove the shortcuts, and uninstall the .MSI.....but I thought, maybe SCCM has something built in for this that I'm not using? Appreciate the help

I'm definitely going to spend a few minutes reading through these, thanks for providing some examples! Looks like an entirely new method of deployment for me so, I'm excited to expand my options

Hey Garth, Always glad to have your thoughts - I've followed a few of your guides/instruction in the past and it has been quite helpful . Not quite sure what you mean 'as a part of the package' (this is deployed as an application btw). Are you suggesting that I install the .msi as its own 'deployment type' in the application, and then have a second deployment type for the scripted tasks? I only built it this way because this is the only way I could think to accomplish all my goals with this application. Self-taught SCCM admin over here! I'd be very interested in any best-practice or recommended methods!

The 'Active Setup' caught my interest so I messed around with that a little bit last night. It was kind of a pain getting Powershell to concatenate everything properly with all the quotes and empty values I needed to enter, but in the end I got it working. See updated version of the script below...I posted it as 'code' but it didn't autodetect it as powershell so the comments and a few things are coloured incorrectly, but you get the idea. The only caveat is that this requires a logout/login in order to apply the reg keys to HKCU Set-ExecutionPolicy RemoteSigned #Checks if Outlook is running, then closes it $ProcessActive = Get-Process Outlook -erroraction SilentlyContinue if($ProcessActive -eq $null) { Start-Sleep -s 3 } else { Stop-Process -ProcessName Outlook } #Install Proofpoint Plugin msiexec.exe /i "\\risccmp1\Sources\Proofpoint\ProofpointSpamReporting_1.2.4.0.msi" /quiet /norestart Start-Sleep -s 20 #Create 3 new registry keys called ACTIVATE, CONFIRM, and URL in the Active Setup location #On next login, the contents of StubPath are executed and a flag is automatically set in the HKCU location so this only runs once per user #The contents of StubPath are the commands I need to run in order to create the HKCU values New-Item -path "HKLM:\Software\Microsoft\Active Setup\Installed Components\Proofpoint-SpamReporting-Plugin-ACTIVATE" New-ItemProperty -path "HKLM:\Software\Microsoft\Active Setup\Installed Components\Proofpoint-SpamReporting-Plugin-ACTIVATE" -Name "StubPath" -PropertyType String -Value "REG ADD HKCU\Software\Proofpoint\Outlook\Settings\ /v ""Reg Value1"" /t REG_SZ /d 18db1cbcc1f90a1c70a2dfeb47492202" -Force New-ItemProperty -path "HKLM:\Software\Microsoft\Active Setup\Installed Components\Proofpoint-SpamReporting-Plugin-ACTIVATE" -Name "Version" -PropertyType String -Value "1" -Force New-ItemProperty -path "HKLM:\Software\Microsoft\Active Setup\Installed Components\Proofpoint-SpamReporting-Plugin-ACTIVATE" -Name "(default)" -PropertyType String -Value "Proofpoint Spam Reportig Plugin Activate" -Force New-Item -path "HKLM:\Software\Microsoft\Active Setup\Installed Components\Proofpoint-SpamReporting-Plugin-CONFIRM" New-ItemProperty -path "HKLM:\Software\Microsoft\Active Setup\Installed Components\Proofpoint-SpamReporting-Plugin-CONFIRM" -Name "StubPath" -PropertyType String -Value "REG ADD HKCU\Software\Proofpoint\Outlook\Settings\ /v ""UIConfirmSpamReport"" /t REG_DWORD /d 1" -Force New-ItemProperty -path "HKLM:\Software\Microsoft\Active Setup\Installed Components\Proofpoint-SpamReporting-Plugin-CONFIRM" -Name "Version" -PropertyType String -Value "1" -Force New-ItemProperty -path "HKLM:\Software\Microsoft\Active Setup\Installed Components\Proofpoint-SpamReporting-Plugin-CONFIRM" -Name "(default)" -PropertyType String -Value "Proofpoint Spam Reportig Plugin Confirm" -Force New-Item -path "HKLM:\Software\Microsoft\Active Setup\Installed Components\Proofpoint-SpamReporting-Plugin-URL" New-ItemProperty -path "HKLM:\Software\Microsoft\Active Setup\Installed Components\Proofpoint-SpamReporting-Plugin-URL" -Name "StubPath" -PropertyType String -Value 'REG ADD HKCU\Software\Proofpoint\Outlook\Settings\ /v "Reg Value" /t REG_SZ /d ""' -Force New-ItemProperty -path "HKLM:\Software\Microsoft\Active Setup\Installed Components\Proofpoint-SpamReporting-Plugin-URL" -Name "Version" -PropertyType String -Value "1" -Force New-ItemProperty -path "HKLM:\Software\Microsoft\Active Setup\Installed Components\Proofpoint-SpamReporting-Plugin-URL" -Name "(default)" -PropertyType String -Value "Proofpoint Spam Reportig Plugin URL" -Force #If Outlook was originally open when the script ran, re-open it if($ProcessActive -eq $null) { Start-Sleep -s 3 } else { cd "C:\Program Files (x86)\Microsoft Office\Office15" .\Outlook.exe }

Hey everyone, I've written a Powershell script that works fine when ran manually, but not when deployed through SCCM. The script does the following.. - Checks if Outlook is running, then closes if it is - Installs Proofpoint spam-reporting plugin - Creates 2 registry keys for activation and enables confirmation before send - If Outlook was originally open, reopen Outlook If I run the script manually it works great. If pushed through SCCM, only the .MSI file gets installed, and the activation (registry entries) do not occur. I've also tried writing this in VBS. Is there something I'm missing regarding SCCM deploying registry edits, or is there a preferred method to do this? A copy of the script is included below... Set-ExecutionPolicy RemoteSigned $ProcessActive = Get-Process Outlook -erroraction SilentlyContinue if($ProcessActive -eq $null) { Start-Sleep -s 3 } else { Stop-Process -ProcessName Outlook } msiexec.exe /i "\\risccmp1\Sources\Proofpoint\ProofpointSpamReporting_1.2.4.0.msi" /quiet /norestart Start-Sleep -s 20 New-ItemProperty -path "HKCU:\Software\Proofpoint\Outlook\Settings" -Name "Reg Value1" -PropertyType String -Value "123456" -Force New-ItemProperty -path "HKCU:\Software\Proofpoint\Outlook\Settings" -Name "UIConfirmSpamReport" -PropertyType DWord -Value "1" -Force if($ProcessActive -eq $null) { Start-Sleep -s 3 } else { cd "C:\Program Files (x86)\Microsoft Office\Office15" .\Outlook.exe }

Thanks for the quick reply Nathan, looks like a pretty straight forward script, the simpler the better! I'll keep this in my back pocket for when I get to that step. Has anyone else used something similar with success?

Hey everyone, This project got pushed to Q2 so I am just gearing up to work on this again now. We'll likely go from SCCM 2012 to 1511 as well, hoping that I can still get some tips as you were all very helpful in the planning stage. The question I had is about migrating clients from our current site to a new site. Are there any recommended ways to do this in bulk? We have about 500 desktops and 100 laptops in the environment and I'm not sure if the best approach is to use the current SCCM server to push a script to uninstall of the old client and reinstall with new client details, or if there are other methods? Your thoughts are much appreciated

I found that in a few cases this was related to the client getting stuck in Provisioning Mode due to a "Restart PC" task in the OSD. The problem is that the Restart PC task at the end of the task sequence wasn't properly letting the client close itself out of provisioning mode. By changing the following registry keys and rebooting the PC, I was able to get some of these clients reporting properly again. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\CCM\CcmExec Provisioning Mode set to FALSE (was set to true) SystemTaskExcludes set to *BLANK* (was set to a variety of things) However, the issue still stands that PCs that were previously reporting OK, have begun to stop reporting. Here is a ClientIDManagerStartup.log for another device that isn't reporting properly