TSBackground Mark II - ConfigMgr Task sequence background application.

I replaced the TSBackground.exe with the new one and updated the boot image, but when booted, the old TSBackground.exe was still in use.  I tried several more times modifying other things to get it to use the new one, but in the end I had to create a new one to get it to pickup the new file.

Hello, great product, real good features, thanks for developing it!

But i'm having issues with the latest versions.
I have 5 different machines running the same boot image and Task Sequence. And there's always 1 or two failing when running "Setup Windows and ConfigMgr" step.

I traced the problem into the TSBackground folder isn't copied to the \Windows\Temp folder.
The parsing error displayed is showing issues with the unattend.xml and the logs say that it can't find the specific file. After reboot and starting the boot image again i look at the OSDisk and rightly so, there's no TSBackground in the C:\Windows\Temp folder.

Unattend.xml 
*
<RunSynchronousCommand wcm:action="add">
    <Description>TSBackground</Description>
        <Order>1</Order>
             <Path>%OSDTargetSystemDrive%\windows\temp\TSBackground\TSBackground.exe UNATTEND</Path>
</RunSynchronousCommand>
*
TSBackground.exe.config:
*
<add key="DisableTimeHandling" value="False"/>
<add key="CopySelfToOSDisk" value="True"/>
<add key="CaptureF8" value="True"/>
*
The odd thing is that all 5 machines are running the same Boot Image, and basically the same task. And the sometimes the problem occurs, sometimes it don't.
Any logs i might look at concerning the move of the TSBackground folder?

Thanks for reporting the issue, I'm investigating if the "copying" can get more robust - it seems a small (very) number of users experience the problem...

An improved version has now been published; please report if the problem persists?

Oh perfect, was nervous i did something wrong :).
I'll get right on testing the new version. Thank you!

Seems to be running alot smoother now, thanks for the update!

Firstly thanks for this great utility. Documentation is very well written, and following it, I (mostly) for this working in my environment without any issues.

I am using Config Mgr CB 1902, with the latest MDT and ADK. I have created an MDT Task Sequence, which uses a UDI Wizard interface to prompt for machine name, optional applications ewtc.

I have used the recommended options in the TSBackground all the way, and edited my unattend.xml file, with the following line as suggested -
"%OSDTargetSystemDrive%\windows\temp\TSBackground\TSBackground.exe UNATTEND"

Boot, remote control, background changes all work fine, until the machine reboots from WinPE to Windows. TSBackground no longer loads, and the build actually fails. As TSBackground has taken over the build UI, I don't see the normal error dialogue, but it just reboots twice, and presents me with Windows login screen.

Checking the logs, I finally found out that when trying to load TSBackground after the reboot, it was failing with file not found / access denied error, as it was trying to run the command - 
D:\windows\temp\TSBackground\TSBackground.exe UNATTEND

At the time that TSBackground is copied to local drive, %OSDTargetSystemDrive% is indeed the D: drive (C: is BDEDrive and X: is Boot, and D: is the drive that Windows image is copied to). However, when the machine reboots, D: drive changes to C: (as it should), but when unattend.xml is parsed, it still resolves "%OSDTargetSystemDrive%\windows\temp\TSBackground\TSBackground.exe UNATTEND" to "D:\windows\temp\TSBackground\TSBackground.exe UNATTEND"

The only way I can get around this is to set the command in unattend.xlm to -
"C:\windows\temp\TSBackground\TSBackground.exe UNATTEND"

Doing this and redistributing my OS Settings Package does the trick and the build works.

Have I done something wrong elsewhere in my Task Sequence to cause %OSDTargetSystemDrive% to not update to point to C: after the reboot ?

Nice find; I will put this in the Issues section of the manual at next revision. Your %OSDTargetSystemDrive% is probably updated once the tsmanager (re)starts? Problem is, its being resolved while still in PE. If the behavior is consistent you should be fine.

Hi Johan,

Just starting out the implementation of this tool, thanks up front for your hard work in this product!

So far I am having no issues with the implementation and steps, however there seems to be a very long delay when the TSBackground.exe starts. Most of the time, around 1 and half minutes?

Currently I am using the RunSilent.exe as the boot images prestart command, I can see that .exe running as a process for a short time, as well as the TSBackground.exe it spawns. But once the RunSilent process finishes, the TS continues along and the TSBackground just sits in processes, until it hits around that 1 and half - 2 minute length.

Also once the device restarts, my 'Run command line' step fires the .exe and moves on, yet it takes same amount of time to show up and in the meantime the TS has moved on.

I can also replicate the length of time it takes by manually initiating the .exe from an open F8 window for testing. Any insight would be appreciated :)

Mitch

Every restart to PE is like booting to a new operating system, .Net will have to initialize etc.... Use the recommended method; winpeshl.ini, and you will get a much better experience. It will add a little time to you deployment but since TSBackground is launched earlier and at the time the only running application it will load much faster.

