ssTek

I could use some help from one of my favorite software mentors. The below is a mess, so forgive my rambling. Some of my issues might also be due to trying to use a batch command I've never used before, "SCHTASKS", which I'll get to later. I'm trying to learn how to automatically deal, via batch, with the problems of needing to have Admin permissions to do certain tasks while keeping in mind:

* UAC is enabled or disabled
* Dealing with 32-bit and 64-bit
* Dealing with XP requirements vs Vista and onward, ie NT5 vs NT6, Handle at least XP, 2003, Vista, Win7, 2008, Win8, 2012 All versions Home to Ultimate to Server
* The possibility of dealing with batch parameters
* Handling file systems in different languages, ie dealing with special characters
* Ideally, code should work both during OS install and on a running system
* Depend on as few external files or programs as possible
* Be location independent and preferably be able to run correctly from CD/DVD, ie non-writeable source
* Be as small, fast, and unobtrusive as possible

Individually, most of the requirements are easy to deal with, but I've not seen anything that deals with them all at once. I personally have no immediate real need for such code, it started out just trying to help someone out improving a batch they already found. But you know me. If I'm going to write code, I will try to make it flexible, bulletproof, and all powerful! MWUAHAHAH! :cough:, :cough: Excuse me, I digress. Sorry. LOL It began with this post http://www.wincert.net/forum/topic/10458-everything-search-engine-v130632b/?p=90706.

[If there are better alternatives to doing this via batch I would like to know about them, but I would like to understand how to do this via batch if at all possible. I think I can understand the underlying issues better that way.]

I found many references to the Admin Access Prompt for Batch files issue. It seems the accepted process is to test to see if you already have Admin access, and if you don't, to relaunch the batch requesting Admin access and requiring the user to approve this. ( I would think it would be great if Admin rights could be obtained without requiring the user's approval, but I guess that would be a security issue. I also seem to never run into the need for this since I operate as an Admin with UAC disabled, but if I'm going to try and improve this batch, it would be best if it can operate correctly with UAC enabled. ) I'm also not totally sure how best to fit XP into this. Do you ignore all this if the OS is XP or does XP have to deal with the issue as well? It's been too long since I used XP and A just don't remember. I'll assume XP has to deal with it as well in this discussion.

So, to begin, assuming you have a batch that does a task, but it requires Admin access and you want to adapt it to work correctly with UAC enabled, what then? I found many examples of code that you can insert at the beginning of your batch code that is supposed to do the test and relaunch as described above.

https://sites.google.com/site/eneerge/scripts/batchgotadmin - BatchGotAdmin International-Fix Code:


NOTES:

* This is supposed to deal with the special character issue:

in the line
echo UAC.ShellExecute %0, "", "", "runas", 1 >> "%temp%\getadmin.vbs"
replace %0 with %~s0 because with a special character in the path (German Umlaut "ü"), the VBS interpreter didn't see it anymore. I guess that's a bug on M$'s part, so this is a workaround. (Info on that syntax: http://www.computerhope.com/forhlp.htm#03 %~sI expanded path contains short names only)

* It also does not depend on trying to write a dummy file to a restricted area as a test, nor does it use the old trick "AT > NUL" since AT depends on a service that is often disabled.
* But this method does not forward arguments


This is essentially what Rob van der Woude also lists [url]http://www.robvanderwoude.com/clevertricks.php[/url:




I was having problems testing my code, because I couldn't reliably keep the relaunched cmd window open during code execution so I could use 'echo-pause' statements to see what was going on in the relaunched batch. Though similar to the above code, I didn't care for the exact method shown here http://jagaroth.livejournal.com/63875.html:



but it did give me the idea of spawning my relaunched batch in a specified "cmd.exe". This did wonders in stabilizing my test environment such that my relaunched code was always visible.


This next link - http://stackoverflow.com/questions/1894967/how-to-request-administrator-access-inside-a-batch-file:



gave me an idea how to pass the batch parameters to the relaunched program, but again it just wasn't reliable for me. After playing around for a while, I came up with this:



