RulerOf

Hello Folks, This took me long enough to do that I thought I'd share with the world. I needed a MAC address from AutoIt code by parsing the output from "ipconfig /all" stdout stream. It'll return the first MAC address it finds, and contains no error handling. Quick and dirty. #include <constants.au3> $ipconfig = Run(@ComSpec & " /c " & 'ipconfig /all', "", @SW_HIDE, $STDOUT_CHILD) Local $line = "" While 1 $line &= StdoutRead($ipconfig) If @error Then ExitLoop WEnd $macraw = StringRegExp($line, "\s*Physical\sAddress[\s\.]*\:\s*((?:(\d{1,2}|[a-fA-F]{1,2}){2})(?::|-*)){6}", 2) $mac = StringRegExpReplace($macraw[0], "\s*Physical\sAddress[\s\.]*\:\s*", "") Cheers, RulerOf P.S.: I hate regular expressions.

Oh hot damn that is one sexy script! Won't work here cause our users aren't admins... then again my biggest problem there is that SYSTEM doesn't have the symlink creation privilege, so it likely wouldn't work anyway. If you want to test for yourself, try calling mklink from a SYSTEM cmd prompt. It's kinda stupid.

Clever idea, and while I could do that, the local administrator accounts are disabled. As an aside though, I'm not a fan of embedding passwords I appreciate the thought though!

No, Group Policy startup scripts. Startup scripts run in the SYSTEM context and are transparent (and oh so easy to implement ), and usually give me a secure method for running administrative tasks that are local to a given machine. I wrapped the AutoIt3 executable and includes into an MSI with WIX such that admins and SYSTEM are allowed to run scripts and deployed that through group policy. That way I can stuff an .au3 file into the policies I'm using to get work done rather than using compiled scripts or resorting to javascript/vbs/whatever inferior language

Wow. It gets even more obnoxious than I thought. There's a policy setting in Windows to allow the creation of Symlinks by non-admin users, specifically the "SeCreateSymbolicLinkPrivilege" privilege. Every single attempt I've made to modify the privilege both through local/group policy, and using the security.au3 UDF, turns back successful but it doesn't f***ing do anything! Turns out that this is an issue with Windows that's apparently never been fixed, but I don't know how deep this bug goes. I'm whipping out some C++ today (groan) to see if I can dig at this privilege and get the damn thing working.... I just find it extremely stupid that I can't create symlinks programmatically with the SYSTEM account. FWIW, I'm digging into this (and I've wasted DAYS of work on this, thanks Microsoft!) because Symlinking is the only method I've been able to come up with (and if I had known about this, I would have tried anything else) to address a compatibility issue with a line of business app (hell, for my company it is the line of business app). If I'm successful, I'll post any methods/code/whatever that I come up with here, as well as other places. We'll see where this goes I suppose.

Yessir. Symlinks are only supported on NT6+ You could junction or hard link them, but I wasn't interested in those because I need to symlink a network folder

Oh good lord this is obnoxious... NT AUTHORITY\SYSTEM doesn't have the privilege to create Symlinks. I wanna shoot myself right now At least the code works

Hello Folks, Posting just to share I was wracking my brain yesterday trying to figure out why my script to generate a Symlink wouldn't work, and among other things, invoking @Comspec wasn't helping things any! A little googling and I stumbled across the method to create them programatically using the Windows API, which works pretty well. Here's the function if anyone would like to use it! ;======================================================================================= ; Function Name: _SymLink ; Description: Creates an NTFS Symbolic Link at the specified location ; to another specified location. ; ; Parameter(s): $qLink = The file or directory you want to create. ; $qTarget = The location $qLink should link to. ; $qIsDirectoryLink = 0 for a FILE symlink (default). ; 1 for a DIRECTORY symlink. ; ; Syntax: _SymLink( $qLink, $qTarget, [$qIsDirectoryLink = 0] ) ; ; Return Value(s): On Success: Returns the path to the created SymLink. ; ; On Failure: 0 and set @Error: ; ; 1 = DLLCall failed, @extended for more info ; 2 = $qLink already exists! ; ; Notes: To remove a Symbolic link, just delete it as you would any ; file or directory. ; ; Author(s): Andrew Bobulsky (RulerOf@{Google's-infamous-mail-service}.com) ; ; Other info: http://www.informit.com/guides/content.aspx?g=dotnet&seqNum=762 ; MSDN: http://msdn.microsoft.com/en-us/library/aa363866(VS.85).aspx ;======================================================================================= Func _SymLink( $qLink, $qTarget, $qIsDirectoryLink = 0 ) If FileExists($qLink) Then SetError(2) Return 0 EndIf DllCall("kernel32.dll", "BOOLEAN", "CreateSymbolicLink", "str", $qLink, "str", $qTarget, "DWORD", Hex($qIsDirectoryLink)) If @error Then SetError(1, @extended, 0) Return EndIf Return $qLink EndFunc Enjoy! =) -RulerOf

