This is an interesting method. However, I mitigate those task sequence problems using what I believe it is a much easier method to deal with the problem of domain policies interfering with the final stages of MDT deployments. Basically, all we need to do is suppress the scripted reboot that happens right after MDT joins the domain. This allows for MDT to fly through the rest of the task sequence and perform software installs and any other tasks you've created after joining the domain without reboots, therefore, preventing any group policies from the domain to interfere since you haven't rebooted yet. Then, when the task sequence finishes, you can automatically reboot the machine by adding FinishAction=RESTART to your CustomSettings.ini.
All you have to do is edit the ZTIDomainJoin.wsf script by "commenting out" the two lines that end with "true". Just type an apostrophe in front of each of the lines as illustrated below:
This method is much cleaner and far less intrusive because it does not require changing the Unattend.xml as many others suggest around the internet, or altering the task sequence order or removing MDT's built-in method to join the domain or using any 3rd party vbs scripts to join the domain. Others have suggested to put your computers in AD in a different OU where the policies won't affect them which then changes your workflow since you then have to move those computers back to the OU where they belong. The method I propose does not require changing your workflow in this manner. In addition, there is no need to "undo the damage" as explained in this video presentation because there is no damage done in the first place. It is also a more secure method since it does not require to hard code your passwords anywhere like some others suggest in other tutorials.
The method was needed (and still is) due to the complexity of the environment. Some post-domain join application installs do not allow the suppression of reboots, so your solution would not work for us. The method presented is still being used and has caused no problems, with over half a million Windows installs since it was put in place.
One caveat: back in 2012 when presented, the solution to the technical issue of using the PowerShell to restore was not known at the time of the presentation - the script was correct and actually works, only how it was invoked needed to be changed. When invoked AS SYSTEM (use PSexec to do it), without alteration to the script itself, it works. This is because TAKE OWNERSHIP is a different right than ASSIGN OWNERSHIP, and the script as built would only work with TAKE OWNERSHIP.
I am however glad that you found a solution that works for you, and appreciate your contribution to the community; My 8-year old method isn't for everyone.