@Narcoticoo - I changed the deployment to required but it still didn't install.

@Kerwin - I was afraid that the logs rolled over.  I figured I will try again and try to catch the log before it rolls over.  I didn't think about the fact that it may have run out of space. 

Just out of curiosity, is there a best practice on how to handle updates to the OS?  Or maybe a good way to do this?

I made an update group with one update it and it still doesn't install.  Additionally the logs are rolling over faster than I thought so I wasn't able to get anything useful.

Make sure your Setup Windows and ConfigMgr step has the SMSMP=yourmp.yourdomain.com.  I found in the past this must be present for running updates during a TS.  I also assume this is a known machine and is getting the deployment from an existing collection.  If not you need to deploy the updated group to the Unknown computers collection as well.

And from my experience, if the TS env runs out of space, it happens at the very beginning of the TS, before it starts (when querying policy).

I didn't have the SMSMP entry in there so I added it, but it didn't appear to help the situation.

When the machine starts out, it is an unknown machine.  This is where I have the update group and the TS deployed to. 

Have you tested importing the VM with MAC as a known computer to ConfigMgr, put it into a collection and deploy your task sequence and updates against that collection?

Yeah sorry I missed on your OP that you deployed to unknown.  So once it completed the build, it becomes a known machine.  Are you removing it from SCCM DB before retrying?

And as stated above, if you can capture the full set of logs we may be able to assist.

@Narcoticoo - No I haven't tried that.

@William - Yes, I am removing it from the SCCM DB before trying.  Yeah, I just don't know how to go about capturing them all just yet.  That is one thing I haven't figured out.

Hello everyone,

I have been racking my brain and doing all sorts of research but I can't figure out what I'm missing.  So right now my OSD has a Windows 7 image that we made back in April with all of the April updates.  So what I want to do is basically install the updates that have come out since then.  So what I did was copy a currently working task sequence and removed all the application and package installation to save time.  I then added an Install Updates task that is set to install All Software Updates. I have both the task sequence and software update group (available not required) deployed to the unknown computers container.

During the deployment, it would appear as though it is doing something because it sits there with a blue bar and the name of the task but doesn't give me a status of downloading or installing. When the OS comes up and I log in, I go to the control panel and look for installed updates from today but there is nothing there.

I grabbed the SMSTS log file and put it up on my onedrive and shared it out.
OneDrive Share

These are some of the entries that stand out for me but I haven't been able to find information that seems good and pertains.

RegQueryValueExW is unsuccessful for Software\Microsoft\SMS\Task Sequence, SMSTSEndProgram TSManager 8/13/2015 1:26:22 PM 448 (0x01C0)

GetTsRegValue() is unsuccessful. 0x80070002. TSManager 8/13/2015 1:26:22 PM 448 (0x01C0)

ReleaseRequest failed with error code 0x80004005 TSManager 8/13/2015 1:26:22 PM 448 (0x01C0)

Task Sequence Manager could not release active TS request. code 80004005 TSManager 8/13/2015 1:26:22 PM 448 (0x01C0)

RegQueryValueExW is unsuccessful for Software\Microsoft\SMS\Task Sequence, SMSTSEndProgram OSDSetupHook 8/13/2015 1:26:31 PM 900 (0x0384)

GetTsRegValue() is unsuccessful. 0x80070002. OSDSetupHook 8/13/2015 1:26:31 PM 900 (0x0384)

Any assistance would be greatly appreciated.

Change the deployment to be required instead.

