Using Script/Global Script to ensure Project Settings on startup.

[mikejbonner]

Hello All,

Does anyone know a way to script "project settings" when autoplay is started?
Specifically, I need the Project Setting for the Advanced User Privilage to ensure it is set to the default "As Invoker" option. I know I can do this from the menu manually but I am invoking the Autoplay Project from another application and want to present a seamless process to the user. This option needs to be set before the project starts to be built to enable the user to open the CD file without restriction.

Thanks for any advice or pointers.....Mike

[Ulrich]

The Project Settings are defined in the template used when the project was created. The setting cannot be changed via a command line parameter... I am not sure that I understand what you are asking - AutoPlay Media Studio does not modify the project settings by itself.

Ulrich

[Ulrich]

Autoplay...anyway, after months of IT involvement, testing etc....it seems the As INvoker setting is being changed somehow. We don't know how or why as no one does this that we know of. However, if we create a disk each time with this setting being made explictly then all appears to be well!?!?

I doubt it that this is indeed what is happening.

When you posted about this problem the first time, gave you a few pointers about group/user policies, code signing, etc. A few questions:

1. Are you signing the code now, and the problem remains?
2. What happens if the content of the removable media is copied to the hard drive, and the application is started from the hard drive?
3. What happens if you publish the project with a name for the executable that was never used before, for example "demo20150320.exe"?

If you see a change after investigating question 2, and the program runs from the hard drive, then you can be sure that there is a block or policy in place, which prevents the execution of software on removable media.

If you see a change when you check question 3, then there appears to be some kind of compatibility setting in place for the former program name, normally used for applications which were coded many years ago and don't obey current deployment rules. Even when a program was not manifested to be run with administrative rights, it still can request elevation if the "run as admin" compatibility option was set. Checking the executables Properties dialog might show something in this case.

Ulrich

[mikejbonner]

Hi Ulrike,
I just read your reply above and can confirm that:

1. We have not tried to sign the code, mainly because we are not sure what this means or how we sign it - needs some research.
2. I will try running from hard drive as suggested and investigate effect.
3. Our current program (using a text file and AutoIt) automatically generates a new name for every CD created. We actually use a code to determine the name based on the model type and the serial number of the machine to which the drawings on the CD relate. This uses all 16 digits of the filename.

We have also observed a peculiar behaviour that may or may not be relevant. After we produce the CD and we ensure the User Privilage is set to "As Invoker" - we then generate an apz file as a backup. When we reload the apz file back into autoplay, the User privilage has been changed to "Run as Administartor". (????). Could this be to do with your point 3 above - could it be that our file naming convention, that uses all 16 digits to make the CDs both traceable and be subject to be audits, is causing an issue?

It would be great if you could confirm this as I can then commit resource to perform some testing to see what happens and not waste on it if we are barking up the wrong tree).

Many thanks for your prompt responses and support. Mike