Recently I’ve had to work on deploying an Agent named SCSP (version 6.0) to about 100 workstations that were going to be monitored for security requirement. It’s a product of Symantec’s Data Center Security software. I was preparing the agent to be installed/deployed silently and we use Microsoft’s System Center Configuration Manager (SCCM) 2012 for software deployment.
You can find the silent install command for the agent installation from Symantec’s documentation. Their documentation will have example of silent installation command, which might look something like this:
agent.exe /s /v"MANAGEMENT_SERVER=192.168.1.103 SSL_CERT_FILE=c:\temp\Agent-cert.ssl -l*v+! %temp%\SISAgentSetup.log /qn"
I’ve set it up as an application in SCCM and tested it on a workstation, but the application/agent failed to install. I know that the previously mentioned install command works, but obviously something wasn’t working right. So, it was time to start troubleshooting.
Opened up the “AppEnforce.log” file from the target machine where the install had failed and found that the install had returned an MSI error code “1603”. I don’t usually like that error code, since it’s very generic and doesn’t tell you where the problem is. But, there’s a nice tip that helps locate the source of MSI error code 1603.
So, now it’s time to look at the verbose error code generated during installation, which is saved in “%temp%\SISAgentSetup.log” file (if that’s what you specified in your install command like the previous example). Opened up that log file and after parsing through the logs above the line where there was “return value 3″, found the following error:
1: ************************************************** 1: *** SilentInputValidation() -> begin. 1: *** INPUT VALIDATION ERROR! Could not read from the certificate file.
That was an interesting error! I had the following as installation command in SCCM application deployment type:
agent.exe /s /v"MANAGEMENT_SERVER=my_server_ip SSL_CERT_FILE=Agent-cert.ssl IDS_CONFIG_GROUP=my_group -l*v+! %temp%\SISAgentSetup.log /qn /norestart"
Notice that difference between my install command and Symantec’s example in the SSL_CERT_FILE parameter value. I have it as “Agent-cert.ssl” as opposed to “c:\temp\Agent-cert.ssl“. This is because when an application is deployed by SCCM, it will download the install source to a directory on the target machine. This directory will be randomly generated but will always be a sub-directory under “C:\Windows\ccmcache\” directory. So, for different workstations, the install source will be located at different directories. That’s why my install command used relative path because one thing I know for certain is that the cert file will ALWAYS be located at the same location as the “agent.exe”.
I then modified the previous command slightly to indicate that the cert file is in the same directory as “agent.exe”. Now, the install command looked like this:
agent.exe /s /v"MANAGEMENT_SERVER=my_server_ip SSL_CERT_FILE=.\Agent-cert.ssl IDS_CONFIG_GROUP=my_group -l*v+! %temp%\SISAgentSetup.log /qn /norestart"
Did you see the difference? Now, there’s a “.\” in front of “Agent-cert.ssl”. I’ve had to add “.\” to the parameter value for few other applications I had packaged. But this time, it didn’t work. Still getting same issue & error as above.
After doing a lot of trial & error with silent install command and running it manually, it was clear that the path to the cert file MUST BE absolute. The installer can’t seem to locate the cert file if the value of SSL_CERT_FILE is relative. In fact, the verbose log shows following line well before previously mentioned error was logged:
MSI (s) (50:74) [12:03:33:994]: PROPERTY CHANGE: Modifying SSL_CERT_FILE property. Its current value is 'c:\temp\agent-cert.ssl'. Its new value: 'Agent-cert.ssl'.
The installer seem to have it hard coded that the cert file will be located in “C:\temp\” directory and that it will be named “agent-cert.ssl”. So, not only it can’t interpret the path to the cert file relative to where the installer is, but it actually assumes that the cert must be in above mentioned directories.
So, then I had modified my install command in SCCM application to use ABSOLUTE PATH, even though the cert file is available on the target machine. Now, the install command looked like this:
agent.exe /s /v"MANAGEMENT_SERVER=my_server_ip SSL_CERT_FILE=\"\\server\sharename\app_source\symantec_csp\v6.0\Agent-cert.ssl\" IDS_CONFIG_GROUP=my_group -l*v+! %temp%\SISAgentSetup.log /qn /norestart"
So, now the application gets installed successfully according to install status on “Software Center” and SCCM log file (AppEnforce.log), but I don’t see it installed. After a bit more digging, found the application is indeed installed, but it didn’t create a shortcut in the Start Menu. That was because when the application was installed by SCCM, it ran under a system account. The installer for SCSP (agent.exe) will create Start Menu shortcut by default for the user account that runs the installation. One more update to the install command:
agent.exe /s /v"MANAGEMENT_SERVER=my_server_ip SSL_CERT_FILE=\"\\server\sharename\app_source\symantec_csp\v6.0\Agent-cert.ssl\" IDS_CONFIG_GROUP=my_group ALLUSERS=1 -l*v+! %temp%\SISAgentSetup.log /qn /norestart"
Added “ALLUSERS=1″ into the installation command line, which is an MSI property for installing the application for, well, All Users! Now everything is working as expected.
You could also solve it slightly differently. For example, you could write a simple batch script that will determine the current location of the install source files and then pass that as the parameter value for SSL_CERT_FILE. Then you could simply use that batch script as the installation program for SCCM deployment type.
If you’re working on deploying the agent silently, I hope this helps.