Gentlemen,
Wondering if anyone seen the issue we've been having in our rollout of SEP:
- in about 5% of all machines with SEP installed, SMC.EXE is taking 50% CPU (on dual-core) or 100% CPU (on single core). This occurs after install is completed, machine is rebooted and LiveUpdate is run. System sometimes have a green dot, sometimes it doesn't, but in all cases under  Help and Support -> Troubleshooting, server is listed as "Offline". It looks like machine gets SEP installed, connects to the server successfully, gets policies and sends logs and then loses connectivity for some reason. Interestingly, straight TCP connection to server works fine: I can resolve, ping or telnet to the server on SEP port just fine; it's SMC.EXE that loses its mind and can't connect to the server for some reason.
The fix so far, after many hours, is to uninstall CheckPoint SecureClient -> reboot -> reinstall CheckPoint SecureClient. Again, CheckPoin's SecureClient is not blocking SEP's traffic, it just looks like SMC.EXE and CheckPoint start to butt heads at some level, causing SMC.EXE not being able to communicate, and therefore peg CPU. I'm speculating, but I suspect that something happens during the installation that modifies either the order of network interfaces or changes the routes altogether, that throws SMC.EXE off completely. ROUTE PRINT looks OK and like I said above, direct TCP connections work fine, it's something with the way SMC.EXE tries to route traffic that is causing the issue, something that reinstalling VPN client fixes.
I searched the forum and Google and general and made sure there're no rogue adapters, no RIP network services, no orphaned Cisco VPN clients, etc. For the moment we have a fix, but I would like to hear an explanation of why such things may be happening from the old and wise here. We opened a ticket, too, but it will probably be few years before we'll get someone with half a brain via that route.
Thank you for your time.

Dimitri