Video Screencast Help

Is a SQL agent needed for BackupExec 2012 and Symantec Endpoint Protection?

Created: 18 Nov 2012 • Updated: 21 Nov 2012 | 3 comments

I upgraded the Endpoint Protection to 12.1.2 and now my backups are failing with the following errors.  The folder for the 12.1.1101 is no longer there since the upgrade.  I unchecked the C drive and then reselected it, so I don't know why it's still in the selection list.

I am not using SQL other than what Symantec uses it for.  Do I have to by a SQL agent now?  I hope not!  Never needed it before.

The following backup sets contain Microsoft SQL data. Symantec recommends that you install and use the Backup Exec Agent Applications and Databases to better manage your SQL data:


Backup- \\SERVER\System?State VSS Snapshot warning. File c:\program files (x86)\symantec\symantec endpoint protection\12.1.1101.401.105\bin64\smclu\setup\smcinst.exe is not present on the snapshot. 

Comments 3 CommentsJump to latest comment

Colin Weaver's picture

What the second error means is that the upgrade of SEP left something behind in the registry relating to the old program binaries, but unfortunately still deleted the files. This shows up as an error in the System State backup. You wil probably need to contact the team that supports SEP to identify where this invalid reference to the old path is in the registry to get it removed.

The first message is a warning. However you would not normally see it against the SQL database used by Backup Exec so do you have another SQL instance installed on the C: drive?

M Strong's picture

Just to bump the issue. This is not the first time I've seen this occur. I've seen the same symptom after at least the last 2 SEP updates.

After deploying new SEP client using SEPM, the backup jobs (Symantec Backup Exec 2012) fail on several servers citing the same missing file (smcinst.exe) from vss snapshot. The missing file is always from the previous version of SEP client. In our case it seems to affect only 64 bit machines running Windows 2008 R2. I am not sure if it affects Windows 2008 (prior to R2 release), but it does NOT seem to affect our 64 bit Windows 2003 servers. All backups of Win2k3-x64 succeeded. Only backups of Win2k8R2-x64 fail.

To fix this - I typically only have to change 2 registry entries in each server affected. Update the contents of the [ Imagepath ] value in each key below to reflect the current correct location of smcinst.exe from the post-update installation:

- HKLM\system\controlset001\services\smcinst
- HKLM\system\controlset002\services\smcinst

You should be able to deploy a reg-fix for this by script if there are enough nodes affected that manually editing the registry is not economical.
I wouldn't necessarily recommended it though. I've caused the services.msc snap-in to not respond with fatal errors by incorrectly changing these registry keys. (EXPORT REGISTRY KEYS BEFORE EDITING!) :)

I find it incredible that Symantec has not ironed this out. The SEP installer should be capable of properly cleaning up after itself. I know there are several forum threads regarding this issue.


KRedd's picture

Hi GMan

Regarding the the 1st error you have on the job log i would suggest you to uncheck the SQL instance of backup exec  as its causing you that error 

The backup exec maintaince would take care of that instance backup

and coming to the second exception that you are getting  i would suggest you the following documents  that would help you better