which was reliable. My very simplified testing on Win7 x64 with UAC disabled indicates that this reliably handles relaunching a batch program with or without parameters even if some or all of those parameters are enclosed in quotes. It even properly handles extra or empty quotes, such as Param-6 or Param-2 below:



Improper parameters such as ""Param x"" will be handled the same way that they are usually handled, which is not the way you probably want them to be handled. The embedded space will break the single parameter into two parameters as far as the batch processor is concerned. I have code available that I could use to "correct" such a problem, but did not include it since I considered it beyond the scope of this exercise.

Note that I also picked up a tip along the way to specify cspript to launch the VBScript in case the user did not have .vbs files associated with a proper script engine.


An even better test might be "CALL NET SESSION >nul 2>&1" as shown here: http://stackoverflow.com/questions/4051883/batch-script-how-to-check-for-admin-rights/4054937#4054937 (NOTE: Even though "NET SESSION" is proven to be a valid test for Admin rights on XP, both of the next two coding examples skip the relaunch if XP is the detected OS. Why??):



along with experimental proof by Ben Hooper that this test for admin rights works on XP - Win8:





Then there was a discussion that began here - http://ss64.org/viewtopic.php?id=1491 suggesting that the batch command "OPENFILES" is the best test for admin rights and is the least likely to get changed by MS as the OS evolves (It wasn't "proven", but I assume that "OPENFILES" is just as valid a test as "CALL NET SESSION >nul 2>&1" was proven above.):



and that cumulated with the example given here http://ss64.com/vb/syntax-elevate.html:



NOTE: They brought up the point that when a script is run with elevated permissions, several aspects of the user environment may change: The current directory, the current TEMP folder and any mapped drives will be disconnected. So the script saves the current drive mappings and re-maps them once the session has been elevated.


I then also considered the possibility of the original batch being called by something that did not expect to have control returned until the batch was finished. Even launching the elevated batch via -- START "Relaunch" /WAIT cscript "%_tempvbs%" //nologo -- doesn't really do any good since the VBScript launches the elevated batch and then closes, releasing the calling batch from the "/WAIT" condition before the elevated batch is finished. So since I had to create the temporary batch file anyway, I figured I would use that as my flag file and not delete that via the elevated batch until it was done and I added a wait loop in the calling batch to wait for it. That also means that if the elevated batch hangs or does not complete normally, that the file will not be deleted and the calling batch will wait forever until canceled by the user. I wish I had a better idea, but that was the best I could come up with.

So taking all I learned above, I combined all of that into the following:




This code seems to work fine on my Win7 x64 Ultimate with UAC disabled, but then in that situation not much is being done, is it? So I forced it to go though the relaunch by REM'ing out the line -- (OPENFILES >NUL 2>&1) & IF '0'=='!ERRORLEVEL!' (GOTO:gotAdmin) -- and the batch relaunched with all parameters being passed along appropriately. I then tried it on my wife's laptop which has Win7 x64 Home Premium with UAC enabled. With an "ECHO--PAUSE" statement in the "Your Batch HERE" section it tested fine. The batch was relaunched, the UAC prompt was displayed and once approved the "echo" statement displayed. Once I then pressed "Any Key" the window closed and everything closed and cleaned up correctly. So far so good.

But I need to know if it's appropriate to treat XP and 2003, ie NT5, the same way or should I test for NT5 at the beginning and skip straight to :gotAdmin if NT5 is detected? I guess I should skip the relaunch if trying to relaunch to get admin access will either not work or won't do any good. If that is what I need to do, I would think I can just add one line at the beginning like this and all would be good?:



Once I'm completely satisfied with this I thought I'd change the relaunch code from [ "runas", 1 ] to ["runas", 0 ] so the relaunched window will be hidden except for a brief flash. What do you think? Any other ways you can think of that this code could be strengthened, or made more flexible, quicker, useful, etc?


