Endpoint Encryption

I have tried to install the same MSI as used and worked previously onto a machine from a different AD domain but part of the same forest.

IP Communication seems fine from both ends.  http communication seems fine.

When a client starts and the SEE client applciation is loaded, we can see that it has never checked in and when a manual attempt is tried it fails.  The computer can be seen in the AD users and computers within the SEE manager on the server, but it has not encryption details next to it.  Another machine on the same IP subnet, using the same MSI, part of the same domain has worked and has checked in.

In Summary all seems fine with the installation, 1 machine works fine, 2 others do not checkin.

To help me troubleshoot this can someone tell me how a machine checks in?

From my limited knowledge of the mechanism... I'm pretty sure the clients connect to the SEE IIS service to do their checking in, e.g.

http://<your-see-server>:<port>/GECommunicationWS.asmx

It also needs to authenticate to that service using the credentials you supplied when you created the MSI, so it could be that those are wrong in the new one? A good way to check might be by browsing to that address on the client having the trouble and see what you're presented with. Hopefully it will give a clue. If you get to it OK, try the IIS logs for the website on your server (feel free to post back if you need more details on that) to see if it gives any error codes that you can work with.

I think its uses http as well. but this one machine just wont register. but it can see the web page you mentioned above.

Hmm OK. Are you looking in AD users and computers or Symantec Endpoint Users and Computers? Have you got the AD Sync service set to use just the other domain instead of the whole forest maybe?

Not sure otherwise, Vaibhav can probably comment further..

I'm looking in both.  AD Sync must be working as the other 2 machine from the same network are OK.  We are going to try and remove SEE from the server and re-install on Monday just in case.

Hi there,

There are few things that I would like to verify -- 

is the client machine and the see server in same domain??

When you try registering a user on the client machine -- what is the error message you are getting ???

Which version of see you are using ??

the client machine that is not checking in which OS is installed ???

If you go to C:\Program Files\Symantec\Symantec Endpoint Encryption Clients\TechLogs on the client machines -- check what error message is coming up ???

make sure that EAFRcliManager should be automatic and started on these machines ???

When you try opening See config console or the see manager on the server -- is there any error message that comes up ???

the machines that are not checking in -- was it a fresh deployment of see on them or an upgrade ???






Also there is no need for you to uninstall see server and start from scratch -- I am sure that there is something not correct specific to few machines because of which they are not checking in ...... 

The 3 machines (2 work 1 doesn't) are in the same domain and on the same subnet, but this is different to the SEE server.

The client is registered automatically so no message appears, but within the client all seems to be normal.

7.0.5

XP

Directory is empty

Will Check

no

fresh

Already have removed it but I agree in general.  Only thing was, that when the install happened the user had a firewall switch on, so I was just wondering if that may have stopped something from registering properly.

I am not sure but I have my doubts that firewall can make the registration unstable. This is strange if the client machine is not checking to the server then there should be some logs that should've been generated. 

Ian - please confirm that when you manually try to check in the client machine via the console then it keeps trying and in the end it fails right ??

Lets check something -- the client machine that is not checking in -- open regedit >> hkey local machine >> softwares >> look for something like symantec encryption software >> expand framework >> go to client database >> give full permission to the currently logged in user >>> then scroll down and check to which server is the client machine pointing to ..... 


I am rebuilding my lab -- else i would have given u a snap shot ... let me know the server name in registry -- if you don't see it then I'll attach a snap shot here .... 

When we manually check it does try and then fail.

Ok will look when the user is available.

Thanks for your time.

Something to add to it -- if in registry if the client machine is pointing towards the right server then try opening the IIS see website on the client machine -- check if that comes up well .... If that also comes up fine then then then ..... 


Well in that case call symantec and ask them do they have a installer package which can manually change keys (used for comm) on the client machine like a key changer ....


if yes then create client packages for keys and install it on the client machine -- then check if then the client machine checks in

The reg key seems fine (did post screen shot but not here now)! and the user can get to the website via IE.

well the only thing left now is key changer ....

Thanks for your help.  Call has been logged, and I'll keep us all updated.

This is a stretch...and I think all my clients weren't communicating...but could your transaction log be full on your database?  I dealt with this recently and upon looking at my application errors on my server, I had this error going on for days.  Looking it up the error, when the log is getting full you can get inconsistent results or your app can just stop working.  Once I did a full backup, it reduced the completed steps in the log and my clients could check back in.  I ended up scheduling a maintenance plan to do full backups weekly, differentials daily, and transaction log backups every hour.  It's probably really overkill for this application, but doesn't hurt.