Retrospect 7.5.370 and Vista - Run Retrospect as the logged-in user grayed out?

[xtianp]

I installed 7.5.370 on a fresh copy of Vista and set up the schedules to backup automatically.

 

I don't see the red icon in the toolbar (bottom-right hand corner), but most importantly, Retrospect does not launch at the time of the backup in interactive mode. I know it's working because when I launch it manually the log shows the backups were done. Also, if it's in the middle of the backup it tells me that another instance is running and if I proceed the other instance will be terminated, then it launches but it aborts the backup in progress.

 

I checked the settings in Preferences-Security and the radio button that says "Run Retrospect as the logged-in user" is grayed out and not selected.

 

Does anyone know how to fix this?

 

Thank you.

[AmyJ]

From the Read Me:

 

Retrospect Backup User (RBU): The RBU is not supported on Windows Vista and you must run as the logged in user.

[xtianp]

Yes, I saw that but I don't understand what it means. If I can't select "Run Retrospect as the logged-in user" in Preferences-Security, how do I run as the logged in user?

[yingqing]

In Configure->Preference->Security window, is the "Use Default" button also grayed out. If not, you may try to click it to let the "Run Retrospect as the logged-in user" option set as default. Not sure if this suits to your case, since I am using 7.5.370 on WinXP.

[xtianp]

Yes, "Use Default" is also grayed out.

[xtianp]

Does anyone at EMC look at this? Perhaps they can shed some light on the problem.

 

Is anyone else experiencing this problem when running Retrospect on Vista?

[xtianp]

Apparently not.

[jelenko]

FWIW, the same option in Security is greyed out on 370 on Vista on my install.

At the same time, Retro on Vista is daily executing several scripts successfully.

 

FYI. In Services, you can open Retrospect Launcher and choose which account Retro runs under, if that helps.

[xtianp]

Hi jelenko,

 

Thank you so much for your reply.

 

Yes, mine too is executing scripts successfuly, but the problem is that if, say, it wants me to change a tape or something there's no way to know, since the interface is not available.

 

I have tried changing Retrospect Launcher in Services to run under my account, but that didn't make a difference.

 

Have you been able to make that change and see it when it runs?

 

Once again, thanks for jumping in

[Mayoff]

On Vista, Retrospect can only run as the currently logged in user (Vista is all about security ;} )

 

Anyone who really needs to run Retrospect under a specific user account should not be running Retrospect on Vista.

 

We note this in the Read Me

[xtianp]

Hi Mayoff,

 

First, thank you so much for your reply.

 

With all due respect:

 

I know what you're saying but it's not clear in the documentation, and the behavior of Retrospect is not consistent with either the documentation or what you said, unless, again, I'm not understanding your point.

 

You said "On Vista, Retrospect can only run as the currently logged in user", but if you schedule a task, that task runs as the "Local System" account, which is not the logged in user.

 

You can't make retrospect run scheduled tasks as the currently logged in user, since that option is grayed out in Retrospect.

 

So, if Retrospect is open when the schedule task fires, it runs the scheduled task using the logged in user security context, but if Retrospect is not open it runs using the Local System security context.

 

Not knowing the architecture of your software, this is a guess, since the security context used to read the files could be determined by something else, perhaps the Retrospect Helper service, which runs as the Local System, but I doubt it. What is not a guess is the security context of the Retrospect user interface, which is definitely either the Loal System (if Retrospect is closed when the task fires) or the logged in user (if it's open), as described above.

 

In either case, I've been playing around and I just found a way to make Retrospect open before the task kicks in, so it is the equivalent of changing the grayed out option, "Run Retrospect as the logged-in user". To make what I want happen I've had to create a task in Windows Vista's built-in Task Scheduer a few seconds before the task in Retrospect is scheduled to run. The task simply starts Retrospect. Note: If anyone is going to use this trick make sure you check the "Run with Highest Privileges" checkbox.

 

Then, since Retrospect is open it runs as the currently logged in user.

 

Simple enough.

 

Now, my point is, if there is a way to do this, as I've just proven, why not give us the option to select "Run Retrospect as the logged-in user" to begin with? It seems pointless that I have to schedule 2 tasks, a task in Retrospect and a task in Windows Vista, so I can get it to behave that way.

 

Thank you for listening.

[xtianp]

The only thing left for me to work exactly as I want would be to start Retrospect.exe with some sort of switch so that it exits when it's done.

 

Is there such a thing?

[xtianp]

EMC: Any ideas?

[rhwalker]

Quote:

---

EMC: Any ideas?

 

---

This is a user-to-user support forum. Here's the link to contact EMC support:

Contact Support

[xtianp]

Oh, I thought I saw a reply from an EMC rep (AmyJ) before.

 

I apologize if that's not the case, but if it is, any ideas?

[rhwalker]

Quote:

---

Oh, I thought I saw a reply from an EMC rep (AmyJ) before.

 

---

Yep, right on that, and you also got a reply from Robin Mayoff, EMC manager of tech support. EMC people sometimes do respond in this user-to-user forum. So, in one sense, you have gotten the answer to your question whether there are any ideas from EMC from two very qualified EMC people. I thought that their responses were pretty clear that you wanted to do something that wasn't possible. They certainly are more knowledgeable than I am.

 

Russ

[XOR42]

Quote:

---

On Vista, Retrospect can only run as the currently logged in user (Vista is all about security ;} )

