Alternative commands for running Roboscript

[DChild]

Hi,

Because of the way our office configures our PCs, I can't run Roboscript in the normal fashion.  It returns the attached errors.

After Clicking Ok, it just exists from the Navigation dialog, and closes.


What's the exact command line, to run Roboscripter?  How many different ways are there?

[td]

The "command line" is in the error message.  The executable is WinBatch.exe and the parameter is RoboScrp.w32 or just double click Roboscrpt.w32 from an Explorer shell window.   However, you are likely to have the same issue because you installed WinBatch into an unsecured folder instead of using the default Program Files (x86)/WinBatch.

[DChild]

That's interesting.  Yes, I've always installed it in the c:\Winbatch folder.  In fact, it's what I do for almost all third party applications, at my office, because they screwed up my credentials long ago, and even the Help Desk can't figure out how to make it 'normal'.

So there's no way around this?  Ok, thanks.


Regards,

DC

The "command line" is in the error message.  The executable is WinBatch.exe and the parameter is RoboScrp.w32 or just double click Roboscrpt.w32 from an Explorer shell window.   However, you are likely to have the same issue because you installed WinBatch into an unsecured folder instead of using the default Program Files (x86)/WinBatch.

[td]

You can use one of the WinBatch executables with an 'F' in its name like WinBatch_IF.exe.  This will prevent the error but it will also limit what Roboscripter can do or may even render it inoperable.

A better alternative would be to change the permissions on your WinBatch installation folders to match the permissions on "Program Files (x86)" assuming that the "Program Files (x86)" permissions are not altered from the system defaults.

[DChild]

"A better alternative would be to change the permissions on your WinBatch installation folders to match the permissions on "Program Files (x86)" assuming that they are not altered from the system defaults."

Under normal circumstances, that would be the backup position, to simply take the defaults.  I'll certainly give it a try, after trying the WinBatch_IF.exe suggestion.

The main problem is that my office desktop configuration, is the furthest thing from normal I've ever encountered.


If none of these bear fruit, then I'll reinstall one of the older WinBatches, which worked fine the last time I tried.



Thanks and Regards,

DC

You can use one of the WinBatch executables with an 'F' in its name like WinBatch_IF.exe.  This will prevent the error but it will also limit what Roboscripter can do or may even render it inoperable.

A better alternative would be to change the permissions on your WinBatch installation folders to match the permissions on "Program Files (x86)" assuming that they are not altered from the system defaults.

[td]

If you are using a pre about 2007 version of WinBatch, you will encounter the same limitations the OS imposes on the WinBatch_if.exe version of WinBatch. 

Also, the default permissions for Program Files (x86) include that only administrators have write access to the folder and sub-folders.   This is what MSFT calls a "Protected" directory.  It is also what you would need to set on your WinBatch installation folder if what I think is going on is what is going on.

[DChild]

Tangent to your point - When I started at the agency, I had full admin access to the PC.  I don't know exactly when it changed.  We have a special login, that allows us to do things that our ordinary credentials can't do, but it's still not full admin.

Anyway, I'll try installing into the default Programs folder, and see what happens.


Another tangent - since the Winbatch setup still has an optional Other Folder option, should you let the user know that using a custom folder might cause inconveniences?  Up to you.


Thanks, I'll update the thread, after reinstalling this week.


Regards,

DC

If you are using a pre about 2007 version of WinBatch, you will encounter the same limitations the OS imposes on the WinBatch_if.exe version of WinBatch. 

Also, the default permissions for Program Files (x86) include that only administrators have write access to the folder and sub-folders.   This is what MSFT calls a "Protected" directory.  It is also what you would need to set on your WinBatch installation folder if what I think is going on is what is going on.

[td]

The vast majority (maybe 99% or more) of our users just use the default,  know how to work around it by changing folder permissions or know how to and have the ability to tweak group policy.  We know this because the issue almost never comes up anymore.  Windows has had UAC for about 12 years now so it makes sense that our users are aware of it and know how to deal with it.

I rechecked to make sure it works before I mentioned it but another workaround is to start an elevated command prompt and type WinBatch.exe  RoboScrp.w32 at the prompt.

[DChild]

"The vast majority (maybe 99% or more) of our users just use the default,  know how to work around it by changing folder permissions or know how to and have the ability to tweak policy group policy.

