epo 4.6.7 two domain configuration

[bhamill]

I have ePO 4.6.7 running in my AD domain.  We bought another company and have established a trust with their AD domain; I'm now trying to push out agents and deploy VScan in their domain the way I do in mine, and it's not behaving.

On my ePO, I don't do system tree sorting - I enter the systems' NetBIOS names and credentials of a domain user who can install software; push the agents, wake the up, they get a task to deploy VScan, and we're set.  On the new domain, I entered a system's FQDN and administrator credentials for that domain.  I pushed the agent, and it appears to have installed: it shows up in the system tree, and says it's managed.  But it doesn't  show the FQDN, only the NetBIOS name; the ePO server has collected no properties on the system; if I try to show the agent log, I get "403 Forbidden"  (and the brower's address shows http://system:8081, not http://system.domain.org:8081), and it's not getting the "deploy" task.

As I said, the two domains trust each other, and our DNS and theirs are set up as conditional forwarders for each other.  If I "ping system" from the ePO server, "system.domain.org" responds.

I'm obviously missing something in my setup - do I need to do something to tell ePO that it is managing systems in both domain? 

[JoeBidgood]

When it comes to agent/server communications, ePO doesn't use windows authentication at all (apart from the initial agent install), so if the clients can communicate everything else should be OK. The symptoms you're describing almost sound like you're looking at an entry for an unmanaged machine, but you say that they're showing as managed...

In the first instance, check on one of the clients - make sure that the agent is actually installed, and check the agent log to see if there are any comms-related errors. Feel free to attach the logs here if you like and we can have a look.

HTH -

Joe

[bhamill]

Thanks  for the quick reply.

Yes, the system looks like an unmanaged one, but it says managed.  For the hell of it, I deleted it from the tree; within a hour, it was back in the tree in the "Lost and Found" subgroup.  The agent (4.8.0.1500) is installed, and the Framework Service is running. 

When I run "cmdagent /s" the monitor says "Agent Service is running," and I can see it enforce policies every five minutes.

When I try to "check new policies, the only message that shows is "Agent started performing ASCI" - on a working system, I see "Agent Communication session started, sending PROPS VERSION package, agent is connectint to the ePO server, no package received from ePO server, communication session closed."  So, that points to the client not being able to get to the ePO - but, it's pingable by IP and by FQDN.  

So, where should I look next?

[JoeBidgood]

It's almost as though it's failing to collect properties, so that it doesn't actually have any information to send to the server. I would try this:

1) On an affected system, enable log level 8 and restart the framework service.

2) On the agent monitor click "collect/send props" and wait for 5 minutes or so

3) Collect and attach the agent log folder, which is %PROGRAMDATA%\McAfee\DB - we're interested in the agent log and also the prdmgr log which will tell us what the plugins are doing.

HTH -

Joe

[bhamill]

OK, saved and cleared logs, increase logging, attempted to collect/send, saved resulting logs.  I could upload everything, but that would annoy anyone looking at this - can you tel me what I should look for in logs?

For instance - PdrMgr_ServerName_error.log is empty after run, and PrdMgr_ServerName.log shows no errors.

Agent_ServerName_error.log shows:

2014-04-21 13:44:09.541    e    #6600    Agent    Agent failed to communicate with ePO Server

2014-04-21 13:44:26.932    E    #3152    ServiceMgr    Error trace:

2014-04-21 13:44:26.932    E    #3152    ServiceMgr      Not persisting SAHU_SERVER stat data. It is either invalid or not running currently

at the same time as that first line (2014-04-21 13:44:09.541) Agent_ServerName.log shows the agent doing a "relay discovery," whatever that is, and getting this result:

2014-04-21 13:44:09.541    I    #6600    RelayClient    RelayClientApi, No relay servers were discovered in the network

2014-04-21 13:44:09.541    I    #6600    imutils    Relay discovery failed.

2014-04-21 13:44:09.541    I    #6600    naInet    HTTP Session closed

2014-04-21 13:44:09.541    e    #6600    Agent    Agent failed to communicate with ePO Server

2014-04-21 13:44:09.541    i    #6600    Agent    Agent communication session closed

Any idea what the "Relay Server"is?

[JoeBidgood]

Hm - this shows that the agent thinks it can't communicate, but it must have communicated at least once, otrherwise it can't have reappeared in lost and found.

Could you zip up the contents of the DB folder and attach the zip here?

Thanks -

Joe

[bhamill]

