11 D System State Backup

[Kevin_DiBricida]

After upgrading to 11 D we seem to be getting the following error on our Domain Controllers.  Symantec says to ignore the error in the knowledge base but does anyone know of a way to confirm that the system state is actually getting backed up?  When I go to the restore section in Backup exec On the Domain Controller the active directory section says "none" is this normal?

Event Type: Warning
Event Source: NTDS Replication
Event Category: Backup
Event ID: 2089
Date:  5/21/2007
Time:  9:06:25 PM
User:  NT AUTHORITY\ANONYMOUS LOGON
Computer: DC1
Description:
This directory partition has not been backed up since at least the following number of days.
 
Directory partition:
DC=ForestDnsZones,DC=cb,DC=domain,DC=com
 
'Backup latency interval' (days):
90
 
It is recommended that you take a backup as often as possible to recover from accidental loss of data. However if you haven't taken a backup since at least the 'backup latency interval' number of days, this message will be logged every day until a backup is taken. You can take a backup of any replica that holds this partition.
 
By default the 'Backup latency interval' is set to half the 'Tombstone Lifetime Interval'. If you want to change the default 'Backup latency interval', you could do so by adding the following registry key.
 
'Backup latency interval' (days) registry key:
System\CurrentControlSet\Services\NTDS\Parameters\Backup Latency Threshold (days)

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

[Dave_Hunter]

Having the exact same issue on all our DCs. When you look at the restore the AD says None. I have read through other forums and this is an issue for lots of people.  As many have said, Symantec says it is okay to ignore but how can we be certain. Will someone from Symantec please answer.

[Dave_Hunter]

I have also noticed in the job logs that it does list the AD components being backed. I checked logs from before our upgrade and after and they show the same.  So it looks as Symnatec says, like the components are being backed up but the application is not resetting the bit.  I guess the only way to be completely sure is to try a restore, but that won't be that easy.   So the question is, if Symantec is aware of this, where is the hot fix.

[Mark_H]

While not ideal I'd probably schedule an NT backup to grab the system state every so often.

Since only M$ will support ntbackup of AD and thats the one service that scares me the most to lose I typically run system state and Backup software (currently Data Protector) together just to CYA.

[DY]

This needs to be revisited.  Here is a link to the Microsoft Knowledge Base referring to this very issue:

http://support.microsoft.com/kb/914034

About half way down, it notes, "Third-party backup programs may use a method that calls the backup API that updates the attribute. When these programs use this method, it causes the DSA Signature attribute to be updated."  This means BackupExec should be executing this method and it clearly is not, or the warning would not appear.

Whoever is monitoring this forum, please respond here with an update on this issue.  Warnings come up for a purpose.  Ignoring it is not acceptable.

[DY]

Can someone please address this??  We are getting this error on a daily basis and scheduling an ntbackup job defeats the purpose of using your software.

[DY]

I opened a case with Symantec about this issue, and they responded by saying the warning is left on intentionally, but did not give a specific reason.  They hold that if a successful system state backup is completed, this warning can be ignored.  I am not completely satisfied with this, but it seems that is as far as they are willing to go.

[ricr]

We have been getting this error for a month now as well.  It is completely absurd that Symantec would say to simply ignore an error warning with this level of potential importance.  What does Symantec suggest users do if there really is a problem with AD somehow not getting backed up.

This needs to be fixed immediately!

 Just one more example of Backup Exec being Symanteced

[DY]

I opened a case with Symantec regarding this issue and made it clear I wanted answers.  I was transferred to level 2 support which is 1000000x better than level 1.  After some discussion with the engineering team, I found that they worked with Microsoft on this very issue and could not come up with a solution.  The technician was very knowledgeable, and could even help out with event log troubleshooting which I would never trust with level 1.

Before I closed the case, I wanted to do a test restore.  What I did was take a disk backup of the System State and the C drive (I was specifically told a restore needs to have the C drive backed up as well for DC role restoration/utilities), set up a standalone network of two computers for a Backup Exec media server and destination DC, installed Windows Server 2003 SP1 on both servers since that is what our DC is running currently, copied the disk backup file onto a USB drive to put on the standalone media server, and tested a full restore in a disaster recovery situation.

The only problem I encountered was different hardware which required a recovery console "bootcfg" command, and the recovered local administrator password is your Active Directory Restore password which was created during dcpromo.  Also I had to configure the partitions the same as our existing DC since the sysvol is separate from the C drive, something to keep in mind.  When it booted up I had a fully functioning DC, same domain settings and all objects, I could even take a computer from our existing network and get a gpresult off the restored DC. 

If you have the time it could help to do a test restore like I did, if for no other reason than to experience a System State restore.  My test was successful though.  I will check back here if there is any more I can help with since the moderators never seem to respond to problems that require actual work.