Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Question
Tuesday, June 2, 2015 5:51 AM
Hi,
I have a task sequence which is working fine and able to run all TS steps successfully. I copied this Task sequence and made it to use the new custom OS image(recently build) in "Apply Operating System Image".
During the OSD, the OS image applies fine, post which it moves to the Setup Windows and ConfigMgr step and it reboots normally as set in the Task Sequence but it comes up to the Windows login screen for the OS already installed and doesn't complete all of the steps.
I have tried changing the settings in TS for Restart computer (just after the Setup Windows step), to run "the boot image assigned to this task sequence"but that doesn't help.
What I am not sure is why the original task sequence works fine but when it is copied, it doesn't work. The only difference here is the OS image changed under the "Apply Operating System" step and everything else is same. Also the image does applies successfully.
There aren't any errors in SMSTS.log as well. here are the logs :
==========================================================
Successfully completed the action (Setup Windows and ConfigMgr) with the exit win32 code 0
MP server http://ABC.com. Ports 80,443. CRL=false.
Setting authenticator
Set authenticator in transport
Sending StatusMessage
Setting message signatures.
Setting the authenticator.
CLibSMSMessageWinHttpTransport::Send: URL: ABC.com:80 CCM_POST /ccm_system/request
Request was successful.
Set a global environment variable _SMSTSLastActionRetCode=0
Set a global environment variable _SMSTSLastActionSucceeded=true
Expand a string: %_SMSTSMDataPath%\Logs
Clear local default environment
The action (Setup Windows and ConfigMgr) requested a retry
Reboot to local harddisk
_OSDGinaIsConfigured variable set to TRUE
_SMSTSServiceStartType variable set to
Command line for extension .exe is "%1" %*
Set command line: "bcdedit.exe"
Executing command line: "bcdedit.exe"
Process completed with exit code 0
Calling RebootSystem()
OSD type of task sequence. ignore the service window setting
Updated security on object C:\SMSTSVolumeID.7159644d-f741-45d5-ab29-0ad8aa4771ca.
Updated security on object D:\SMSTSVolumeID.7159644d-f741-45d5-ab29-0ad8aa4771ca.
Updated security on object S:\SMSTSVolumeID.7159644d-f741-45d5-ab29-0ad8aa4771ca.
Path variable OSDisk converted from C: to 12EF4E7C0000401F00000000:
Updated security on object C:\SMSTaskSequence.
Set a global environment variable _SMSTSNextInstructionPointer=88
Set a TS execution environment variable _SMSTSNextInstructionPointer=88
Set a global environment variable _SMSTSInstructionStackString=0 76
Set a TS execution environment variable _SMSTSInstructionStackString=0 76
Save the current environment block
Expand a string: %_SMSTSMDataPath%\Logs
==========================================================
Many Thanks
Vikram Midha
All replies (20)
Tuesday, May 31, 2016 4:57 AM ✅Answered
Hello Mike,
This was normally suspected to be due to drivers concerns but that was not the case.
As I investigated further, this came out to be due to version mismatch for the boot image, i.e. this normally happens when the boot image used has an older version with respect to the SCCM hierarchy version you have.
When the SCCM core hierarchy is upgraded but you still continue to use the older version custom boot image with the task sequences.
let me know for any queries.
Tuesday, June 2, 2015 6:42 AM
I would start by looking at the client installation. Did it succeed? Also, is the device joined to the domain? If not, you might have to redo the credentials of the accounts used in the task sequence.
My Blog: http://www.petervanderwoude.nl/
Follow me on twitter: pvanderwoude
Tuesday, June 2, 2015 6:58 AM
Hello Peter,
I am trying this on a PC which has an OS already installed.
I could see that the machine name is the same as it ways and not changed to the new one provided during OSD, also the machine is not part of the domain.
The machine already had the SCCM client installed on it. Also as per the SMSTS logs, the client was installed successfully.
Thanks
Tuesday, June 2, 2015 7:11 AM
And the device should have joined the domain? If it should, you might have to redo the credentials of the accounts used in the task sequence.
My Blog: http://www.petervanderwoude.nl/
Follow me on twitter: pvanderwoude
Tuesday, June 2, 2015 7:14 AM
Hello Peter,
I am trying this on a PC which has an OS already installed.
I could see that the machine name is the same as it ways and not changed to the new one provided during OSD, also the machine is not part of the domain. Also, this is happening for this task sequence only.
The machine already had the SCCM client installed on it. Also as per the SMSTS logs, the client was installed successfully.
Thanks
Tuesday, June 2, 2015 9:08 AM
I could see that the machine name is the same as it ways and not changed to the new one provided during OSD, also the machine is not part of the domain. Also, this is happening for this task sequence only.
So the image your provided hasn't been applied? Are you sure you aren't looking at old smsts.log file on the machine? I would babysit it as it deploys and see where it fails. Do you have F8 prompt enabled on your boot image?
It doesn't even sound like its formatting the drive if the name of the computer is the same as before.
Tuesday, June 2, 2015 9:25 AM
These are the latest logs.
I have actually seen it while it deploys the Image and it reboots while on "Setup Windows and ConfigMgr".
It takes a good amount of time as is usually done when on the step "Applying Operating System Image". Also the smsts.log confirms the same that the step was completed successfully for applying Operating System.
The strange thing is the original TS from where it's copied actually works but not this one.
Tuesday, June 2, 2015 11:00 AM
Can you provide more detail about the current platform/scenario.
Did you do PXE Boot then kickoff build or from Existing OS.
Tuesday, June 2, 2015 11:25 AM
Hello,
Yes, I am trying to re image a PC using PXE boot.
Please let me know for more details apart from the one provided above.
Tuesday, June 2, 2015 12:51 PM
If you are trying to reimage the system, the fact that it currently has the client or is currently joined to the domain are meaningless as these must both be re-done during the re-install.
You need to actually check on the things that Peter mentioned above: specifically that the system is getting an IP address and that the client agent finished installing successfully.
Jason | http://blog.configmgrftw.com | @jasonsandys
Wednesday, June 3, 2015 11:43 AM
Hello Jason,
Looking at the system properties as soon as the system comes backup after the reboot, it shows the hostname which was given some days back (could be when the image was captured) and not which was given during the OSD startup process.
It shows the SCCM client available on it but that is due to the fact that it was part of the image when it was captured. So I could say, the client wasn't installed with OSD and its the old one persistent with the image.
The machine also shows up to be part of the WORKGROUP.
I am suspecting something with the captured image and planning to recreate one. As I said, the original TS works but not this copied one, the only difference is the OS image which was changed and nothing else.
Wednesday, June 3, 2015 1:21 PM
hostname is meaningless.
Have you checked smsts.log?
Have you checked ccmsetup.log?
Have you done a simple ipconfig to test if the system has an IP?
Jason | http://blog.configmgrftw.com | @jasonsandys
Thursday, June 4, 2015 4:32 AM
hostname is meaningless.
With the information I posted above, i am trying to convey that it seems that the machine was not imaged at all. Though the TS process shows that the OS was downloaded and applied successfully which was confirmed from the smsts.log as well. but as I said, when machine boot backs up, it shows the name and details for the system which I am trying to reimage.
Have you checked smsts.log?
Yes, already. the smsts.log are what I posted originally above. As per it the step Setup Windows and ConfigMgr ran successfully and doesnt have any errors.
Have you checked ccmsetup.log?
Yes, the ccmsetup.log available on the system are the one when the original system (on which I am trying to reimage) was deployed with OS and there aren't any new logs generated. But during OSD process, it shows downloading the CCM files which I cross checked and were available on the system.
Have you done a simple ipconfig to test if the system has an IP?
If the machine boots up to PXE and proceeds with the OSD process up to the Setup Configmgr step, why is it required to check it again? Not sure about it.
Thursday, June 4, 2015 5:30 AM
Hi Vikram,
Machine can loose IP after reboot.
Machine can loose IP after reboot.
Also as you mentioned you suspect that there could be some issue with captured image. could you do recapture to confirm if it worked?
Thursday, June 4, 2015 6:11 AM
Hello,
Yes, thats what I think as that is the only thing changed. I am in the process of capturing it.
Will post very soon.
Thanks
Thursday, June 4, 2015 3:45 PM
Having the same name is expected. What other name would you expect it to have?
Having network connectivity (and really the proper drivers) during the WinPE phase which occurs before the Setup Windows and ConfigMgr task and having connectivity after this task which is when the system boots into the deploy OS are two different things because they use two different sets of drivers.
Also, I missed this in the log above: "The action (Setup Windows and ConfigMgr) requested a retry"
This means it did not complete successfully and is often the result of the ConfigMgr client agent not being installed properly.
Your image is also a likely culprit here.
Jason | http://blog.configmgrftw.com | @jasonsandys
Thursday, May 26, 2016 2:29 PM
Hi, Did you ever resolve this. I am have the same issue. Thanks, Mike
Thursday, May 26, 2016 5:10 PM
Hello,
Yes, thats what I think as that is the only thing changed. I am in the process of capturing it.
Will post very soon.
Thanks
Hi, Did you ever resolve this. I am have the same issue. Thanks, Mike
Wednesday, June 22, 2016 3:11 PM
Hello Mike,
This was normally suspected to be due to drivers concerns but that was not the case.
As I investigated further, this came out to be due to version mismatch for the boot image, i.e. this normally happens when the boot image used has an older version with respect to the SCCM hierarchy version you have.
When the SCCM core hierarchy is upgraded but you still continue to use the older version custom boot image with the task sequences.
let me know for any queries.
Hi Vikram,
Good work identify a version mismatch. I have the exact same issue. Where do I look to confirm the version mismatch on the boot image and resolve.
Thanks in advance Andy
Saturday, July 9, 2016 11:05 AM
Hello Andy,
Check the boot image version under "\Software Library\Overview\Operating Systems\Boot Images", enable the "Version" tab in it.
By default, when you upgrade the core hierarchy, the default boot images versions are also upgraded but it does not upgrade the version of the custom boot image(s).
Go to the above location and make sure that all boot images you have shows the same version. You could notice any difference there, (if default have another version and custom have another). At this point if you continue to use the older custom boot image, you will face the discussed issue here. So, in order to make the custom boot image match the current version, you have to recreate them.Once done, integrate these new custom boot images with your task sequences and it will work fine.
Let me know for any troubles.