VSS Snapshot warning. File oem0.inf is not present on the snapshot

Check your selection exclusion list of your backup selection list, and make sure that the files above are not INCLUDED for backups. If they are, and don't exist, you'd get that error message.

Hi,

What if the system state automaticly tries to backup the c:\windows\inf folder?
Is there another way to eliminate this error?

Thanks!

Hi,

What if the system state automaticly tries to backup the c:\windows\inf folder?
Is there another way to eliminate this error?

Thanks!

Orcanic is right. That is exactely what is going on. BE gives warnings about skipping files during the System State backup. These files dont exist in c:\windows\inf folder. And System State backup not allows to except anything from it. There are no entries for these oem*.inf files in registry. It looks like something goes wrong with creating VSS snapshot stage. Isn't it? Any help?
Thanks!

Cool work-around! =)

I also had this problem.  According to the Symantec knowledge-base you can ignore the issue because it just means that VSS thinks a file should be there, but it isn't anymore.

The most likely cause was that an uninstall did not fully clean up after itself and left a reference to that INF file.

Creating the dummy INF files should fix this and is the fix any sane person would use.

However, being anal-retentive I could not leave well enough alone and decided to search for the references to these missing files.  As per the comment above, nothing in the registry (which wasn't a major surprise).  I then used Windows' search to look for "OEMx.INF" in the content of files on the system drive.  The files it found were log files in the Windows/Inf directory.

Here's the kicker.  Both OEM fies it was complaining about (OEM4.inf and OEM5.inf) were being referenced by a prior version of the Symantec Endpoint Protection (v11.0.4202 MR4 MP2 -- I believe).  Recently I had upgraded this machine to v11.0.5.  The Symantec installation is supposed to remove the prior version and install the new version.  Obviously, this did not happen.

The recommended action is to reinstall the offending program (in this case it requires removing 11.0.5 and reinstalling 11.0.4204) and then uninstalling it using something like Microsoft's Clean Uninstall utility (I believe that's the name).  Then I'd have to reinstall 11.0.5 again.

Unfortunately, this is not the first time that I've run into one Symantec program being the cause of pain for another Symantec program.  My theory is that beyond the name "Symantec" on the box their applications share nothing in common (including an awareness of each other).  In this case, it's most likely just a poorly tested uninstall routine.  However, in the past PcAnywhere has made SEP barf, SEP has made PCAnywhere not function, BackupExec has broken down in tears because of something SEP said to it, etc.

Our original theory for buying Symantec products was that perhaps since everything came from a single vendor these program might be aware of each other and not need as much manual tweaking to happily coexist.  This has woefully not been our experience.

Symantec if you are listening... It is a real benefit (and added value) to your customers if your programs are designed to work together.  It would be beyond wonderful if things like SEP actually detected other Symantec programs on the system and asked you about automatically configuring themselves for peaceful coexistence.

I've been around long enough to know that the guy who keeps telling us to switch to AVG has simply drunk different Kool-Aid.  In the end, nothing is perfect, but every time I get a vendor who's stuff isn't compatible with it's other stuff I am magically transported back to the days of PDP-11's and DEC in the late 1970's.  DEC had a wonderful rendition of the Fiddler on the Roof "Horse Mule" song, it went something like, "it's a hardware problem, no it's a software problem, no it's a hardware problem".  Eventually we all bought microcomputers and DEC disappeared into one of Stephen Hawking's black holes where they will sing that song for eternity.

If you read this whole thing II hope my rant may have bought a smile to your face and a knowing nod of agreement.  Perhaps I might have even given you some useful information in the first three sentences.

I'm going to go resign now and start a career as a blogger.  This is just too much fun.

The problem with the upgrade from version 11.0.4xxx.xxx --my install is 11.0.4014.26 to version 11.0.5002.333 is that they put the incorrect path in the service definition.  The service Symantec Auto-Upgrade Agent has the location of the file as C:\Program Files (x86)\Symantec\Symantec Endpoint Protection\SmcLU\Setup\smcinst.exe.  The installation package puts the file in C:\Program Files (x86)\Symantec\Symantec Endpoint Protection\smcinst.exe - two directory levels up from where the service says it should be.

I exported the service key and updated the ImagePath key to the correct path to fix the problem. 

BTW -- I agree with mjaarons rant about Symantec products should work with other Symantec products.  I use Symantec Enterprise Vault and BE 12.5.  When we upgraded to EV 8.0.2, the BE Enterprise Vault agent would not allow a backup to complete properly because the media server could not get access to the remote SQL server.  I ended up removing the EV agent and went back to the method we used to backup the EV server when it was on EV 6 SP4. 

Bear in mind that this same issue has been seen with the inf files for some non Symantec products  as well - nVidia graphics cards have been known to cause the same types of errors as it relates to how a product registers with the System State/VSS data on the operating system and not how Backup Exec itself relates to the product that causes the issue.