Backing up Active Directory: V-79-57344-33928 - (AD LDS) database was not found.

[cypher]

Hello,

We have this error from time to time, but it usually fixes itself without any end user intervention.  However I am getting this error three nights in a row now on one of our domain controllers.  This started happening on Wed morning, and continued through Friday morning.  In all three instances the error message in the log is:

Job ended: Thursday, October 29, 2009 at 1:18:54 AM
Completed status: Failed
Final error: 0xe0008488 - Access is denied.
Final error category: Security Errors

For additional information regarding this error refer to link V-79-57344-33928

Errors
Click an error below to locate it in the job log Backup- \\dc1.domain.com\System?State V-79-57344-33928 - Unable to complete the operation for the selected resource using the specified op...

 
So I checked the selections and under the server in question, I can see System State > Active Directory > C:_WINDOWS_NTDS, and this is all checked off.  I did a test Resource Credentials for everything in this backup and it all returned successful so I'm at a loss.

Under Settings > Microsoft Active Directory for this job properties we have all three boxes checked (GRC, Consistency Check, Continue if Consistency check fails.)  Backup method is greyed out, but says Full - Back up entire Active Directory.

We are using Symantec Backup Exec 12.5 for Windows Servers
Media Server Version 12.5 Rev 2213
Administration Console 12.5 Rev 2213
Desktop and Laptop Option: Version 3.1 Rev. 3.41.32a
Installed updates:
Service Pack 2
Hotfixes:
324947
317436
325647
319242
324012
326004
323894
324011

Thanks for the help, we really do appreciate it!

[Hemant_Jain]

This is a GRT error, you would get when Backup Exec tries to populate individual active directory objects to show the catalog information. Check which specific objects it is failing on. Running Backup to disk should help or you may want to run a duplicate backup to disk, to avoid failures. But, later at the time of restore, you might need to ensure enough credentials for the Backup Exec logon account, on the active directory.

Thanks

[cypher]

We are doing backup to disk.  The media set is a 1 TB NAS by Buffalo.

How do you determine which objects it's failing on?  I did an expand all on the log I get and it doesn't really pinpoint the issue.  It's been failing for almost a full week now.  Previously we would only get this in spurts... not enough to worry about.  Maybe once a week, or once a month, or a few times per week, but it would always fix itself.  Right now this particular job 'fails' (which I don't think it fails because I can see all the servers data in it looking through the restore catalog) every day since last wednesday.

If you know of a way to determine the cause, please let me know.  Also what is GRT?  Granular something technology, right?  That is something we were never able to get work on Exchange because it didn't support backup to disk.  GRT is some kind of beta or experamental thing right?  That's why it's very instable? 

[Hemant_Jain]

GRT is Granular Restore technology. It is not in beta or testing, it works with supported devices. If there are limitations, they are documented. If this device could not get it working for Exchange, i would be interested in knowing, was it similar messages, that you were getting there? GRT gives you the ability to restore individual active directory objects from a complete system state backup. If you would like to disable GRT backup, you can go to the backup jo properties and uncheck the option "enable granular...  " from "Microsoft Active Directory" tab. That would disable GRT, which is good if you are interested in disaster recovery using System State. Butt, later if you may want to restore individual active directory objects, you would need to use GRT for the same.

Please mark it a solution, if this information helps.

Thanks

[cypher]

We backup to a Buffalo Terastation II PRO NAS .  Basically it has a share on it called backup, and we write to that \\tera1\backup.  I've installed the latest firmware on this device as well.

What's strange about this feature, it used to work fine on the domain controller (never on exchange).  In exchange I believe we would have to create a recovery storage group, recover everything to it, then use Exchange 2007's tools to pull the individual mailbox were looking to recover.  A bit more work yes, but not impossible.

GRT sounds like a nice feature for Active Directory, but I don't know if it's nessesary.  We don't delete objects right away like some might.  We disable them and move them to a disabled objects OU.  In 6 months later we finally delete the object from within that OU.  So maybe if I disable GRT, which for some reason used to work, at least I can have a successful job.