Thanks for the reply. We might look at going down the path of the winpeshl.ini at some stage, just want to avoid having to update the boot image for any changes to the TS background package.

Also I have just noticed, when using the F8 support, the list of TS variables that is displayed, it shows variables in plain text that are supposed to be masked (hidden). I would suggest you not do this? It is a potential security risk for those of us using that field to mask service account passwords.

Thanks for pointing it out - hidden values are now hidden in the debug grid, just switch to the latest version and you should be "safe" :)

When TS failed, TSProgressUI (spinner animation in the middle of the screen) is not hide. Is ti normal ? I just set TSBStatus to Error.
Thank you

Hi Johan,
We've started to implement the new TSBackground app into our task sequence which, by the way, is absolutely fantastic!  We've noticed that since we've implemented it, we're experiencing random reboots, within Windows PE, where the TS doesn't seem to recover.

CM 2012 R2 1902 - 5.00.8790.1025
Boot media: 10.0.18362.1
MDT: 8456
WinpeShl.ini contains just the TSBackground/TSBackground.exe call
Prestart media points to a fileshare location where the extra files exist
Prestart command is Wscript.Quit(0)
Added a task sequence step at the very beginning of the task sequence to copy some of our other needed prestart commands:  Powershell script -  Copy-Item -Path (Get-ChildItem -Path 'x:\sms\pkg\sms10000\amd64' -Directory -Exclude ('TSBackground')).FullName -Destination 'x:\' -Recurse -Force

Prestart  Media:
Root -
  Program Files
  Scripts
  sms
  Windows
  runsilent.exe (is this needed if we don't use it?)
  runsilent.ini

We're currently removing TSBackground to verify it's really the culprit and not the 1903 boot media.  Just figured I'd see if anyone else has experienced this issue as well.

Thanks for all that you do.  Was great meeting you at MMS!

Best Regards,
Jeremy Sichak

Sorry, folder structure was missing TSBackground in my question.  Missed transposing it to the question.

TSBackground folder:
  Backgrounds
  Layout
  x64
  TSBackground.exe
  TSBackground.exe.config
  TSBClasses.dll

Thanks :) 

It appears that you already had some working prestart commands; if so, just revert to you previous working configuration. When that's done; copy the TSBackground folder (the one with TSBackgound.exe in it) to you network share, include the winpeshl.ini file and rebuild the image.

Wscript.Quit(0) is a dummy command that should only be used if you don't use any commands at all; the wizard does not allow to include extra files without a command.

In other words; the ini file will take care of launching TSBackground, all other prestart commands works just as before, don't change it if has proven to work.

Hi Johan,

Thanks for the response.

It looks like, at least in our situation, the tsbackground executable is crashing, and taking down the TS, in Windows PE.  Not sure if it's something that we're doing in our environment, or how we're building the boot media.

We removed the winpeshl.ini file from our boot WIM's, and moved the tsbackground call in our prestart command field.  After doing this, we can see that the tsbackground executable randomly crashes.  From our understanding, if the process that is called in the winpeshl.ini file crashes, it will cause the TS to fail out and do a hard reboot.  You can test this by dropping into a command prompt and killing the tsbackground executable when you call the tsbackground from within the winpeshl.ini file.

I think our next step may be to just create a stub program that runs in the background and watches the tsbackground executable.  If it crashes, we'll just launch it again.

Thanks again!  Looking forward to promoting tsbackground to production in a few weeks.  :)

Hi there Johan (or others that might have the answer)

I have implemented TSBackground into our environment and it all seems to work just fine.
Untill after the configmgr client install + reboot..

I assume this has to do with my unattend.xml-file. (I set it up as you suggested in the documentation).
I have however only made a package with the said unattend.xml and put this into my "Install Opreatingsystem"-step where I specify which unattend.xml file to use...

Do I need to copy\move the modified unattend-file elsewhere in addition? To get it to trigger after booting into Win?

After the reboot after client install step, I can F8 and bronse to c:\windows\temp\tsbackground and run tsbackground.exe manually.
Everything will then work okay-ish.
(I have no mouse-Cursor).

So, the issue is simply that the tsbackground doesn’t trigget after the reboot. I thought that the unattend runsynchronouscommand took care of this after every reboot? But perhaps I misunderstand?

Nevermind, I was being silly here.

