Endpoint Encryption

WE are migrating to SEE v .8.2 in a Windows 2008 and 2003 server environment.  I have submitted tickets to Symantec support to identify why some clients are "registering"  with the new SEE management console as expected and some are not--won't check in if they have FDD 8.2 installed, don't show up with their SEE products and attributes listed in the management console.   There is no apparent differenece between those clients that show up and those that don't. Some have Framework and RSE and some have Framework, Full Disk and RSE.   They are all members of the same Windows domain and there are no firewall issues to deal with.  Wireshark captures so far show no "dialogue" with between the client and server, but no errors either compared with those that can "check-in".  Techlogs are unhelpful.  Tried running procmon from Sysinternals but don't see anything yet.

Anyone else seeing the same behavior.  Most clients are running WIndows XP SP3.   

I have tried upgrade and fresh installations.  Some of these clients ran versions of GuardianEdge but those were removed before installation and CCleaner run after uninstallations of the earlier versions.

Things to check then.  Can you advise on the below?

Is this an inplace upgrade?

Do the frameworksettings.xml files on your working and non-working clients match?

Can you enable IIS logging on your SEE Management Server, attempt a check in, and let us know what you see?

Plus a few basics too like, do the working and non-working machines resolve the servername to the same IP address, can you telnet the SEE Management server on the configured comms port, have you enabled HTTPS for comms, etc?

Sorry I never saw your post.  I've been working with Symantec support and am no closer to the reason.

No one ever advised a comparison of the frameworksettings.xml files but they're all the same on the "working" and "problem" clients--the exact same client msi has been used on them all.

IIS logging on the SEE server shows no issue...all clients have a 200 response code.

I finally figured out how to get trace logging activated since every registry change I was advised to make would not create any trace logs.  I know get trace logs but am finding it difficult to know which client is associated with the associated id in the log file.  I've sent them onto Symantec support for their review.  It sure would be easier if those traces id'd either the system name or the IP number in use.  I dont' see any correlation between id in the log file with the system id in the database computers table.

Name resolution is not an issue for any client.  I've tried http and https for the client to server communications and there doesn't seem to be any difference in behavior between either one.

I'm also trying to figure out why some clients are plunked into the SEE Unassigned category rather than their system OU even though AD has no problem identifying their proper system OU.  But SEE does--for some clients.  I'm tempted to edit the Computers table records directoy to reference the proper OU but that wouldn't solve the underlying problem there.

To review then...

On the IIS side, when you click the "Check In" button on a problem client, you see a corresponding log entry in the IIS logs for that client's IP address, and appears to be successful, correct?

You didn't confirm, but I'm assuming this was an inplace server upgrade using the same database; what version did you upgrade from?

On a problem client, if there are errors communicating, then the EAFrmCliComm log file under the Techlogs folder inside the software installation folder should be updated.  Can you post this please?

Finally, the assignment of SEE clients to their OUs in the SEE Manager, is reliant upon the Directory Sync being up and running.  Check your directory sync settings by opening the SEEMS Configuration Manager on your server and make sure it's all running and syncing.

On a final note, all of the above (client check-ins, directory syncing, etc) is dependent on the database being fully operational.  Can you confirm the health of the database please (maintenance plans, backup strategy, available space, etc), and if has been moved as part of your upgrade (plus details please)?

Sync is working fine.  AD is correct but SEE doesn't always assign systems to the proper OU--some get postioned in the SEE Unassigned folder. 

Database is running fine.

This was NOT an inplace upgrade.   Created a new server and have run OTPKeyChanger to direct clients that were reporting to the ADAM-based server to report to the new database-version of SEE.  Used a Symantec utility to get the database entry entered in the database.  Assume OTPKeyChanger when set up picks up this key.   However, have seen issues with some clients that had NO previous version of the ADAM-based clients installed.

IIS logs show a 200 return.  So the client does appear to be communicating the IIS service properly.

I have not checked the log files...There are so many useless log files that show false reports of issues that I rarely have used the client log files.  I will check this one.