I recently installed Ghost 14 on a Win XP platform. Created the boot CD with drivers. Backup to a network server without any problems. When I test the recovery disk, I start network services, can ping the network server by IP and name but can not connect to the server to find the backup file. What am I missing? (have done this with Ghost V9)
A related issue, after searching the forum, it appears Ghost 14 will NOT do a bare metal recovery of a drive. Is this correct?
What is the network locations? Is it a SAN? On a server that requires account validation? Etc.
For the secondary comment, it depends on what you define as a "bare metal recovery." Could you clarify?
Let me start from the beginning. Got hit with a Trojan (DNS swap) that I couldn't remove successfully. No worries, I did a complete backup two days ago. I'll restore the full backup and be done! Booted the recover CD, could not link to the network drive.
Network drive is a Samba (Linux) share without a sign-on requirement. A thought I have yet to try, could the network workgroup be a requirement? I read an article somewhere on changing your workgroup from a dos prompt.
Not to worry, I have another option, I installed the drive in another machine, restored the image using an active Windows machine versus the recovery CD and the files transferred but I could not boot the disk in the original machine. Now I'm really sunk!
Ended up re-imaging the entire drive.
As for "bare metal" recovery, take a new or blank drive and restore a saved image to it.
To confirm, you're in a situation now where you have everything back?
As to the "bare metal" recovery you can do that. Sometimes you want to format in case there is a problem in accessing the drive.
Erik, yes I have everything back...but the hard way. I had to re-image the drive from scratch, install a new version of Ghost then recovered my files from the backup server. I used Ghost for a complete backup weekly so in the event of a disaster of this sort I could recover the entire drive and not have to re-image from scratch and reload applications and files.
I have used previous versions of Ghost and successfully restored entire drives without incident (I have two kids in college that have had hard disk issues).
So, I guess my questions remain:
Will Ghost 14 permit me to create a rescue disk (with the necessary drivers), boot from that disk, connect over a network and recover an entire drive to it's previously stored state (bootable and all)? If so, what am I missing as I can not connect to the shared network attached drive?
Thank you.
Tom
The only thing, from the Ghost side of things, is to create your custom recovery disk and ensure that your NIC drivers are present. As to the drive, you need to ensure that it has a drive letter (across the network) in to access while in WinPE. While in the recovery environment, you'll need to map that drive. The following is from the product help:
If you started the networking services after you started the recovery environment, you must map a network drive. This lets you browse to that drive and select the recovery point that you want to restore.
If there is no DHCP server or the DHCP server is unavailable, you must provide a static IP address and a subnet mask address for the computer on which you are running Symantec Recovery Disk.
After you provide the static IP address and subnet mask address, you can enter the recovery environment. However, because there is no way to resolve computer names, when you run the Recover My Computer Wizard or the Recovery Point Browser, you can only browse the network by using the IP addresses to locate a recovery point. You can map a network drive so that you can locate the recovery points more effectively.
Ghost has a pretty thorough help file for just about any action that you can do with the product.
Attn: Erik Carlstrom
Erik:
Simply cutting and pasting instructions from the User's Guide is not helpful, because the network share functionality of the product does not work (at least for some users, including me) according to the User's Guide, pgs. 157-158. I am an EE with 35 years of experience, so please consider the validity of my report, below, and provide an equally responsible answer.
Connecting to a network share is an absolute nightmare with this product (Ghost 14.0). I have spent hours trying to make the "Map Network Drive" function work and still no luck.
System:
Restoring to a Dell C600 laptop running XP Pro.
Dell C600 network attached to a Dell D620 (running XP Pro) via a D-Link DI-624.
Network store is a Maxtor external drive, attached to the Dell D620 via USB.
The above system creates backups using Ghost 14.0 without problems. I am just trying to test the restore capabilities before I actually need them and discover that my confidence in the product has caused me to lose my C600 system.
When using the "Map Network Drive" folder form: \\192.168.0.100\c600 backup
(c600 backup being the network share name that works perfectly for backups) the logon screen appears (apparently normal). I then enter the logon information for the D620 (the machine hosting the share). I then get the error message "A specified logon session does not exist. It may already have been terminated." I cannot get past this point. Clearly the recovery environment has found the host for the share (D620), because entering an invalid share name generates the error message "The network name cannot be found."
Questions:
(1) What does this error message mean?
(2) Where is the list of error messages in the documentation? Ghost 10.0 had these messages in the back of the manual, but I cannot find them in the Ghost 14.0 User's Guide.
(3) Please list any and all services that must be running on the computer hosting the share (the D620 in my case) in order for the recovery environment to operate correctly with a network share.
(4) Please suggest what else could be causing my problem.
Other problems/bugs discovered:
(a) The "Recover My Computer" option works differently when accessed via the "Home" menu vs. the "Recover" menu in the recovery environment.
(a)(1) When accessed from the "Recover" menu, following the instructions on pgs. 157-158 of the User Guide ("View by Filename" or "View by System") and entering a valid UNC path (using computer name or IP address of computer hosting the USB-connected share), the login and password screen appears upon pressing the "Next" arrow. However, upon entering valid login/password to the share host, the login/password screen disappears and nothing happens. No error message at all. At this point, the recovery environment is clearly stuck in a loop, because pressing "Back," "Next," or "Cancel" causes the blank login screen to re-appear. The only way to get out of the loop is to press the upper-right screen cancel "X" of the "Recovery Point to Restore" screen of the Recover My Computer wizard.
(a)(2) When performing sequence (a)(1) from the "Home" menu, however, the message "Error EC950018: Cannot connect to the network resource" appears upon entering login/password.
(b) Under "Map a Network Drive," pressing the Browse button causes the "Browse for Folder--Select a shared network folder" screen to appear with the compressed "Network Neighborhood" world as the only folder shown. Double clicking the "Network Neighborhood" world causes the "Entire Network" world to appear after about 10 seconds. Double clicking the Entire Network world causes the "Microsoft Windows Network" world to appear after several seconds. Double clicking the "Microsoft Windows Network" world name does nothing, even after waiting several minutes.
Could you please help me to resolve the problem stated at the beginning of this email so that I can use the product?
Thanks,
Bruce
P.S. Here's an applicable riddle: What is worse than no backup? Answer: A backup that cannot be restored.
Why? Because with no backup at least there is no **expectation** of restoral.
Apologies as I didn't see a post with your details in this thread.
In the Map a Network Drive folder box have you tried with just the IP as opposed to including the subfolder? There isn't anything beyond the Windows services that need to be running on the host machine.
Eric, I think I'm good now. I started the customized recovery disk (as before). Started network services (as before). Ran IPCONFIG and all looked well. Pinged Samba server by IP and Name, that worked (as before). Mapped the drive successfully (which didn't work before). Explored the files and everything looked right. I did not attempt a full recovery. I'm not sure what was different now than before as I could ping the Samba server by name and IP. However, when I did map the drive I did follow your post and use the server name and directory, I'm not sure I used the directory the last time.
Now that I got this far, one question still remains. If my hard disk is completely gone, can I "Recover my Computer" to completely restore my drive? AND will it boot?
Tom
Yes. Just be sure to restore the MBR and set the parition to active and you should be good.
“Just be sure to restore the MBR and set the partition to active and you should be good” Can you elaborate on how to do this? In past versions I thought I simply checked the box “make disk bootable” but I can’t confirm. Thanks!
You will have the opportunity to check these during the restore. I can't remember the exact wording in Ghost 14 as the wording has changed from Ghost 9, 10, 12, and NSR 1/2.
Erik,
It appears that you may not be reading my posts very carefully. Among several questions in this post, I asked for a LIST of the Windows services that are required by "Map Network Drive" to be running in the machine hosting the share. I did not ask whether anything else is required to be running on the host.
Why would I try entering just the IP address of the host in the Map a Network Drive folder box? It is not documented that way on the Map Network Drive window or in the User Guide. Both clearly state that the format needs to be the UNC name: \\host\share. Not surprisingly, when I enter only the host IP address (per your suggestion), the "The network name cannot be found" message appears, just as it does when any invalid share name is entered. As I said in my exhaustive email, "Clearly the Recovery Environment has found the host for the share (D620), because entering an invalid share name generates the error message "The network name cannot be found."
As I reported, when I enter the valid share name, the logon screen appears, indicating that contact with the host has been made. The problem is with the logon. I indicated to you in the post the text of the error message generated by the logon attempt. Your answer has nothing to do with the logon process. Your suggestion is invalid and is related to the step PREVIOUS to the logon.
Could you please read my post very carefully and answer all the questions so that we can figure this out? Alternatively, could you please escalate this to a support person familiar with the intricacies of the process of logging on to a remote share from the Recovery Environment?
(Please do not route me to a chat session with a clueless person in India.)
Thank you,
Bruce
We don't require anything special beyond what Windows requires. Therefore I would refer you to Microsoft's documentation to determine what services are required for network sharing.
Essentially the two messages you mentioned are the same, i.e."I cannot talk to the machine\share." It does not mean that the machine was contacted and then it could not find the share.
Accessing a network share within the recovery environment and within Windows is the same. We use the Vista version of WinPE for Ghost 14. Instead of using the interface you could use DOS to do the mapping:
net use <driverletter>: \\ipaddress\share
hit enter and put in the username and hit enter again
then put in the password and hit enter again
Then if an error is returned, that can be looked since it gives more information than the errors you are seeing currently. You'll nethelp errors that can be referenced.
As a further troubleshooting step you can set up a new share on that drive and see if you can map to that location within the recovery environment as well (try on the internal drive for the computer the USB drive is connected to first).
Good grief; what a nightmare. I am sooo tired of spending hours documenting a complex problem to tech support and then, in the final analysis, having to find the problem myself anyway because tech support is either not sufficiently trained to resolve complex problems or simply refuses to take the time to do the work. I would not respond further to (my portion of) this mindless thread, except that I feel for others who likely do or will have this problem.
The problem and solution are documented here: http://support.microsoft.com/kb/214726
Symantec is a licensee of the Windows kernal. I doubt that the license agreement suggest that Symantec users should contract Microsoft for technical support for probems related to the Windows/Ghost interface. To the contrary, I suspect that Microsoft's license agreement specifically prohibits such behavior.
In question (1) toward the top of my long post I gave you the applicable error message and asked its meaning. All that you would have had to do would have been to look up that error message to resolve my problem. However, you answered virtually none of my questions, including that one. You did not even answer the question about where the list of error messages is located so that I could look it up myself. And the sparse answers that you did provide were wrong, demonstrating that you did not even read my post carefully, and that you were making wild guesses (e.g., entering the dot address in the network drive folder box without the share name).
I also provided a train of troubleshooting logic pointing to the logon (authentication) process as the culprit. I said "As I reported, when I enter the valid share name, the logon screen appears, indicating that contact with the host has been made. The problem is with the logon" You responded (below) with "Essentially the two messages you mentioned are the same, i.e. 'I cannot talk to the machine\share.'" (NOT!) From my troubleshooting it was clear that the problem was with authentication, as I suggested to you, because everything worked up to the point of authentication.
I also provided valuable bug feedback, important to Symantec if the company cares about retaining customers. Did you report the bugs to engineering? Aside from this forum, Symantec web support is practically non-existent. There is no list of revisions and problems resolved at each revision, for example. There is a link for error messages, but it goes nowhere other than to two FAQs; no error messages at all. The Symantec website is, in reality, a hodge-podge of disparate marketing websites, some of which have no "tech support" button at all. And, even when one finds the tech support button, there is practically no useful information there. The tech support area claims that support is available by phone, email, or chat. In reality, though, it is "cleverly" designed to avoid support at all costs. When one attempts to send a support request email, for example, most of the paths permit no email at all but rather send the user to chat. Chat leads to foreign-based operators who, in my experience, know virtually nothing technical about the product and are simply reading from automated support screens. Why not just put the automated support system up on the website and save the expense of the operators? The reason, of course, is that chat provides the appearance of support. Except that it really doesn't; it just infuriates the user and loses customers.
Thus, it is not at all clear that Symantec has a long-term view of business, given such nonchalant treatment of customer problems. Large sucking sounds are often heard as vacuum created by the mass exodus of customers from businesses who do not care.
Please note that the sequence that you provided on 2/9/2009 at 4:32 PM does not work. The net use command must be entered as a single dos command line string of the form:
net use z: <dot address of share host>\sharename <password> /user:<username>
All that your engineering staff need to do to fix this problem is to trap the error message "A specified logon session does not exist. It may already have been terminated" (message number 1312 as I recall) if the message is returned when the user attempts to authenticate. In that case, the Map Network Drive function can format the above DOS command and execute it to map a drive under whatever circumstances cause the message, all transparently to the user.
That is the way modern software should work. All of this technical nonsense should be transparent to the user. Reading 100 technical forum emails and searching for non-existent tech support resources to make a consumer software product work is beyond the pale. Your software people should have incorporated NetBios into the Recovery Environment in the first place, so that the Network Browse function would not fail, necessitating a lookup of the share host IP address, etc.
Symantec can find the resources to re-invent the wheel by creating its own clunky, amateurish GUI windows and controls in Ghost 14.0 instead of using the resources that Microsoft has spent hundreds of millions of dollars and countless man-years to create. But apparently the company cannot or does not care enough to find the resources to create a rock-solid, average user-capable recovery environment, without which Symantec exposes its customer base to great potential losses when all the expense and effort put into backups over months or years fail at the moment of restoral.
I want my mommy and a good, strong drink...
Let me answer all the opens from this thread:
As to the bare metal questions by Tomstin: Yes, we fully do a bare metal restore. It is one of our strengths. The options that you ask for are in the next to the last dialog on the restore wizard – the dialog before the summary screen where you commit to do the backup that is labeled Recovery Options. If you get to the Summary screen where you commit to the restore, you can backup one screen to find these options. They are labeled in Ghost 14 as “Set drive active (for booting OS)” and “Restore MBR”.
As to bhouston1:
When using the "Map Network Drive" folder form: \\192.168.0.100\c600 backup (c600 backup being the network share name that works perfectly for backups) the logon screen appears (apparently normal). I then enter the logon information for the D620 (the machine hosting the share). I then get the error message "A specified logon session does not exist. It may already have been terminated." I cannot get past this point. Clearly the recovery environment has found the host for the share (D620), because entering an invalid share name generates the error message "The network name cannot be found."Questions:(1) What does this error message mean?
Don’t know. It is not an error that we have run across in testing. This comes from WinPE and we would have to find out what Microsoft says which you have quoted a link for in a later post.(2) Where is the list of error messages in the documentation? Ghost 10.0 had these messages in the back of the manual, but I cannot find them in the Ghost 14.0 User's Guide.
We can only provide info about messages we generate. Microsoft does not make its full list of errors available for anyone to publish. So, rather than have a partial list, the list was dropped from the manual.(3) Please list any and all services that must be running on the computer hosting the share (the D620 in my case) in order for the recovery environment to operate correctly with a network share.
WinPE provides all networking functionality. There are no nice neat tools, like severices.msc, in the PE environment for users to use. There is functionality to drop a network driver onto the SRD. But that is all that we provide. It is all Microsoft give us to changed or modify.(4) Please suggest what else could be causing my problem.
Something in your network is not configured correctly or the networking drivers are not specific enough to you equipment. We cannot shop all NIC drivers so we only ship the most generic. But we do allow adding 32-bit drivers that correspond to you NIC via the custom SRD wizard.
Other problems/bugs discovered: (a) The "Recover My Computer" option works differently when accessed via the "Home" menu vs. the "Recover" menu in the recovery environment. (a)(1) When accessed from the "Recover" menu, following the instructions on pgs. 157-158 of the User Guide ("View by Filename" or "View by System") and entering a valid UNC path (using computer name or IP address of computer hosting the USB-connected share), the login and password screen appears upon pressing the "Next" arrow. However, upon entering valid login/password to the share host, the login/password screen disappears and nothing happens. No error message at all. At this point, the recovery environment is clearly stuck in a loop, because pressing "Back," "Next," or "Cancel" causes the blank login screen to re-appear. The only way to get out of the loop is to press the upper-right screen cancel "X" of the "Recovery Point to Restore" screen of the Recover My Computer wizard. (a)(2) When performing sequence (a)(1) from the "Home" menu, however, the message "Error EC950018: Cannot connect to the network resource" appears upon entering login/password.
I cannot find a difference in trying both. However, I also cannot reproduce the error you encountered either. Both entry points are into the exact same wizard during my testing.
(b) Under "Map a Network Drive," pressing the Browse button causes the "Browse for Folder--Select a shared network folder" screen to appear with the compressed "Network Neighborhood" world as the only folder shown. Double clicking the "Network Neighborhood" world causes the "Entire Network" world to appear after about 10 seconds. Double clicking the Entire Network world causes the "Microsoft Windows Network" world to appear after several seconds. Double clicking the "Microsoft Windows Network" world name does nothing, even after waiting several minutes.
This is from WinPE. We do not do anything to present this view. This is a function of WinPE. To me this suggests that there is something wrong in the home network such as there is no browse master or some other means of getting network information. However, this is just a guess based on experience of working with Microsoft networks.------
It appears that you may not be reading my posts very carefully. Among several questions in this post, I asked for a LIST of the Windows services that are required by "Map Network Drive" to be running in the machine hosting the share. I did not ask whether anything else is required to be running on the host. Why would I try entering just the IP address of the host in the Map a Network Drive folder box? It is not documented that way on the Map Network Drive window or in the User Guide. Both clearly state that the format needs to be the UNC name: \\host\share. Not surprisingly, when I enter only the host IP address (per your suggestion), the "The network name cannot be found" message appears, just as it does when any invalid share name is entered. As I said in my exhaustive email, "Clearly the Recovery Environment has found the host for the share (D620), because entering an invalid share name generates the error message "The network name cannot be found."
Because entering an IP is a valid way of giving a UNC path. It is especially helpful in situations like yours where it sounds like names are not getting resolved into IP addresses properly. There are many possible reasons for this ranging from a firewall on your network blocking all queries to a lack of a browse master in a workgroup environment to any number of other possibilities – all beyond the scope of support for Ghost.
As I reported, when I enter the valid share name, the logon screen appears, indicating that contact with the host has been made. The problem is with the logon. I indicated to you in the post the text of the error message generated by the logon attempt. Your answer has nothing to do with the logon process. Your suggestion is invalid and is related to the step PREVIOUS to the logon. Could you please read my post very carefully and answer all the questions so that we can figure this out? Alternatively, could you please escalate this to a support person familiar with the intricacies of the process of loggingPlease note that the sequence that you provided on 2/9/2009 at 4:32 PM does not work. The net use command must be entered as a single dos command line string of the form:
As written, it works for most users.
net use z: <dot address of share host>\sharename <password> /user:<username>
This does not work. Valid UNC paths start with ‘\\’. Otherwise, this is a valid one line command for ‘net use’.
All that your engineering staff need to do to fix this problem is to trap the error message "A specified logon session does not exist. It may already have been terminated" (message number 1312 as I recall) if the message is returned when the user attempts to authenticate. In that case, the Map Network Drive function can format the above DOS command and execute it to map a drive under whatever circumstances cause the message, all transparently to the user. That is the way modern software should work. All of this technical nonsense should be transparent to the user. Reading 100 technical forum emails and searching for non-existent tech support resources to make a consumer software product work is beyond the pale. Your software people should have incorporated NetBios into the Recovery Environment in the first place, so that the Network Browse function would not fail, necessitating a lookup of the share host IP address, etc.
You would have to ask Microsoft why they did not do it this way in WinPE. Symantec was not involved in creating WinPE. Plus Microsoft has been actively trying to eliminate NetBios. So , again you would need to take this up with them.
Symantec can find the resources to re-invent the wheel by creating its own clunky, amateurish GUI windows and controls in Ghost 14.0 instead of using the resources that Microsoft has spent hundreds of millions of dollars and countless man-years to create. But apparently the company cannot or does not care enough to find the resources to create a rock-solid, average user-capable recovery environment, without which Symantec exposes its customer base to great potential losses when all the expense and effort put into backups over months or years fail at the moment of restoral.
Symantec does not have resources to reinvent the wheel. It is for that reason that we licensed WinPE from Microsoft so that users could run the Recovery Wizard and restore their machines when they needed to and could not boot their computers normally. The pieces of the recovery environment that Symantec provides are as rock solid as we could make them. However, the whole thing sits on Microsoft’s WinPE. They control the environment. We only provide the menus and the software that actually does the recovery plus a few other utilities to help cover the gaps in the environment as best we could. And until something better comes along, we are stuck with WinPE warts, quirks, bugs and all.
I realize that this is a very old thread to most, but I purchased a copy of Ghost 14 recently to use on my Windows XP machine, and was having the exact same connection and error problems as described by Bhouston1. This is how I mapped my network drive using my user created recovery disk. After booting the recovery disk, I first chose to Start Networking Services, found under the Network tab. Then to map my network drive, after choosing a drive letter and entering the \\computer_name\share_name , I didn't press enter but hit the link "Connect Using a Different User Name". Here I entered the exact same User Name and Password that failed ( had I just hit enter at that point ) and it mapped the drive with no errors. I was only testing the ability to use my Recovery Disk, so I didn't run a full restore session, but I went as far as browsing the network drive to find the recovery point folder and feel fairly certain that if I continued the recovery process would succeed. Hope this helps others.
Hank