08-21-2012 01:13 AM
I'm running in a recurrent problem with SSR2011 :
We use to backup our server running under SBS2011 using SSR2011 onto a backup directory on a NAS. The backup directory is protected and access is granted to administrators (me, of course). Note that security on the NAS is managed by Active Directory.
This uses to work perfectly except when server is rebooted (i.e. for updates)
After server has been rebooted, the next backup fails because access to the backup destination is denied :
Erreur EC8F17B7 : Impossible de créer des points de récupération pour l'opération : Sauvegarde du lecteur de Réservé au système (*:\), (C:\), DATA (E:\).
Erreur EC8F03ED : Impossible de créer le point de récupération.
Erreur E7D10041 : Impossible d'établir une connexion de réseau à \\nas1_cbl\svg_sbs.
Erreur EBAB03F1 : Plusieurs connexions à un serveur ou à une ressource partagée par le même utilisateur, en utilisant plus d’un nom utilisateur, ne sont pas autorisées. Supprimez toutes les connexions précédentes au serveur ou à la ressource partagée et recommencez. (UMI:V-281-3215-6071)Détails :
Source : Symantec System Recovery
Sorry for the error message in French essentially, it says that SSR was unable to connect the NAS on the network because many connections to a single resource (the NAS) using more than one name are not allowed.
However SSR knows only one name (mine) which worked fine before reboot of the server.
I tried to remove any protection on NAS directory (access granted to all): same error.
NAS can be accessed from the server using windows explorer. NAS can even be accessed from SSR using Recovery Point Browser. But no backup can be performed on the NAS and previous recovery points are declared unavailable !!!
Up to now, the only solution I have found is to delete the current backup work, remove all protection on the NAS (not only for the Backup directory but fot the NAS as a whole), create a new backup work (which requires a name and password even if not needed - I use always the same - mine), have it run during a couple of backups and then reset the protection on the NAS.
Any hint on why this happens? and how to cure it?
BTW, I would like to know how to cancel all connecions to the NAS as suggested by the last sentence of the error message. I have already reset completely the NAS without any succes...
08-21-2012 01:26 AM
Have you tried using ip address instead of hostname when specifying the backup destination?
http://support.microsoft.com/kb/938120
08-21-2012 07:53 AM
Yes, I did. It works for a new backup but does not consider previous backups which stay unavailable and starts with a new recovery point (does not consider the previous full RP for creating an incremental RP). I really fear that at next reboot of the server, I will have no more access to the NAS , neither by name nor by IP...
Well, OK it is a bit more handy than my previous solution but does not solve the problem of continuity of the backups
I tried too the command NET USE {NAS name} / DELETE which is supposed to clear previous connections to the NAS but SSR still continues to show the same error.
I also tried to stop and restart all services connected to SSR on the server, same result...
Thanks for your help.
08-21-2012 09:01 AM
Well, OK it is a bit more handy than my previous solution but does not solve the problem of continuity of the backups.
08-22-2012 02:12 AM
Sorry for my poor English... It may cause some misunderstanding...
1) "...a new backup destination..." is not actually new, it's the same with another name. Previously recorded RPs are still here. I admit that using an alias for the path to the destination, the system is not clever enough to detect that it arrived at the same place. However, if I have to change the name for the path each time I reboot the server, I will have a lot more full RPs than expected, thus consuming more disk space... and also more time in switching aliases for the path, trying to remember in which set of RPs is the file I want to recover, etc. Therefore, this "solution" is not an "industrial" solution. It is at best a temporary workaround.
2) "more handy" was intended to mean easier to implement than my previous workaround where I had to perform more operations to restart safe backups. However, as said here above, this is NOT a solution (at least in my mind).
I know I'm a bit of a perfectionist, but having little time to spend on these computer issues (this is not my main activity) I do like fixes that fix definitively errors ;)
I suspect that the problem is not only on Symantec side but also on M$ side as network access is managed by the system... but why SSR is the only software affected by reboot of the system ? Our antivirus solution (Symantec Endpoint Protection) has no problem with server reboot though it has to deal with much more network destinations...
08-22-2012 02:29 AM
08-22-2012 03:33 AM
Hi Chris,
1) I knew that computers are a bit more stupid than humans... I wish I could see my mother-in-law with new eyes each time my wife tells me to use another way to go to her ;)
2) OK I confess I'm stupid too. I now understand that designating the NAS by its IP address is supposed to solve definitively the problem and that SSR will no more forget its way to the storage directory.
I have not tested yet (I don't like rebooting the server too frequently) but I will check at next mandatory reboot and post here to confirm the solution.
Thanks a lot for your patience with this damned dumb Frenchy ;)
Pierre
08-22-2012 03:43 AM
No problem. Keep us posted with your results once you have tested this then.
10-23-2012 11:36 PM
Back after 2 months test : I got at least 4 times the same kind of error where SSR was unable to get access to the NAS, even using IP address for it.
Error message :
Erreur EC8F17B7 : Impossible de créer des points de récupération pour l'opération : Sauvegarde du lecteur de Réservé au système (*:\), (C:\), DATA (E:\).
Erreur EC8F03ED : Impossible de créer le point de récupération.
Erreur E7D10041 : Impossible d'établir une connexion de réseau à \\192.168.1.250\svg_sbs.
Erreur EBAB03F1 : Accès refusé. (UMI:V-281-3215-6071)
It seems to appear randomly (no reboot of the server before occurrence of error) and it is in no way linked to a bad password as it worked the following day without any action on my side...
I have now installed SP3 and will see if things improve...
10-24-2012 02:53 AM
This could be a Windows issue but the logs will need to be analyzed before this can be confirmed.
If SP3 does not help, please open a support case for this issue.