Silent deployment of SCSP Agent using SCCM 2012

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.

Locating cause of MSI error code 1603

If you’ve worked with an MSI based installation and passing parameters to automate the installation for software packaging, you may have seen an error code “1603”. This error code basically means there was a “Fatal error during installation”, which is very generic and it doesn’t tell you anything specific about the failure.

Found a very useful post from Aaron Stebner’s WebLog regarding this. You can find more details in the post from above link, but here’s the gist of this trick:

  1. Enable verbose logging for your MSI installation
  2. Open the log file of your failed installation
  3. Look/Search for “return value 3″
  4. The cause of the failure should be logged immediately or few lines above the line where you found “return value 3″

You may also find this post about understanding error code 1603 useful, which is posted on Symantec.

Secrets of setting up BIDS (Business Intelligence Development Studio)

BIDS (Business Intelligence Development Studio) has obviously gone through changes as newer versions of Microsoft’s SQL Server became available. Recently I had to work on setting up BIDS on some workstations, which were going to be used for development purpose. It didn’t seem complicated, at first. As I was preparing to work on this, it became a bit confusing, if not complicated and had to search a lot to find the right source for installing BIDS.

This is a tool that allows developers to create business solutions. When BIDS is installed, various project types will be available in Visual Studio that are specific to SQL Server Business Intelligence. And just because they’re available in Visual Studio, doesn’t necessarily mean BIDS is installed through Visual Studio. And Visual Studio is not available for free but BIDS is a free tool. So, when you install BIDS an “Integrated Shell for Visual Studio”  will be installed, if you already don’t have Visual Studio installed.

The confusing part is, there are different ways this can be installed and they’re not necessarily consistent across different versions. I feel that you need to know what you’re looking for. Hopefully, this post might point someone to the right direction if you need to install BIDS.

BIDS for SQL Server 2005

One source of installing BIDS 2005 is to use the source of SQL Server 2005 (not Express Edition). However, this is a licensed server application and not everyone will have access to this source. If you do have access to a source of SQL Server 2005, run the installation source and when you are at the section for choosing features, you can specify BIDS, along with other tools to be installed.

If you don’t have access to a copy/source of SQL Server 2005, you can download a standalone installer from Microsoft and install the tool. The installer is named “SQL Server 2005 Express Edition Toolkit“. Note that this is SP3 version, which is compatible with Windows 7.

Once you have the toolkit downloaded, run it on the machine where you need to setup BIDS 2005. Be sure to select “Business Intelligence Development Studio” from the Feature Selection screen and continue with the installation. Once the installation completes successfully, BIDS 2005 will be available in Start Menu.

BIDS for SQL Server 2005 Setup
Feature selection screen from SQL Server 2005 Express Edition Toolkit

BIDS for SQL Server 2008 R2

Similar to BIDS 2005, if you already have a source copy of SQL Server 2008 R2 (not Express edition), you can install BIDS from that source. As that’s not a free software, you may not have access to that source.

You can get a standalone installer from Microsoft Download Centre by visiting the download page for SQL Server 2008 R2 SP2 – Express Edition, but there are different types of installers available. Be sure to download SQL Server 2008 R2 Express Advanced (file name: SQLEXPRADV_x86_ENU.exe for 32-bit system and SQLEXPRADV_X64_ENU.exe for 64-bit system). During the install, you’ll have the option to select “Business Intelligence Development Studio” for installation.

BIDS for SQL Server 2010

This is where things started to change. Basically, BIDS is now part of what is called “SSDT (SQL Server Data Tools)“.  The download source for various versions of SSDT is “http://msdn.microsoft.com/en-ca/data/hh297027

According to MSDN article for installing SSDT, if you already have Visual Studio 2010 Professional, Premium or Ultimate Edition, you can simply install Service Pack 1 for Visual Studio which will add BIDS. That’s a licensed software. What if you don’t have Visual Studio 2010? Can you have a standalone installer for BIDS similar to previous versions? If you go to SQL Server Data Tools Download page, you’ll notice there’s no option for downloading BIDS 2010. Instead you’ll see a suggestion to try SSDT 2012 or SSDT 2013.

SSDT Visual Studio 2010 – We are no longer updating SSDT for Visual Studio 2010. Projects and DACPACs are fully compatible across shells. Please download the toolset for VS2012 or VS2013 using the links above for continued updates.

BIDS for SQL Server 2012

So we now know Microsoft introduced a new set of installer/tools called SSDT starting version 2010. According to the “Installing SSDT” article, you can have SSDT if you have Visual Studio 2012 Professional or higher edition installed. But what if you don’t have Visual Studio 2012 installed due to not having a license? You can try downloading a standalone installer for SSDT, but there are 2 different installer available.

  1. SSDT for Visual Studio 2012
  2. SSDT-BI for Visual Studio 2012

You’ll need to download SSDT-BI for Visual Studio 2012 and select BIDS from the Feature Selection page of the installation wizard.

BIDS for SQL Server 2012 Setup
Feature selection screen from SSDT-BI for Visual Studio 2012

BIDS for SQL Server 2013

Fortunately download and setup of BIDS 2013 hasn’t changed since version 2012. It’s still part of SSDT. You’ll need to download SSDT-BI for Visual Studio 2013 in order to get BIDS for SQL Server 2013