TXTechie

Ok, I'm sorry but I've not worked a lot with arrays, how would I go about concatenating the array in a loop like this?

Thanks for the clarification, BrewManNH & Melba23! And, yes, I did just notice that I had left the C: drive hard-coded. I have been modifying it.

I'm using the following script: #include <Array.au3> #include "RecFileListToArray.au3" ; External UDF by Melba #NoTrayIcon Local $aFileList, $aDrives = DriveGetDrive("FIXED") If @error Then ; An error occurred when retrieving the drives. MsgBox(4096, "Drives", "It appears an error occurred.") Else For $i = 1 To $aDrives[0] ; Show all the drives found and convert the drive letter to uppercase. MsgBox(4096, "DriveGetDrive", "Drive " & $i & "/" & $aDrives[0] & " = " & StringUpper($aDrives[$i])) ; Search the drive for all .bat & .ftp files $aFileList = _RecFileListToArray("C:\", "*.bat;*.ftp", 0, 1, 0, 2) Next EndIf _ArrayDisplay($aFileList, @ScriptName) The _ArrayDisplay function only displays the folder path, not the actual filename - how can I get the full path to the .bat or .ftp file, since I'll need it later in order to perform the find & replace on them?

Melba23 & Edano, Thank you very much for the information, I will start playing around with _RecFileListToArray UDF. Thanks!

Well, I'm wondering which of the following (or something else that I haven't found yet) might be faster and/or more efficient for this purpose?: FileFindFirstFile & FileFindNextFile _FileListToArray() RecFileListToArray other?

Hello Everyone, I'm looking for what you think would be a fast and efficient way to search an entire PC (at least all fixed drives, possibly attached USB drives?) for all .ftp & .bat files (in my case). Then, I'll need to read the contents of each of these files doing a find & replace function on each file. Can someone recommend the best way to start this project?

JLogan3o13 & danwilli, It was one of those too obvious to even notice things. I had to check one of my MSI install scripts and compare the entire command-line in order to see it.

dachammer, You need to include the /i switch before you provide the MSI folderpath, like this: ShellExecute("msiexec.exe", "/i " & @ScriptDir & "\KeyViewComponent1080.msi /qb /l*v C:\sccm\msi_logs\KeyViewComponent1080.log") You might even need to include quotes around your MSI folderpath if there are spaces in the folder path.

dolphins, Also, if you're interested in more of an IDE (Integrated Development Environment) for AutoIt, someone is currently developing one using AutoIt ! It is still in beta, but it is actively being updated and it's maturing nicely. It even includes a debugger (again, it's still in beta). Here's the message thread on the AutoIt Forums where you can track it's progress: '?do=embed' frameborder='0' data-embedContent>>. Here's the web site where you can view screen shots and download the latest version: http://isnetwork.isi-webportal.at/index.php/meine-programme/isn-autoit-studio.

Why are you using ShellExecuteWait instead of RunWait? For example: $file = RunWait('msiexec /i "' & $pathToMSI & '" /q') I think this will be a better solution for this particular purpose.

Hi Decipher, I would greatly appreciate any insight you have. Based on several years (and versions) of working with CA and their solution, I don't have much confidence that they will provide me with a solution to this issue. So, I would certainly be interested in being able to control this on my own, apart from the CA agents.

TomMelee, You might want to check out the included form designer of the >ISN AutoIt Studio AutoIt IDE. It's in beta, but it's maturing nicely and it makes it MUCH easier to create GUIs!

Hi orbs, You may be correct, and I'm not enough of a developer to come up with a solution for your 2nd suggestion (another agent). In talking with someone else within the Systems Management discipline at another company, he says he has no problem using AutoIt or other deployment mechanisms that do display dialog boxes to interact with users on Win7 using SCCM and he thinks Altiris. So, what I may need to do is contact my software deployment product company (CA) to see if they have a solution for the Interactive Services Detection feature. I want to thank everyone for their input and feedback!

abberration - The problem is the location of the deployed software will be different and growing, I don't want that management nightmare. I thought that I had read another post here in the forums stating that using any other setting except for the default UPX compression setting of Normal would change the file attributes of the default AutoIt compiled executable - is this true? storme - Since I am also the person in control of the standard workstation clone image, I have thought about including the AutoIt3_x64.exe on our standard Win7 (64-bit) image build - if I go the route of just executing scripts (rather than compiling). However, the less than 1 MB size of each of the AutoIt executables is not a big deal. I don't really care about the visibility of my scripts (especially since I've been using VBScript files for years), but I like the idea of having less additional files by compiling to the a3x format (I had to look that up in the help file, as I was unfamiliar with that) in that it can incorporate all include and FIleInstall files. Plus, I have the added ability to make my scripts a little more secure from easily prying eyes - especially if I may include some more confidential info in some of my scripts in the future (I know that this is not really secure, but is just secure from those who aren't interested in really trying to hack the scripts). Thank you, very much, for the additional information, storme! Does anyone think I should worry about this and just go ahead and use fully compiled scripts to executables for all of my deployments?

Thank you, spudw2k. And, I agree with you - this community has already helped me and if I'm going to be using AutoIt even more than I have in the past, I fully expect to be here in the forums more often.

Hi JLogan3o13, Well, I've been in Systems Management (software packaging and deployments) for 14+ years now and there are two primary methods for software packaging and deployments: 1) drive the installation using the native installer and 2) repackaging everything to Microsoft's Windows Installer (MSI) technology. I am in the 1) camp, so I create a script "wrapper" to drive the native installer (whether legacy or MSI) and then automate any other desired post-installation configurations as desired. So, since I don't use Flexera Software's InstallShield tools - I've been deploying software using a script as a wrapper (currently VBScript, but I've decided to switch to AutoIt). This is why I'm asking the question. My company uses CA Software Delivery as our software deployment solution (I have previously used Microsoft's SMS [now SCCM], Novell ZenWorks, what used to be called Marimba, but is now BMC BladeLogic Client Automation and Dell's KACE KBOX).

