Jump to content

ScriptingSteve

Active Members
  • Posts

    27
  • Joined

  • Last visited

ScriptingSteve's Achievements

Seeker

Seeker (1/7)

1

Reputation

  1. I have attached sample code that is working, ported from VB script implementation from here: https://social.technet.microsoft.com/Forums/en-US/ed4e35c7-a1c9-43ea-ab82-970eadb4915e/ccmclientutilities-pending-boot-script-in-vbscript?forum=configmanagersdk Be sure to add error handling for Windows object error issues. Sample.au3
  2. Wonder if you have suggestion. Looking for an Autoit script to initiate the same process the SCCM 2012 R2 client would use to select an appropriate distribution point server name, based on current location, boundaries, etc., to pull a package. We are trying to implement MS Office 365 Click-to-run, and let the updates process run against the 'appropriate' SCCM DP for the update media... we want to select the same DP that SCCM would use for the PC in its current boundary. I hope that makes sense.
  3. Yes, the "sysnative" technique did work correctly. Thanks to all for assistance.
  4. I have a 32-bit-compiled autoit script that is returning false in error when run on 64-bit Windows 7 for this code: {{ $Dir=@WindowsDir & "\System32\Drivers\mrxsmb10.sys" If FileExists($Dir) Then Msgbox(64,"File found","File '" & $Dir & "' Version " & FileGetVersion($Dir)) Else Msgbox(16,"Error","File '" & $Dir & "' not found.") EndIf }} The file is physically in the above location (C:\Windows\System32\Drivers\Mrxsmb10.sys). When the script is compiled x86 (AutoIt 3360), it returns false (incorrect). If the same script is recompiled as x64(AutoIt 3360), it returns true (correct). The interesting thing here is that on a 64-bit Win7 machine, this file is NOT within C:\Windows\SysWOW64\..., it is sitting at the absolute path "C:\Windows\System32\Drivers\Mrxsmb10.sys". Thus the "If Fileexists($Dir)" from above is looking for this file at path "C:\Windows\System32\Drivers\Mrxsmb10.sys", (I validated this through debugging that variable substitution was correct). Visually verified as being present at the above path on 64-bit Windows 7.. yet 32-bit compiled script returns false (file does not exist, even when it does), but the same script, recompiled 64-bit, returns true (file exists), correct. Unless I'm missing something obvious, I suspected this as an AutoIt bug, but am told to discuss here first. Looking for any suggestions..
  5. @OSLang detects the English OS - it is not looking at the language pack. We use English XP with an optional French language pack. I use this code: $Lang_dll = DllOpen("kernel32.dll") $UserIntLang=DllCall ( $Lang_dll, "int", "GetUserDefaultUILanguage" ) ;This result is an integer - need the hex equivalent If @error=0 Then $UserIntLang=Hex($UserIntLang[0],4) ;Convert to HEX Else ;Unable to determine user interface language $UserIntLang="UNKNOWN" EndIf DllClose($Lang_dll) It returns $UserIntLang=0409 for English, 040C for the French interface, etc.
  6. I have an AutoIt 3.2.4.9 script which I have been compiling with Scite (6/3/2007). Today I updated Scite to the "6/18/2007" version, and now when I try to compile, I receive this error: ! RC.Exe (1) : Error : Resources information will not be updated in target program! None of the resources settings apply. Here are the compilier directives: #Region ;**** Directives created by AutoIt3Wrapper_GUI **** #AutoIt3Wrapper_icon=c:\scripts\icon\PeopleSecurity.ico #AutoIt3Wrapper_Allow_Decompile=n #AutoIt3Wrapper_Res_Comment=My Comment #AutoIt3Wrapper_Res_Description=My Description #AutoIt3Wrapper_Res_Fileversion=1.2.3.4 #AutoIt3Wrapper_Res_LegalCopyright=My Company #EndRegion ;**** Directives created by AutoIt3Wrapper_GUI **** When I remove 6/18/2007 and reinstall 6/3/2007, the compile again works OK. I don't see any documentation changes to the syntax of the directives. What is causing the error?
  7. Thanks for your assistance. Basically, the computer reporting this issue is simply wacked.
  8. I have a script running at logon for approx. 12000 users. I use @OSVERSION to limit execution to Windows XP computers. The script is aborting on one computer, claiming it is "WIN_NT4" when it is most obviously XP. Something that AutoIt reads to fulfill the @OSVERSION function is obviously corrupted, and if I knew what these were, I could analyze the corruption further. So, What registry values, etc, are referenced by the @OSVERSION macro?
  9. Thanks... I did try that, it didn't seem to work - perhaps I will try again. Thanks for your help.
  10. I am trying to convert this VBscript to Autoit 3.2.0.1: On Error Resume Next Const ADS_SCOPE_SUBTREE = 2 Set objRootDSE = GetObject("LDAP://RootDSE") strConfigurationNC = objRootDSE.Get("configurationNamingContext") Set objConnection = CreateObject("ADODB.Connection") Set objCommand = CreateObject("ADODB.Command") objConnection.Provider = "ADsDSOObject" objConnection.Open "Active Directory Provider" Set objCommand.ActiveConnection = objConnection objCommand.Properties("Page Size") = 1000 objCommand.Properties("Searchscope") = ADS_SCOPE_SUBTREE objCommand.CommandText = _ "SELECT ADsPath FROM 'LDAP://" & strConfigurationNC & "' WHERE objectClass='nTDSDSA'" Set objRecordSet = objCommand.Execute objRecordSet.MoveFirst Do Until objRecordSet.EOF Set objParent = GetObject(GetObject(objRecordset.Fields("ADsPath")).Parent) WScript.Echo objParent.CN objRecordSet.MoveNext Loop Unfortunately, AutoIt does not like my version of the line: Set objParent = GetObject(GetObject(objRecordset.Fields("ADsPath")).Parent) which I wrote in AutoIt as this line: $objParent = ObjGet(ObjGet($objRecordset.Fields("ADsPath")).Parent) It aborts with the error: "Object referenced outside a "With" statement.: " I've attached my code, which is intended to be a Function for another script. Can anyone assist with the syntax? The VB script version works fine, and is pulled right from Microsoft. Thanks!
  11. Well I feel silly... obviously... Thanks!
  12. I have an applet that has been in production for months, which uses a continuously-updated progress bar on a GUI. The last production release was compiled with 3.1.1.105. Today I recompiled in 119, and 123, and found that the progress bar was not updating correctly. When I regressed back to 105 and recompiled, the progress bar displayed correctly again. I have reviewed all of the changes since 105, but see nothing that may contribute to my problem. Here is a simple script that gives the "bad" progress display simply by setting the progress percentage to 0. Anything above 0 and it displays normally. In my real applet, I am updating other text on the dialog, not changing the progress setting, only re-applying it... the same problem happens. Note that the attached script shows a normal empty progress bar set at 0 in 105, but not in 123... Any ideas? ProgressBugfix.au3
  13. My program is launched by the logon script. The logon script is a Kix32 script that does check RAS settings.
  14. The script checks for user eligibility by looking up user and computer goup membership in Active Directory using an ADO connection. If the user or computer is not found in specified groups, the script executes anoterh script using the Runas command. There is nothing in my code dealing with RAS.
×
×
  • Create New...