Issues with DAT files building up in \Symantec Endpoint Protection Manager\data\inbox\agentinfo
Anyone else having issues with DAT files getting backed up (read not processed) in the data\inbox\agentinfo directory? We've had it happen a couple of times and restarting the SEPM service seems to remedy the situation at least temporarily. We are running version 11.6a
We have a case open with Symantec in regards to this but are being told that this is a known issue, yet there is no public documentation that states that this issue exists in 6a (It is documented in the release notes for MR4 MP2)
Slow process of DAT files in the Inbox\Agentinfo folder on the Manager
Fix ID: 1513330
Symptom: Large numbers of files in the Inbox\Agentinfo folder. The number of files continually increases.
Solution: Updates to Avman and Agentinfo processing along with SQL batching of statements, and configurable multi-threading to the Agentinfo processing.
Comments
as you have identified the
as you have identified the fix, this has been fixed in MR4 MP2 release of SEPM. Since you are using the latest version than MR4 MP2, this should have fixed, you may need to open a case with SYmantec on this issue. There are instances when the SEPM is overloaded the agentinfo folder gets filled with .dat fiiles.
Try restarting the DB and the SEPM service.
http://translate.google.co.in/translate?hl=en&sl=ja&u=http://service1.symantec.com/support/inter/entsecurityjapanesekb.nsf/jp_docid/20090609112202949&ei=k4uHTPeoLMKrcd-erJ4I&sa=X&oi=translate&ct=result&resnum=2&ved=0CBsQ7gEwAQ&prev=/search%3Fq%3DFix%2BID:%2B1513330%26hl%3Den
Cheers!
Pete
Help Link: http://www.symantec.com/business/support/overview.jsp?pid=54619
I'm looking for a fix, not a
I'm looking for a fix, not a workaround. I've opened a case and it's been open for two weeks now with nothing but me getting the run around. I really want to know WHY this is happening as well, our management isn't to pleased with this product right now and we are starting to look at other solutions since we can't seem to get a stable product here.
The SQL Server Native Client
The SQL Server Native Client will need to be removed (Add/Remove Programs) and reinstalled from the SQL 2005 CD. In the case where the 32-bit version was installed on 64-bit Windows, then the appropriate SQL 2005 64-bit CD needs to be located and used to get the SQL Server Native Client installed correctly.
Remove the SQL Client:
1. Open Control Panel, Add/Remove Programs
2. Remove the all SQL components that are listed (unless this is an SQL server, in which case do not remove SQL Server 2005!)
Install Microsoft SQL Server 2005 Native Client:
1. Start the Microsoft SQL Server 2005 installation CD and begin the installation process.
2. In the Start window, click Server components, tools, Books Online, and samples.
3. Continue the installation until you are prompted to select the components to install.
4. In the Components to Install dialog box, click Advanced.
5. In the left pane, click and expand Client Components.
6. Click Client Components, and then select Will be installed on local hard drive.
7. Click Client Component features Connectivity Components and Management Tools, and then select Will be installed on local hard drive.
8. Complete the installation.
Configure Microsoft SQL Server 2005 Client Components on SEPM:
1. Click Start > Programs > Microsoft SQL Server 2005 > Configuration Tools > SQL Server Configuration Manager.
2. Under SQL Native Client Configuration, click Client Protocols, right-click TCP/IP, and then click Properties.
3. In the Default Port box, type the port number that matches the port that is used by the Microsoft SQL Server 2005 instance.
Note: The default port is typically 1433. You specify this port number when you create the database.
4. Click Apply > OK.
-VKalani
These are known causes for
These are known causes for this issue:
Cause 1: SQL Server Native Client is not fully installed, e.g. the 90\Tools\binn folder was copied over from another system.
Cause 2: The 32-bit version of the SQL Server Native Client was installed on 64-bit version of Windows.
Cause 3: SQL Server Native Client version does not match the version of remote SQL Server, both should be at same service pack or patch level.
Cause 4: SQL Server Native Client is not configured to use same port as the remote SQL Server. These scenarios cause BCP.exe to not be able to function correctly when called upon by the JDBC. This results in an inability to transport the information in the Inbox to the SQL database.
-VKalani
We've done the SQL client
We've done the SQL client reinstall on one of the two servers, the other server we can't because it's running another app that is connecting to a 2008 SQL DB. Out SEPM DB is on a SQL 2005 server.
so, did the SQL client
so, did the SQL client re-installation did not solve the issue?
-VKalani
Correct
Correct
Have applied Group Policy on
Have applied Group Policy on any Symantec Service ?
VMWARE-- SEP 12.1 vs McAfee vs Trend Micro
No Group Policy applied for
No Group Policy applied for any Symantec EP service.
Also check this Clients
Also check this
Clients cannot send data back to Symantec Endpoint Protection Manager
http://service1.symantec.com/support/ent-security.nsf/854fa02b4f5013678825731a007d06af/ddb6fb9fd9dc8798882574810068d826?OpenDocument
VMWARE-- SEP 12.1 vs McAfee vs Trend Micro
A few questions.
1.) Are you using a clustered SQL server?
1a.) If so, when the server fails over, does the the node switch IP addresses? The SEPM requires a constant connection to the SQL server. If your connection to the SQL server was established via hostname and the initial connection is broken when failover occurs, your SQL agent wont' be able to send anymore logs to the server until you restart the SEPM and the connection is restablished. (presumably the hostname will resolve to the updated IP of the new node, resolving the issue.)
2.) Did you check permissions on the SEPM\data\ folder to ensure that "everyone" has "full control."?
3.) Do the .dat files just slowly keep building until you restart the service or is there a sudden flood of .dat files? If the .dat files are slowly building, your SQL server may not be powerful enough to process all the transactions. In this situation you would want to decrease your heartbeat interval. See the sizing and scaling documentation for more info.
http://service1.symantec.com/SUPPORT/ent-security....
1. We are not using a
1. We are not using a clustered SQL server.
2. Yes
3. Slowly building, then when we restart the SEPM service, they are handled by the SQL server in a matter of minutes. The SQL server is not the issue.
Thanks for the feedback!
Would you like to reply?
Login or Register to post your comment.