The manual\documentation did not specify where the <add key="CopySelfToOSDisk" value="True"/>
was supposed to go. (I assumed it was already a part of the TSBackground.exe.config-file.

Which it was not.

It all works now... And looks FANTASTIC. Also way faster than the older OSBackground. Timing works. I'm happy!

Hello Johan! 
First thanks for your work. Is it possible to integrate TSBackground inside mdt task sequence, which integrated intro sccm?

It is designed for ConfigMgr, with or without MDT integration.

Stand-alone MDT is not supported - mentioning it because the question keeps popping up.

Alright mdt integrated in sccm its my variant. May i ask you make some small guide for mdt task sequence(i mean only udi)? In standard mdt udi task a lot of steps, including init, preparation and wizard. I have a poor understanding where i can put it. Big thanks.

Hey. First of all I want to thank you for this application. I had no problems with TSBackground launched in the framework of deployments of Windows 10. I'm having trouble integrating TSBackground when deploying Windows 7. TSBackground is successfully initialized in WinPE, but after rebooting in Windows 7 in the "Setup Windows and Configuration Manager" step TSBackground does not start and Task Sequence works with the default shell. Does TSBackground support Windows 7?

Is your Windows 7 image patched => DotNet 4.6.2 or higher?

My Windows 7 image has DotNet 4.7.2.

I have (re)tested Windows 7, x86 and x64 - both works. I just uploaded a new version and as a possible help included the Unattend files I used for testing, please see if that helps?

I noticed a peculiarity. The directory "TSBackground" is successfully copied to C:\Windows\Temp on the step "Setup Windows and Configuration Manager", but after the reboot into the full operating system "TSBackground" directory is missing.

Are you sure your Unattend.xml contains the complete command? This could happen if the argument "UNATTEND" is missing.

Correct command should be:

%OSDTargetSystemDrive%\windows\temp\TSBackground\TSBackground.exe UNATTEND

Hi Johan,
I got the TSBackground with some customization, working well. 

In my boot - when I declare the PStart for RunSilent.exe, and TS step as mentioned in your PDF, it loads the TSBackground very well. Upon reboot during the TS Imaging, the TSBackground does not run again. 

Then I followed your next step in the pdf "winpeshl" as recommended, changing the Prestart to "WScript.Quit(0)", it doesn't load the TSBackground at all. 

I followed the steps in step 12 for copying the files. 

Am I missing something here?
May be this - "Next time you upgrade your boot images the files will be included"

Note - I didn't not upgraded my boot image nor I created from fresh, I had 1809 ADK and created from it prior to use the TSBackground.

Thanks in advance. BTW wonderful tool!

There was a similar question a while ago; turned out the Path to the TSBackground folder was wrong.

If the path on disk is for example: "\\server.domain.com\pkgsource$\BootExtraFiles\TSBackground" where "TSBackground" should directly contain the exe, dll, config and subfolders etc. Then the path indicated on the Customization tab of the image should be: "\\server.domain.com\pkgsource$\BootExtraFiles".

"Next time you upgrade your boot images the files will be included" - this simply means, Right click the image and choose "Update Distribution Points", this will rebuild and redistribute the modified image.

Yes I do have the correct path in the Customization tab of the image. 
I copied the winpeshl file to the correct folders as mentioned in the pdf doc. Distributed the boot image.  

After digging, somehow I am seeing a TSClient.ini file in \\sccmserver\RemoteInstall\SMSTempBootFile\TSClient.ini
in the TSClient.ini I see this:

CommandLine=WScript.Quit(0)
Source=SMS10000

But the Source package here it says "SMS10000", I am assuming this was a name chosen as a referral only, and we are supposed to give it our own package name, please correct me if I am wrong here. Whereas I had actually modified the "SMS10000" to reflect it with our system in the PS script in the TS Step. Was I not supposed to make the change of the package? I am gona revert the package names to SMS10000 and try again. 

"SMS10000" refers to "x:\sms\pkg\sms10000" on the RAM Drive; you should not modify this, it's a built-in "location" where the included extra files will reside.

If you check the content of the ini-file(s) you will see that's where we assume TSBackgound.exe to be located and launched from: "x:\sms\pkg\sms10000\TSBackground\TSBackground.exe"

I reverted back the package name. I shouldn't have changed it, forgot about it. 
It started working. But on the 2nd reboot it didn't load TSBackground, instead it loaded the built in one. I think someone did mention somewhere there's a glitch at certain step especially installing ConfigMgr client.  

Am I getting this; it now works in PE (repeated reboots) but fails to start after "Setup Windows and ConfigMgr"? If so, you must look for the problem in your Unattend.xml. And yes, it will take a while before TSBackground starts the first time in full OS, during that period you should have a black background with the standard TsProgressUI, this lasts for a minute or so before TSBackground takes over again.

I probably didn't write it properly to explain. Apologize for that.
TSBackground loads fine on the initial boot of PXE. It performs all the step. After the 2nd reboot (during TS), at the step of "Setup Windows and ConfigMgr" TSBackground doesn't load for the rest of the TS steps. 
To mention - I did copy the winpeshl to the location mentioned in the pdf, and updated the boot image. 

I see what you mean. I will check the Unattend.xml, and report back if any issues. 

Update - its working now after fixing the Unattend file.
Thank you for your great help! Much Appreciated!!
 
Just out of curiosity, does it suppose to show the last "Success Status", because I didn't see any during imaging, not that of any issue or it bothers me :)