strange behavior with #requireadmin

[gcue]

hello world.

 

i have a large script which declares #requireadmin up at the top first few lines. There is an option within the script to run the following but it doesn't seem to run with administrative privelages as some of the functionalities are missing..

ShellExecute(@SystemDir & "\dsa.msc")

 

yet, if i create a blank new script with only #requireadmin at the top and the same line above - it works - all functionalities are available.

i have no idea what might be conflicting with #requireadmin which would impact privelages when running dsa.msc.

thanks in advance.

[nitekram]

You could post your code to get help, or just starting turning off functions, statements until you find the issue.

[JLogan3o13]

Can you please qualify "doesn't seem to run"? Are you getting an error, or is it simply that ADUC isn't opening?

[jdelaney]

How are you initiating the script when you are unable to get the full tool rights vs when you are able to run it.  Possibly user rights/groups issue.

Edited May 21, 2013 by jdelaney

[gcue]

Can you please qualify "doesn't seem to run"? Are you getting an error, or is it simply that ADUC isn't opening?

 

it runs but when i go into an object's membership, not all the tabs are there

[gcue]

You could post your code to get help, or just starting turning off functions, statements until you find the issue.

can't file size exceeds attachment limit - even after zipping.

[JLogan3o13]

But if you just call dsa, using #RequireAdmin, in a reproducer, you do see all tabs?

[gcue]

How are you initiating the script when you are unable to get the full tool rights vs when you are able to run it.  Possibly user rights/groups issue.

same way.  double clicking a compiled script.  not sure what you are referring to.

[jdelaney]

Never know, you could start from

1) a scheduled task, which may run as the logged in user, or a fixed user, or

2) through winrm or

3) psexec

all will run as diff users depending how you initiate them (which may or may not have been diff from when you double click the exe locally)...obviously, that's not the case

Edited May 21, 2013 by jdelaney

[gcue]

But if you just call dsa, using #RequireAdmin, in a reproducer, you do see all tabs?

i do

[JLogan3o13]

There is an option within the script to run the following but it doesn't seem to run with administrative privelages as some of the functionalities are missing..

 

   I know you stated you cannot upload the whole script, but can you post the relevant portion that shows what this "option" is? Logic dictates that if it is working with a simple reproducer, the issue is somehow contained in this branch of your script.

[gcue]

looks like it was due to compiling as 32 bit vs 64 bit

sigh

i have some users using 32 bit os and some using 64 bit

anyone come up with a way to auto swtich versions of the exe or make something that was compatible for both?

thanks =)

[AdamUL]

You could compile the script for both 32 and 64 bit. Then create a smaller 32 bit wrapper script, that extracts the 32 or 64 bit EXE and runs it based on the OS.

You can use these AutoIt3Wrapper directives in your main script to compile both at the same time.

 

#AutoIt3Wrapper_Compile_Both=y
#AutoIt3Wrapper_UseX64=y 

[JohnOne]

As far as I'm aware, if you compile for 32 bit, it should be fine on both 32 and 64

#AutoIt3Wrapper_UseX64=n

[AdamUL]

Now I think about it. It looks like it is due to 64-bit Windows returning the "SysWOW64" directory for @SystemDir macro for a 32 bit application. You could use the following.

Global Const $sSystemDir = @WindowsDir & "\System32"
ShellExecute($sSystemDir & "\dsa.msc")

Edited May 31, 2013 by AdamUL

[gcue]

Now I think about it. It looks like it is due to 64-bit Windows returning the "SysWOW64" directory for @SystemDir macro for a 32 bit application. You could use the following.

 

Global Const $sSystemDir = @WindowsDir & "\System32"
ShellExecute($sSystemDir & "\dsa.msc")

nice work around adamUL - that worked!

[AdamUL]

Glad I could help.

[gcue]

i tried that with regedit not the same results though - seem to be missing some entries.

regread also seems to be missing some stuff

[AdamUL]

This has to do with 64 bit redirection as well. This is a good read. Registry Keys Affected by WOW64

http://www.autoitscript.com/autoit3/docs/intro/64-bit_support.htm

Put "64" in your registry key paths, e.g. HKEY_LOCAL_MACHINE64 or HKLM64. See the notes in the Reg* function docs. This path will work on 32 bit as well, and go to the correct place unless you are trying to access the "Wow6432Node" node on a 32 bit system.

[gcue]

great links - thanks again for your help!