Ahem: <3 You. I come into work today only to find you've made my job sooooo much more concise. I owe ya! =) Thanks so much, RulerOf

This was driving me nuts for hours, trying to think of a good way to do this, and then I stumbled upon the LogonUser function in advapi32.dll. This code seems to work for me against the accounts I tried. Not sure what permissions are necessary for the autoit code to validate against the AD you're targetting though Also, use an NT-style domain (like "domain" instead of "domain.com") as I'm not sure if the FQDN will work. Hope you like it ;Returns 1 for valid credentials, 0 for invalid credentials and sets @error Func _ValidateUserCreds($d_Account, $d_Password, $d_Domain = @ComputerName) const $LOGON32_LOGON_INTERACTIVE = 2; const $LOGON32_LOGON_NETWORK = 3; const $LOGON32_PROVIDER_DEFAULT = 0; const $LOGON32_PROVIDER_WINNT50 = 3; const $LOGON32_PROVIDER_WINNT40 = 2; const $LOGON32_PROVIDER_WINNT35 = 1; $d_LogonUser = DllStructCreate("HANDLE") DllCall("advapi32.dll","BOOLEAN","LogonUser", "str", $d_Account, "str", $d_Domain, "str", $d_Password, "dword", $LOGON32_LOGON_NETWORK, "dword", 0, "ptr", DllStructGetPtr($d_LogonUser)) $d_Success = DllStructGetData($d_LogonUser, 1) If $d_Success Then Return 1 Else SetError(1) Return 0 EndIf EndFunc

Aye aye, I kinda fell off the wagon on this project when other things came up and never revisited it However, at the moment I find myself sorely in need of AutoIt on IIS right now (Because to hell with PHP! ) for a Win7 deployment I'm doing, so I'm going to be setting this up again and I'll give you my notes =) Apologies, but also many thanks!

Hello Folks, A little bit of Googlin' and a couple of Forum searches seems to indicate that, for some reason, this function isn't really prevalent, so I wanted to post the code I wrote here. Anyone care to pick it apart for me? I write AutoIt code in my spare time, so I may have missed a few gotchas that my limited (but successful!) testing couldn't reveal. _ProcessGetWindow() is designed to be the counterpart of WinGetProcess(), returning HWND's from an input process ID. It can also be told to provide a single, best guess result in the event you don't want to try parsing multiple windows from the output. In the event that this is a highly redundant post, I apologize, but I did do some searching in advance, and all I came up with was instructions to do just this Edit: Ha-ha, found a bug when I went to use it. As originally written, it wouldn't return HWND's for processes owning less than two windows Code updated. #include-once #include <array.au3> ; #FUNCTION# ============================================================================================================================ ; Name...........: _ProcessGetWindow ; ; Description ...: Returns an array of HWNDs containing all windows owned by the process $p_PID, or optionally a single "best guess." ; ; Syntax.........: _ProcessGetWindow( $p_PID [, $p_ReturnBestGuess = False ]) ; ; Parameters ....: $p_PID - The PID of the process you want the Window for. ; $p_ReturnBestGuess - If True, function will return only 1 reult on a best-guess basis. ; The "Best Guess" is the VISIBLE window owned by $p_PID with the longest title. ; ; Return values .: Success - Return $_array containing HWND info. ; $_array[0] = Number of results ; $_array[n] = HWND of Window n ; ; Failure - Returns 0 ; ; Error - Returns -1 and sets @error ; 1 - Requires a non-zero number. ; 2 - Process does not exist ; 3 - WinList() Error ; ; Author ........: Andrew Bobulsky, contact: RulerOf <at that public email service provided by Google>. ; Remarks .......: The reverse of WinGetProcess() ; ======================================================================================================================================= Func _ProcessGetWindow( $p_PID, $p_ReturnBestGuess = False ) Local $p_ReturnVal[1] = [0] Local $p_WinList = WinList() If @error Then ;Some Error handling SetError(3) Return -1 EndIf If $p_PID = 0 Then ;Some Error handling SetError(1) Return -1 EndIf If ProcessExists($p_PID) = 0 Then ;Some Error handling ConsoleWrite("_ProcessGetWindow: Process " & $p_PID & " doesn't exist!" & @CRLF) SetError(2) Return -1 EndIf For $i = 1 To $p_WinList[0][0] Step 1 Local $w_PID = WinGetProcess($p_WinList[$i][1]) ; ConsoleWrite("Processing Window: " & Chr(34) & $p_WinList[$i][0] & Chr(34) & @CRLF & " with HWND: " & $p_WinList[$i][1] & @CRLF & " and PID: " & $w_PID & @CRLF) If $w_PID = $p_PID Then ;ConsoleWrite("Match: HWND " & $p_WinList[$i][1] & @CRLF) $p_ReturnVal[0] += 1 _ArrayAdd($p_ReturnVal, $p_WinList[$i][1]) EndIf Next If $p_ReturnVal[0] > 1 Then If $p_ReturnBestGuess Then Do Local $i_State = WinGetState($p_ReturnVal[2]) Local $i_StateLongest = WinGetState($p_ReturnVal[1]) Select Case BitAND($i_State, 2) And BitAND($i_StateLongest, 2) ;If they're both visible If StringLen(WinGetTitle($p_ReturnVal[2])) > StringLen(WinGetTitle($p_ReturnVal[1])) Then ;And the new one has a longer title _ArrayDelete($p_ReturnVal, 1) ;Delete the "loser" $p_ReturnVal[0] -= 1 ;Decrement counter Else _ArrayDelete($p_ReturnVal, 2) ;Delete the failed challenger $p_ReturnVal[0] -= 1 EndIf Case BitAND($i_State, 2) And Not BitAND($i_StateLongest, 2) ;If the new one's visible and the old one isn't _ArrayDelete($p_ReturnVal, 1) ;Delete the old one $p_ReturnVal[0] -= 1 ;Decrement counter Case Else ;Neither window is visible, let's just keep the first one. _ArrayDelete($p_ReturnVal, 2) $p_ReturnVal[0] -= 1 EndSelect Until $p_ReturnVal[0] = 1 EndIf Return $p_ReturnVal ElseIf $p_ReturnVal[0] = 1 Then Return $p_ReturnVal ;Only 1 window. Else Return 0 ;Window not found. EndIf EndFunc

