Sign in to follow this  
Followers 0
gcue

strange behavior with #requireadmin

20 posts in this topic

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.

Share this post


Link to post
Share on other sites



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


All by me:

"Sometimes you have to go back to where you started, to get to where you want to go." 

"Everybody catches up with everyone, eventually" 

"As you teach others, you are really teaching yourself."

From my dad

"Do not worry about yesterday, as the only thing that you can control is tomorrow."

 

WindowsError.gif

WIKI | Tabs; | Arrays; | Strings | Wiki Arrays | How to ask a Question | Forum Search | FAQ | Tutorials | Original FAQ | ONLINE HELP | UDF's Wiki | AutoIt PDF

AutoIt Snippets | Multple Guis | Interrupting a running function | Another Send

StringRegExp | StringRegExp Help | RegEXTester | REG TUTOR | Reg TUTOT 2

AutoItSetOption | Macros | AutoIt Snippets | Wrapper | Autoit  Docs

SCITE | SciteJump | BB | MyTopics | Programming | UDFs | AutoIt 123 | UDFs Form | UDF

Learning to script | Tutorials | Documentation | IE.AU3 | Games? | FreeSoftware | Path_Online | Core Language

Programming Tips

Excel Changes

ControlHover.UDF

GDI_Plus

Draw_On_Screen

GDI Basics

GDI_More_Basics

GDI Rotate

GDI Graph

GDI  CheckExistingItems

GDI Trajectory

Replace $ghGDIPDll with $__g_hGDIPDll

DLL 101?

Array via Object

GDI Swimlane

GDI Plus French 101 Site

GDI Examples UEZ

GDI Basic Clock

GDI Detection

Ternary operator

Share this post


Link to post
Share on other sites

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


√-1 2^3 ∑ π, and it was delicious!

Share this post


Link to post
Share on other sites

#4 ·  Posted (edited)

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 by jdelaney

IEbyXPATH-Grab IE DOM objects by XPATH IEscriptRecord-Makings of an IE script recorder ExcelFromXML-Create Excel docs without excel installed GetAllWindowControls-Output all control data on a given window.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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


√-1 2^3 ∑ π, and it was delicious!

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

#9 ·  Posted (edited)

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 by jdelaney

IEbyXPATH-Grab IE DOM objects by XPATH IEscriptRecord-Makings of an IE script recorder ExcelFromXML-Create Excel docs without excel installed GetAllWindowControls-Output all control data on a given window.

Share this post


Link to post
Share on other sites

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

i do

Share this post


Link to post
Share on other sites

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.


√-1 2^3 ∑ π, and it was delicious!

Share this post


Link to post
Share on other sites

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 =)

Share this post


Link to post
Share on other sites

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 

Share this post


Link to post
Share on other sites

#15 ·  Posted (edited)

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 by AdamUL

Share this post


Link to post
Share on other sites

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!

Share this post


Link to post
Share on other sites

Glad I could help.

Share this post


Link to post
Share on other sites

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

regread also seems to be missing some stuff

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

great links - thanks again for your help!

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0