Ghost Solution Suite

Is there a way I can use a custom Robocopy batch file (that we use here quite frequently) to backup a machine prior to "clonong" it?

I know I can use the user migration tools, but I cannot get them to work, I would just like to use these commands to backup a machine, I only need the files from the current user who is logged into the machine backed-up, I do not need any other profile backed up.

Here are the commands I normally use, of course I still have to manually kick this off, but my question is, can I include this as a task on a machine that has the Symantec Ghost client installed?

Robocopy "C:\Documents and Settings\%username%\Application Data\Microsoft\Outlook" "\\BACKUPSERVER\BACKUPSERVERSHARE\%username%\Application Data" /E /Z /R:0 /W:5 

Robocopy "C:\Documents and Settings\%username%\Desktop" "\\BACKUPSERVER\BACKUPSERVERSHARE\%username%\Desktop" /E /Z /R:0 /W:5 

Robocopy "C:\Documents and Settings\%username%\Favorites" "\\BACKUPSERVER\BACKUPSERVERSHARE\%username%\Favorites" /E /Z /R:0 /W:5 

Robocopy "C:\Documents and Settings\%username%\Local Settings\Application Data\Microsoft\Outlook" "\\BACKUPSERVER\BACKUPSERVERSHARE\%username%\Local Settings" /XF outlook.ost /E /Z /R:0 /W:5 

Robocopy "C:\Documents and Settings\%username%\My Documents" "\\BACKUPSERVER\BACKUPSERVERSHARE\%username%\My Documents" /E /Z /R:0 /W:5

Are you "hot imaging" ?

Robocopy, although a command line program, does not work under DOS AFAIK, so if you want to backup the current user profile, you need to run the Robocopy task in the context of the current user.  My suggestion would be to run this from the logon script.

By the way - why do you have /W set to 5 when you have /R set to 0 ?  There is no point waiting 5 seconds if you are not going to retry.....

Could I add those exact paths into the "files and folders" area inside a "Backup Task"? I have tried but it does not seem to be working, again, I only need the current logged in users backed-up.

Foe example, if I add this path - "C:\Documents and Settings\%username%\Application Data\Microsoft\Outlook" will I need the quotes? Will Ghost recognize the % symbol?

If I could get the backup and restore tasks to work without the need of any Robocopy script then all the better.

I see that you have a batch file with Robocopy commands .Run the batch file on a machine locally to check the results.

If everythig OK , go ahead and use the Console Software and File Actions task to transfer the batch file to the client machine and execute the  same ,

Under Software and File Actions ,choose Transfer Files and Folders to transfer the batch file to any location on the client .

In the same task add Execute task under Software and File Actions to run the batch file

See how this works .You could also include a delay between Transfer Files and Folders & Execute actions

Also you could have the batch file on a network share and run the same using Execute task .

I got it to transfer and run, however it looks like it's running but it's not working, is there a trick to run a batch file remotely like that?

If I take the same file and click on it myself on the same computer it will run just fine.

Execute task will just run the command but will not report the outcome.

Run a single command without using batch file using execute command and check the result.

When you run the batch file manually, it is run in the context of the logged in user.

However, what context is the Ghost task executed in?  If it is using a service account, chances are that the service account does not have access to the network URL that is the destination for the Robocopy operation.

As a diagnostic measure, pipe the output of the Robocopy operations to a text file on the local hard disk - ie add  > c:\temp\log1.txt  to the end of the robocopy command string. (Amend the path and logfilename as required).

Then examine the logs and see whether there are any error messages recorded.

OK, I added the > c:\temp\log1.txt at the end of each line and ran the batch file manually first to test and it worked dropping a log file in the c:\temp folder as expected. So I then had Ghost do it and as usual it looks like its running but it goes to fast so I know its not working, when I went to look for the log file, it was not there? Strange. It doesnt create the log file when it runs it?

If no logfile is created then perhaps the batch file is not running at all. Put a PAUSE statement into the batch file and see if the code halts as expected. If there is no pause implemented then the batch file is not running at all. If that proves to be the case, then check that you are giving full path information to the batch file, which ideally should be local on the hard disk.

The batch file runs fine and always has for years, it's not the batch file, I'm thinking it's running under another account that could be causing issues? I don't think this is unexpected behavior, the only way I have been able to really run a file like that remotely is using a tool like PSEXEC.

I put a PAUSE in the file and it is running, but it's taking out the %USERNAME% in each of the commands, so instead of this: C:\Documents and Settings\%username%\Application Data\Microsoft\Outlook

You see this: C:\Documents and Settings\\Application Data\Microsoft\Outlook

It does indeed look as if your batch file is running under another account, as clearly the username is not being resolved.

Although what I am about to suggest is not as efficient, it does offer a solution that is not user specific.

Just use a single robocopy command to backup c:\Documents and Settings\  and add a few XF and XD commands to exclude profile files (eg ntuser.*) and directories that are not required (eg nethood). This ensures that all user profiles are backed up - which may be relevant if a machine has more than one regular user.

Per the title, all commands run by GSS console tasks run as LocalSystem by design, as there's basically no other way they *could* work unless we started shipping login credentials around.

For shipping credentials around, to do that properly (using actual security, not fake security such as storing obfuscated domain credentials in unattend.xml files) requires an inversion of the security relationship built into GSS. When I originally designed it, I was quite explicit that a client being managed is a one-way trust relationship; the client trusts the management server (to give it code to run, etc) but that does not work the other way around - from the management server, securely identifying and authenticating a client needed more work, and most especially more UI work, and without the ability to do that authentication then the server couldn't trust the client. This is because credential sets are security-critical items, and you can't just give them out to anybody; you need to be able to authenticate the places you send them to, not just encrypt them in transit.

Now, when designing the authentication systems in GSS in 1998 I chose ElGamal certs with the intention of adding a half-certified Diffie-Hellman for connection privacy (also, the RSA patent hadn't yet expired); however, it wasn't until around a decade later after GSS 2.5 that it was possible to get approval to work on that, and so one of the bits of feature work for GSS3.0 I did was add the key exchange and start to work towards that. However, there was a lot to be done; UI for the trust relationships in the console to have the clients securely authenticated was needed, and only after that existed would it make sense to attach items like credential sets to tasks and let them be used inside tasks, and we hadn't gone through the design of that fully before the product was cancelled anyway.