none
Intermittent "Failed to show task sequence progress dialog. Error code 0x80070534" error on Windows XP Task Sequence RRS feed

  • Question

  • Hi all,

    This is officially driving me mad! On my Windows XP Task Sequence I am intermittently seeing these errors in the smsts log and the Task Sequence progress dialogue box doesn't from the point of booting back up into Windows. Another symptom is that I'm guessing because there is no progress box, my Application scripts run but fail with a non-zero 1618 return code error.

    If anyone has seen this before or has any idea's I would be mega grateful for suggestions. I have tried as much logical 'trial and error' testing I can think of, different makes/models/drivers/network ports/network switches/VLAN's the lot!

    Thank you in advance for your time.

    James

    Wednesday, June 12, 2013 3:21 PM

Answers

  • Hi David/all,

    Sorry it took me a while to get round to this, I complete forgot I still had it open as an unanswered question!

    The issue turned out to be due to some custom scripts we have performing Active Directory OU moving as part of the Task Sequence, specifically the order in which we were performing these actions in relation to when the domain join happens. I shall go into more detail on the issue below;

    In the FrontEnd we are using (a heavily customised version of the PrettyGoodFrontEndClone by Maik Koster) before you kick off a deployment it is required to select the OU you wish the computer to be moved to as it is joined to the domain. For general tidiness and to avoid any conflicts with Group Policies running somewhat keenly while the machine is still building, we have an OU labelled _MDT To Be Assigned which has inheritance blocked from all GPO's - this is known as our Staging OU.

    The Active Directory OU maintenance work is comprised of two stages;

    In the FrontEnd, we are saving the value of the destination OU off to a custom MDT variable called StagingOU. In the MDT Database, we have the MachineObjectOU set to the value of the _MDT To Be Assigned OU.

    As we want the machine to reside within the _MDT To Be Assigned staging OU during the actual deployment, on press of the Finish button we check if the computer account currently exists within AD, if it does it will move it from it's current location to this temporary OU. As MDT can only perform move actions based on the value of the MachineObjectOU variable we must then swap the variables around so that for the final stage once the deployment has completed, we rewrite the MachineObjectOU value to be that of the StagingOU we defined earlier in the FrontEnd using the following code;

    'Swap Variables around for OU's
     sStagingOU = oEnvironment.Item("MachineObjectOU")
     oEnvironment.Item("MachineObjectOU") = oEnvironment.Item("StagingOU")
     oEnvironment.Item("StagingOU") = sStagingOU

    The problem with this was due to the stage in the process when XP performs the domain join action, and therefore it was joining the domain and immediately putting the new computer into the final destination OU specified in the FrontEnd. So when the computer then booted up into Windows to carry on installing custom apps etc as part of the Task Sequence, we had some Group Policy's running which was interfering with the Task Sequence and causing it to fail.

    The resolution was simply to move the variable swapping code from the end of stage one, and to the beginning of stage two, which is run as one of the final steps within the Task Sequence, meaning until this point, the MachineObjectOU variable was still set with the value of the _MDT To Be Assigned staging OU so that when the domain join was happening the machine was being dropped into an iusolated OU with blocked inheritance meaning that the Task Sequence could finish successfully without any interference from overly keen GPO's.

    Ultimately a very simple thing and thankfully a very simple fix, but something that took a LOT of investigating and sleepless nights! Hopefully this post will enable someone else to not experience this headache!

    Kind Regards,

    James


    Tuesday, August 6, 2013 2:33 PM

All replies

  • Since I don't believe you can mark your original question itself as the answer, please post a reply (not edit) that it's resolved and then mark that as the answer so that the thread shows as resolved when searching and browsing the forum. : )

    David Coulter | http://DCtheGeek.blogspot.com | @DCtheGeek

    Wednesday, June 12, 2013 6:12 PM
    Answerer
  • Hi David/all,

    Sorry it took me a while to get round to this, I complete forgot I still had it open as an unanswered question!

    The issue turned out to be due to some custom scripts we have performing Active Directory OU moving as part of the Task Sequence, specifically the order in which we were performing these actions in relation to when the domain join happens. I shall go into more detail on the issue below;

    In the FrontEnd we are using (a heavily customised version of the PrettyGoodFrontEndClone by Maik Koster) before you kick off a deployment it is required to select the OU you wish the computer to be moved to as it is joined to the domain. For general tidiness and to avoid any conflicts with Group Policies running somewhat keenly while the machine is still building, we have an OU labelled _MDT To Be Assigned which has inheritance blocked from all GPO's - this is known as our Staging OU.

    The Active Directory OU maintenance work is comprised of two stages;

    In the FrontEnd, we are saving the value of the destination OU off to a custom MDT variable called StagingOU. In the MDT Database, we have the MachineObjectOU set to the value of the _MDT To Be Assigned OU.

    As we want the machine to reside within the _MDT To Be Assigned staging OU during the actual deployment, on press of the Finish button we check if the computer account currently exists within AD, if it does it will move it from it's current location to this temporary OU. As MDT can only perform move actions based on the value of the MachineObjectOU variable we must then swap the variables around so that for the final stage once the deployment has completed, we rewrite the MachineObjectOU value to be that of the StagingOU we defined earlier in the FrontEnd using the following code;

    'Swap Variables around for OU's
     sStagingOU = oEnvironment.Item("MachineObjectOU")
     oEnvironment.Item("MachineObjectOU") = oEnvironment.Item("StagingOU")
     oEnvironment.Item("StagingOU") = sStagingOU

    The problem with this was due to the stage in the process when XP performs the domain join action, and therefore it was joining the domain and immediately putting the new computer into the final destination OU specified in the FrontEnd. So when the computer then booted up into Windows to carry on installing custom apps etc as part of the Task Sequence, we had some Group Policy's running which was interfering with the Task Sequence and causing it to fail.

    The resolution was simply to move the variable swapping code from the end of stage one, and to the beginning of stage two, which is run as one of the final steps within the Task Sequence, meaning until this point, the MachineObjectOU variable was still set with the value of the _MDT To Be Assigned staging OU so that when the domain join was happening the machine was being dropped into an iusolated OU with blocked inheritance meaning that the Task Sequence could finish successfully without any interference from overly keen GPO's.

    Ultimately a very simple thing and thankfully a very simple fix, but something that took a LOT of investigating and sleepless nights! Hopefully this post will enable someone else to not experience this headache!

    Kind Regards,

    James


    Tuesday, August 6, 2013 2:33 PM