At my last job we used BackupExec 11d.  Exchange GRT worked fine as long as we kept Exchange 2003 SP2 off of the box.  But we also backed up to HP Ultrium 400GB tapes.  At this job were not backing up to tapes (don't want to loose them).  Instead we backup to NAS, and script the NAS to copy it's contents to another.  So the differences in my experience is the Backup Exec version (now 12.5), the backup destination (Now NAS), and versions of everything (Windows 2003 R2, Exchange 2007).

[Hemant_Jain]

NAS devices did have some known issues in the past, and not all devices have been completely tested with best results with GRT. That is one of the reasons, i am expecting for the behaviour. But, it is something to do with permissions on the active directory database. In order to perform GRT, Backup Exec has to go, logon to active directory and browse through individual objects. It can encounter this problem, if it fails to access some or the other active directory objects. So, try a backup with GRT disabled and see if that works, to isolate the problem and then you can decide which way you would prefer.

Please mark it a solution, if this is useful.
Thanks

[cypher]

OK I turned it off for the daily incremental and weekly full backup jobs.

I also checked and we had the same error last Saturday.  On Saturdays the backups go to a different NAS.

Actually I had it backwards in my previous post.

Weeknights, the backups go to a SNAP server NAS.  This is an incremental backup.
Weekends the backups go to the Buffalo Terastation II Pro NAS.  This is a full backup.

It fails on both.  This is from Saturday:

 Backup- \\dc1.domain.com\System?State V-79-57344-33928 - Unable to complete the operation for the selected resource using the specified options.  The Active Directory, Active Directory Application Mode (ADAM) or Active Directory Lightweight Directory Services (AD LDS) database was not found.

It uses a Backup user account.  This account tests out successful when doing the tests, and nothing has changed with this user account.  

I'll let you know how the backups go with GRT off.

 

[Hemant_Jain]

So, does it work withoug GRT selected?

[cypher]

 Yes.  We were error free last night.  GRT off fixed the problem.

Any idea why that would be?

I guess it still backs everything up, but a restore would be 'all or nothing' not picking individual objects.

I think our plan of never delete AD objects, just move them to a disabled objects OU, then delete them in 6 months might mitigate the necessity of restoring individual AD objects.  Feel free to correct me if I'm wrong.

[Hemant_Jain]

Yes, that is a good idea. In fact, when you do it using Backup Exec, it also restores from deleted objects container. So, if you are moving to disabled objects OU, it is a good strategy to go about. Otherwise, if you want Backup Exec to do it for you, you might have to troubleshoot this error message, for which i would recommend checking with tech support, as the job log is not clear enough, so we may require debug logs, so that they can be analyzed to find out specific objects in which you may require permissions. But, yes the disabled objects method thaty you have currently implemented looks good to me.

Please mark it a solution, if this is useful.
Thanks

[Gene_Tang]

FYI,

Came across this thread when searching for something else.  The reason for your problem is listed here:

http://seer.entsupport.symantec.com/docs/328487.htm
https://www-secure.symantec.com/connect/forums/access-denied-after-hotfix-324011-installed

In short, it is primarily to do with the fact that you have update 324011 installed, are using AD GRT and B2D Backups.  The whole reason I'm searching is because with the release of BE12.5 SP3, I'm unsure if this issue has been resolved, given that hotfix 324011 is part of the service pack. 

Unsurprisingly Symantec's fix for the problem is: 1) uninstall the hotfix, or 2) Redesign your backup scheme to skip B2D and go straight to tape.  In this day and age, who uses tape anymore when hard disks are so much cheaper?

Gene

[Spencer_Simpson]

Those links are now dead; here's a link to a 2010 version of the KB article on the Wayback Machine:

https://web.archive.org/web/20100130210031/http://seer.entsupport.symantec.com/docs/328487.htm