Page 1 of 1


PostPosted: Tue Mar 03, 2015 5:58 am
by nikolaosp
Hey guys,

I 've been trying to add more stuff to my templates and decided that JRT would be a nice addition for my dSS subscribers in order to remove toolbars from my clients' PCs. Before I add it to the template I checked the d7II configuration of JRT and basically decided that since it works fine under Nick's configuration, I should just use it in dSS like in d7II. So, I used the JRT_Auto.cmd file as pre-execution config (like in d7II) and also used the "-y -om1 -nr" command line parameters (like in d7II). Saved it, uploaded it on a user ID and manually run the maintenance using the maintenance button.

It all went smooth as expected but when JRT run, windows switched to the SYSTEM user. Even after it finished the maintenance and emailed me etc, windows was still in SYSTEM user and if I would try to switch to my user, it would not let me, it would return to the SYSTEM user desktop. On top of that, I had a word document open at the time I started the maintenance, and even though after JRT run, windows was on the SYSTEM user, my word document was open and even task manager showed my user as active.

So the question is, WHY? Why would it switch from my user to the SYSTEM user? I have read the JRT_Auto.cmd file and I can't find anything that would direct it to do something like that. Is it one of the -y -om1 -nr parameters? If so, why doesn't it do the same in d7II? BTW, I have noticed that in d7II's app configuration there is an option to "Run as SYSTEM", in dSS there is no option like that so I don't think I have done something by mistake.

And another thing, I have noticed that if I add a custom app in a template and upload it to a clientID, the client doesn't get the new app. Is this the same for everyone or just me? I want to continue enhancing my templates but I don't want to reinstall dSS every time I want to make a change or addition.

Hope you're all good,


PostPosted: Tue Mar 03, 2015 10:54 am
by Nick
dSupportSuite runs maintenance mode under the local system user account so it can bypass file system permissions as necessary, which is a frequent thing with my apps.

For example, in order to perform the temp file cleanup on all user accounts, running under the system account means it doesn't have to add permissions for itself to other user profile folders in order to access them and delete the temp files. This is just one example but usually involving manipulating other user accounts simultaneously instead of operating under just *one* account.

While d7II has the capability of running either itself and apps, or just the apps, under the local system account, dSupportSuite isn't designed to work in that way - at least for the maintenance routine where the executable performing the maintenance (and subsequently launching 3rd party apps like JRT) is already running under local system to begin with. Any process being spawned will be under the same user account as the parent process, so the 3rd party apps (e.g. JRT) are forced to run as the system user.

What is probably happening is that JRT is killing the explorer.exe process (providing the desktop environment) to aid in removal of items that, depending on how they are loaded, may have open handles to them from explorer.exe, preventing their deletion. After the JRT removal it restarts explorer.exe, but it starts under the user account (system) that the 'parent' process that started it is running under (JRT) which does the same thing as it is started by the dSupportSuite maintenance routine which runs under local system. (as a side note, loading the first instance of explorer.exe as system ends up creating user profile directories in %systemroot%\system32\config\system\..)

There isn't an easy way to de-elevate from system either, a simple reboot is the best way. I think if you are going to use JRT, as it is restarting explorer.exe, then you may need to consider the reboot options in the maintenance config after the routine. I don't see why not -- because you MUST be scheduling maintenance at a time when it won't just restart explorer and run toolbar removal tools while the user is actually trying to use the PC, so a reboot should be fine there as well.


PostPosted: Tue Mar 03, 2015 2:32 pm
by nikolaosp
Hey Nick,

thanks for your reply and for clearing this issue to my mind. I have set up dSS to reboot (after 60 seconds) the PC but I just wanted to make sure that the customers who do not understand what is going on would not start browsing the internet, or executing programs under the SYSTEM account or even cancelling the reboot because they thought that "replying on a facebook post is more important".

So, that is a feature request for the next version... Instead of having a reboot countdown, how about having a prompt (Yes or No) with some space to explain why the user should reboot. And even an always visible window while maintenance is running that would allow us to explain the user what should be expected, since if the user minimizes the "running xxxxxxx" window, he is left in the cold without knowing whether it is running or hung or whatever...

Anyway, to stay on topic, after Nick's explanation if any of you guys have a way to run the explorer.exe as the user of the machine (tried runas command-no good) under the SYSTEM account without rebooting I would appreciate your input.



PostPosted: Tue Mar 03, 2015 4:54 pm
by Nick
I honestly don't even remember if I discovered a method -- I was taking an approach previously (in code, with access tokens and stuff) but I know I ended up looking for ANY way to do it. Whatever I figured out, I gave up and went the reboot method, which d7II does for certain things. If you do figure it out don't be shy with the info. ;)

I have this kind of thing worked out in my head for future d7II custom apps updates, which will also become dSS custom apps updates, but that won't be for a bit... a new system allows to bypass the entire issue with a "controller" process running as an admin user that does the re-launch.


PostPosted: Tue Mar 03, 2015 6:27 pm
by nikolaosp
Yeah, after spending must if my afternoon trying to figure out a way, I am certain we are in a vicious circle with this....
I've read your post on the vipre topic and was happy to see you actively trying to improve both d7ii and dSS. I understand how important is to unify the custom apps module for both of these products and I believe you're thinking it right. I also believe that the management console and the client configuration is more important and also feasible to be improved sooner than the redesign of the custom apps system, that would serve both programs. There are some more issues ( portability-decentralization, subscription management etc) that will probably come up with the management console redesign, but you know best what you want to do with your babies.

Keep up the good work mate!