The cleanupOS cmd is created within MRPFirstboot.cmd, it saves the created cmd file to Windows folder out the way and then reg adds the runonce entry. The cleanupos file will remove the scripts folder and anything within it on the cycle. It maybe the RMDIR line in your setupcomplete.cmd confuses MRP, i don't think it should. Unless setupcomplete is called BEFORE the project has fully completed. I know OOBE stage has a set way of running, OOBE.cmd first then either FirstLogin.cmd (W8.x/10), then finally setupcomplete.cmd so technically MRP should of completed in time.
@apologized - OK, yes it may be non standard characters of the Arabic language lost in convertion, Russian and Chinese may also have ????. Will remove the query and line on next beta it's not important the other lines should be ok.
Now i've removed the "rmdir" line from my setupcomplete.cmd and the "invisible.vbs" file is gone, but my setupcomplete.cmd is still inside the remaining scripts folder. I'll see if my very limited coding skills can modify your "if exist" line (to put in my setupcomplete.cmd) to delete the setupcomplete.cmd.
@Enth, A slight edit to your setupcomplete.cmd... Code: IF NOT EXIST "%Windir%\MRPCleanUpOS.cmd" (RMDIR /S /Q "%systemroot%\Setup\Scripts") SHUTDOWN /R T/ 10 DEL /F /Q %0% >nul That hopefully will make your script work for MRP as if it detects the cmd, then ignore the delete folder command, (as MRP will do it), plus if no MRP used it will cleanup the folder as it used to. Shutdown maybe increase to 15 or 20 will allow the project to complete before the reboot, it may be ok, just a suggestion. Have added the DEL... last line - this self deletes the script file. Anything after that line is ignored as the script will be auto deleted. I'm sure SetupComplete.cmd should be auto-deleted by windows, but i always add that del line to make sure.
I was already running a test install with this modified setupcomplete.cmd Spoiler Code: @echo off echo Set ServiceManager = CreateObject^("Microsoft.Update.ServiceManager"^)>%TEMP%\MSU.vbs echo ServiceManager.ClientApplicationID = "My App">>%TEMP%\MSU.vbs echo Set NewUpdateService = ServiceManager.AddService2^("7971f918-a847-4430-9279-4a52d1efe18d",7,""^)>>%TEMP%\MSU.vbs %windir%\system32\wscript.exe %TEMP%\MSU.vbs del %TEMP%\MSU.vbs IF EXIST "%WinDir%\Setup\Scripts\setupcomplete.cmd" DEL /F /Q "%WinDir%\Setup\Scripts\setupcomplete.cmd" >NUL Exit Now the invisible.vbs file is gone, and the scripts folder is empty Next test is with your suggested modification
The shutdown.exe time is started the instant the command is called, if the PC it is running on is not a fast one then the time may be a bit short, so i always try to give a shutdown.exe i am using a value of about 30 (seconds) sometimes a bit longer, just to give whatever called it enough time to complete its tasks. In your case the MSU.vbs may still of been run time the shutdown timer reached zero and reboot. It's a fine line to guess the amount of time to use on Shutdown.exe within Windows setup. One reason MRP no longer does the reboot after its completed and you need to do that manually for Win10 as i cant guess what PC MRP is run on and if it a slow pc the reboot can cause the side effect of not allowing time for the user pic etc to become finalized. Your edit would work, although the DEL /F /Q %0% >nul is less typing. Try to avoid using EXIT as the last line of a script.
My tests are in vmware on a very fast system and on an old intel e6420 system (sata2) from 2008, but from the many people who download my projects, i never got a complaint about the reboot timing creating problems I can live with a 30sec setting, though
30 Seconds is a 'happy medium' plus once the pop up appears the user can reboot manually as whatever script was running prior to the Shutdown.exe timer should of had enough time to complete by then. I remember playing about with a large number as thinking it was same as the vbs's sleep command. I was like OMG when it said your computer will shutdown in 2 days LOL.
The test install, with your suggested modification, finished and i am sad to report the invisible.vbs file is there again but the scripts folder is gone ps, i've never seen a popup appear during my tests.
As the invisible.vbs is an inert file it can be removed manually, if you tried to run it by double clicking no harm would be done, just an error message. I will see if i can adjust the Add-On's that use the invisible.vbs to use the scripts folder instead of Setup one. I only used the Setup folder incase something caused an error in MRP that it would attempt to carry on its other tasks and tidy up after itself. As it still beta i can play about and see what i can do. The shutdown popup may not get displayed as SetupComplete is run as SYSTEM not a normal admin/user. Text Output is turned off.
Please don't modify it more for my sake, i can live with the simple modification i made and have an empty scripts folder leftover And please go to bed, don't become, like me, an insomniast
As it late here almost 2am, i will have a go tomorrow and do new a beta which hopefully will fix the stubborn file.
Even if i go bed early i'm always awake at silly o' clock. As Mr.X will testify I don't give up easy, OCD gets the better of me and I usually find a way around an obstacle.
Same here with the never giving up part I sleep my 8-14 hours, but only when a problem is solved ps, it's 3 am on the other side of the canal
Why didn't you do it correct from the start? It worked with my original setupcomplete.cmd, the "scripts" folder is deleted and no invisible.vbs left over
Let's just say i had a idea that worked in theory but in practice it went a bit off the rails. In reality one of the Add-On's was originally called on the reboot cycle (a Server one to enable Theme service), hence why the .vbs was in Setup so that it wasn't deleted before it had chance to run the task. As the module is called earlier on now if Server is detected, i forgot to remove the copy command to place the vbs in Setup folder. At least it sorted. Thanks for bringing it to my attention, took a while to find the command as it was buried in the 600+ code lines of MRP!
Have done a silent update of the Query Tool (v15 Build 1), have removed the Country Name line to prevent odd conversion errors. As mentioned in a previous post sometimes the BIOS string is either incorrect or shown as [ , ], as it not an important item for the QT or MRP i have not altered the code. It is a WMIC call and it maybe on certain BIOS's the string has either non printable characters or is located in another area. Lenovo is one such brand that can have this weird phenomena.