We know this because the issue almost never comes up anymore.  Windows has had UAC for about 12 years now so it makes sense that our users are aware of it and know how to deal with it."


Ok, let me clarify a few things.  I don't have control over group policy, at my agency.  And the people who DO have that control, can't figure out how to manage the different groups that they threw me into.  These people have been managing the credentials at our agency for years, and are experts at it ; but they can't make sense of the complex configuration of my account.


I've been a programmer for 30 years, and I know something about folder permissions.  But I am telling you, that there have been problems with lots of installations over the years.  So e.g. I have no problem installing NuSphere, but some Visual Studio plugins have been problematic.  We can't even install any newer versions of Visual Studio.  I used to be able to install Acronis Image, but they changed the way they activate their application ; however, I can install Macrium.

Several times, the software installs ok and actually works, but some of the registry items won't get written.

It depends on what the vendor uses to activate and run their applications.  It's a roll of the dice.

We're *supposed* to be given admin access to our desktops.  But local management screwed that up for my PC, a couple of years ago.  And the Help Desk hasn't been able to make sense of it. 

Because of this, I have tried to simplify things, by taking permissions out of the equation.  So whenever possible, I try to install new software in a folder that has full permissions including subfolders ; or choose tools like UltraEdit or TinyTask or Total Commander that can be run portably.


"I rechecked to make sure it works before I mentioned it but another workaround is to start an elevated command prompt and type WinBatch.exe  RoboScrp.w32 at the prompt."

Tried that, and it has the same problems.

Thanks for the tips, I'll send a final status after we have a chance to try a few things.  If need be, I'll just upgrade my personal laptop with the most recent Winbatch, and try to record any macros there.



Regards,

DC

The vast majority (maybe 99% or more) of our users just use the default,  know how to work around it by changing folder permissions or know how to and have the ability to tweak policy group policy.  We know this because the issue almost never comes up anymore.  Windows has had UAC for about 12 years now so it makes sense that our users are aware of it and know how to deal with it.

I rechecked to make sure it works before I mentioned it but another workaround is to start an elevated command prompt and type WinBatch.exe  RoboScrp.w32 at the prompt.

[td]

Tried that, and it has the same problems.

It is certainly possible to configure UAC related group policy settings to prevent the command shell solution from working.  I should have mentioned that possibility alone with the suggestion. 

It is also the case that we have encountered security "experts" in the IT departments of some entities that draw into question the appropriateness of the application of the term "expert".  But you gotta make the best of what your given...

[DChild]

I doubt very much that I could persuade them of a business reason to do so.  This is a state agency we're talking about.

Tried that, and it has the same problems.

It is certainly possible to configure UAC related group policy settings to prevent the command shell solution from working.

[td]

I wasn't suggesting that you try.  Just giving a possible reason why you got a different result. 

Should also mention that WinBatch is used by multiple state and federal agencies. 

[DChild]

I'm sure it is.  I've also used scripts developed in Winbatch for years, at different companies.

This agency is relatively independent.  It has elements of both the inflexibility & red tape we associate with state agencies ; and management refusing to wait for the appropriate tech people to set things up, and instead tweaking things their own way.

I wasn't suggesting that you try.  Just giving a possible reason why you got a different result. 

Should also mention that WinBatch is used by multiple state and federal agencies.

[DChild]

For anyone paying attention to this thread, I'm holding off for a little while on the resolution.

We're moving our Windows 7 desktops to Win 10, soon.  In a meeting today, I asked if they will be updating the group policies while they are in the process of upgrading the OS for everyone.

They said no, the policies will remain the same. 

But in the case of my particular profile, they said the upgrade might fix the issues I've been having - or it might make it worse.  We laughed, but that's the reality.



Once the issue is resolved one way or the other, I'll update this thread with the resolution.

[td]

If you install WinBatch into the "Programs Files (x86)" folder, you should be fine.  Once you get to Windows 10 take a look at the permissions on that folder.  Administrators should have "Special permissions" checked.  "Special permissions" mean that administrators can modify that folder and have "Full control" over files and sub-folders below "Programs Files (x86)".   Users should only have Read, Execute, and "List contents" permissions.  This set of permissions makes the folder what MSFT calls a protected location.  If that is not how the OS is set up, you are definitely dealing with non-experts.

[DChild]