Anyone who really needs to run Retrospect under a specific user account should not be running Retrospect on Vista. We note this in the Read Me

 

---

With all due respect for your valued participation, that does not answer the siginificant problem that makes RP effectively incompatible with Vista. We do not care what account RP runs under. We need to see Retrospect when it runs a scheduled operation. As it stands, it runs invisibly if triggered by schedule and remains in backgrourd invisibly. This is completely unaccaptable.

 

As we users all know, RP requires constant hand holding, supervision, tons of head scratching, and tweaking to make it work. It is impossible to support its operation without having access to the GUI during its execution. We HAVE to be able to see it work to check on it and look out for the many problems that routinely occur with all but the simplest backups.

 

Furthermore, complex backups can take many hours. Since it runs invisibly, it forces us to cancel the current execution to bring up a visible GUI to see what is going on. However, if it is still running a backup, we will essentially DESTROY the backup since it would be a forced termination. And we all know that RP blows its backups when you do that.

 

As it stands, we cannot run the RP GUI unless we wait many hours after what we think was the last execution, praying to God, it is really finished before we have to force the exit of the invisible current execution.

 

Such behavior cannot be considered Vista compatible. At best, it is "functionally limited" or "partially usable". Ergo, we can no longer safely use RP for our Vista backups with any certainty or control. That is not what this customer expects and paid for.

 

Lastly, since RP requires so much of our time, energy, and money to keep it running, I think it behooves EMS to be much more forthcoming with acknoweldgement of these major problems and a sincere response as to their plans and timetable to address them. If this is not in their plans they need to tell us so we can start seeking alternative solutions. Backups are mission critical and sensitive issues.

 

Granted, the interaction and answers we seek may occur with expensive support packages. If that is, indeed, the case, then it seems unethical to not publish and share such findings when they have been paid for by those with a budget.

 

Q1: Does EMC plan to contunue the RP line and fully support Vista? They certainly had enough time. Decent Vista betas have been available for 2 years!

 

Q2: When will RP be as functional with Vista as with XP and what steps is EMC taking?

 

Q3: When is the FREE update planned to be available with those fixes?

 

Thank you for your time.

[creagin]

Ditto on what XOR42 said!

[Mayoff]

If you manually launch Retrospect, all scheduled backups will run and you will be able to see the interface. Change the Preferences to "stay in Retrospect".

 

Just launch Retrospect and minimize it. When a backup isn't running it won't use very much memory and almost no CPU.

[creagin]

So what you are saying is that automated backups are out of the question under Vista. This is unacceptable. I am also curious if a fix is being worked on for this or if we (as a company), and my many customers, need to be looking for another backup solution as we/they upgrade various machines to Vista. I don't mind being a little patient and waiting for a solution to be worked out, if one is being worked on. However, if this isn't a priority for the Retrospect folks, we need to know this so we can move on to other solutions.

[Mayoff]

Quote:

---

So what you are saying is that automated backups are out of the question under Vista.

 

---

 

I never said this. I said the opposite of this.

 

If Retrospect is manually launched, ALL automatic Backups will happen at the scheduled time and complete as expected. You are overreacting to the issue.

 

Retrospect runs as the System Account. Microsoft made a major change to how user accounts work in Vista. This means that when a program wants to run as "another user" or as "system account", the currently logged in user can't see anything running under the "other" account. This is an unfortunate change made by Microsoft, and we can't easily workaround the fundamental change to how Windows works until the Retrospect engine is separated from the interface.

 

If you are unhappy with this behavior or the workaround I have offered, then I would suggest backing up this computer as a client and running Retrospect on XP or any other version of Windows which uses the traditional user account methods.

[alexjoy]

I am having a new kinda of problem with Vista and express.370. I originally thought I would be able to transfer data from an external HD to anew Vista machine but ran into issues. So then I had someone transfer directly all data off previously used xp machine. Now when I go to open Retrospaect Express( I have removed and replaced several times) it begins to open then just quits, or crashes. Anybody else experience this or know how to fix it?

[gosub]

Quote:

---

Quote:

---

So what you are saying is that automated backups are out of the question under Vista.

 

---

 

I never said this. I said the opposite of this.

 

If Retrospect is manually launched, ALL automatic Backups will happen at the scheduled time and complete as expected. You are overreacting to the issue.

 

Retrospect runs as the System Account. Microsoft made a major change to how user accounts work in Vista. This means that when a program wants to run as "another user" or as "system account", the currently logged in user can't see anything running under the "other" account. This is an unfortunate change made by Microsoft, and we can't easily workaround the fundamental change to how Windows works until the Retrospect engine is separated from the interface.

 

If you are unhappy with this behavior or the workaround I have offered, then I would suggest backing up this computer as a client and running Retrospect on XP or any other version of Windows which uses the traditional user account methods.

 

