|
|
|
Backing Up Business Data |
|
Thursday, June 28, 2007 |
More accurately, "small" business data. Below you will find what I believe is an ideal solution for small business owners who need to secure their valuable data off-site. 1. Get a Good Flash KeyPreferably a key manufactured by PQI or Corsair. You will finda variety at Newegg.com under Computer Hardware » Flash Memory and Readers » USB Flash Drives. The 2GB PQI Model BB53-2031R0111 is a good choice for small business needs at only $26 delivered to your door, but look for the 4GB model if available. This series caps securely, includes a handy lanyard, and looks as good as your business. You will pay a premium but it may be worth it if you feel the need for extreme speed: Corsair's Flash Voyager "GT" key series provides 34MB/s read and 27MB/s write times. Very impressive indeed. 
2. Use Robocopy as Your WorkhorseYou will find that most of your data does not change and therefore does not need to be backed up repeatedly. Only newly created or altered files need to be copied after the initial backup job has been performed. Enter Robocopy, a robust command line utility that compares files during copy operations. By default, Robocopy will only perform a copy operation if the source and destination files have different time stamps or different sizes. That means no redundancy, no wasted time. Beautiful. 3. Create a Custom Autorun.inf FileAutorun functionality is disabled by default for USB devices. Therefore, you cannot fire up a routine—in our case, the backup operation—just by plugging in the key. You can, however, add a custom entry to the autoplay dialog box by including the parameter "action" in an autorun.inf file. Adding a custom icon is a nice touch. 
autorun.inf
[autorun]
icon=.\backupjob\TOOLS\icon.ico
open=.\backupjob\backupjob.exe
action=Click “OK” to run the Backup Operation!
4. Write the Backup Script
Now this is where things get interesting. Well, interesting if you appreciate a technical challenge. Got Geek? Then ask yourself, how can we reliably copy mission-critical data from one or more sources to the flash key and verify same? Some issues to consider:
The flash key drive letter assignment is subject to change. Today it is the F: drive but tomorrow it might be the G: drive depending on your configuration.
Pretend we are in a simple network environment. It would be nice to back up valued data from multiple machines in one simple operation.
If a document is open and unnoticed when the backup job commences, will the entire backup operation fail?
It's best to shut down the PC following the backup operation and then remove the key. Just pulling the key is probably fine for Joe-Home-User on a Windows XP box but is foolish when your business data is on the line. We also know that the "Safely Remove Hardware" feature is not always responsive.
Taking into account these and other considerations, here's the script:
backupjob.au3
If _Singleton('test\test',1) =
0 Then Exit;prevent multiple scripts from running
#include ‹TOOLS\AU3includes\Constants.au3›
#include ‹TOOLS\AU3includes\Misc.au3›
TraySetIcon( @ScriptDir
& '\TOOLS\icon.ico')
TraySetToolTip('Backup operation is running . . . ')
$usb = DriveGetDrive("REMOVABLE")
If Not @error Then
;MsgBox(4096, "",
"Found " & $usb[0] & "
drives") ;‹-- uncomment to verify
For $i = 1 To $usb[0]
If DriveGetLabel($usb[$i]) = "PQI_4GB"
Then
Global
$TargetDrive1 = $usb[$i];‹==
set flash key drive letter assignment
EndIf
Next
EndIf
Global $MyDir = '\DIRECTORY_ONE_BACKUP'
Global $MyDocs = '\DIRECTORY_TWO_BACKUP'
DirCreate($TargetDrive1 &
'\DIRECTORY_ONE_BACKUP')
DirCreate($TargetDrive1 &
'\DIRECTORY_TWO_BACKUP')
If MsgBox(4, 'Backup Operation', 'Has the Client PC
been turned off?') = 7 Then
MsgBox(16, 'Backup
Operation', 'Please turn off the Client PC before performing _
the Backup Operation!', 5)
Exit
Else
Backup();perform the backup operation
MsgBox(0, 'Backup Operation',
'The Backup Operation completed successfully!')
If MsgBox(4, 'Backup Operation', 'Do you want to shut down the Server
and _
remove the Flash Key?') = 6 Then
Shutdown(9)
Exit
Else
Exit
EndIf
EndIf
Func Backup()
FileDelete( $TargetDrive1
& '\*.log');delete old log files
TrayTip('Backup Operation',
'Backup Operation in progress . . . ', 0, 1)
TraySetState (4)
TraySetToolTip('Backup
Operation in progress . . . ')
Dim $prog = @ScriptDir & '\TOOLS\robocopy.exe'
Dim $source1 = 'C:\Directory One';specify
directory here
Dim $source2 = 'D:\Directory Two';specify
directory here
Dim $dest1 = ($TargetDrive1 & $MyDir)
Dim $dest2 = ($TargetDrive1 & $MyDocs)
Dim $what = '/V /E /COPYALL /B'
Dim $options = '/R:3 /W:3'
Dim $log = ('/LOG+:' & $TargetDrive1 & '_Logfile.log')
RunWait($prog
& ' "' & $source1 & '" "' & $dest1 & '"
' & $what & ' ' & $options & ' ' & $log, '', @SW_HIDE)
RunWait($prog
& ' "' & $source2 & '" "' & $dest2 & '"
' & $what & ' ' & $options & ' ' & $log, '', @SW_HIDE)
TrayTip('','',0)
TraySetState (8)
TraySetToolTip('Backup job is
running . . . ')
EndFunc 5. Put It Together Go ahead and format the key, giving it a name. In the example above, I have formatted my key as "PQI_4GB." You will need to place the autorun.inf file on the key together with a directory called "backup," which contains additional directories and files including:
A directory called "backupjob," which houses the above script in compiled form.
A directory called "TOOLS" located inside "backupjob." It holds the icon.ico file and robocopy.exe. Different Robocopy versions exist; I use the 85KB version pulled from Vista's System32 directory. The 78KB version included with the Windows Server 2003 Resource Kit also works well.
A directory called "AU3includes" located inside "TOOLS." It contains the constants.au3 and misc.au3 include files copied from the AutoIt program files directory.
So if you can put six files on a flash key, you have yourself a kickin' backup solution. Hey, it's not supposed to be easy. If it was, everyone would do it. 6. What it Does More soon . . .ZonaNet |
posted by
ZonaNet
@
6:53 AM
 |
|
|
|
|
Running WPI |
|
Wednesday, June 27, 2007 |
It became apparent that WPI would be useful not only during a full unattended Windows XP installation but also as a stand-alone application to selectively install programs on a pre-configured machine. As a stand-alone app, it would need to start automatically when inserted into the CD-ROM drive. The problem, however, is that standard autorun functionality supports executable files only and not others such as .cmd or .hta.
Enter TARMA SOFTWARE RESEARCH, the creators of AutoRun, a freeware application that supports multiple file types. Placing Tarma's AutoRun executable at the root of the CD togther with a custom .inf file calls WPI when the CD is inserted: AUTORUN.INF:
AUTORUN.INF:
[autorun]open=autorun.exe -q2 -w -x wpi\WPI.hta
cleanup.exeicon=wpi.ico
AutoRun's versatility extends beyond simple .inf installs. For example, it can be called from the hard drive to run, in turn, the WPI .hta, batch files, and compiled AutoIt scripts. My hard drive install routine runs WPI and then performs a cleanup operation before allowing me to alter the machine name and workgroup information. Once uniquely named, the CD is ejected and the machine reboots. The routine is a tad convoluted, like so:
A WinRAR SFX called Run_WPI.exe is placed in the $OEM$ Startup directory and copied over to the hard drive during the OEM install with the following comment:
Path=%windir%\
TempSetup=RunWPI.exe
Silent=1Overwrite=1
Title=Extracting
files...
Run_WPI.exe holds the files AutoRun.exe, RunWPI.exe, and RunWPI.cmd. It is sparked upon first boot and fires up a compiled AutoIt script from the Temp directory called RunWPI.exe. RunWPI.exe hides completely a batch file that, together with Tarma's AutoRun, performs the actual install:
RunWPI.au3:
AutoItSetOption("TrayIconHide",
1)
AutoItSetOption("WinTitleMatchMode", 4)
BlockInput(1)
SplashTextOn("", "" & @CRLF & "Preparing
post-installation..." & @CRLF & "" & @CRLF & "Please wait..."
& @CRLF & "", 320, 90, -1, -1, 1, "Arial", 12,
12)
Sleep(3000)SplashOff()
Run("RunWPI.cmd", "", @SW_HIDE)
Exit
RunWPI.cmd:
@echo off
::Locate the CDROM drive if necessary,
where AUTORUN.INF exists at the root...FOR %%d IN (c: d: e: f: g: h: i: j: k: l:
m: n: o: p: q: r: s: t: u: v: w: x: y: z:) DO IF EXIST %%d\AUTORUN.INF SET
CDROM=%%d
::Run WPI...autorun.exe -q2 -w -x %cdrom%\wpi\WPI.hta
%cdrom%\cleanup.exe %cdrom%\rename.exe
%cdrom%\restart.exe
CLS
EXIT
The following files are placed at the root of the CD to perform post-WPI
operations:
A compiled Cleanup.au3 AutoIt
script:
AutoItSetOption("TrayIconHide",
1)
AutoItSetOption("WinTitleMatchMode", 4)
BlockInput(1)
Run(
@ScriptDir & "\cleanup.cmd", "", @SW_HIDE)
Exit
A corresponding Cleanup.cmd batch file:
@echo off
RD /S /Q "%systemdrive%\Drivers"
ECHO Y Del
"%systemdrive%\WINDOWS\*.bmp"
ECHO Del "%systemdrive%\*.log"
DEL
/F "%systemdrive%\Documents and Settings\All Users\Start
Menu\Programs\Startup\Run_WPI.exe"
@Rmdir %systemdrive%\TEMP /s/q
@mkdir
%systemdrive%\TEMP
@Rmdir %systemdrive%\WINDOWS\TEMP /s/q
@mkdir
%systemdrive%\WINDOWS\TEMP
CLS
EXIT
A compiled Rename.au3 AutoIt script:
AutoItSetOption("TrayIconHide",
1)
AutoItSetOption("WinTitleMatchMode",
4)
BlockInput(1)
Send("#r")
WinWaitActive
("Run")
Send("sysdm.cpl{Enter}")
WinWaitActive("System
Properties")
Send("{TAB 3}")
Send("{RIGHT
1}")
Send("!c")
Send("{BACKSPACE}")
BlockInput(0)
MsgBox(0, "Rename
PC", "Please rename this machine.")
WinWaitActive("Computer Name Changes",
"You must restart this
computer")
BlockInput(1)
Send("{ENTER}")
WinWaitActive("System
Properties")
Send("{ENTER}")
WinWaitActive("System Settings
Change")
Send("!n")
Exit
The author chose to call batch files from AutoIt scripts to hide their activity instead of using the "cmdow @ /HID" convention. Although useful, cmdow.exe nonetheless produces a command window momentarily, whereas AutoIt's "@SW_HIDE" parameter flag hides the window completely.Labels: Others |
| posted by
ZonaNet
@
1:57 PM
|
|
|
|
|
IP.Board 2.3.1 and IP.Converge 1.0.0 RC 1 Released |
|
Tuesday, June 26, 2007 |
We are pleased to announce the release of IP.Board 2.3.1 and IP.Converge 1.0.0 RC 1
IP.Board 2.3.1
This release fixes some bugs reported in the 2.3.0 release and includes a command-line post rebuild script for larger boards. As with any new release please be patient for upgrade requests as our staff works through the queue. An upgrade pack from 2.3.0 to 2.3.1 with only changed files is available in the client area for easier upgrading.
IP.Converge 1.0.0 RC 1
IP.Converge is our system which allows you to link multiple IPS products allowing them to use one central login authentication system. Power users can also write their own authentication modules to allow for single sign on across other applications. This is the first public release candidate for IP.Converge. As a release candidate, we will not be able to provide technical support. Please submit any bugs you may find to our bug tracker. IP.Converge requires IP.Board 2.3.1 to function.
Getting Started Guide
For our new or novice users, a getting started guide has been added to our documentation page. This guide provides a quick overview on setting up an example board on a new installation. Our full documentation and developer documentation has also been updated.
This diff report is provided for power users who wish to manually patch files:
Bugs Fixed^_^ enjoy it......ZonaNet
Labels: Web Development |
| posted by
ZonaNet
@
2:34 PM
|
|
|
|
|
|