Thanks, I know what permissions and special permissions are.


You are mistaken about their expertise.  That's not the problem.  They aren't the people who screwed up my desktop.


Anyway, we'll see what happens with Windows 10.  There's an off-chance that there's something wrong with the PC itself.  I've run tests, but I recall that one of those tests couldn't complete.


Maybe I can coax them into getting me a new PC.


We'll see what happens.



Regards,

DC

If you install WinBatch into the "Programs Files (x86)" folder, you should be fine.  Once you get to Windows 10 take a look at the permissions on that folder.  Administrators should have "Special permissions" checked.  "Special permissions" mean that administrators can modify that folder and have "Full control" over files and sub-folders below "Programs Files (x86)".   Users should only have Read, Execute, and "List contents" permissions.  This set of permissions makes the folder what MSFT calls a protected location.  If that is not how the OS is set up, you are definitely dealing with non-experts.

[td]

Thanks, I know what permissions and special permissions are.

I guess the begs the question.  If you know what the correct permissions should be then why didn't you either reinstall into the "Program Files (x86)" folder or change the permissions on your installation folder to match the permissions required by MSFT? At the very least I would have expected to hear that you didn't reinstall into "Program Files (x86)" because the permissions are such that they would not help solve the issue along with having no way of getting them changed.

You are mistaken about their expertise.  That's not the problem.  They aren't the people who screwed up my desktop.

I have no idea who you mean by "they" in this context.   The point was the whomever  would alter the default permissions on  "Program Files (x86)" without neutering UAC does not have a good understanding of how the OS works. 

[DChild]

Ok.  We're done here.  As I described throughout the thread, I always try to install programs off the root, on this particular pc, because it usually simplifies and isolates problems outside of permissions.

There is something wrong with my profile, or my pc, or the complex set of policies they initially set up for me.  Many people at the help desk have examined it, and haven't been able to figure it out.

I'm sorry that you're not grasping that some users have unique situations.  I'm not responding to this, any further.

Thanks, I know what permissions and special permissions are.

I guess the begs the question.  If you know what the correct permissions should be then why didn't you either reinstall into the "Program Files (x86)" folder or change the permissions on your installation folder to match the permissions required by MSFT? At the very least I would have expected to hear that you didn't reinstall into "Program Files (x86)" because the permissions are such that they would not help solve the issue along with having no way of getting them changed.

You are mistaken about their expertise.  That's not the problem.  They aren't the people who screwed up my desktop.

I have no idea who you mean by "they" in this context.   The point was the whomever  would alter the default permissions on  "Program Files (x86)" without neutering UAC does not have a good understanding of how the OS works.

[td]

Based on your description throughout the thread, installing off the root is the apparent cause of a permission problem.  So why bother or at least why not change the permissions on your "off the root"  folder to match the permissions MFST requires?  The only thing you are isolating now is your ability to isolate and simplify problems.   

With regard to "grasping that some users have unique situations".  Users contact us with unique situations often.  Most of the time they are not all that unique but certainly isn't all that hard to determine when they are and offer solutions.   While hardware issues can be a source of all manner of problem, your situation doesn't appear all the unique.  It is more likely an issue of identifying and conforming to the requires imposed by the OS.

[DChild]

Resolved.  If anyone is having similar problems to mine with Roboscripter, and they don't want to waste time troubleshooting whether it's a folder permissions issue or some other problem with your desktop, this works perfectly:

https://techsupt.winbatch.com/webcgi/webbatch.exe?techsupt/nftechsupt.web+WIL~Extenders/Control~Manager/Roboscripter+Create~portable~RoboScripter.txt

Just compile it into a portable version.  I've confirmed that the resultant executable runs in various folders without a popup error.

Obviously, there might be Copyright issues.  So before you share it with anyone, check with the Winbatch staff.

Hi,

Because of the way our office configures our PCs, I can't run Roboscript in the normal fashion.  It returns the attached errors.

After Clicking Ok, it just exists from the Navigation dialog, and closes.


What's the exact command line, to run Roboscripter?  How many different ways are there?

[td]

A caution with regard to this approach, depending on how your compiled exe version of Roboscripter is manifested, codesigned, the UAC settings of the system, and the type of windows in targeted applications, you may encounter cases where either Roboscripter or its generated script will fail because of cross-process UI access issues.