repairing symantec endpoint protection 12.1 “Client version unavailable” broken client message on Mac OS X

If you’ve had Symantec Endpoint Protection 12.1 for Mac deployed for any length of time, you’ve probably come across this message in the SEPM console “Client Version Unavailable” under the Client Version heading. The only technical support articles I can find on Symantec’s website relate to making a previously unmanaged client into a managed client, which while useful, does not address the specific issue of a managed client that “breaks” and becomes unmanaged. Through extensive troubleshooting and a few shots in the dark, I believe I’ve uncovered several files that control the functional managed state of a SEP 12.1 client on a Mac.

The first is the file SyLink.xml, located in /Library/Application Support/Symantec/SMC/. This file controls management aspects for the SEP client, such as the management server name and address. On an unmanaged client this file is fairly empty and can be populated at varying times, all dependent on the type of installer package used to put SEP 12.1 on the client Mac. The second file, SymantecRegistry.xml in the same directory, controls machine-specific information like groupID, Hostname, Hardware ID, etc. This file is populated at install time and has a backup named SymantecRegistry.bak, also in the same directory. The backup file contains the same information as SymantecRegistry.xml.

Symantec’s fix for turning an unmanaged client into a managed client by replacing the SyLink.xml file only works for clients that are already functional and does not address the above issue where the SEPM server cannot gather information from the client (hence the “Client version unavailable” message). The problem stems from the SymantecRegistry.xml file being completely wiped out. Additionally, the SymantecRegistry.bak file is also completely wiped out. The physical files are there, they just don’t contain any data. I’m not entirely sure why this happens, but Symantec technical support seems to think  that this was an issue in the version 11 days… You’ll also notice that on managed clients, the SyLink.xml file is still populated with the correct information, and clients are still receiving virus definition updates from their internal LiveUpdate server (if your environment is so configured).

With that in mind, I modified the Symantec installer metapackage to only include the SMC installer package, some resource files, and the pre- and post-flight scripts for each. The SMC package replaces the /Library/StartupItems/SMC folder that Symantec uses, the SymantecRegistry.xml and .bak files, and the SyLink.xml file. Since this package was created from my company’s original installer package that contained a SyLink.xml file to manage each client, this brings the clients back into a managed state in addition to repairing SEP. You’ll want to replace the SyLink.xml file with your own before installing this package. The post-install and post-flight scripts in the SMC.pkg file re-populate these registry files just as they do on initial installation of the SEP client. Finally, I added a line to the post-flight script in the RepairSymantec.mpkg that kills the Symantec Quick Menu. This process respawns automatically after it is killed. This allows the technician to visually confirm that the client is back in a managed state by clicking on the Quick Menu. Otherwise a logout and login is required.

I’ve linked to the zipped package below. In the interested of expediency, I did not repackage the SEP metapackage, just altered the contents and changed the name, so it still has the .mpkg extension. Feel free to repackage as necessary. So far I have repaired half a dozen clients using this package.

About this entry