---

 

First off, I don't believe creagin is overreacting at all. This is a major functional shift that, had I known about, I wouldn't have spent the money on the Vista upgrade. I use this software in a home/office environment, with Retrospect running on and backing up my machine and two others. I am unwilling to keep Retrospect running in the background so my automated backups run properly. I also can't run this software from any of the other network machines, nor do I have an XP box I can dedicate to the effort.

 

That being said, you never addressed creagin's curiosity about possible development to deal with the issue, other than to say it's difficult. Are you indeed working on, or at least planning to work on, separating the engine from the interface? I'm in the same boat as creagin: if a true solution isn't going to be offered, then I'd like to know that so I move to another product. I realize EMC doesn't want to lose customers, and I would prefer to remain a customer, but I've been a Retrospect user since 1995 and would appreciate a certain amount of respect and honesty when it comes to a situation like this.

[Mayoff]

We are planning to separate the engine from the interface, but I do not know the timing of this product change.

[XOR42]

This situation is becoming insulting to some of us Retro users. EMC needs to acknowledge that either Retro does not adequately work under Vista or that they intend to kill the product from Vista onwards. It's been about a full year since EMC has the necessary info to recode the product. We pay a premium for Retro to ensure that they do - and, well, they haven't!

 

As of the latest 379 release - which had no visible improvement over 370 and seems to run even worse for me - Retro has the following severe problems (among others).

 

1. When run as designed, by schedule

a. It runs invisibly so it cannot be monitored.

b. Operator cannot access the product

c. Any operational error dialogs are HIDDEN!

d. Program can sit for days, locked up, without us knowing

 

2. Attempting to run manually:

a. As Retro is silent and runs 24/7, we cannot start manually because Retro will forcibly crash the BG process.

b. Any crash or hiccup of a Retro run destroys the backup integrity.

c. You cannot automate manual operation via on Start Up as it fails with Access Security Prompt

 

3. "Assert Failure" - When 379 runs in BG and wants to pop an error or warning dialog, nothing happens, it sits and hangs in silence. So, after 2-3 days or suspicious silence, you run it manually. It says running already so you are forced to terminate the BG process. It then starts in FG but we get a weird "Assert Failure" messages from Vista. After several confirmations Vista switches to lower res mode and shows the original Retro warning, which was something simple like "drive out of space". But, since this occurred 3 days ago and we just axed its execution to get to interface, we just trashed the back up. Upon re-running Retro, adding salt to the wound, we get another Assert Failure messages that eventually leads us to a Retro error that tells us Retro crashed. Yeah, right, because it just forced us to crash it. Not nice.

 

4. Help system unstable!

The critically important Retro help system has been broken for years and seemed so in the last 379 version. HOWEVER, it miraculously started working again. Hitherto, Help would fail to start saying it can't find the help (older versions) or it would show the index but fail to find the text content (latest version). Only when you started Retro from the system tray icon did it show the help - or vice versa? It now seems to be working when running from Windows icon but only after multiple crashes as per above. EMC needs to acknowledge this long time bug and explain if, when, and how it is was fixed -- if at all. To wit: Issue with help when Retro is run from system tray icon versus Window icon.

 

There are many other usability issues and operational deficiencies but there's no sense getting into them until the above major issues are dealt with. Here's a few summarized:

 

1. Auto-groom has never worked for us. Retro ALWAYS runs out of space because it seems to need a LOT of extra space to groom. So it ALWAYS underestimates the space needed to groom then runs our of it. Our backup source has only 300 Gb. Our back up drive 500 GB. Yet with groom sets=1, it still run sout of space. We've added 5, 10, 20, and 40 extra GB but it just keeps running short.

 

2. Retro backup sets cannot be trimmed, matched, rebuilt, or otherwise checked for 100% integrity.

 

3. Reto back up sets continue to grow in size because Retro does not seem to eliminate some files that are no longer on the source. Our current backup of our 300 GB artea is now 450 GB though we only asked to keep 1 generation.

 

4. Catalog rebuild does not rebuild catalog. Long-known and well-documented issue.

 

... Ad nauseum ...

 

If EMC continues to remain silent on all these major issues and the lack of acceptable Vista support, it cannot be said that there is a Vista version nor can Retro be recommended as the professional back up solution it claims to be. This is not shareware nor a game. It is a product that is critical to daily operations of a computing environment - regardless of whether it is for SMB, SOHO, or Home. I've never tried so hard to be loyal and gotten so little in return.

 

After having successfully led countless s/w projects, I am aghast over how the current product has been allowed to break so badly and, beyond that, has had so little functional improvement. I'm only a few miles from their HQ if they need help.

 

Parting suggestions:

 

1. Review Retro operation closely and collect ALL known issues.

2. Publish a bug list ASAP. It show responsibility, ethics, and build loyalty.

3. Accept and acknowledge bugs ASAP from customers.

4. Affirm that Retro is Pro product designed for utmost reliability and auto operation.

5. Read point 3 then add all problems to bug list that prevent Retro living up to that.

6. Make sincere statement about their design and support directions for Retro.

 

Thank you.