OK - here you go, I think.  Many thanks for your help.

[JoeBidgood]

OK - the log shows that the machine is talking to the server, but it's getting an "I'm busy" response back:

2014-04-21 13:44:04.494    I    #6600    naInet    failed to receive package..server is busy

Check the server.log (and its backup) on the ePO server - does it still cover this time? If so, are there any errors logged? Again, feel free to zip and attach them here if you like.

Thanks -

Joe

[bhamill]

here's the relevant section of server.log:

20140421134403    I    #04196    NAIMSRV     Received [PropsVersion] from CBB-APPSV1:{6230F661-E46F-410B-8603-E5B50AFAA430}

20140421134403    I    #04196    NAIMSRV     Signing agent response package with key i7josws5HSiG2nzlSEF2vkt13ZAig3zrwtlmh396l+k=

20140421134404    I    #03884    NAIMSRV     Received [FullProps] from CBB-APPSV1:{6230F661-E46F-410B-8603-E5B50AFAA430}

20140421134404    I    #03884    NAIMSRV     Processing agent props for CBB-APPSV1(6230F661-E46F-410B-8603-E5B50AFAA430)

20140421134404    E    #03884    EPODAL      COM Error: 0x80040E14

20140421134404    E    #03884    EPODAL      File: .\ePOData_Connection.cpp(699)

20140421134404    E    #03884    EPODAL      Function: CConxIndex::Execute

20140421134404    E    #03884    EPODAL      Source: Microsoft OLE DB Provider for SQL Server

20140421134404    E    #03884    EPODAL      Description: Could not allocate space for object 'dbo.RSDInterfaceProperties'.'PK_RSDInterfaceProperties' in database 'ePO4_PEL-EPO-V01' because the 'PRIMARY' filegroup is full. Create disk space by deleting unneeded files, dropping objects in the filegroup, adding additional files to the filegroup, or setting autogrowth on for existing files in the filegroup.

20140421134404    E    #03884    EPODAL      COM Error: 0x80040E14

20140421134404    E    #03884    EPODAL      File: .\ePOData_ComputerProperty.cpp(72)

20140421134404    E    #03884    EPODAL      Function: DAL2_CComputerProperty::Flush

20140421134404    E    #03884    EPODAL      Source: Microsoft OLE DB Provider for SQL Server

20140421134404    E    #03884    EPODAL      Description: Could not allocate space for object 'dbo.RSDInterfaceProperties'.'PK_RSDInterfaceProperties' in database 'ePO4_PEL-EPO-V01' because the 'PRIMARY' filegroup is full. Create disk space by deleting unneeded files, dropping objects in the filegroup, adding additional files to the filegroup, or setting autogrowth on for existing files in the filegroup.

20140421134404    E    #03884    NAIMSRV     servdal.cpp::ProcessComputerPropsXML: Flush computer property failed. Err=-2147217900

20140421134404    E    #03884    NAIMSRV     Failed to process computer properties

20140421134404    E    #03884    NAIMSRV     naimserv::servdal_ModifyAgentProps: Modify agent props failed!

20140421134404    E    #03884    NAIMSRV     Failed to process agent request

"PRIMARY filegroup is full" doesn't make sense to me - because right after it, another device sends props:

20140421134453    I    #03564    NAIMSRV     Received [PropsVersion] from CE-SHIP-02:{BAEA6616-A11B-4015-A0F3-FE216F64D92D}

20140421134453    I    #03564    NAIMSRV     Processing agent props for CE-SHIP-02(BAEA6616-A11B-4015-A0F3-FE216F64D92D)

20140421134453    I    #03564    NAIMSRV     Sending props response for agent CE-SHIP-02, agent has up-to-date policy

20140421134453    I    #04164    NAIMSRV     Received [Event] from CE-SHIP-02:{BAEA6616-A11B-4015-A0F3-FE216F64D92D}

... as do many others.  A rights issue, maybe?  The database is the SQL 2005 that ePO installs automatically, and uses Windows authentication.  

[JoeBidgood · Accepted solution]

This is almost certainly the cause of the problem - and even if it's not the direct cause it's still a critical error that needs addressing before anything else.

If it's the SQL express that ships with ePO, then the database will be limited to 4GB, and before anything else you need to free up some space in there. You can try the approach in KB68961  , or you can upgrade to SQL 2008 express which has a higher limit, or you can of course upgrade to full SQL (or move the DB to a full SQL server if one is available) which has no limit.

HTH -

Joe