cancel
Showing results for 
Search instead for 
Did you mean: 

Backup FAILED: An error occurred retrieving the WMI repository..

Robin_Farrell
Level 3
An error occurred retrieving the WMI repository data directory.
The WMI repository could not be backed up.

I have been getting this error for 2 weeks now and every nights backup fails because of it, I have tried the fixes in the knowledge base and have even written a batch file to automatically rebuild the repository on the main server (on which backupexec is installed).

We are using this to back up 7 servers, can someone please tell me if its a different server I should be concentrating on or is it contained to the server backup exec is installed on??

Also can someone please tell me how to get rid of this error as it doesn't seem like veritas' OR microsofts solutions work:/
161 REPLIES 161

William_Yauch
Level 2
I just spent $245.00 with MS on this issue. Here is what they did:
1.) Reregestered the dlls in the wbem folder
Command used by MS in the Wbem folder:
for /f %s in ('dir /b *.dll') do regsvr32 /s %s
2.) stop and disabled wmi service
3.) renamed the wbem folder
4.) started and reenabled the wmi service
5.) Everything is working for now.

If you don't see an update by wednesday Dec 9th 2005 that means this fixed the problem.
Note: This did occure after applying ms updates sp4

Antony_Grace
Not applicable
I remember having this problem years ago and contacted Veritas support about it. At the time, as I remember they had no solution and the fix was to upgrade to the latest version (i.e. the normal "fix" when the support technician doesn't have a clue). Then, magically, it started working again (way after I upgraded mind so this didn't fix it) so the call was closed.

Since then, I've been ignoring it to be honest cos I really coudn't be bothered to fix something that isn't really that important on our servers (i.e. WMI repository).

I just got called about a server which is getting this problem again and came across this thread, and the responses from Veritas have really made me laugh. The issue is complex so log a support call!! Come on Veritas, are you telling me every person who has this problem is getting a different issue, so you couldn't possibly release a fix for it or maybe a document with the 3-4 different causes (I fail to believe there are more than this given the posts here seem to all describe exactly the same thing with the exception maybe of whether SAV is installed or not)?! Or is it so few people have paid the support call for it so you haven't actually bothererd to try and find a fix?! In my years, I have yet to find a worse support service than that from Veritas (with the exception maybe of Dell, but even then it's close) and I've logged many calls with them, most of them being fixed by me while I was waiting for them to get back to me.

Anyway, rant aside, I will try this latest fix from William (as I have tried all the others so thanks for hopefully a new solution fella, at least someone is working on the problem!) and let everyone know if it works next week sometime as we're getting the error once every 2-3 days at the moment.

Many thanks!

Antony

Gene_Beamer
Not applicable
All,
I do not believe Norton Antivirus is an issue. I have a 2003 SBS server with Trend Securites software. This server has been having the problem on and off for the past month now. For now i am just going to remove wbem folder from the backup since it is backed up under the sys state. However I am still going to follow this forum.

Oh someone mentioned about memory resources. This server is running at 99% cpu usage right now because of a Database.

Gene

Don_Mulvihill
Level 4
Has anyone else tried William Yauch's solution he posted on 12/9/05:

"I just spent $245.00 with MS on this issue. Here is what they did:
1.) Reregestered the dlls in the wbem folder
Command used by MS in the Wbem folder:
for /f %s in ('dir /b *.dll') do regsvr32 /s %s
2.) stop and disabled wmi service
3.) renamed the wbem folder
4.) started and reenabled the wmi service
5.) Everything is working for now. "

Dean_Payne
Not applicable
First I tried the manual backup of WMI to the WBEM\Repository, and it went fine.
I tried what W. Yauch suggested, registered the DLLs, went into the properties for the WMI service and set it from "automatic" to "disabled", then stopped it. I then tried to rename the WBEM folder, but got a sharing violation. Rather than take down the server, I restarted the WMI servce and set it back to "automatic". I then went into the Symantec AV 10.0.2 and excluded the WBEM folder from autoprotect. This morning, I got a call that the backup ran fine! It had failed twice in a row, after installing SAV 10, loading all the Win2k Critical Updates and MS AntiSpyware.
Whether this was fixed by re-registering the DLLs or excluding the WBEM folder, I do not know. Neither have I had a chance to run it cleanly more than once. (A manual backup DID run to completion, but the 2 scheduled backups failed.) The previous antivirus was InnoculateIT 6. I am using BE ver 9.0, from what I can tell, upgrading to 9.1 would not have helped any.
Thanks for posting suggestions on this thread, you guys have been more help than the Symantec technicians!

Jonathan_Pace
Level 2
I'm still having this problem. Why the hell doesn't veritas release a fix for it?

It's affecting nearly ALL of their customers.

Doing a great f#cking job leaving us with stuffed backups everynight Veritas!

Whenever I want a tape, I have to

1. Cancel the job (puts it into a never ending canceling state)
2. Restart all backup services
3. Wait 10 mins for it to do so
4. Sometimes it bombs out and I have to manulally restart them
5. Run and eject job to get my half written tape out
6. Think to myself "What a useless Peice of Sh#t bit of software, while I am spending another 15 mins driving the tape to another site because its missed the early morning courier to get it off site..

I am sure I am not the only one doing this. Probably about another 100,000 users doing \ saying the same thing.

William_Yauch
Level 2
The solution I posted did fix the problem. I have had good backups for over a month. Good luck.

William

Steve_Crow
Level 3
So far, changing the WMI backup time to 3 hours has worked great on 3 different machines that were having this problem. All backup by the same server and job. Tried all the veritas solutions. Had not tried the expensive Microsoft solution yet. I'll post back if this fix does not hold.
Have a great day,
SC