Regarding your post here: There may very well be a method for determining what server is calling AuCGI. You seem quite interested in being able to run this on IIS (as I am, too!) so I'll grab the latest AuCGI and web.au3 code and roll up some changes or patches if you like. In the meantime, I'll investigate the options. I'll post back either in a couple hours or by Monday and let ya know! In the meantime if I get a chance, I'll keep this thread subscribed if you've got anything to add Oh one more thing: It seems that passing serverside info to a CGI application is supposed to be done through environment variables, so it's likely that adding support for IIS/Apache/Tomcat/whatever will all be extensions of the same code base, FWIW. Thanks again guys __________ Update: Here's a snippet of what IIS is passing to the CGI module: SERVER_SOFTWARE: Microsoft-IIS/7.0 SERVER_NAME: drew-dc.drew.local GATEWAY_INTERFACE: CGI/1.1 SERVER_PROTOCOL: HTTP/1.1 SERVER_PORT: 80 REQUEST_METHOD: GET PATH_INFO: /AutoIt/test.auw PATH_TRANSLATED: C:\inetpub\wwwroot\AutoIt\test.auw SCRIPT_NAME: /AutoIt/test.auw REMOTE_HOST: 192.168.1.61 REMOTE_ADDR: 192.168.1.61 Ironically, all of these variables seem to be declared in web.au3, so I'm going to have to read them an additional time in AuCGI if it detects IIS. If anyone has another suggestion though, I'd be welcome to it Should have a code snippet ready soon.

Not sure if anyone cares, but I got this working on IIS 7 under Win2008. Screenshot: If you want to do this, it requires a modified AuCGI.au3. IIS passes the calling script over the the handler via environment variables. Change this: If $CmdLine[0] < 1 Then error("what are you trying to do???") Global $sourcescript = $CmdLine[1] To this: If StringRight(EnvGet("PATH_TRANSLATED"), 3) <> "au3" And StringRight(EnvGet("PATH_TRANSLATED"), 3) <> "auw" Then error(EnvGet("PATH_TRANSLATED") & ": Not a .au3 or .auw script file!") Global $sourcescript = EnvGet("PATH_TRANSLATED") Create a web application and add the AuCGI handler mapping to your web application under the IIS Manager to handle *.auw and/or *.au3 files. Seems to work pretty well! I've been dying to use AutoIt to handle HTTP boot scripts for gPXE, and /this/ is just what I've been looking for =) Thanks for the great work! ___ Also, I was thinking it would probably be prudent to pass the other environment variables down to the actual Au3 code, but I'm not sure. I'm not really a web programmer Wikipedia has the full list here.

Heh, i'd link to it but i have no idea where it is Search function to the rescue, sir! I need to go find some documentation on the XML wrapper i just found :-X