dbi services Blog
Welcome to the dbi services Blog! This IT blog focuses on database, middleware, and OS technologies such as Oracle, Microsoft SQL Server & SharePoint, EMC Documentum, MySQL, PostgreSQL, Sybase, Unix/Linux, etc. The dbi services blog represents the view of our consultants, not necessarily that of dbi services. Feel free to comment on our blog postings.
Forefront Endpoint Protection (FEP) 2010 and database policies
I have seen at a customer that SQL Server's policy doesn't follow Microsoft's recommendations about antivirus and databases (kb 309422), such as excluding *.mdf,*.ndf and *.ldf files. In addition, there is no Oracle policy in case of Forefront Endpoint Protection 2010 (known as FEP 2010).
I have decided to create generic databases policies for FEP (optimized by dbi services) adapted for all SQL Server and Oracle environments.
It's very simple. On the one hand we know that antiviruses can improve stability and performance like disk latency problems. On the other hand we don't know how SQL Server FEP policies are optimized for SQL Server databases. Also, we do not know their impact if we don't apply the antivirus recommendation for databases.
And, finally what’s appending in a cluster environment?
Which policies do already exist for FEP?
You can download all FEP policies for windows server here.
There, you will find 2 policy files for SQL Server (FEP_SQL2005.xml and FEP_SQL2008.xml) and nothing for Oracle.
Using these 2 files, Microsoft excludes 3 processes:
SQLServr.exe, ReportingServicesService.exe and MSMDSrv.exe
These 2 policies are for the default instance of SQL Server. If you have multiple instances, it's very difficult to exclude specifically all processes with their complete path.
Of course you can also find other policies for DNS, Exchange, or SharePoint, as an example.
What is Microsoft's recommendation for SQL Server and Antivirus?
In the policy file for SQL Server, you can find this note:
This indicates that we do not need to excluded the data file extensions (*.mdf,*.ndf and *.ldf), but I don't understand why...
KB article 309422 extract:
Unfortunately, I haven't found anything about it. To be sure, I recommend excluding data files extensions in order to avoid having locked data files during a virus scan.
On its website, Microsoft also recommends to exclude processes and data files.
For more information, see KB309422.
What is Oracle's recommendation for Oracle and Antivirus?
Like for SQL Server, dbi services recommend to exc,ude Oracle processes from the scan.
These processes are oracle.exe (database process) and TNSLSNR.exe (listener process) installed on Windows Server.
Of course all data files extensions, such *.ctl,*.dbf and *.rdo or whatever configured on the Oracle level, should be excluded. In addition, archivelog (*.arc) and log files (*.log) can be excluded. It is not mandatory, but it may avoid bad surprises!
For more information, see KB54817.
Now, we go on to create 3 policies, one for SQL Server, one for Oracle, and one compiling both.
Creating a new policy for SQL Server
Like policies from Microsoft, I have created a XML file named “FEP_dbiServices_SQLServer.xml”.
Change Processes key:
As a first step, I have to delete the path from the 3 processes (SQL server Engine, Reporting Services and Analysis Services) to adapte them for multiple instance.
Then, I added the other SQL Server processes: Integration Services(MsDtsSrvr.exe), SQL Server Agent(SQLAGENT.exe) and SQL Server Browser(sqlbrowser.exe).
This is a good practice for stability and performances.
Change Extensions key:
In this section, we have to exclude all data files extensions (*.mdf,*.ndf and *.ldf) and backup file (*.bak and *.trn).
I have added the log file to complete it. This is normally not critical for the protection strategy.
What's the result in FEP?
If you want, you can see the keys directly in the registry:
I haven't excluded the full-text catalog files.
As a comment in the file, you can find the directory that holds Analysis Services data (DataDir property of Analysis Services) and the cluster path that must be excluded.
This must be decommented by you.
Creating a new policy for Oracle
For this policy, I have excluded all data files extensions and the 2 processes (see above).
The XML file is named “FEP_dbiServices_Oracle.xml”.
Create processes key:
Like for SQL Server, we exclude oracle.exe and TNSLSNR.exe, but not with the entire path such as C:\oracle\product\10.2.0\db_1\BIN or C:\oracle\product\11.2.0\dbhome_1\BIN - just the executable.
Create Extensions key:
Once again, like for SQL Server, we exclude the data et backup files.
Creating new policies for both
Why a policy for both?
If you have both databases on your IT structure, you have a generic database policy for the whole database servers' environment.
The XML file is named “FEP_dbiServices_Oracle_SQLServer.xml” and is a compilation of the 2 other files.
Package "ssisFEP_GetErrorsDuringUpload" failed
To finish this posting, I want to give you important information about a problem with a SSIS package.
Periodically, the FEP data collection job (FEP_GetNewData_FEPDW_%) fails.
The failure is in one of the following job steps:
- Step 6: End raise error section on DW, raise errors that were thrown from DW DB
- Step 7: ssisFEP_GetErrorsDuringUpload_FEPDW_%
A lot of alerts of this type:
Alert: IS Package Failed
Last modified by: System
Last modified time: 12/19/2011 4:47:30 PM Alert description: Package "ssisFEP_GetErrorsDuringUpload" failed.
See more on this blog posting for explanation .
It is fixed in Update Rollup 1 for Forefront Endpoint Protection 2010 (KB2551095).
For more information and to download it, click here.
These 3 policies are a base for your database strategy with FEP scanning.
You can download the 3 policies here.
You can at anytime, customize your FEP policies, but having a generic database policy is simply saving time and effort.
I hope this may help you for your FEP database policies as well as for database performance and stability issues.