Steve_Crow
Level 3
So far, your solution has worked for me. I hope it continues to work. Has it been working well for you?
SC

Viktor_Glinski
Level 3
To be honest, I don't know. I made several changes including the one where you extend the timer to 3 hours.

I don't remember all the changes but since I made them I haven't had any problems.

Keep us updated how it goes for you.

Henry_Dyck
Not applicable
Veritas software is garbage.
I've had this WBEM problem off and on for over a year now. Sometimes it works, other times it doesn't.

What kills me is the HORRIBLE Veritas service. I've had other issues with this garbage product and have called in to service for help.
In each instance, the only time I got any kind of call backs were well past our business hours, usually past 9:00 pm.
Despite me calling them back (and NEVER getting ahold of anyone) and leaving messages telling them that they have to call me during business hours, this never happened. Eventually, two weeks went by and all I ended up getting was a phone message left at 9:15 pm telling me that since I haven't called them back they were closing the call. This despite the fact that I called them back every single day for two weeks and leaving them messages telling them to keep the call open and I still needed help.

For those that can convince their manager to switch to a different backup service please do so!
Dealing with Veritas products and their customer support have easily been the most painful experience of my life! I've worked in the industry for close to 15 years and I've never dealt with anything like it.
Not only is their product complete garbage but their customer service is beyond reproach.
Good luck getting any type of help regardless of what kind of Gold or Premium coverage you have.
Chances are you're going to have to deal with someone that barely speaks english let alone knows what they're talking about.

721308991
Not applicable
Any more updates by anyone? I tried rebuilding the repository, it's worked on one system for over a month now, another system I have it didn't work.

Dimitri_Putilin
Level 3
It seems that running a pre- and post- batch files to stop and start WMI does NOT work. As soon as the backup job starts, it starts the WMI service also.

I'm going to see if there's a way to set the WMI service to DISABLED from a batch file, and if that makes a difference.

Dimitri_Putilin
Level 3
Here's the latest:
As mentioned above, stopping the WMI service (winmgmt) in a pre-command and starting it after the job does not work. What ends up happening is that the WMI service is stopped (by the batch file) and re-started (by Backup Exec) right as the backup job starts.

However, that in itself seems to have helped, because the problem had not recurred until today. What happened today was also a little different from before: the job was still "running" after 36 hrs., although it's set to auto-cancel after 20. But it was stuck on the Repository folder itself, not on regevent.mof; AND, I was able to stop the WMI service (normally it would hang in this situation); AND, as soon as the WMI service stopped, the backup exec job continued as if nothing happened (then cancelled itself when it realized it was past its runtime limit).

Now I am going to try something different -- setting the WMI service to "disabled" in a pre-job batch file using SC.EXE from the Windows NT Resource Kit, and stopping it; then setting it to "auto" and starting it the same way in a post-command.

SC.EXE can be downloaded from Microsoft here:
http://www.microsoft.com/ntserver/nts/downloads/recommended/ntkit/default.asp

My batch (.CMD) file to disable and stop the WMI service looks like this:

echo Starting time: >> c:\stopwmi_log.txt
time /t >> c:\stopwmi_log.txt
sc config winmgmt start= disabled >> c:\stopwmi_log.txt
net stop winmgmt >> c:\stopwmi_log.txt
echo ----------------------------------------- >> c:\stopwmi_log.txt

I ran one test job so far and it worked, let's see what happens over the long term!

Dimitri_Putilin
Level 3
In case anyone is using Backup Exec 9.1 and is thinking of implementing my suggestion from the previous post, read this or your post-job command will not run:

http://seer.support.veritas.com/docs/267184.htm

Bugs within bugs, and if you want them fixed you have to buy the next release with new and improved bugs. Is there a better business than being a software publisher? :)

Geoff_Warner
Level 2
Just wanted to add myself to the list of affected users - we just started experiencing this problem 3/31/06. I'm going to try excluding the directory and cross my fingers (since Veritas support hasn't given us any other options).

Dimitri_Putilin
Level 3
Geoff,

My experience indicates that it is not possible to exclude the directory. If you are backing up System State, the directory will be backed up regardless of exclusions.

Geoff_Warner
Level 2
Thanks for the reponse Dimitri. Did this work for you:

"Now I am going to try something different -- setting the WMI service to "disabled" in a pre-job batch file using SC.EXE from the Windows NT Resource Kit, and stopping it; then setting it to "auto" and starting it the same way in a post-command."

Dimitri_Putilin
Level 3
Geoff,

So far, no problems! However, it has only been two and a half weeks, and this problem has been known to disappear for a while. Personally, however, I think it's fixed.

- Dimitri

Ceri_Richards
Level 2
Hi All,

Just to add my name to the list of ANOTHER user experiencing this problem!!!!

So far we've tried excluding the WBEM folder from the SAV 10 real time protection with no joy (apart from a fortnight of successful backups!!!!). However we did notice that even though the folder is excluded, the Rtvscan.exe process still accesses several files in the WBEM directory which it shouldn't do (used the un-locker tool to view this)!!! Also seems very strange how the virus def files are out of date whenever this problem occurs, requiring a reboot to fix!

Next step is to try the expensive MS fix from William Yauch, still a little bit reluctant to try the fix from Dimitri but may use it as a last resort!!!!

Also, one of my colleagues has tried to contact Veritas Tech support several times regarding this issue - to date we've never had a techy call us back - only sales people asking us to upgrade to version 10!!!! We're now seriously looking at moving to another backup vendor due to the problems we've encountered with this release of Backup Exec and the generally garbage Veritas support!