in
Support Center

Why memory resident and systray

Last post 05-16-2008 7:42 PM by spm. 9 replies.
Page 1 of 1 (10 items)
Sort Posts: Previous Next
  • 02-25-2008 11:57 AM

    • Uphoff
    • Top 150 Contributor
    • Joined on 02-25-2008
    • Netherlands
    • Posts 7

    Why memory resident and systray

    I am evaluating SP now and am impressed with both (desktop and IT) versions. Fast, reliable and the HIR is Top of The Bill!

    However... there is allways something to wish:

    1: Resize image to SMALLER partitions (once again a request for this VERY usefull option)
    2: Option for no icon in systray. I am thinking of using SP for auto imaging of the computers in our company networks, but the possibility for end users to fiddle with SP just by clicking on that tray-icon keeps me from actually implementing this. Maybe a password protected icon, or another way to avoid tinkering or even theft (end-users making images and take those out of the office...).
    3: Don't like those files in memory all the time, that's is just a unneeded waste of around 20MB ram. A small executable for the scheduler (that starts the other services when needed and unloads them after the job is don) is more mature. Or, maybe even better: Make it possible to launch SP with windows task scheduler. A few simple modifications/additions are needed: SP launces the services when SP is started (it allready does), makes the default image, shuts down the services and closes itself.

    M. Uphoff

  • 02-25-2008 12:48 PM In reply to

    Re: Why memory resident and systray

    A1) This feature is on our roadmap.

    A2) You can deploy ShadowProtect to a machine using a custom installation which omits the GUI itself. All of the work is done by the ShadowProtectSvc.exe NT service so the GUI itself is not actually needed.  You can then remotely manage many installations (which do not have GUIs installed) from one machine on which the GUI is installed.

    A3) Very little, if any, physical RAM, is consumed by an idle process.  The pages of virtual memory used by an idle process are paged out to the pagefile on the disk.  When the ShadowProtect NT service is not performing a backup operation it is using virtually no CPU cycles or pages of physical memory.

    Thank you for your thoughts and suggestions.
     

  • 02-25-2008 3:07 PM In reply to

    • Uphoff
    • Top 150 Contributor
    • Joined on 02-25-2008
    • Netherlands
    • Posts 7

    Re: Why memory resident and systray

    Nate,

    Thank you for your response.

    I do understand that it is very conveinient to remotely manage many computers, but that is not allways possible (we allso have many small networks all over the country). So I would like to automate the imaging without giving the end users a chance to destroy things.

     That's why I just looked at the scripting possibilities. I have te following in mind:

    - The services set to manual (they will auto launch when needed)
    - launch a VB script that creates the image on a nas
    - unload the services
    - place the script in a scheduled task

    I took you sample script (here are the last nine lines of 'your' BackupManyToNet.vbs):

    StdOut.Write "Let's test ShadowProtect.FindObject()..." & vbCrLf
    StdOut.Write "I will try to find latest Job with ID " & ShadowProtect.FindObject(Job.Id).Id & vbCrLf
    StdOut.Write "OK." & vbCrLf & vbCrLf

    StdOut.Write "Let's start job as full"& vbCrLf
    Job.Execute 3
    StdOut.Write "OK." & vbCrLf & vbCrLf

    StdOut.Write "Let's test ShadowProtect.RemoveAllJobs..." & vbCrLf
    ShadowProtect.RemoveAllJobs
    StdOut.Write "OK." & vbCrLf & vbCrLf

    The script runs fine until it reaches Job.Execute 3   (BTW What does that 3 mean? No documentation about it).

    Here are the last lines of the output:

    Let's add trigger to start tomorrow at current time
    Let's test ShadowProtect.FindObject()...
    I will try to find latest Job with ID {1F5F3A65-0DBF-4018-AF37-6529B1EC8273}
    OK.

    Let's start job as full
    D:\Temp\BackupManyToNet.vbs(38, 1): Runtime Error Microsoft VB Script: Invalid procedure-call or argument

    Everything runs nicely until the execution of that job..
    Alas, I am not even a beginner in VBS, so could you give me a clue?

    Thanks in advance,

    M. Uphoff

    Filed under:
  • 02-25-2008 4:47 PM In reply to

    Re: Why memory resident and systray

    Providing support for scripting is so expensive (it always ends up turning into a custom development task) that we simply don't do this for any but the largest customers.  As a "beginner in VBS" you can see that there would likely be an enormous amount of support that you would need, custom developer support, from engineers at StorageCraft, to help you to develop the scripts that you're interested in writing.  That level of support is way beyond the type of support which we normally provide for our products.  We do our best to be responsive to questions, and to resolve reported issues, but we frankly don't have the resources to help users to write and diagnose custom scripts.

    On that note, let me give you some advice.  When running these scripts, you cannot simply execute them from the command line link this:

    C:\> BackupManyToNet.vbs

    But instead you need to execute them like this:

    C:\> cscript BackupManyToNet.vbs

     


     

  • 02-26-2008 10:00 AM In reply to

    • Uphoff
    • Top 150 Contributor
    • Joined on 02-25-2008
    • Netherlands
    • Posts 7

    Re: Why memory resident and systray

    Nate,

    >> cscript BackupManyToNet.vbs <<

    That little I do know of VBS, so that's the way I started the script.

    As you can see, the script runs normal, the output is as expected, except for that job.execute 3 statement.

    As far as I can see it is a general problem in all the sample scripts (every part of ecery script you provided runs fine, exept mentioned statement).

    It must be something simple I think.

     

  • 02-26-2008 10:09 AM In reply to

    Re: Why memory resident and systray

    I'd like to help you, but I can't.  I'm sorry.  :(
  • 05-15-2008 11:48 AM In reply to

    • spm
    • Top 500 Contributor
    • Joined on 05-15-2008
    • Posts 2

    Re: Why memory resident and systray

    I represent a UK-based IT Consultancy, and regularly implement imaging backup solutions for our small business clients. I order that we could properly evaluate ShadowProtect Desktop, I recently purchased a ShadowProtect Desktop licence based on its claimed scripting ability, and on a set of example scripts StorageCraft sent me, only to find none of the scripts actually work. Like Uphoff I see that the Job.Execute command always fails. I have e-mailed StorageCraft on multiple occasions, and they have steadfastly refused to even respond. For StorageCraft to simply say here they cannot provide 'consultancy' just doesn't cut it. No 'consultancy' has been asked for, simply a note on how to make Job.Execute work in their example scripts work.

    Right now I am looking to arrange for a credit card chargeback against StorageCraft, and a recommendation to all of our clients they stay well clear of StorageCraft products. Unless, that is, StorageCraft resolve this situation within the next 24 hours...

  • 05-16-2008 4:31 AM In reply to

    Re: Why memory resident and systray

    Uphoff:
    The script runs fine until it reaches Job.Execute 3
     

    In this script one line is missing. The destination object which is used as a part of the job is not saved after its creation.

    You should insert the following line after you finish setting DO properties:

    Set DestObj = ShadowProtect.NewDestinationObject(4)
    DestObj.Path = "\\MyServer\backups\"
    DestObj.UserName = "DOMAIN\Administrator"
    DestObj.Password = "1111"
    DestObj.Save

     

    Uphoff:
    (BTW What does that 3 mean? No documentation about it).

    3 means to execute a full backup.
     

     
     

  • 05-16-2008 9:26 AM In reply to

    Re: Why memory resident and systray

     

    Nate, I understand that StorageCraft can’t provide debug support for users who author their own ShadowProtect scripts. Nonetheless, has StorageCraft authored documentation on the script capabilities of ShadowProtect for users who wish to do so? If not, do you have a sense of when StorageCraft will be able to create and distribute script documentation?
    Filed under:
  • 05-16-2008 7:42 PM In reply to

    • spm
    • Top 500 Contributor
    • Joined on 05-15-2008
    • Posts 2

    Re: Why memory resident and systray

     OK, the DestObj.Save call does allow Job.Execute calls to succeed. Thanks for that. However, I am finding the few sample scripts and little accompanying documentation that StorageCraft provided to be somewhat lacking. For one thing, the documentation details a few parameters by name, but fails to give many of their numeric values (which are needed in the scripts). Also, there appears to be no way (or no sample showing a way) to start a job a synchronously (i.e. for the script to regain control only when the job finishes), or to monitor a running job, so as to find out when it finishes. All this makes me believe scripting is not a viable proposition at all.

    It's no wonder StorageCraft find they would need to spend a lot of time supporting customers who want to script the product. If you simply provided a useful document (a few well written pages would no doubt suffice), the problem would be solved. Sigh.

Page 1 of 1 (10 items)
(c) StorageCraft Technology Corporation 2008