Hello Everyone! Now that I've decided to begin using AutoIt as my standard template "wrapper" for deploying software and automating changes on computers within my work environment, I want to ask the community whether you think I should deploy my software packages as compiled executables, or should I just include the main AutoIt executables (AutoIt3.exe & AutoIt3_x64.exe) and then call the software package in my software deployment solution via the command-line (for example: AutoIt3.exe Flash-11.6.au3)? The primary reason for this question is based on the AutoIt and Malware link on the AutoIt Wiki. While, AutoIt executables are not currently being flagged as false positives by our current Anti-Virus and Anti-Malware solution, I'm concerned about the potential scenario where a false positive occurring again at any time in the future (for any number of reasons) disabling all software deployments within our company because I've chose to use compiled AutoIt scripts for my standard deployment mechanism. What are your thoughts?

I have also heard (and experienced some) of the slowness of PowerShell. Just another good reason to go with AutoIt. I have decided to go ahead an migrate my template from VBScript to AutoIt. I want to thank everyone for their input!

BrewManNH, Check out the link that I initially shared on the Interactive Services Detection feature. Really, I'm looking for more of a RunAsUserSession - since I want to execute something (GUI, install, etc.) in the user's session 1 rather than in the running process' session 0 (since my and most software deployment solutions use the SYSTEM account).

Thanks, water! You make some great points - using AutoIt as my primary foundation or "wrapper" I have GUI functions AND I can use PowerShell from within AutoIt (even adding a GUI for PowerShell functionality)! The best of both worlds! Does anyone else have any suggestions/input?

Hi BrewManNH, Unless I'm missing something in the AutoIt Help for the RunAs/RunAsWait functions, I don't see how these can help me as I need a generic solution for any and all software deployments that won't require me to know and have the username and password of all users in my environment. Am I missing something?

Hello Everyone, I know that this is an AutoIt forum and that everyone here loves AutoIt (as I do). But, I was hoping that some of you whom might have experience with PowerShell could provide me with a more objective comparison as to whether it makes more sense to use AutoIt or PowerShell as my primary "wrapper" for driving all of the software deployments within my company. Currently, I'm using VBScript for my "wrapper" template, but I'm seriously thinking about switching to either AutoIt or PowerShell. Which one should I use and why?

Thank you, AdamUL. The msg.exe command/tool is, indeed, a useful workaround. Also, I'm a bit ashamed that in my ~ 20 years experience of technical support and systems management roles, that I was unaware of the msg.exe command/tool, which is built-in to Windows. However, I was hoping for more of an internal RunAsUser function (most preferred) or some external DLL or EXE that could be called to perform this function. This would allow for a custom message of my choosing along with the ability to receive input back from the user. Also, since this is now no longer a silent install, I would then prefer to then display a progress bar of the progress of the installation to the user - so that they would know roughly how long until the PC will be rebooted, etc. I already utilize the shutdown.exe message capability, but I'm looking for a more robust way to communicate (two-way) with the user - especially at the beginning of the deployment (as I've just described above). Thank you, again, for your suggestion. orbs - In our environment, we have at least a couple of reasons why we cannot fully implement your formal suggestions... 1) most of our locations are or include manufacturing labs that work around the clock in 3 shifts, and 2) roughly 1/2 of our user community uses Laptops which they take home with them after their work hours. Are there any chances that someone within the community (with more development knowledge and skill than I currently have) might be willing to develop (or help me to develop) a RunAsUser function using AutoIt - or some other tool?

Are you running the script on a 64-bit version of Windows 7 ? If so, Windows is automatically redirecting to HKCUSoftwareWow6432NodeMicrosoft... rather than HKCUSoftwareMicrosoft.... Assuming you've compiled the script to an executable, you'll need to compile using 64-bit compilation (using the Compile X64 version. option setting).

Let me try to clarify what I want to do. Yes, most of our software deployments are completely silent to the user, but sometimes we want to let the user know something before beginning the installation or at the end of the installation. For instance, when installing one ore more Office-related applications, we display a dialog box instructing the user to close all Office applications so that the installation is successful and doesn't error out because one or more of the Office applications are running. Another example is to display a dialog box instructing the user to save all open files and then to close all open applications because the software package will automatically force a reboot of the PC at the end (as it is required) - this is only true for a few critical software deployments. Of course, this wasn't a problem with Windows XP, but starting with Windows Vista the Interactive Services Detection feature will not allow us to do this - at least not with any amount of certainty that the user will actually see the dialog box of instructions, since the user may never see the button flashing on the taskbar. So, I was hoping that AutoIt (either natively or via the UDF's from the community) has provided a way to display a dialog box (or something similar) to the user (Session 1) while the main script is running as Local System (Session 0). Allowing the same functionality as WinXP and previous versions of Windows, without "breaking" the Interactive Services Detection feature. That's why I called it more of a workaround. Am I making sense?