Even though I'm fairly confident in what I came up with, except not being sure about the handling for XP, I still had problems when I tried to use it to help in the original thread referenced at the very beginning of this post. Here is the code I came up with , setting up a scheduled task. (This is the first time I've ever tried to use the SCHTASKS command, or Powershell, or work with UAC, so I'm sure this is a major part of my problem. LOL) In this case setting it up to run "Everything.exe" ONLOGON and Start in system notification area only. (It of course assumes that Everything was installed to its "normal" location) (And I really need your help to verify correct behavior in XP.):



This code works for me when inserted in the "Your Batch HERE" section above in Win7 x64 Ultimate with UAC disabled, both in Win7 mode and if I force it to use the :treatAsXP section. But I could not get it to work on the Win7 x64 Home Premium with UAC enabled. I'd just get an access denied type of error. I also have no way to test if it would work correctly in XP.

I tried modifying the code like this using part of the latest suggestion from myselfidem:



It only sort of worked even on my Win7 x64 with UAC disabled. Note that I had to lose the "-startup" Everything option because I couldn't figure out the right way to escape the necessary double quotes. No matter what I tried, either it thought that '-startup' was being specified as an "Invalid argumentg/option" for SCHTASKS, or '(86)' was being specified as an invalid "cmdlet, function, script file, or operable program" for Powershell. On my wife's laptop I still got the access denied type error. When I tried to force the use of the :treatAsXP code on either machine, I got a prompt to "Please enter the run as password for _________:". No matter what I tried I got "ERROR: User credentials are not allowed on the local machine." This was true on my Win7 x64 Ultimate that does not have a password for my administrator level account and UAC is disabled, and on my wife's Win7 x64 Home Premium and her administrator level account and UAC is enabled.

Then I adapted some of the very original code from http://myunster.com/blog/server-administration/30.html that started this whole mess like this:



I have no idea what this did, if anything, in the Win7 code on my machine since I saw no results, errors, popups, messages, or feedback of any kind whatsoever, so I didn't even try it on my wife's machine. The XP code is the same as my original try so I know what it will do on both machines.

Just for reference, here is a copy of the code from http://myunster.com/blog/server-administration/30.html:

In my current job we needed to automatize some processes by using Windows Task Scheduler; I wrote a batch file, which you may find useful,
especially when you don't have direct/remote access to user's desktop.

The main problem of implementation this task was Windows Vista/7 with its UAC, I had to use powershell to get Admin privileges by popping a window prompt to user directly to accept rather than have the user type the password manually upon the request.

Obviously I'm doing something wrong, though I have no idea what else to try. Looking at the differences between this original code and what I have tried, part of the problem might be the '-startup' Everything argument. Also, he was scheduling things as system level tasks and I understood from the original Wincert thread that Everything needed to be scheduled as a user level task. Note from Geej:

Just my thought on the followings (may not be 100% right, still learning...)
The reason why the original code for XP did not work is because {/RU "SYSTEM"} runs as {NT AUTHORITY\SYSTEM} context.
This context is non-interactive. That is why no system tray icon shown up on your systray.
(non-interactive means you can't bring up the program GUI to make your search as you cannot interact with the program interface).

So to create an interactive logon, you need to provide a user name & password. This password is use to login to XP.
My XP do not have login password as it is autoboot+login to desktop w/o password.
Hence I have to create a password (I use justforfun as password as an example) for myself so that I can create a task schedule.

I just don't know. There is also this info from mooms:

I have asked David Carpenter, developer of Everything, if he can rewrite his installer, he have answered that the next major release will be an client-server approach, eliminating the problems with UAC and the fact that anything you run from "Everything" is being elevated.
It might also be open-sourced.

So to get this kind of thing working with Everything, at least using this kind of approach, we might have to wait on the Developer to add the appropriate hooks? It also indicates that the developer is willing to take input, so maybe we have some suggestions for him?

It also makes we want to know how you/Trouba got the ssApp/ppApp versions to behave for both Win7 and XP and can I use any similar type of trick in my code?

Sorry for the length of this post, but I would very much appreciate some feedback.

Cheers and Regards

Before Vista came out, I used to use a batch tool (from Microsoft) when I was a network admin to temporarily elevate the current command-box to admin privileges (this even worked from a guest account). One only needed a valid admin password that the local PC recognized, either from the local PC's or from the domain. And from there any process launched from that cmd-box would have admin privileges. Think "control.exe" or "explorer.exe", etc. I'm sure I still have it somewhere but I'm still looking for where I'd put it.

Also, isn't Powershell a Windows 7 (and now 8) exclusive? I mean, I think everyone else needs to download it from MS because it's not included with the operating system -- as a default "pack-in" like it was with Win7.

Anyway, I'll keep slogging through and testing what I can on my NT5 systems and let you know what I find out if anything.

The Freezer wrote:Before Vista came out, I used to use a batch tool (from Microsoft) when I was a network admin to temporarily elevate the current command-box to admin privileges (this even worked from a guest account). One only needed a valid admin password that the local PC recognized, either from the local PC's or from the domain. And from there any process launched from that cmd-box would have admin privileges. Think "control.exe" or "explorer.exe", etc. I'm sure I still have it somewhere but I'm still looking for where I'd put it.

This might be useful. Maybe not totally general purpose, since you have to have the PW that the PC recognizes, (hence the current approach to just have the user approve the elevation with no PW required), but probably a useful option if you DO have such a PW.

The Freezer wrote:Also, isn't Powershell a Windows 7 (and now 8) exclusive? I mean, I think everyone else needs to download it from MS because it's not included with the operating system -- as a default "pack-in" like it was with Win7.

I don't think exclusive, but rather a default for Win7 and Win8. It is downloadable for XP, AFAIK. This is my very first time ever even attempting its use. If we find that using it gives us some options that are easier, or we wouldn't have access to otherwise, then I have a way to test for its presence and we could fall back to XP style procedures if it is not there. Even though it is there in a default install for Win7&8, some people do remove it in an effort for a "slimmed" build. [OT: It also annoys me that even some of the batch commands now have different options, XP vs Win7 at least, as I found out with SCHTASKS.]

Anyway, this is what I came up with to test for the presence of Powershell:



From what I've been able to gather, no matter which version of Powershell you have installed, (I have ver 3), this test for "PowerShell\1" is a valid test and seems to mean you have some version installed. This snippet initializes and cleans up after itself, but you could move the initialization and clean up elsewhere if you wish, of course. I hate the use of GOTO's and I know it's bad coding practice, and yes I know I could have encapsulated the psNotFound and psFound sections in (IF "!_PSInstalled!"=="1" (psFound code) ELSE (psNotFound code) and not used any GOT'O's at all, and depending on what you need to do differently in the two cases that might very well be more appropriate. But the CMD batch processor would consider all of that one single statement and evaluate all the variables as it read in that one statement into memory. So I have found that the judicious use of a FEW GOTO's therefore makes more efficient use of memory and introduces fewer chances for silly programming errors when you forget that you might need to handle variables differently due to delayed expansion requirements. I'm sure I'm not telling you anything you didn't already know, but that was for the benefit of any other potential readers.


I also realized that in order to be more universally usable, I need to change slightly the code to check for OS version. What I have above is great for use in English versions, but will fail for versions where the VER command does not return "Version _____". So, instead of this:



an improved code snippet is:



Either version can very easily be expanded if needed to be able to tell which specific OS is installed, Vista, Win7, Win8, etc.

bphlpt wrote:I don't think exclusive, but rather a default for Win7 and Win8. It is downloadable for XP, AFAIK.

Yeah, sorry. That's what I meant. That the inclusion of Powershell to the defaults were exclusive to Win7 and that even Vista needs to download it to use it.

An alternate approach to install "Everything" in both Win7 and XP has been used successfully by Geej in the above mentioned thread over at Wincert. He made a WA type addon, (basically a renamed 7-Zip made to be used with Win Toolkit -- in the same manner that our .apz are made to be used with ssTek tools), which uses an INF file:



I still would like to get a "universal" batch way to achieve admin rights elevation figured out because I'm sure that there could be a use for it. I also would like to better understand how to use the SCHTASKS command, so I'd like to continue what I began in this thread. But maybe I can use Geej's file to help figure out some of the syntax I'm having difficulty with.

Cheers and Regards