Retrospect Server user must remain logged in? HUH?

[tjyoung]

We are pretty new to retrospect, but in testing the setup for our eventual deployment we have come to the realization that Retrospect must remain running as a loggged in user in order to run it's jobs. Can this be correct? If it is this seems like a very large security hole to us.

 

It seems that when the user loggs off that Retrospect must shutdown. Why can't Retrospect run as a service in the background when the user loggs off?

 

Am I correct here, or did I miss a setting?

[Mayoff]

If Retrospect is closed and you logoff, Retrospect will autolaunch and run at the scheduled time. You can also setup password options to "lock Retrospect" so user's can't access it during a backup.

 

You can also use a password protected screen saver to lock the screen.

 

Running as a service is a high priority for the feature list

[tjyoung]

But this is not my experience. When I shut down Retrospect the proactive backups do not run. Is that correct? It even warns me upon shutdown that proactive backups are being stopped.

[Mayoff]

Proactive backup should start again within 1 hour of being closed. We did make a bug fix to proactive backup autolaunch in 7.5 with the latest RDU.

[JohnJ]

We are new Retrospect users too (about 6 months now). What we are seeing is that, about half the time, the Proactive backups do not autolaunch after a previous logoff and we have not found any common reason for why they do or don't. It seems like the autolaunch happens eventually but it could be up to a day later than expected and there have a few occasions that required a manual start. We agree with Thomas that it would be far more preferable to have it run as a service.

[tjyoung]

Yes, it looks like they do start again after 1 hour, but still the console is logged in by Retorspect. Would much rather have it running as a service for standard security practices. Thanks for your help.

[bilbus]

it auto launches into terminal server .... still a god awful way of doing things.

[ZippySLC]

Same thing here. If I don't log into terminal services and leave retrospect running, it's a gamble as to whether or not my jobs will run.

[JohnJ]

Mayoff or others, we need some advice regarding how Retrospect is launched, shutdown etc since it does not run as a service yet. When we implemented, we set it to run as the logged in user. The Launcher Service is enabled and the box is checked to Automatically Launch Retrospect. However, if the Administrator logs off the server after working with Retrospect, it does not appear to automatically launch within the hour mentioned in several posts above. What we see is that the Proactive backups do not start until the admin logs in the next day even though the monitor shows the next backup as 'asap' and the machines are online prior to the admin logging in. Is this controlled by the Look Ahead time in the Schedule panel? We currently have it set to 12 hours which I think is the default.

 

Also, is Retrospect's advice to set up an account for it to run under rather than the account for the Adminiistrator? If that is the case, it would need to be logged into all the time which gets back to ThomasY's original post in this thread.

 

Thanks for any guidance here because what we are seeing is that the Proactive backups only run after the Admin logs in each morning rather than being spread throughout the day.

[atravesde]

i think

Retro has a bug,

try disable run as service, disable icon, quit retro

run retro enable run as service, enable icon, quit retro

try a lot of time until you see the icon in the task bar icon,

 

try clicking the red x, to defer, exit retro, and see if the icon blink,

run retro again and click red x, to continue runing schedule scripts

 

if the you can see the icon you can exit retro, and automatically it lauch to run

proactive scripts

 

it works for me for retro multi 7.5, try it.

 

Maynor

[Mayoff]

On my server, I never logout and and I never close Retrospect. I keep Retrospect on a box that is:

 

1) In a secure location

2) I password protect Retrospect so users must enter a password before using it

3) I use a screensaver that requires a password to unlock the screen.

 

Proactive backup is really designed to always be running, so I let it run.

[JohnJ]

Thanks Mayoff. Still not 100% clear though. Do you have an account specific to the server for starting the app (as opposed to your userid?). The way our severs are configured, even if we just close the terminal services session, the our userid's will be logged off automatically eventually. Since Retrospect started under the userid, it will then stop and not start again until one of the admins logs back on. I totally agree that it would be best to keep it running all the time - we just don't seem to be able to make that happen.

[AmyJ]

>>When we implemented, we set it to run as the logged in user.

 

>> Also, is Retrospect's advice to set up an account for it to run under rather than the account for the Adminiistrator? If that is the case, it would need to be logged into all the time which gets back to ThomasY's original post in this thread.

 

If you have Retrospect set to run as the "Logged in user" but no user is logged in I don't believe it will autolaunch behind the login screen.

 

I recommend setting up a dedicated backup user account with Administrative privileges and set Retrospect to run as that user in Configure > Preferences > Security. It doesn't mean that other Admin users cannot log into the application, but it should ensure that Retrospect always autolaunches with correct permissions.

[JohnJ]

Thanks Amy. One last question because we are concerned about having the user account logged on all the time (our security team objects). Are there implications to having Retrospect start every day as a scheduled task under the admin's userid?

