Duis mollis, est non commodo luctus, nisi erat porttitor ligula, eget lacinia odio sem nec elit. Sed posuere consectetur est at lobortis. Vestibulum id ligula porta felis euismod semper. Donec ullamcorper nulla non metus auctor fringilla. Aenean lacinia bibendum nulla sed consectetur. Cras justo odio, dapibus ac facilisis in, egestas eget quam. Cras mattis consectetur purus sit amet fermentum. Morbi leo risus, porta ac consectetur ac, vestibulum at eros. Sed posuere consectetur est at lobortis. Etiam porta sem malesuada magna mollis euismod. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Duis mollis, est non commodo luctus, nisi erat porttitor ligula, eget lacinia odio sem nec elit. Cras justo odio, dapibus ac facilisis in, egestas eget quam. Aenean eu leo quam. Pellentesque ornare sem lacinia quam venenatis vestibulum. Curabitur blandit tempus porttitor. Sed posuere consectetur est at lobortis.
I'm sorry that your experience in this issue has been so ...... frustrating.
On the first issue, some good news which unfortunately is not going to help in this situation. From input on other threads we were able to duplicate the issue. It turns out there is a bug in the process of LiveUpdating Ghost 14. If a backup is running when LiveUpdate tries to update Ghost, things get screwed up and you will get "Error - This operation cannot be performed while windows is running. You must complete this operation inside the recovery environment." This has now been given to our developers to fix.
As a work around to this issue, after installing Ghost, it is important to ensure that a backup is not running when LiveUpdate is running. If Ghost is manually kept up to date with updates then you don't run into this problem. And for all those that are reading this, v.14.0.3 is in the pipeline and it will be good to manually update in the next few days -- just make sure a backup is not running at the time you manually run LiveUpdate.
Now as to the second problem. I need some more details so that we can try to duplicate it in house. If we can duplicate it, we can get it fixed. Also, I have a workaround for you. First the questions:
What exactly are you seeing when you click on Recover My Computer? In addition to the steps, please include any messages and the titles of dialogs you see -- not the whole thing, but enough to know what you are seeing.
In the Recovery Point To Restore dialog there is an option called View by that lists Date, FileName, and System.
- When Date is chosen, do you see any recovery points in the list?
- When File name is chosen, how are you getting to the v2i, with Browse or typing the filename in?
- When System is chosen and you browse to where your backups are, is there an .sv2i file available?
- Same location as the previous question, if you change the file type from .sv2i to All Files, what happens when you select a v2i file? Can you get further in this way?
Now, as a work around, since you can access your backup in the browser in the SRD (System Recovery Disk), use the browser to copy the v2i to another file without a password. (Select the .v2i, then File | Copy Recovery Point) Then use the Recovery My Computer Wizard with the new file.
I usually enjoy irony but not this time.
Ghost has, among other settings, a trigger to backup whenever a new application is installed. This is quite a common setting.
When liveupdate installs some software a backup is then triggered. Later in the same update Ghost is updated.
So a common Ghost setting triggers a backup during live update which corrupts the Ghost update later in the same session.
Security and backups are the two most important background processes on any computer. They, taken together, provide peace of mind. My thinking was that using the same vendor for both processes would result in a high level of compatibility and assure routine proper operation. Boy was I wrong - a common backup setting by design corrupts updates to the backup software.
In the more than a week I waited for a response I may have changed my mind. Perhaps it's better to use separate vendors - each dedicated to their own task.
The upshot is that because I'm comfortable with NIS, I've been looking at other backup software vendors.
PS Going to manual updates, closing Ghost, updating, then restarting Ghost is way too clumsy AND automatic updates are automatic for the obvious and very important purpose of keeping NIS current.
You misunderstand me on the manual updating or may be I've not be clear enough. All that is needed is make sure that a backup job is not running -- you do not have to shut Ghost down. Then after you have ensured that a backup is not currently happening, you start up LiveUpdate and update Ghost. And after the update, you should reboot your machine so that the driver that Ghost depends on is reloaded. (You must reboot to reload the driver since it lives so far down in the OS it is only loaded at boot time.) This would bring your Ghost up to the latest of 14.0.3. No further updates will happen to Ghost until the next patch comes out no matter how many times LiveUpdate runs between now and then. So, once you are up to 14.0.3, your Ghost is safe from this bug. And you can use it to your heart's content to do it primary job of backing up your computers.
While I can never promise anything in the name of Symantec, I personally expect this will be resolved in the next patch so that it makes no difference if a backup job is running or not. To us this LiveUpdate problem is a big problem that we want solved as soon as possible.
Ghost is set to be triggered by the installation of new software. If, as is likely, the update installs software then presumably a backup will commence - even if no backup was in progress when the update session began. When the update session subsequently attempts to update Ghost, the backup triggered earlier in the update session will be running and the Ghost installation will be corrupted. I could turn the trigger off but I become very concerned when even one workaround is required - two and more are unacceptable.
Backups are far too important to trust to software that misbehaves and requires workarounds.
Having lost faith, I may now lose sleep!
It's really a moot point now. This experience has so soured me on Ghost that, after careful review, I have acquired the requisite installations of ShadowProtect Desktop 3.2. (PCMagazine's Editor's Choice and well reviewed on blogs I respect.)
Ghost will not be used and, though I have recommended it in the past, I will rescind those recommendations and issues cautions in the future.
I'm sorry that your experience has been less that a good one. I'm sorry that you feel the need to turn elsewhere. We endeavor to be the best backup product there is. Unfortunately, you have run into a rather nasty bug -- something that can happen with anything that involves software. We will fix this bug and continually try to improve our product to be the best there is.
Nevertheless, may you find the peace of mind that you seek in the path you have chosen to go!
For anyone else who may read this thread... In the scenario richardfror gives in the previous message, there is a bug in using LiveUpdate with Ghost 14. The solution to this scenario is to not allow LiveUpdate to happen until the initial backup completes. This in done by unchecking LiveUpdate when prompted. Then after you have taken you initial backup, run LiveUpdate which will update you to the current version of 14.0.3. At this point you would now be past the point that this bug occurs and your Ghost will safe. Development is working to address the problem and fix this bug.
Johan,
We are using Symantec Backup Exec Recovery Desktop 8 and are experiencing the same issue with the message:
"This operation cannot be performed while Windows is running. You must complete this operation inside the recovery environment."
I installed the client and the user interface on a Vista PC and while LiveUpdate was running behind the active window (I did not notice it), I began to set up my first backup. Suddenly the server became unavailable and I had to start over, that's when I realized that LiveUpdate was running. The backup was not actually running when this happened. After a restart, I set up the first backup job and received the above message. Am I in the same situation b/c I did not run the initial backup before LiveUpdate? Does Recovery Desktop 8 use Norton Ghost 14 behind the scenes? Finally, how do I fix this problem?
Thanks
Actually, Ghost is based off of Backup Exec System Recovery (BESR). Ghost is the consumer version and BESR is the enterprise version. As to fixing the problem there are two ways that I know of.
Method 1) The first method is to run the FixInstall.bat in C:\Program Files\Symantec\Backup Exec System Recovery. Then reboot when this is done. The reboot is critical since the driver that is only loaded at boot time needs to be reloaded in order to see if this worked. If this does not work, as we have found sometimes does not happen, try the other method.
Method 2) Uninstall BESR and then reinstall it.
To check if either method worked, try to run a backup.
After all this is done, you then need to protect yourself against the possibility of this happening again by running a LiveUpdate AFTER the backup mentioned above is complete or canceled. This will update you to 8.0.3 and will prevent LiveUpdate from updating BESR again until the next patch is ready. I'm hoping this one will be resolved then, but I can not state on behalf of Symantec that it will be fixed then.
Additionally, if you would like to further discuss Symantec enterprise products (like the product mentioned above) please visit https://forums.symantec.com/. These Norton forums are specifically for consumer product discussion. I apologize for this inconvenience.
To begin: I'm amazed as to how many people are experiencing these problems with the product and the inability of Norton support (India) to fix the issues.
I've spent hours with someone from support going through all of the usual suspects
After that was done they were supposed to escalate me to the next tier which NEVER happened
All of the trouble began with version 12 so I figured that I'll upgrade to 14 and that should take care of all of the problems
It made things worse
Problems include:
cannot retrieve backup job properties when creating or editing job tasks
ghost will not automatically update and maintain max level of backup images
SQL errors
plus others
When speaking to Michael John Nazareth this is what they stated
From: {removed}
Subject: Symantec technical support < {removed} >
This is {removed} from Symantec Technical Support. It has been my pleasure to work with you on your support request. Based on our conversation, your ticket, Priority ID {removed}, I will leave your case as 'open pending' for the next seven days. Please confirm the status of the issue.
I contacted support again, again and again and ALL were equally incompetent and unable to resolve anything
Even when I received a follow up to ask "how things went" they didn't respond either
I too have a CS degree and have been programming since the fortran days (IV & 77) and have NEVER experienced such issues with a software product
I even went as far as to uninstalling EVERY Norton product from the target computer, used the utility to remove any remnant and re-installed from scratch to no avail
Current ver Ghost 14.0.3.28361
I cannot see spending another several hours on the phone with "support", working through the language barriers, to end up in the same place
It's been 3 times so far
Doesn't Norton care?
[edit: Removed Identies per Participation Guidelines and Terms of Service.]
I certainly care. But in order for me to be able to do or suggest anything I need to get a clear statement of what the issues and symptoms you are currently experiencing with Ghost 14.0.3.28361.
I just installed Norton Ghost v14.0.3.28361 on November 3, 2008. I am running Windows XP and I to am experiencing the same issue. "This operation cannot be performed while Windows is running. You must complete this operation inside the recovery environment." This thread seems to have been going on for months. Has this issue been resolved? As a former Symantec employee, I find this to be embarrasing. This should have been resolved a LONG time ago.
On my system, the Live Update service was set to manual which means the update service wasn't even running during the attempted backup. My laptop is running Vista and I have NO issues what-so-ever. Could you please address this issues as son as possible or I too will have to look else where for disk backup/recovery solutions. I am at the beginning of my evaluation period and, thus far, it isn't looking good.
Thanks,
Brian Frazier
Yes, it has been a long time. Far longer than I would like. However, this issue has proved somewhat elusive. We now know that there are at least two separate and distinct flavors of this bug. One involves LiveUpdate occurring while a backup is occurring. And the net effect is the SymSnap Service is getting trashed. There is a fix for this one currently in testing.
The other flavor of this is appears to be a failure of a call to the OS we do to validate what we have already done and this is failing. This flavor of this error is something that try as we might we have not been able to reproduce. We are actively looking for anything or any one that could help us reproduce this problem. It sounds like your case might fall into this second scenario. Would you be willing to help?
What can I do to help? My scenario is a simple one.
- LiveUpdate service - Not running
- Attempt to create a revovery point - Fails with the aformentioned message
If there is something I can do, please let me know. However, time is short as my trial will end in 29 days.
Brian Frazier
mrbriankf@yahoo.com
Oh yeah. One other small item. Norton Internet Security 2009 is running on both machines.
That is a very interesting tidbit. Let me have one of my testers throw NIS 2009 a box and try it first.
OK. For clarification...
- Win XP Media Center (latest patches)
- NIS 2009
- LiveUpdate Service set to Manual, not automatic (this is really bad as this is a out-of-the-box install)
- Try to create a recovery point (fails every time)
This is a brand new server install. That is why I am trying to get a good clean image to store.
Why is the LiveUpdate service set to manual? The average novice user will not know to run this process to get updates. Is there something in NIS or Ghost that kicks off the process?
From first installation of Ghost 12, I started getting one of the errors listed in this thread; "Cannot Retrieve Backup Job Properties".
But first, let me give some specifics.
I have a simple setup with a desktop, a laptop, and a 2wire 2700 modem/wireless router.
The laptop is connected wirelessly, and the two computers are networked.
Both are running XP pro.
I was trying to backup my laptop onto a shared location on my desktop hard drive.
I had tried several things before I tripped on this resolution.
First, I deleted all tasks in the Run or Manage Backups window.
Then I returned to the Home page and clicked Run or Manage Backups
This started the Easy Setup Wizard.
I selected the remote location as normal
*here's what resolved the issue* I entered in the right username and password information. Ghost uses a slightly different format than Microsoft (or perhaps terminology would be more appropriate word). In this case, when I set up my network, I did not name any domain. I had a computer name and a user name and no password (I'm the only user), and XPs "welcome screen" was bypassed.
Well, the trick was in entering that information correctly.
All I entered under Network Credentials was:
Username: computer_name (NOT my user name in Windows, but what I named the desktop computer when I set up the network)
Password: blank (since I have no password)
All of a sudden, everything started working great.
Hope I helped.
The reason that things would have started working is that Ghost 14.0.4 was release and made available on LiveUpdate just before Christmas. 14.0.4 contains a fix that was causing our driver's installation to get corrupted.
So are you saying the issue is now resolved?