penpen wrote:I'm not sure if the following is faster
Not quite. It's querying the Win32_GroupUser class that isn't optimized. I decided to use WMIC path Win32_Group WHERE "LocalAccount='TRUE' AND SID='S-1-5-32-544'"
to get the admin group name and try to find it in the output of NET USER %USERNAME%
. The code was already updated... Thanks anyway!
penpen wrote:i'm not sure if there are always 3 characters appended
I always use the /value option in order to have name and value in only one line. I never saw any appended characters as in the list format.
I'm running Windows 7 Pro on a laptop connected to a large network. When disconnected, commands for the Win32_GroupUser class run fine. When connected, they takes hours
, and likewise for Win32_UserAccount. My research says that 'wmic /node:"%computername%" path ...
' or 'wmic /node:localhost path ...
' ought to limit the search to the local machine, but they have no apparent effect.
I've found a solution that's pretty ugly, but works, and also addresses a weird scenario that hasn't been brought up yet. Supposing that my computer name is "MyComputer", my user name is "douglas", and the user name of an administrator who has logged in to MyComputer is "smith". When I run "net user", I get this output:
Code: Select all
User accounts for \\MyComputer
administrator douglase945iz6wtitsr douglasxwhmq2q508hge
guest smith74 smith75
The command completed successfully.
There is no "douglas" account, according to NET. If I run 'net user douglas
' I get "The user name could not be found." We could extract the account names that start with my login name, but then we'd have to either repeat the following code for each one, or decide between them, and I have no idea what the criteria would be.
The solution below relies on GPRESULT, which has been available since XP SP2
, but only became standard in Windows Server 2003
, so we might have compatibility issues with XP, but I figure we have the same issues with WMIC, so it's pretty much break even. This runs in about 40 seconds for me.
Code: Select all
rem :: Get name of admin group, based on SID (language-independent)
for /f "usebackq skip=1" %%F in (
`wmic group where "LocalAccount='TRUE' AND SID='S-1-5-32-544'" get Name /format:table ^| findstr /i /r "[a-z0-9]"`
) do set "admin_group_name=%%F"
rem :: Group membership is listed at the end of the RSOP report from GPRESULT.
rem :: Each major heading is underlined with a series of dashes.
rem :: I don't know if the output of the report is language-dependent,
rem :: so instead of looking for the heading, we look for the dashes,
rem :: and store the line number, which tells us where the info starts.
for /f "delims=" %%F in ('gpresult /r /scope user ^| find /n "--------"') do set /a _lines=%%F
rem :: Now that we know where the data starts, we can skip down to there,
rem :: and trust that we won't be examining irrelevant lines that might match.
rem :: For some reason, piping the output directly to FIND or FINDSTR
rem :: isn't working for me (it may have something to do with extra CR chars),
rem :: so I'm writing it to a temp text file first.
for /f "skip=%_lines% tokens=* delims=" %%F in ('gpresult /r /scope user') do @echo %%F
) > "%user_groups%"
rem :: Read the temp file and filter for admin group name.
rem :: If it's found, set the admin flag to true.
rem :: My normal account isn't admin, so I've added the Everyone account
rem :: as a backup test, just to be sure it all worked.
type "%user_groups%" | find "%admin_group_name%" && set "LocalAdmin=true"
type "%user_groups%" | find "Everyone" && set "EveryoneAccount=true"
rem :: Check result.
echo end: %time%
echo beg: %start_time%
rem :: Clean up.
I haven't run into the extra characters that penpen mentioned, and I can't speak to the registry workaround that compo brought up.
For what it's worth, this guy
ran into a similar "running forever when on a network" problem, and says he solved it by resorting to PowerShell. Unfortunately, he doesn't say exactly what the solution was. My guess is just re-writing the original command in PS format, but I haven't tried that.
I found a page that mentioned high resource usage from WMI (the system, not WMIC the tool) under certain conditions, and suggested using get-object instead of... whatever the alternative was. I can't find the page again to save my life, so I'm just going off memory.
The point of the last two paragraphs is that there may be an issue with the WMIC tool, or with WMIC on Windows 7/8, rather than with WMI itself. You seem comfortable with the other Windows scripting languages, so if you haven't already, I suggest trying the 'assoc /assocclass:Win32_GroupUser
' command using one of them, possibly in combination with "/node", and see if that solves the hanging issue. If it does, then I think you've also got a solution that works with XP, since those are older technologies.