Backup Exec 2012 - Failure on System State Backup

Hi,  If able, let’s investigate your issue as well since it may prove to be the same or related.  When able, please provide all of the requested diagnostic information (1 to 20) for detailed review.  Keep in mind that System State backups and restore exclusively use VSS and that is why the current theory is that there is some unexpected VSS System State Writer discovery information causing the issue.  Also, as you have mentioned, since volume drive letter mount points were modified this would most likely be the cause of your issue.  Meaning, that a VSS System State Writer is still reporting the historical volume drive letter as a data path location, hence, the appropriate 0xe0000352 error.  Thank you.

Output and Log attached

11:> Physical System

12:> Remote Server

Since the affected system is a remote server (INTEGRATOR), please ensure that all diagnostics are collected from the remote server (INTEGRATOR).  For the debug procedure, (13)(a) will need to be performed on the remote server ((INTEGRATOR).  Thank you.

Here it is

Thank you for providing all of the diagnostic information so quickly!

For your issue, SYSVOL appears to be mis-configured.  SYSVOL is reporting two volume path locations:  ‘e:\windows\sysvol\*’ and ‘f:\windows\sysvol\*’.  SYSVOL typically only reports one volume path location and in this scenario the ‘f:’ volume is currently not valid on the server.  As suspected, this issue seems to originate from the volume drive letter assignments that were performed.

Use the MMC DFS Management utility (dfsmgmt.msc) to review the SYSVOL configuration.  If the SYSVOL Replication Group is not present, then manually add the existing group using the ‘Add Replication Groups to Display..’ from the ‘Action’ menu.  Also, review the reported volume path locations using Windows Explorer (explorer.exe).

Hope this proves helpful.  Please let us know the outcome of your review.  Thank you.

The requested files are attached.

Thanks!

Thanks for the diagnostic information.  The debug log (WIN2K11-SGMon.zip) is exactly what I need but appears to end abruptly: ‘BEREMOTE: [07/03/12 14:34:18] [26424]     2012-07-03T14:34:00.293 [fsys\shadow]…’.   Please review the original and provided debug log.  I will continue to review the information I have but ultimately a complete debug log is essential.  Please see what you can do to provide a full debug log.  Thank you.

The Replication Group is present and works fine. There was in fact a sysvol folder under volume f:\ but that changed before we installed the BE Agent on the server. I deleted all references to the old folder in the registry, without success

I understand your predicament.  The System State FRS VSS Writer Component is still reporting the volume path of F: as a replication folder.  You will have to convince the Component otherwise by using FRS Management utilities.  By the way, I've misspoke about using DFS Management earlier because it appears that your SYSVOL replication is using the legacy FRS and not the later DFSR, which has replaced FRS.

From the perspective of BE, the FRS VSS Writer Component metadata should not report the inaccessible F: volume path.  The metadata is located in the Backup Exec logs directory; example:  ‘c:\program files\symantec\backup exec\logs\{D76F5A28-3092-4589-BA48-2958FB88CE29} - FRS Writer.xml’.  You can use this as a diagnostic to know when you have successfully removed the inaccessible F: volume path without having to perform a backup each time as confirmation.  This metadata is updated by BE whenever a new explicit browse (or backup) of System State is performed (not a browse refresh, must be a complete re-browse).

Here are solutions that can be considered and will require in-depth research...

(A) Use the FRS Management to correct the inaccessible F: volume path.

(B) Migrate FRS SYSVOL to use DFSR SYSVOL.

(C) As a temporary backup workaround, create an ‘F:’ volume and path ‘f:\windows\sysvol’ and a data file ‘temp-workaround-sysvol-data.txt’.  This is not a validated backup workaround and should be used as a temporary last resort.  The restore impacts are unknown.  Please use with extreme caution!

When able, please let us know the outcome of your research and solution.  In the meantime, I will still continue to investigate a solution for your dilemma.  Thank you.

I created a new backup job that only backs up the System State.  The debug log is from that job.  I terminated the log capture shortly after the job ended, with errors, in Backup Exec.  If you need data from after this point, I can capture another debug log.

Thanks.