If you are using MDT integrated Task Sequences, the "Copy Logs" task (pointing to ZTIcopylogs.wsf") will copy the logs to a path set by using CustomSettings.ini called SLShare.

Example:

SLShare=\\yourserver\yourshare

Domain Computers must have write access to this share.  If you drop a the "Copy Logs" task into your "Post Install" phase (prior to first reboot) you should be able to capture the logs from PE as well as the logs upon completion.

Note: "Copy Logs" is not to be confused with "Copy SMS Logs".  The latter is used during USMT functions.

Alternatively you can enable command line support in your boot image and Press F8 once the build begins.  This will prevent Windows PE from rebooting after the post install phase.  You can map a drive and copy the logs off there, then grab the final logs after it completes.

• Edited by William Bracken 12 hours 11 minutes ago

If you are using MDT integrated Task Sequences, the "Copy Logs" task (pointing to ZTIcopylogs.wsf") will copy the logs to a path set by using CustomSettings.ini called SLShare.

Example:

SLShare=\\yourserver\yourshare

Domain Computers must have write access to this share.  If you drop a the "Copy Logs" task into your "Post Install" phase (prior to first reboot) you should be able to capture the logs from PE as well as the logs upon completion.

Note: "Copy Logs" is not to be confused with "Copy SMS Logs".  The latter is used during USMT functions.

Alternatively you can enable command line support in your boot image and Press F8 once the build begins.  This will prevent Windows PE from rebooting after the post install phase.  You can map a drive and copy the logs off there, then grab the final logs after it completes.

• Edited by William Bracken 12 hours 13 minutes ago

Sorry but I'm not using MDT.

What I did do is increase the size of the logs in the hopes that it would capture more information.  I then, just to make sure ran a copy job to grab a copy of the logs when it appeared as though the Windows Update task was running or hung and then did a second copy job when it appeared to have finished.

I myself, haven't really gone through them yet but I will in a minute to see if I find anything.

I have placed them in the same location

OneDrive Logs

If you are using MDT integrated Task Sequences, the "Copy Logs" task (pointing to ZTIcopylogs.wsf") will copy the logs to a path set by using CustomSettings.ini called SLShare.

Example:

SLShare=\\yourserver\yourshare

Domain Computers must have write access to this share.  If you drop a the "Copy Logs" task into your "Post Install" phase (prior to first reboot) you should be able to capture the logs from PE as well as the logs upon completion.

Note: "Copy Logs" is not to be confused with "Copy SMS Logs".  The latter is used during USMT functions.

Alternatively you can enable command line support in your boot image and Press F8 once the build begins.  This will prevent Windows PE from rebooting after the post install phase.  You can map a drive and copy the logs off there, then grab the final logs after it completes.

• Edited by William Bracken Friday, August 14, 2015 7:36 PM

If you are using MDT integrated Task Sequences, the "Copy Logs" task (pointing to ZTIcopylogs.wsf") will copy the logs to a path set by using CustomSettings.ini called SLShare.

Example:

SLShare=\\yourserver\yourshare

Domain Computers must have write access to this share.  If you drop a the "Copy Logs" task into your "Post Install" phase (prior to first reboot) you should be able to capture the logs from PE as well as the logs upon completion.

Note: "Copy Logs" is not to be confused with "Copy SMS Logs".  The latter is used during USMT functions.

Alternatively you can enable command line support in your boot image and Press F8 once the build begins.  This will prevent Windows PE from rebooting after the post install phase.  You can map a drive and copy the logs off there, then grab the final logs after it completes.

• Edited by William Bracken Friday, August 14, 2015 7:36 PM

Those lines are not real errors. The TS is just cleaning-up.

Unfortunately, the TS logs have rolled over and we can't see the actual failure.

My guess is that you have too many updates targeted to the client and the TS ran out of environment space. Please try targeting a few updates first and see how that goes.

Those lines are not real errors. The TS is just cleaning-up.

Unfortunately, the TS logs have rolled over and we can't see the actual failure.

My guess is that you have too many updates targeted to the client and the TS ran out of environment space. Please try targeting a few updates first and see how that goes.

@Narcoticoo - No I haven't tried that.

Well try it. Also, is the deployment for the Software Update Group configured so that it's available as soon as possible and that the deadline is as soon as possible also? And there are no maintenance windows configured on the unknown computers collection?

Yes they were both configured for as soon as possible. There is no maintenance window on the unknown computer collection.  I can give it a try.

Although Narcoticoo's suggestion may tell if you have an overall issue, you should absolutely be able to deploy updates to an unknown machine...  just an FYI. :-)

Unfortunately the log files still don't go back far enough Brian.  

The logs are filled with items similar to this:

[1563] Deleted setting 'CCM_CIVersionInfo.ModelName="Site_DE1A34AD-32EF-4E20-AD1E-E345E9E17E45/SUM_66484bd9-1b76-445b-9642-54ee56b5869a",Version="104"'.

At what step in your Task Sequence are you installing updates?  

And if you are not using MDT integrated Task Sequences, I would highly recommend it. ;-)

Sorry I didn't get a chance to work on this yesterday.  Had a few fires to put out yesterday.

I do understand that Narcoticoo's suggestion would test an overall issue, which I am not having an issue deploying updates in general.  It is just during OSD.  I think I was able to increase the size of the logs and it looks like I may have gotten logs to catch from the beginning as the time stamp is about the time I started the latest image.  I have uploaded the new logs to the same link.

As for the task sequence order, I took the current one that is working (without updates) and made a copy. I then went through and disabled all of the steps that I wanted to skip for testing purposes.  I wanted to get it right once before I tried the whole thing.  I took a screenshot of task sequences.

What's interesting is that in the smsts.log, I did find where it appears to be preparing the updates and then it says "No updates need to be installed on this machine." It then says that the task successfully completed with win32 code 0. It seems as though it thinks the update is not needed.

I did download the update manually it is willing to let me install it.  I also checked Windows Update by going out to the web and it shows as an available update.  So it is missing and needs to be installed.  Not sure why it thinks that it's there.

Oh and in regards to MDT.  I did start to look into it because I saw a new version has been released.  I just need to look into whether or not I should use that version or if I need to upgrade as I just went to R2 recently.

There are very recent reports of some nasty bugs in MDT 2013 Update 1 (just released) so I would stick with MDT 2013 RTM unless you must deploy Windows 10.  

Where is that restart step booting to? It isn't needed there since the earlier step already reboots the machine. Have you tried changing the order of your update steps? Try adding the scan and wait first before the actual install updates step. I'm guessing this has something to do with the policies not kicking in fast enough after the setup client step...

@William - I have no need to deploy Windows 10 any time soon.  We got done migrating to Windows 7 not to long ago.  We had some slow adoption rates for it.  Users loved Windows XP.  A few Windows 10 machines may pop up within the IT department but they were all be disked based builds.

@Narcoticoo - The reboot is part of our bitlocker enable.  The first step makes some changes that requires a reboot before the remainder can move forward. So there is the Bitlocker Enable Script, a reboot and then there is the Enable Bitlocker package that is in the application installation part. I supposed I could move that down into its own section to test and if it works move the bitlocker things to the very end along with the reboots.

Just as an aside.  I recently took over the OSD portion and know very little about bitlocker.  We had a tier 3 service desk help with the deployment of bitlocker and he told me that this was the order things had to happen in.  So I am not 100% sure how truthful that is.

I suggest you to look at pre-provisioning Bitlocker in the WinPE -phase, just after the disk partitioning steps. More info on this can be found here http://www.niallbrady.com/2012/09/23/how-can-i-pre-provision-bitlocker-in-winpe-for-windows-8-deployments-using-configuration-manager-2012-sp1/

@Narcoticco - Thanks for the pointer. I implemented that today and it seems to be working great.

@William or anyone - I have been looking at MDT and looking at how to do this.  I did find this link over at Windows-Noob.com.  It looks like I basically need to install the software and then "redo" a lot of the stuff I did when I first configured OSD including creating all new tasks as MDT tasks.  Just out of curiosity, is this true?  Or can I just use the boot images and tasks that I have now and just add in the MDT integrated tasks?

Just to remind you, if you're going to use MDT's ZTIWindowsUpdate -script for the update installation, you will need additional WSUS server to act as a source. You cannot use ConfigMgr's SUP for this.

Did you try my method for changing the order? In my sequence, I have lot's of app installations after the Setup Windows & ConfigMgr step, after that the updates are installed with scan-install-wait x 3 and it just works.

You would be better served to create a new MDT Task Sequence and migrate your customizations to it in my opinion.  Given you are new to MDT it may take a bit of running the TS and watching all the logs to get a handle on how everything works together.  You can continue using your own Boot image.  No need to switch that up.

The MDT help files will show you all the things you can do with variables (Using CustomSettings.ini for example).  There are a ton of blog posts on the internet referencing MDT Task Sequences as well.  

Once you go MDT, you may never go back. ;-)

Sorry for not getting back to this faster. Had a number of fires and projects that had to get pushed out.  I haven't had much time to change or test anything in regards to the updates.  I did discuss with my boss setting up MDT but he seems to be discouraged about setting up an additional WSUS server.  Does it really require any additional one just for itself?

I did however, change the location of the bitlock step and it works great. 

You dont have to use a standalone WSUS server for MDT.  The MDT script to install updates will use Microsoft Updates if no local WSUS server is provided.  You dont have as much control however you can exclude updates from installing using CustomSettings.ini if there are known updates you don't want in your image.

asking again, did you change the orde of the steps like I proposed earlier? You do not need to setup MDT for update deployment issues.

@William - Thank you for the clarification.

@Narcoticoo - I changed things this morning and gave it a test but I get the error code 0x0000ADDA.  As soon as I saw the error, I grabbed the logs and posted them onto my OneDrive Share.  They are in the log3 folder.

I did some brief research into the error but have not found anything of substance yet.  I am going to go through the log myself and do some more research on the error but assistance would be greatly appreciated if someone knows something more than I do.

I also remembered that I took a new screenshot of my task sequences.  So basically I added a line that put in a 60 second delay.  Then it scans.  The wait for Scan to Finish is set for 30 seconds. The install updates is set for Mandatory Software Updates. 

• Edited by BrianGWAccount 17 hours 34 minutes ago

Got past that issue and you can see it go through all of the task sequences but the update that I deployed still doesn't install. I uploaded new logs to log4.

@William - Thank you for the clarification.

@Narcoticoo - I changed things this morning and gave it a test but I get the error code 0x0000ADDA.  As soon as I saw the error, I grabbed the logs and posted them onto my OneDrive Share.  They are in the log3 folder.

I did some brief research into the error but have not found anything of substance yet.  I am going to go through the log myself and do some more research on the error but assistance would be greatly appreciated if someone knows something more than I do.

I also remembered that I took a new screenshot of my task sequences.  So basically I added a line that put in a 60 second delay.  Then it scans.  The wait for Scan to Finish is set for 30 seconds. The install updates is set for Mandatory Software Updates. 

• Edited by BrianGWAccount Tuesday, September 01, 2015 2:15 PM

So I'm a little lost at this point. In the log it says that there are no updates to be installed on this machine.  However, once the machine is up and running, I can go to Windows Update via the web and that update is listed as being required.  It isn't there when I look at the add / remove programs.  I am not sure what is going on here.

You refer to update as a single update you want to install? What is it? Is it needed for the machine from ConfigMgr point of view?

I only refer to it as a single update because I had a bigger package and someone suggested reducing the amount of updates in it. So I cut it down to one update that was a critical Windows 7 update. I figured that would be the easier way to get it working and then once I get this working, add more.

So that is the interesting thing here.  When I run the report to look for "Computers in a specific compliance state for an update (secondary)" for this update and "Update is not required" the machine that I just tested on is in there. So it seems SCCM thinks it isn't required even though Windows Update thinks it is required.

So add more updates to the deployment and try again.

I did and none of them installed. I wonder if I just need a longer delay between installing the client and installing the updates. I think I am going to turn back on most of the application installation and try again.

I did and none of them installed. I wonder if I just need a longer delay between installing the client and installing the updates. I think I am going to turn back on most of the application installation and try again.

• Proposed as answer by Xin GuoMicrosoft contingent staff, Moderator Wednesday, September 09, 2015 9:07 AM

According to your logs, none of the mandatory updates are applicable to the client machine.

Installing mandatory updates InstallSWUpdate 8/18/2015 3:45:13 PM 2508 (0x09CC)
Checking if the active request handle: {30938873-4ABE-40C1-99A9-64E8DC7D3C2F} is valid. InstallSWUpdate 8/18/2015 3:45:13 PM 2508 (0x09CC)
CoCreateInstance succeeded InstallSWUpdate 8/18/2015 3:45:13 PM 2508 (0x09CC)
Active request handle: {30938873-4ABE-40C1-99A9-64E8DC7D3C2F} is valid. InstallSWUpdate 8/18/2015 3:45:13 PM 2508 (0x09CC)
InstallSWUpdates(spInstall, spCIAgentCallback, tType, pszActiveRequestHandle, &jobID), HRESULT=87d00708 (e:\nts_sccm_release\sms\client\osdeployment\installswupdate\installswupdate.cpp,929) InstallSWUpdate 8/18/2015 3:45:13 PM 2508 (0x09CC)
No updates need to be installed on this machine. InstallSWUpdate 8/18/2015 3:45:13 PM 2508 (0x09CC)
Setting TSEnv variable SMSTSInstallUpdateJobGUID= InstallSWUpdate 8/18/2015 3:45:13 PM 2508 (0x09CC)
Process completed with exit code 0 TSManager 8/18/2015 3:45:13 PM 952 (0x03B8)
!--------------------------------------------------------------------------------------------! TSManager 8/18/2015 3:45:13 PM 952 (0x03B8)
Successfully completed the action (Install Software Updates I) with the exit win32 code 0 TSManager 8/18/2015 3:45:13 PM 952 (0x03B8)