Automatic Installation¶

Administration¶

For an unattended installation or rollout, different command line parameters are available that can be passed to the setup:

/SILENT /SUPPRESSMSGBOXES: Installs the software with the default values without user interaction. The installation progress is displayed.
/VERYSILENT /SUPPRESSMSGBOXES: Installs the software without user interaction with the default values without any visual feedback.
/PASSWORD=InstallKey: Registers the software with the specified installation key.
/DIR="x:\dirname": Specifies the path where SpaceObServer should be installed
/SERVICEUSER “<user name>”: Passes the application the name of the user account to be used for scanning and indexing. If no input is provided, the default system account will be used (not recommended).
/SERVICEPWD “<password>”: Passes the application the password of the user account to be used for scanning and indexing. If no input is provided, the default system account will be used (not recommended). Note: Use this parameter only in combination with /SERVICEUSER “<user name>”.
/ENABLEINDEXSERVER: Use this parameter to enable central indexing (DataCentral service). With this option, you can use UltraSearch to search this central index. This allows multiple devices to share a single common search index.
/USESELFSIGNEDCERTIFICATE: Use this parameter to create and use a new self-signed certificate (PFX file). Note: If no certificate parameters are specified, this parameter is the default option.
/INDEXSERVERCERTIFICATE “<full path to pfx-file>”: Specifies the full path to a certificate file (PFX file) that is already installed and will be used for encrypting communication with the DataCentral server.
/INDEXSERVERCERTIFICATEPASSWORD “<password of pfx-file>“: If the PFX file specified with the /INDEXSERVERCERTIFICATE parameter is protected by a password, use this parameter to specify the password. Note: Use this parameter only in combination with /INDEXSERVERCERTIFICATE.

Unattended Installation using a PowerShell script¶

Using the options above SpaceObServer can be distributed automatically. For example, the following PowerShell script copies the Setup.exe from a specified directory to a PC and executes it there. This example requires administrative shares to be enabled.

In the initial lines, the search path of the installation file and the name of the target computer are defined. Next, the username and password for accessing the computer are prompted. After testing the computer’s reachability, the temporary directory C:\temp will be created and the setup file will be copied.

Finally, the Setup.exe will be invoked using these options to install SpaceObServer with enabled DataCentral service and self signed certificates: /VERYSILENT, /SUPPRESSMSGBOXES, /ENABLEINDEXSERVER, /USESELFSIGNEDCERTIFICATE

$SOSSetupName = "SpaceObServer-Setup.exe"
$SetupPath = "\\intranet\setups\$SOSSetupName"
$DestinationHost = "client-pc"

$User = Read-Host "User name (z.B. domain\username)"
$SecPassword = Read-Host "Password" -AsSecureString

$Credential = New-Object System.Management.Automation.PSCredential ($User, $SecPassword)

$RemoteTempFolder = "\\$DestinationHost\C$\Temp\"
$LocalSetup = "C:\Temp\$SOSSetupName"

if (-not (Test-Connection -ComputerName $DestinationHost -Count 1 -Quiet)) {
    throw "Target host '$DestinationHost' cannot be reached."
}

if (-not (Test-Path $RemoteTempFolder)) {
    New-Item -Path $RemoteTempFolder -ItemType Directory -Force | Out-Null
}

Copy-Item -Path $SetupPath -Destination $RemoteTempFolder

$ScriptBlock = {
    param($LocalSetup)
    Start-Process -FilePath $LocalSetup -ArgumentList "/VERYSILENT", "/SUPPRESSMSGBOXES", "/ENABLEINDEXSERVER", "/USESELFSIGNEDCERTIFICATE" -NoNewWindow -Wait
}

Invoke-Command -ComputerName $DestinationHost -ScriptBlock $ScriptBlock -ArgumentList $LocalSetup -Credential $Credential

Remove-Item -Path "$RemoteTempFolder$SOSSetupName" -Force

Unattended Installation on Multiple Servers as Local Scan Agents¶

For the best scan performance, SpaceObServer should scan directories/shares locally instead of scanning them remotely over the network (see “Recommended Settings”). To achieve this, or to balance load over multiple machines, it can be useful to install multiple SpaceObServer instances on different machines. Each of these installations then acts as a local scan agent: it can either only scan its own local drives or a subset of servers via the network, using its own “SpaceObServer scan service”, and stores the results in one shared, central database, so that all servers can still be reviewed together from a single “SpaceObServer Client Access” or “SpaceObServer Web Access” installation.

The sample script “UnattendedInstallation.ps1” in the subdirectory “Demos\powershell” of your SpaceObServer installation directory (C:\Program Files\JAM Software\SpaceObServer) automates the setup of exactly such a local scan agent on one server. It performs three steps in sequence:

It runs the setup with /SILENT /SUPPRESSMSGBOXES /SERVICEUSER /SERVICEPWD /PASSWORD= to install SpaceObServer silently and register the “SpaceObServer Agent” scan service with a dedicated service account.
It creates a SpaceObServer OLE automation object and sets ConnectionString to point the new instance at your central SQL database.
It calls ScheduleScan to set up recurring scans.

To roll this out to multiple servers, you need to adjust the following:

Replace the placeholder values at the top of the script (installer path, service account, service password and installation key).
Replace the connection string by copying it from your main SpaceObServer instance under “Home” > “Options” > “Database”. Keep in mind that you need to replace the placeholder with the actual password: it is stored encrypted within SpaceObServer, but must be supplied unencrypted here.
Replace the added C:\\ and D:\\ scans with the paths that each individual instance should analyze. By doing this here in the script, only this local instance will be responsible for scanning those paths. See the “Observing Server” expert setting for reference.

Run the script once per server: either locally on the target, or pushed via Invoke-Command/PsExec the same way as the single-host example above. The script itself only ever configures the machine it runs on; it does not loop over a server list.

When installing several of these local scan agents against one shared database, watch out for the following:

Service account permissions: The account passed via $ServiceUser/$ServicePwd needs read access to the drives being scanned on that specific server. Using the same domain account on every server is convenient, but its rights must still be verified locally on each machine.
Overlapping scan paths: Every server writes into the same database. If two servers are configured to scan the same path (e.g. both pointing at the same network share), only the first is added, since SpaceObServer only allows a given path to be scanned once.
Matching connection strings: All agents must use a ConnectionString that resolves to the exact same database so that “SpaceObServer Client Access” shows one consolidated view. An incorrect connection string will not be accepted, as SpaceObServer directly verifies the connection — make sure the database is reachable from this machine.
Installation key: $InstallPwd registers the installation key on each machine individually. Check your license terms/customer area for whether one key covers all servers in the rollout or whether each installation needs its own key.
Scan scheduling: Scheduling all servers to scan at the same time (as in the default script) causes every agent to write to the shared database simultaneously. For larger rollouts, stagger the ScheduleScan start times across servers to spread the load on the central SQL Server.
Remote execution prerequisites: If you push the script to remote servers instead of running it locally, the same requirements as for the single-host example apply: administrative shares and, for Invoke-Command, PowerShell remoting (WinRM) must be enabled and reachable on each target server.