Jump to content
bytesmith

Backup Jobs Don't Run Unless Logged in and Retrospect is Started

Recommended Posts

We have a couple of clients complaining that Retrospect will only run on their 2008 and 2012-R2 Windows servers if retrospect user is logged onto the server and the Retrospect program is open.

 

I have validated this, but I can’t find any support articles to help resolve the problem. Furthermore, unless I'm reading things incorrectly the Retrospect 10 documentation seems to elude that this is an issue.

 

Retrospect is scheduled to run a number of backup jobs overnight. If the backup user is not logged and Retrospect program is not open, as soon as user logs in and starts Retrospect, the jobs begin to run. This is not good because backup jobs starting at unscheduled times can cause huge issues with resources, etc...

 

A really big problem for one client -- when Retrospect propgram is left running on their server, it consumes all the server memory ultimately reducing the value of their server.

 

Agressively looking for a solution to this big problem...

 

 

 

  • Like 3

Share this post


Link to post
Share on other sites

Retrospect does not run conitnuously as a service, but runs on demand as a normal program.

There is a Retrospect Launcher service that is responsible for monitoring the schedules and starting Retrospect when required. This service SHOULD be running all the time.

Check that the Launcher service is running, if it is not the scheduled executions will not start until Retrospect is started manually, as you have described.

There are also settings in the Configuration section to control what Retrospect does when scheduled executions start and when has finished all it's scheduled executions, stay running, shut down etc. You may want to adjust these to suit your situation.

It is possible to have executions run without actually starting the Retrospect interface, whihc may create the impression that nothing is happening.

Check your Services and Tasks (remember to select all users) to see what Retrospect is doing under the hood.

Share this post


Link to post
Share on other sites

Thanks for your comments JoTraGo.

 

I've been communicating directly with Retrospect support on this issue. The bottom line is that in Server 2008 and later, Retrospect will not Auto Launch jobs unless a user is logged in and Retrospect is started, or UAC is disabled on the server. We have validated this behavior on Windows Server 2008 through Server 2012 R2.

 

Unfortunately, this model is outside proper server security practices. I've requested that Retrospect development team prioritize an update to resolve this issue.

Share this post


Link to post
Share on other sites

I also have this issue with one of my client's systems. The trouble is, I had gotten it working after some effort on a Windows Server 2008 9.5 system, and lost it when I upgraded to 10.5.  I had some notes, but apparently not enough, so I'm back to testing and experimenting.  If I come up with a solution that works I'll post it here and make plenty of notes.

 

I also cast my vote for Retrospect programmers permanently fixing this at the earliest opportunity.  As a competitive issue, it's impossible to look an experienced in-house admin in the eye and tell them it's impossible to automatically launch a defined backup job if the program isn't already running.

 

I can't say things like that without blushing, and I have too many gray hairs to pull off an innocent neophyte act.

Share this post


Link to post
Share on other sites

Good Morning,

 

 

I finally have a solution for this, and it does work. It is probably outside security standards for some environments, so be cautious about where you install this.

 

My scenario is a network with a Windows 7 Pro system running the Retrospect administration program, backing up other systems on the network. The normal user on the host is a domain user, not a domain administrator.

 

The key to the whole thing is creating a runas command with the /savecred flag.

 

If you don't have a domain, but rather are on a workgroup, you'll need to enable the user named Administrator, which exists but is disabled by default. Follow these steps:

 

  • Using "Run as administrator", launch a command prompt.
  • To enable the user named "Administrator", at the command line, type and enter this:
    • net user administrator /active:yes
  • If that command completes successfully, close the command window. If it doesn't complete, you're probably not running the command window with the "Run as Administrator".
  • In Control Panel | Users, assign a password to the Administrator.

 

For all systems, do this:

On the desktop, right-click to open the context menu and create a new shortcut.

 

In the shortcut box, enter one of the following:

 

1a. If you have a domain:

runas /user:Administrator@Domain /savecred "C:\Program Files\Retrospect\Retrospect 11.0\Retrospect.exe"

 

(Adjust the administrator name, domain and path to match your system requirements.)

 

1b. If you don't have a domain, but are in a workgroup:

 

runas /user:SystemName\Administrator /savecred "C:\Program Files\Retrospect\Retrospect 11.0\Retrospect.exe"

 

(The PC name is the first variable for the /user.)

 

Click Next and finish creating the shortcut.

 

 

2. Now double-click the shortcut and you will be prompted for the password for the above user.  The system will save that password (I suspect in the registry) and supply it in the future when that shortcut launches, without a UAC prompt.

 

Retrospect should launch and run normally as soon as you enter the password.

 

 

3. On the shortcut you created, change it to run minimized if you want. Change the icon to the Retrospect icon if you can find one. I had to make one since there are no *.ico files that Retrospect supplies.

 

 

4. Double-click your desktop shortcut again to test it, then minimize the program so it continues to run.

 

 

5. Drag the shortcut to the user's Start-up folder. Now when the PC reboots and the user logs in Retrospect will start minimized, logged in as the user you provided in the command line above, and the scheduled Retrospect jobs will launch as desired.

 

 

I frankly don't think this is any more dangerous than manually launching Retrospect as an Administrator and leaving it open and running on the taskbar. It's certainly not as secure as having it launch from a service.

 

This will apparently not run on any of the lesser versions of Windows, such as Windows 7 Home.  Only use Professional.  Always test it extensively to make sure it's working as you expect.

Share this post


Link to post
Share on other sites

Thank you all for your help and replies.

 

For my money, I am still toying with running the Mac server, because as far as I can tell, it is 100% of the functionality. (almost: no disaster recovery CD creation, but I already did that with the evan retro)

 

For launching retro on Windows while running, going to the "dashboard", and hitting "re-launch". It's not elegant, but it works reliably.

 

I have also confirmed that if I quit the GUI, despite claims that activity will "stop", my scripts run.

 

I **think** I have a working installation that I understand. ;->

Share this post


Link to post
Share on other sites

I have also confirmed that if I quit the GUI, despite claims that activity will "stop", my scripts run.

 

 

 

It is the currently running activities that will stop. Scripts that are scheduled to run later will start (and run) later.

Share this post


Link to post
Share on other sites

Yes. That is what I see. However, unlike the Mac, the currently running scripts get killed and restarted. On the Mac, the executions continue without interruption.

Share this post


Link to post
Share on other sites

For the record, iCompute began another thread on his problem (whose description starts in post #7 in this thread) on the "Windows Products—Professional" forum.  My explanation for what he is seeing is at the beginning of the third paragraph in post #10 of that thread.  The best description of how to get around the problem is in iCompute's own post #15 in that thread, although it is prefigured slightly less clearly (at least for non-Retrospect-Windows administrators like me) in the second paragraph of ProFromGrover's post #11 in that thread.  My clarification for Retrospect Windows administrators of why iCompute would not have previously encountered the same problem in Retrospect Mac is in the third and fourth paragraphs of post #18 in that thread

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×