Backup Exec 2012 database cleanup

When using Backup Exec 2012 by default will install a rather dated at this point in time version of SQL Server 2005 Express Edition. As time goes with and install the database grows and eventually can lead to errors like: “The Backup Exec Database has almost reached the 4-GB limit that is allowed for SQL Server Express Edition. To ensure that Backup Exec continues to function properly, either clean up the Backup Exec Database or upgrade to the full version of SQL Server.”, also known as V-287-13257.

To correct this there have been two trains of thought one to use the built-in BEUtility and the other is to modify SQL directly. I don’t view this as an either-or approach, I view it as a try this first and if not then try that.

First option, use BEUtility. Why, because it’s using the built-in methods provided by Symantec. Run the following options from the utility:

1. Age database

2. compact database

3. repair database

4. rebuild db indices

5. check db consistency.

The second option is to use the SQL Management Studio to manually perform some cleanup. Usually the source of the problem is the BELog table which can grow to gigabytes in size all by itself.

Lets check and see how many records are older than 6 months old:

SELECT count(username) from [BEDB].[dbo].[BELog] where TimeStamp < DateAdd("m", -6, getDate());

On larger environments don’t be surprised if it returns millions.

Now lets check and see if this is anything we still need.

SELECT * from [BEDB].[dbo].[BELog] where TimeStamp < DateAdd("m", -6, getDate());

Ok, now lets purge logs older than 6 months

delete FROM [BEDB].[dbo].[BELog] where TimeStamp < DateAdd("m", -6, getDate());
, , ,
July 9, 2013 at 12:35 pm Comments (0)

Forefront Endpoint Protection 2010 Reporting Services

Over the last few days I’ve been working on a Forefront Endpoint Protection 2010 Deployment on top of an existing Server 2008 SP2 (64-bit) with SQL Server 2005 (64-bit) Standard Edition with SP3 and a production version of SCCM 2007 with R3 and SP3. While working through the pre-requirements and had a number of failures with the SQL server portion. The bulk of these revolved around being unable to detect the version of the Integration Services that were installed. Installing SP4 for SQL Server 2005 did not clear up this issue. The next step was do an in place upgrade to SQL Server 2008 R2 w/SP1, after completing this upgrade the Integration Services version issue was resolved (later the source of the problem was an unknown prior SQL Express install on the server originally which during the install never cleaned up properly).

With all the pre-requirements done, it appeared as life was good but this eventually was met with a failed install with the install going as planned with the exception of the Reporting/Alerting services. To step through this a custom install was done to install everything but the Reporting Services (this install worked). Then followed by a custom install of the Reporting Services only with again another failure. Below is a sample of what the FepReport_*.log created located C:\ProgramData\Microsoft Forefront\Support\Server\

MSI (s) (C8:48) [14:19:50:481]: Product: Microsoft Forefront Endpoint Protection 2010 Reporting — Installation operation failed.

MSI (s) (C8:48) [14:19:50:482]: Windows Installer installed the product. Product Name: Microsoft Forefront Endpoint Protection 2010 Reporting. Product Version: 2.1.1116.0. Product Language: 1033. Installation success or error status: 1603.

MSI (s) (C8:48) [14:19:50:484]: Deferring clean up of packages/files, if any exist
MSI (s) (C8:48) [14:19:50:484]: MainEngineThread is returning 1603
MSI (s) (C8:98) [14:19:50:485]: RESTART MANAGER: Session closed.

While the 1603 is very generic and when looking up this product there were references to TCP 1433 being blocked (which would be odd considering the SQL install was on the same server). Then an attempted manual install from the fepreport.msi was attempted with the below error.

Now at this point it would seem odd that all the pre-requirements foundwere met, the domain server account was even added to the local administrators group and UAC disabled during troubleshooting.

At this point what should be enough for permissions fails, so an attempt with a domain admin level account was done and worked without an issue.

Now doing this method in a production environment introduces many security issues so you’ll need to perform the below steps to change the credentials post-install for the reporting service.

  1. In a web browser, open the Report Manager. By default, the URL is: http:// ReportingServerURL /Reports Where ReportingServerURL is the URL of the reporting server in your organization.
  2. Click Forefront Endpoint Protection_XXX, where XXX is your Configuration Manager site code.
  3. Click Show Details and then click DataSources.
  4. Click DefaultDataSource, under Credentials stored securely in the report server, in the Password box type the new password, and then click Apply.
  5. Verify that the new password is correct by opening a Forefront Endpoint Protection report.

The above is taken from

, , ,
November 21, 2011 at 11:03 pm Comments (0)