Forefront Endpoint Protection 2010 now supports upgrading an existing Forefront Endpoint Protection database and reporting database to Microsoft SQL Server 2012.
To use SQL Server 2012 with Forefront Endpoint Protection 2010, you must upgrade the existing instance of SQL Server from SQL Server 2008 or SQL Server 2008 R2. It is not supported to install new Forefront Endpoint Protection components on an existing or new instance of SQL Server 2012.
Before you can use Forefront Endpoint Protection 2010 with Microsoft SQL Server 2012, you must install the following update on the server running Forefront Endpoint Protection.
Forefront Endpoint Protection data warehouse and reports fail to get new data on SQL Server 2012 - http://support.microsoft.com/kb/2683558
J.C. Hornbeck | System Center & Security Knowledge Engineer
Get the latest System Center news on Facebook and Twitter:
App-V Team blog: http://blogs.technet.com/appv/ ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/ DPM Team blog: http://blogs.technet.com/dpm/ MED-V Team blog: http://blogs.technet.com/medv/ Orchestrator Support Team blog: http://blogs.technet.com/b/orchestrator/ Operations Manager Team blog: http://blogs.technet.com/momteam/ SCVMM Team blog: http://blogs.technet.com/scvmm Server App-V Team blog: http://blogs.technet.com/b/serverappv Service Manager Team blog: http://blogs.technet.com/b/servicemanager System Center Essentials Team blog: http://blogs.technet.com/b/systemcenteressentials WSUS Support Team blog: http://blogs.technet.com/sus/
The Forefront Server Protection blog: http://blogs.technet.com/b/fss/ The Forefront Endpoint Security blog : http://blogs.technet.com/b/clientsecurity/ The Forefront Identity Manager blog : http://blogs.msdn.com/b/ms-identity-support/ The Forefront TMG blog: http://blogs.technet.com/b/isablog/ The Forefront UAG blog: http://blogs.technet.com/b/edgeaccessblog/
Hi everyone, Peter Gallagher here and I wanted to talk about one of the new features in System Center 2012 Configuration Manager (ConfigMgr). The feature is the ability to automatically deploy software updates to clients and it can be utilized to automatically deploy Forefront Endpoint Protection 2010 antimalware definition updates to ConfigMgr clients. For more information on deploying Forefront Endpoint Protection 2010 with Configuration Manager as well as how to create an Automatic Deployment Rule for Forefront Endpoint Protection 2010 antimalware definition updates, please see the following: http://technet.microsoft.com/en-us/library/hh508770.aspx.
The issue I wanted to talk about was one where after following http://technet.microsoft.com/en-us/library/hh508770.aspx, antimalware definition updates may not be automatically deployed to clients as expected.
When this occurs, per the UpdatesDeployment.log and WindowsUpdate.log on the client, other software updates may be deployed successfully, but examining the UpdatesDeployment.log on the client shows that the client is not detecting Forefront Endpoint Protection 2010 as a product. The only indication of an error or problem will be the status of Forefront Endpoint Protection 2010 antimalware definition updates in the Windows Security Center on the client or the Configuration Manager console.
This issue can occur if the product “Forefront Endpoint Protection 2010” is not selected on the Software Update Point Component in Configuration Manager. An Automatic Deployment Rule in System Center 2012 Configuration Manager DOES NOT verify that the corresponding products or classifications that are selected are also selected on the Software Update Point itself.
To resolve this issue perform the following:
1. On the Central Administration Server (CAS), navigate to Administration\Overview\Site Configuration\Sites.
2. In the results pane on the right, highlight the servername that has the type of “CAS”. If you have a single server install, highlight the server listed.
3. In the ribbon at the top, click Configure Site Components and in the dropdown select Software Update Point.
4. Select the Products tab and then place a check next to Forefront Endpoint Protection 2010.
5. Review the Languages/Classifications tabs to ensure that the items selected in the Automatic Deployment Rules are also selected on the properties of the Software Update Point. Click OK when complete. There is no need to manually initiate a synchronization as Configuration Manager will detect a change (step 4 above) and automatically start a synchronization.
Note that this example is specific to Forefront Endpoint Protection 2010 antimalware definition updates, however the process applies to any Automatic Deployment Rule in System Center 2012 Configuration Manager. If a product/classification is selected in an Automatic Deployment Rule, the corresponding product/classification must be selected in the Software Update Point configuration screen.
Peter Gallagher | System Center Support Engineer
Jason Githens, Senior Program Manager for System Center 2012 Configuration Manager & System Center 2012 Endpoint Protection, just published a great article on System Center 2012 Endpoint Protection and false positives over on the Microsoft Server and Cloud Platform Blog. You can check it out at the link below:
=====
Though Microsoft’s antimalware technologies have one of the lowest false-positive rates in the industry, you should always be ready to address Endpoint Protection false-positive situations if they occur in your environment. There are some basic steps you can take to mitigate and remediate the problem. The case study below presents a hypothetical example of how Kevin, the security administrator at Contoso, addressed a false-positive situation at his company.
You can read the rest of Jason’s article here.
Here’s a cool article I found while going through what was new over on our community-driven TechNet Wiki. This one discusses some best practices for WSUS that should ease Microsoft Forefront Endpoint Protection and Client Security deployments. And as with all of the Wiki articles, if you have some tips of your own please feel free to add them in.
Forefront Client Security and Endpoint Protection both use WSUS infrastructure in different ways. This, unless your Forefront update policy uses a network share to deploy the updates. The goal of this article is not to explain the relationship between Forefront and WSUS in details, but to provide best practices regarding WSUS management and administration, that will surely ease FCS/FEP deployment, and even avoid certain issues (eg: updating failures).
The key point to remember is that FCS and FEP may really rely a lot on the WUA's (Windows Updates Agent) health and performance, on the client computers. Below are a few points, role-based: clients, and Server-based (mostly WSUS), that are known to ease Forefront deployment and updating…
You can continue reading the rest of the article here:
The FEPDW database may be larger than estimated prior to deploying FEP to all the clients in the environments and\or may be larger than estimated after full deployment if you used the FEP Capacity Planning worksheet for size estimation purposes.
For the scenario where the FEPDW is larger than expected prior to deploying FEP to all clients, where you may have deployed FEP to a test group, this is expected and by design. The FEPDW Database contains tables named dtFEP_AM_ComputerDeploymentAndProtectionStateFact_XX where XX is some integer value. These tables will be the largest contributors to the size of the FEPDW as they maintain the historical data of all the SCCM clients in the environment in regards to their FEP state. State includes items such as Engine Version, Signature Version, Write Time and so on. These items will have values for every system, not just the ones that have the FEP Client installed. This is how we maintain statistics for deployment of the FEP client.
For the scenario where the FEPDW is larger than expected after deploying to all clients, this could be for several reasons which I will step through below. When using the Capacity Planning Worksheet, the information is related to estimates on the size of records and the number of collections, along with the number of clients. We need to confirm each before we assume there is some other issue with the FEPDW Database.
WITH MembershipsPerComputer AS
(select COUNT(*) InHowManyCollections from [CollectionMembers] where isClient = '1' group by machineid)
select AVG(M.InHowManyCollections) AS NumberOfCollectionsPerClientAvg
FROM MembershipsPerComputer AS M
2. Size of each record. To determine the size of each record stored in the dtFEP_AM_ComputerDeploymentAndProtectionStateFact tables, run the following SQL Query against the FEPDW Database:
SET NOCOUNT ON
CREATE TABLE #TBLSize
(Tblname varchar(80),
TblRows int,
TblReserved varchar(80),
TblData varchar(80),
TblIndex_Size varchar(80),
TblUnused varchar(80))
DECLARE @DBname varchar(80)
DECLARE @tablename varchar(80)
SELECT @DBname = DB_NAME(DB_ID())
PRINT 'User Table size Report for (Server / Database): ' + @@ServerName + ' / ' +
@DBName
PRINT ''
PRINT 'By Size Descending'
DECLARE TblName_cursor CURSOR FOR
SELECT NAME
FROM sysobjects
WHERE xType = 'U'
OPEN TblName_cursor
FETCH NEXT FROM TblName_cursor
INTO @tablename
WHILE @@FETCH_STATUS = 0
BEGIN
INSERT INTO #tblSize(Tblname, TblRows, TblReserved, TblData, TblIndex_Size, TblUnused)
EXEC Sp_SpaceUsed @tablename
-- Get the next author.
END
CLOSE TblName_cursor
DEALLOCATE TblName_cursor
SELECT CAST(Tblname as Varchar(60)) 'Table',
CAST(TblRows as Varchar(14)) 'Row Count',
CAST(LEFT(TblReserved, CHARINDEX(' KB', TblReserved)) as int) 'Total Space (KB)',
CAST(TblData as Varchar(14)) 'Data Space',
CAST(TblIndex_Size as Varchar(14)) 'Index Space',
CAST(TblUnused as Varchar(14)) 'Unused Space'
FROM #tblSize
Order by 'Total Space (KB)' Desc
DROP TABLE #TblSize
3. The output above will have the Row Count column and Total Space (KB) column. We will use these to give us the approximate size of the each record. Add up the Total Space (KB) column for the dtFEP_AM_ComputerDeploymentAndProtectionStateFact tables, then add up the Row Count column for the dtFEP_AM_ComputerDeploymentAndProtectionStateFact tables. Divide the total from the Total Space (KB) columns by the total from the Row Count column and this will give you the current average record size. The number should be somewhat close to the value from the FEP Capacity Planning worksheet of 0.1499.
4. We now have the Average Collections number and the Average Record size for the dtFEP_AM_ComputerDeploymentAndProtectionStateFact tables which can then be used in the FEP Capacity Planning worksheet to see if the estimated size of the worksheet is now closer to the actual size of the FEPDW Database. Put the value from step 1 above in the “Average number of collections to which each client computer belongs:” cell. Then modify the “Computer deployment and protection state fact table” record size in kilobytes value to what was determined from step 3 above.
5. Once these are entered the value of the Total FEP Datawarehouse size should more closely match what the actual size of the FEP DW database is showing in SQL.
6. There are other factors, including the Retention Period which defaults to 12 months (365 days), however, this can be changed from any value of 3 to 12. See the following for details - http://technet.microsoft.com/en-us/library/gg710931.aspx. Please note that once this is changed, it is not effective immediately. The FEP DW maintenance task listed here - http://technet.microsoft.com/en-us/library/gg710933.aspx - runs once a day, but it does not initially remove the data older than the new value you have chosen. There is a 10 day layover period before the new grooming date takes effect. After the 11 day, you should see that the FEP DW Maintenance job has now dropped the dtFEP_AM_ComputerDeploymentAndProtectionStateFact tables that have data older than the specified amount of time you have set for Retention. To confirm this, run the following SQL query against the FEPDW database and notate the End Time column. It will be within your specified Retention time:
select OBJECT_NAME(TableID),* from dtAN_Infra_MaintenancePartition where OBJECT_NAME(TableID) = 'dtFEP_AM_ComputerDeploymentAndProtectionStateFact_SCHEMA'
7. If the End Time on the dtFEP_AM_ComputerDeploymentAndProtectionStateFact tables is outside of the Retention time that has been sent and it has been longer than 10 days since setting the new Retention time, then we need to verify the FEPDW Maintenance tasks are running. Check for errors regarding these Maintenance tasks in both the Event logs and the SQL Jobs View History option.
NOTE: If you change the retention period, FEP does not shrink the FEPDW database for you to recover space. You must use SQL to do this manually - http://technet.microsoft.com/en-us/library/ms189035.aspx