Aaron Margosis' "Non-Admin" and App-Compat WebLog

PingBack from http://blogs.msdn.com/aaron_margosis/archive/2005/04/18/TableOfContents.aspx

You could also do something like this:

cacls %windir%\system32\config\systemprofile >nul 2>nul && echo admin || echo non-admin

This should work on both XP and Vista.

Aaron:

Just an FYI, there's an error in MakeMeAdmin.ps1 that you referenced.  The "if" statement in the SuPowershell function should read "if($SuAccount)" not "if(!$SuAccount)".

Otherwise, that's awesome, thanks for point it out!

Harris

Put the bare command

 COLOR FC

in HKCU\software\microsoft\Command Processor *for the admin account only*. No test required.

Of course if you have several admin accounts that you use -- e.g. a local one and a domain one -- put it in each one.

On my own machine I sometimes run in an account which is not a Domain admin but is an admin of the local machine, and I need to distinguish. The BOOTCFG trick won't distinguish between them .. so I would depend on HKCU.

I have to point out that the representation groups.archivesat.com of the script I wrote is incorrect.

You can see a correct version at via google groups at http://groups.google.com/group/microsoft.public.windows.powershell/browse_frm/thread/bc7fb9969347dd4a/84ab68ebb0f486f3?lnk=st&q=makemeadmin.ps1&rnum=1#84ab68ebb0f486f3

On ArchiveSat, the critical lines says:

if (!$SuAccount)

   $StartInfo = new-object System.Diagnostics.ProcessStartInfo

On Google:

if (!$SuAccount){

       return

   }

Makes quite a difference, doesn't it? :)

/Staffan

>> Ross:  The problem here is that with MakeMeAdmin on XP/2003 and with UAC's Admin-Approval Mode on Vista, you can have two CMD windows side by side running as the same user, one with admin/elevated permissions and the other not.  Tying to HKCU won't help. <<

Aaron: Good point, and if I used MakeMeAdmin like I'm supposed to, I'd have hit that myself. :-) Well, is there some kind of test that can distinguish between local machine admin and domain admin?

Very bad thing I found out: it turns every Cmd Console into ANSI mode, yet all subsequently invoked Cmd instance pertain UNICODE.

Test case:

for /f "delims=" %i in ('dir /s /b /a-d') do echo "%i"

This will break for the first file, since the cmd instance invoking the 'dir' command returns unicode, but the calling shell is ANSI and thus stumbles upon the Unicode BOM at the beginning.

Here is a way to change the color if you are running under a Domain Administrator context.

"c:\program files\windows resource kits\tools\ifmember.exe" "mydomain\domain admins" >nul 2>nul && (color 07) || (color FC)

-or you can copy ifmember.exe to somewhere in your path.  Of course, change mydomain to the name of your domain.

I just wanted to let you know there are some side affects that cause things to break when using your bootcfg trick.  

For example we have a Visual Studio 2003 project which runs the following command line function as a Pre-Build Event.  

xcopy ..\..\exe_dir ..\..\debug /d /e /y /EXCLUDE:..\..\exe_dir\exclude.txt

With the trick in place it xcopy fails during the build, although the same code works fine from a command window.

Visual Studio executes the command by generating the following batch file.

Creating temporary file "r:\MyProject\Release\obj\MyDll\BAT000002.bat" with contents

[

@echo off

xcopy ..\..\exe_dir ..\..\release /d /e /y /EXCLUDE:..\..\exe_dir\exclude.txt

if errorlevel 1 goto VCReportError

goto VCEnd

:VCReportError

echo Project : error PRJ0019: A tool returned an error code from "Copy exe_dir to release"

exit 1

:VCEnd

]

Creating command line "r:\MyProject\Release\obj\MyDll\BAT000002.bat"

When run the output is:

Copy exe_dir to release

0 File(s) copied

MyDll : error PRJ0002 : error result returned from 'r:\MyProject\release\obj\MyDll\bat000002.bat'

Removing the AutoRun value fixes the problem, so I don't expect you to troubleshoot this. I just want to warn others.  

Thanks Chris R!  This was driving me nuts. I was getting Pre-build errors too, and couldn't figure out why.

I was able to fix this by adding:

& echo > nul

which will run the echo after either the admin or non-admin commands run.  This will return errorlevel 0 to VS.Net which will allow the pre-build event to complete.

Improvements on my earlier post about setting color and title for CMD (and PowerShell) windows, based on admin/elevation status

Improvements on my earlier post about setting color and title for CMD (and PowerShell) windows, based on admin/elevation status

1fThank's.3k I compleatly disagree with last post .  viw

<a href="http://skuper.ru">паркет</a> 3b

Hi, Aaron! I wish to thank you for your great "non admin" postings !

What command would you suggest for use on Windows 2000 (where bootcfg isn't available) to distinguish between admin/non admin status ?

Also, I need something which will not depend on NTFS permissions.

Thanks once more

--

Czerno

re my above question, found a solution viz

use the command line registry tool reg.exe,

for instance :

reg update software\mytrick=1

There might be more elegant ways...

Regards

--

Czerno

In Windows 7, BOOTCFG always always returns errorlevel 1, even when it succeeds when running as Administrator. Here's a refinement:

(BOOTCFG /query 2>nul |FINDSTR Entries >nul) && (COLOR 47) || (COLOR 07 & echo>nul)

This uses FINDSTR to search the BOOTCFG output for the word "Entries", which it should always have if it succeeds. It also adds the "echo>nul" for the non-admin case, to clear the errorlevel.

Windows 7 already adds the "Administrator" to the title bar, but if you still need the color change, here it is.