IanR

As of this morning's update, AVG antivirus has started deleting compiled v2 scripts (without warning or confirmation!) when it performs a scheduled scan. This is due to a Trojan false-alarm. If you use AVG, make sure your scripts are backed-up or you could lose them.

Any ideas how I might identify the credentials a workstation is using to access the server? The workstation will be running an autoit script hosted on a server-share at the time. (Note that this is NOT necessarily the same as the local-profile on the workstation.)

What he means is that it would be useful to know what error, if any, the program that was launched had returned. At the moment you can tell whether it was possible to launch the program or not, and what its PID is. However, the program you Run might fail to perform its task and thus return an errorcode of its own, and this-is-me is right in that there is presently no way of telling that happened. For example: Run ("XCOPY c:\nonexist.doc q:\nonexistentdriveandfolder\") will presently return an errocode suggesting that it worked, regardless of the fact that XCOPY is being told to do something impossible. HST, errorcodes returned by commandline programs are not totally reliable anyway, XCOPY being a case in point, it sometimes returns a "success" code when that was not the case. Therefore (IMHO anyway) the time and effort involved in adding this functionality might be questionable.

1. Compression would make the backups a lot slower and more processor-intensive, and that's something we're trying to avoid. Plus, most zippers have a size-limit (usually 2GB) over which you must switch to multi-volume archiving, and quie a few users have more data than this. Multi-volume archives cannot be updated easily. 2. The intended role of the script is automated backup workstations to a server HD. Trying to write such backups directly to DVD would not be ergonomic, as it would mean having a human operator standing-by throughout the process to change the discs. It would be more sensible to backup to a large HD first, then burn to DVD. FTP (or direct sockets) would be an interesting idea. I did toy with the idea of havign a server-side process runing on its own TCP port, to receive the data. 3. Possible on Samba I think, but NT Servers allow only one client-login per session, thus if the user's logged-in to their normal account, then they have access to the backup-share whether you like it or not. HST it's possible to set a combination of NTFS permissions that give pretty-good, but not absolute, security, and this is the route I will follow, for the moment anyway.

If you make your file have an .ini file structure (it need not specifically have an .ini extension) you can have seperate sections for each function. Then you can use the enumerate function to recover the names and values of the keys in each section.

; Look for an .ini file as scriptexename.ini: $iniFileName=stringleft(@ScriptFullPath,stringinstr(@ScriptFullPath,".",0,-1)) & "ini" ; Alternatively, look for an .ini file in the same folder as the executable, but with a different name: $iniFileName=pathonly(@ScriptFullPath) & "yourinifile.ini" func pathonly ($pathtostrip) If stringinstr($pathtostrip,"\") =0 then $pathtostrip = $pathtostrip & "\" endif return stringleft($pathtostrip,stringinstr($pathtostrip,"\",0,-1))

Typsoft FTP Server is very stable, and takes its config from .ini files, so (although I haven't tried doing so, please note!) it should be amenable to automation.

Not sure, but redefining an array as a same-named single variable equal to its own elements seems a bit risky. Might be OK, to do this, but then might not. - Opinions, Gurus? This one gets the time of a file in the standard AutoIt string format (which is YMD not YDM, BTW, otherwise numeric comparisons would be impossible. ) func FileDate($fdFile) $fdTa = FileGetTime($fdFile) if @error then MsgBox (0,"Date Error","Unable to get date of " & $fdFile,10) return "0" endif $fdDate = $fdTa[0] & $fdTa[1] & $fdTa[2] & $fdTa[3] & $fdTa[4] & $fdTa[5] return $fdDate endfunc Other point worth noting is that (according to MS) there is a small amount of "granularity" in file-times, therefore I'd allow a small increment in the comparison.

There is no absolutely safe way, but hashing of the password is reasonably secure. In this you generate a pseudo-random string that reperesents the password. Since it's pseudo-random and not actually random, the same password will always give the same hash. This is of course only useful for comparing a user's input with a password; it cannot supply the password, only check that the correct entry was made.

Yes, that's possible if you use a packet-driver and a rewriteable. The packet-driver can be on a server if you prefer, and it's still possible to write to the disc via a share. HST packet-writing is painfuly slow, so don't expect sparkling performance doing things that way.

Knocked-up a quick script to simplify the maintenance of login-scripts. Basically, we have a number of departments, some of which have only selective access to certain areas of the servers. (Nothing unusual there..) Maintaining a separate login-script for each of these departments was getting to be a pain, yet was preferable to using a single script, which would confuse the users by placing inaccessible drive-mappings on their machines. So thought it might be a lot simpler to map all drives from a common script, then check each for accessibility and remove those for which a directory-listing is denied. ; ******** DriveZap.au3 ************ $letters=stringsplit("h,i,j,k,l,m,n,o,p,q,r,s,t,u,v,w,x,y,-",",") $ct=1 while $letters[$ct]<>"-" $letters[$ct]=$letters[$ct] & ":" $share=drivemapget($letters[$ct]) if $share <> "" then $handle=filefindfirstfile($share & "\*") if $handle < 0 then drivemapdel($letters[$ct]) else fileclose($handle) endif endif $ct=$ct+1 wend This method works, but might not be the most efficient one possible. It relies on the "./.." entries being visible if the folder contains no other files. Thoughts on this, anyone?

The double-slash conversion I've outlined above. Removing the \\server\share part is probably best done by searching for the fourth backslash in the string, as that will separate it from the rest. Something like: $relpath = stringmid($fullpath,stringinstr($fullpath,"\",0,4) +1 ,255) (remove the "+1" term if you want the initial backslash included) Also might be useful: $filename = stringmid($fullpath,stringinstr($fullpath,"\",0,-1) +1 ,255) will return the filename and extension only (that is, the part after the last backslash) To return the relative path in relation to a known root-folder: func relpath ($pathname, $rootfolder) if stringright($rootfolder,1) <> "\" then $rootfolder = $rootfolder & "\" $relpath = stringmid($pathname,stringlen($rootfolder)+1,254) Return $relpath endfunc Hope this helps, Ian.

Not quite sure of your objective here, but if yo're looking to log someone on then run a program, this might do the job. Latest version (not on webpage) has "kiosk mode" option where only one program can be run, after which machine reboots.

You're welcome. It should be fairly obvious how each section works but PM me if you need any guidance. It's live on one complete site, and for two volunteer-users on another site. Nobody has reported any issues so far, and the backups seem to be updating daily. In the pipeline: Minor bugfixes. Securing the backup-folders. Grooming module. Did some work on the working grooming module today, as I feel this is a necessary item otherwise there's no way of removing the junk-buildup from the backups... A test on a single user-folder went quite well, now I need to write code to catalogue the backups, and run on each. Intention is to have the server do this as a scheduled process rather than taking-up network bandwidth. Thinks: maybe there should be two date-criteria, one after which individual files no longer present on the source-disk are considered expired, and another after which the entire backup will be considered expired if the user hasn't logged-on at all since that time. Ah, the things we do on Friday evenings.. (-Well, better than pouring our pay-packet down the drain..)

$regString = inputBox ("Registry Key", "Input the key to convert, in English..") $regString = stringReplace($regString,"\\","¬") $regString = stringReplace($regString,"\","\\") $regString = stringReplace($regString,"¬","\\\\") msgbox (0, "Registry Key, in Micro$oftese", $regString) $regString = stringReplace($regString,"\\\\","¬") $regString = stringReplace($regString,"\\","\") $regString = stringReplace($regString,"¬","\\") msgbox (0, "Registry Key in English", $regString)

I was thinking along those lines, reason I asked was mainly in case I'd overlooked a way of implementing it without resorting-to a command-prompt. (although that would be OK in fact as it only has to be done once per run, to one folder, so it would have negligible performance-impact.) Other option might be a DLL-call, I guess. Have to check Technet to see what the call is, and if it's feasible.

Just wondered if anyone has suggestions for ways of setting the permissions when creating a folder on an NTFS volume from within a script? (To complicate matters slightly this would also have to work across a network as a non-Admin user.)

Glad you like it. Spotted a couple of bugs already that slipped-through initial testing: I assumed a 10-series network in determining IP addresses of machines. (next version will have an .ini option) This isn't terribly critical as it's purely informative to log source IPs anyway. The template-delivery options were hardcoded for a quick-and-dirty test, and I subsequently forgot to refer them to the .ini file. Ooops. Never noticed either, as we use the default location so it worked for us. Again, fixed in next release.

YourBackup - a script for automating the backup of Windows 95-XP workstation data to a server. Intended as a loss-prevention mechanism for local email-folders, and as a safety-net for laptop-users who need to store files locally when roving, this script copies the local data from a logged-on workstation or laptop to a server-share in a manner which is largely transparent to the user, and has minimal effect on the usability of the machine whilst the backup is in progress. My first major v3 project, so apologies for any rough edges...

On this subject, does anyone know how to determine the ownership of a file on NTFS from within a script? Just thinking that if so it would be possible to make an inventory of which users have large amounts of certain filetypes. I feel that when dealing with this kind of problem it's politically-better to identify "whodunnit" and make them clean their mess up. Besides, wholesale deletion carries too much risk of deleting something important.

Actually, the feedback I get from users is that the MS Calculator suffers from a serious bug. Most users seem to prefer a hardware-calculator for that reason. Basically, after doing one calculation on the MS product, you MUST explicitly Clear it before using it again. If you don't, your next answer is affected by the previous one, even though Enter (=) was pressed. You don't have to do this on a typical desktop calculator, and it makes the MS calc awkward and error-prone. I think this comes about because MS thought it would be 'clever' to make Enter repeat the last calculation as a timesaver, and didn't think the effects of this through properly. Glad to see this one doesn't suffer that problem.

A while since I've used Netware, but I seem to recall that I usually migrated server disks by xcopying, and then running a little utility that backed-up the security info on the source disk. It created a batch-file which, if run on the destination disk, put the security-info back. Can't remember its name, but it should be on the Novell site I should think. Might be of help here, anyway.

A few tips I thought might help: The way Windows Networking operates, once a username/password has been supplied for a particular server or domain, it need not be supplied again in subsequent NET USE commands. Thus, if you connect to one share (netlogon seems sensible) from within an autoit script (which hides the password) your others can be in a standard batch-file which is Run from the script. This is easier to maintain than modifying the script for each change of drive-mapping. So, doing it this way you just need a simple script that takes-in a password (and optionally a username if different from the local one) makes a single connection to the server, checks the error-flag to see it's successful, then launches the batch-file. BTW, On NT/2k/XP-based systems, shares are permanent by default, and this can lead to a serious security problem if not dealt-with. (Trust Micrsosoft ) Therefore it's highly advisable to start the whole process with the commands: NET USE * /DELETE /YES and NET USE /PERSISTENT:NO either called by RunWait statements, or by equivalent Autoit DriveMap commands. Hope this helps, Ian.

Yes, looking at your source gave me a few pointers for someting I'm working on, thanks. BTW, you can disable Task Manager (and most of the other Ctrl-Alt-Del panel options, such as Change Password) by way of registry keys: (examples in v2 syntax) RegWrite,REG_DWORD,HKEY_CURRENT_USER,Software\\Microsoft\\Windows\\CurrentVersion \\Policies\\System,DisableTaskMgr,1 RegWrite,REG_DWORD,HKEY_CURRENT_USER,Software\\Microsoft\\Windows\\CurrentVersion \\Policies\\System,DisableChangePassword,1 This results in the relevant button being greyed, and is probably a safer approach than renaming the file. Hope this helps.

It is how most dialects of Basic work (with the exception of the excellent RapidQ) though not how most "modern" languages work. Having developed some large-ish programs with MS Basic, lack of a proper inheritance-mechanism in that venerable IDE meant that you had a choice of either: 1. To write your routines as one long, inseparable block of code. Main problem here arises with sections which are only executed conditionally - you may end-up with, for example, an IF statement spanning hundreds of lines of code. This is extremely error-prone and almost impossible to indent/debug. 2. To divide your program into more manageable sections, and to pass the 'environment' varibles to each subsection of the code so each section 'knows what's going on in the big picture.' In practice the subprogram probably doesn't need the entire 'working environment' so you might be able to restrict the number of parameters to those which it actually needs. Issue with this approach is that the amount of donkey-work (and the opportunity for mistakes) grows exponentially with the complexity of the program. This is because in order to add just one parameter to your subprogram's "environment" you need to modify not just its own header, but also the parameters of every single call to that subprogram, even those calls which are in other 'included' files. This soon gets to be even more 'out-of-hand' than writing as one solid block. 3. Use Gosub instead, and accept that no variables are ever local. Purists will be aghast at this suggestion, but provided you maintain a rigorous variable-naming convention (which you should anyway)... it works perfectly. Basically, the answers are either an inheritance-mechanism, or user-defined data-types, so the program's 'environment' can be easily passed to subprogams as a single 'object' whose properties can be modifed without having to re-write every call to the subprogram. Just my ten cent's worth, anyway, not to be taken as a criticism but rather a constructive observation. Ian.