[AmyJ]

Hi John -

 

Setting Retrospect to run as a specific user does not mean the user is logged in at all times - it only means that when Retrospect needs to launch it will launch the application with the provided credentials. This can occur behind the login screen - meaning that it will launch when no one is logged in.

 

There should be no security problems with setting Retrospect to run as Administrator. You can also set Retrospect to require a password for access under the Security Preferences. That way, anyone accessing the application will need to "login" to the application for control. You can then re-lock the application or it will lock itself down again after 15 minutes of inactivity by the user.

 

Hope that helps.

 

Amy

[JohnJ]

Thanks Amy. I think we will go ahead and set up the account and do som testing. I really hope this product gets changed to run as a service sometime soon though.

[JohnJ]

Amy, if you are logged on, another question for you.

 

Are you sure that the account does not need to be logged on? The reason for asking is that I set the app to run under my ID but it has not started in 3 days. I don't think it is a permissions issue because it runs just fine when I am logged on and launch it. (I am a local admin on the server where it runs and we are not backing up any other server data). So, is there a difference between having a dedicated account for the app versus using my own account? Thanks because this is getting frustrating.

[AmyJ]

Hmm.... You said you're a local admin? Is this computer on a domain? If so can you try using a domain admin account to see if the results are any better?

 

It's not launched in a Terminal Session somewhere when this happens is it? If it is launched remotely it will be unable to launch locally.

[JohnJ]

Local admin means that I have admin permissions on the server where Retrospect is installed. It is on a domain. Our usage of domain admin accounts is extremely limited so it is unlikely that I will be given permission to use one. Is it your opinion though, that domain admin permissions are required as opposed to admin permissions on the Retrospect server? And no, so far as I know, a Terminal Session is not active when we expect that Retrospect should launch. Thanks for your help with this.

[AmyJ]

It was more of a thought... trying to think outside of the box as they say. I just tested with a Win 2003 Standard machine joined to a Win 2003 domain. I set Retrospect to run as a member of the local Administrators group and created a small script to run in 2 minutes. I quit Retrospect and logged off the computer. I logged in 5 minutes later and my script had run without error at the scheduled time.

 

Is the Retrospect running when you log off? Make sure you quit the program itself - but leave the system tray icon active (do not exit it).

 

Do you only have the problem with Proactive scripts or does it happen with managed scripts also?

[JohnJ]

We are only having the problem with Proactive scripts because that is the only function we intend to use (at least for now). Sorry to be dense but I do not understand the statement: 'I set Retrospect to run as a member of the local administrator's group......". How is that done, like via the account? Also, I am not clear about how I can logoff but leave the app running in the system tray - it looks like it always wants to end. Is this a setting in the Startup options in Preferences. Thanks again

[JohnJ]

Amy, I think I may have misunderstood what type of account is required. We just added a local admin account and added that to the preferences. I think we had been under the impression earlier that an Active Directory account specific to the application needed to be created. We should see overnight whether this works or not. When in doubt RTFM!!!

[AmyJ]

Hi John -

 

I may have been unclear in my response. By setting Retrospect to "run as xxx" I was referring to the Security Preferences in Retrospect (Configure > Prefs > Security). I created a new User (Amy) in Windows and put that user in the Administrator group for the local machine. I then set the Retrospect Prefs > Security values to use (or "always run as...") Amy. It worked fine.

 

We do typically recommend that a new administrative account be created (local or active directory) for use with Retrospect. It is simpler for many users to have a "backup" account that belongs to all the appropriate groups. That way, if a user account changes (is demoted, etc.) there will be no interrupt in the backup. In a domain environment you would most likely need to use an Active Directory account in order to properly access some applications such as Exchange or SQL. However, as my test indicated, a local admin account should work just fine in a domain environment assuming it has access to all the needed resources (sources/destinations).

 

Amy

[JohnJ]

Hi again Amy,

 

No luck. As described in the manual, we created the Backup Administrator account on the server and changed the Security settings in the Preferences options to point to it. For now, this account was only created on the server and is not set to log on to the domain. After making the changes and recycling Retrospect, I did not log off the server, I just exited the Terminal Services session. It looks like Retrospect ended several hours later when my session timed out and it never restarted. I'm now wondering if we should add a Scheduled Task to start Retospect each day prior to when our users log into the network. Your thoughts about that would be appreciated along with anything else we may have missed. Thanks

[JohnJ]

Update Amy,

 

Starting Retrospect via a Scheduled Task using the Backup Administrator account appears to work. One last question though: why doesn't the Retrospect icon show up in the system tray when it is started this way? I have the box checked in the 'Show taskbar icon' in the Preferences options. Thanks