Storage Admin HubConfiguration · Protection · Recovery
All guides/Security
Security · ONTAP 9

Configure Vscan antivirus for SMB

Scanner servers, Antivirus Connector, scanner pool, on-access policy, validation and fault isolation.

Scenario

Worked example: svm_prod serves an SMB share. Two dedicated Windows scanner hosts, scan01.example.com and scan02.example.com, run a supported antivirus engine and ONTAP Antivirus Connector under EXAMPLE\svc_vscan. Replace every name and address with your own. Check the antivirus partner support matrix and ONTAP version first.

Before you change production

Commands and screens can differ by release and platform. Replace example names and documentation IP addresses. Check prerequisites, impact, current health and rollback with your change owner.

1. Decide scope and availability behavior

  1. Inventory the SMB SVM, CIFS server, client workload, largest files, applications that keep database or virtual-machine files open, and the current antivirus product. Check that the connector and antivirus engine versions support the ONTAP release. Vscan is off-box scanning: ONTAP sends eligible file operations to connected scanners; the antivirus product decides detection and remediation.
  2. Agree whether access must stop when all scanners are unavailable. With scan-mandatory on, affected file access may be denied; with it off, access can proceed without a scan. This is a security and availability decision. Record approved extension, size and path exclusions, and match them with the antivirus engine exclusions.
  3. Plan at least two suitably sized scanners and low-latency connectivity to the SVM. Create a dedicated domain account for scanning with minimum required rights, and identify which management or data LIF the connector will use.
Verify

Approved worksheet lists SVM, scanner names/IPs, account, scan policy, exclusions, failure behavior, and test window.

2. Prepare the scanner hosts and connector

  1. Join scanner hosts to the same or trusted AD domain as the SMB SVM. Install a partner-supported antivirus engine, update signatures, and configure its ONTAP integration as the partner documents. Install the supported ONTAP Antivirus Connector on each scanner host.
  2. In the connector configuration, add the ONTAP management or SVM address specified by the topology, configure the scanner identity and connection details, and use the connector Test action to verify connectivity and authentication. The installer screens and certificate configuration vary by connector version: follow the linked NetApp connector guide.
  3. Confirm DNS, time, routing and firewall paths between scanners, domain controllers and ONTAP. Keep scanners dedicated to this workload; verify antivirus service and connector service are running on both hosts.
Verify

Both scanner hosts pass the connector test and their engine services report healthy signatures.

3. Define and activate a scanner pool

  1. Create a scanner pool for the data SVM or cluster scope as intended. Register both scanner hostnames and the exact domain\user account used by the connector. For a cluster-scoped pool, apply its scanner policy to each data SVM that needs scanning.
  2. Apply the primary scanner policy on svm_prod, then verify the pool status is on. A secondary pool can be used as fallback where designed; idle means inactive. Do not enable mandatory scanning until connected scanner capacity is proven.
Example configuration and validation · review pool scope first 
vserver vscan scanner-pool create -vserver svm_prod -scanner-pool pool_prod -hostnames scan01.example.com,scan02.example.com -privileged-users EXAMPLE\svc_vscan
vserver vscan scanner-pool apply-policy -vserver svm_prod -scanner-pool pool_prod -scanner-policy primary
vserver vscan scanner-pool show -vserver svm_prod -scanner-pool pool_prod
vserver vscan connection-status show-connected
Verify

Pool is active and both expected scanner connections appear. If they do not, stop here and check account, connector, DNS and network.

4. Configure on-access scanning

  1. Review the existing default_CIFS on-access policy before creating another. Only one on-access policy can be enabled per SVM. Plan explicit maximum file size and extension/path exclusions, and understand that excluded files are not scanned even when mandatory scanning is on.
  2. For a staged test, create a separate policy with CIFS protocol and the agreed failure behavior. Avoid broad exclusions that hide executable or office file types. If another policy is enabled, document its settings and disable it through an approved change first. Enable the new on-access policy, then enable Vscan on the data SVM. Both switches must be on for scanning to run.
Example staged policy · verify release-specific defaults 
vserver vscan on-access-policy show -vserver svm_prod
vserver vscan on-access-policy create -vserver svm_prod -policy-name scan_prod -protocol CIFS -scan-mandatory off
vserver vscan on-access-policy enable -vserver svm_prod -policy-name scan_prod
vserver vscan on-access-policy show -vserver svm_prod -policy-name scan_prod
vserver vscan enable -vserver svm_prod
vserver vscan show -vserver svm_prod
Verify

The intended on-access policy alone shows status on, the scanner pool is active, and the scanner servers stay connected.

5. Prove scanning on a controlled share

  1. Create a disposable test folder on a share included in the scan scope. From a permitted SMB client, create and reopen a harmless test file, then check ONTAP Vscan activity and the antivirus product logs for an actual scan. A connected scanner alone does not prove that a file was scanned.
  2. If your security team authorizes an EICAR test, follow the antivirus vendor test procedure and observe its documented response in a disposable location. Do not use live malware or a production file to validate. Repeat from representative clients and each scanner path, and measure ordinary file-open latency.
Read-only ONTAP checks 
vserver vscan connection-status show
vserver vscan connection-status show-not-connected
vserver vscan on-access-policy show -vserver svm_prod
Verify

The antivirus log records eligible test operations, the agreed action occurs for the approved test, and normal file access remains acceptable.

6. Diagnose failures and plan rollback

  1. No scanners connected: compare scanner pool hostnames/IPs and privileged user with connector identity, then check connector/AV service state, DNS, domain trust, routes, firewall and LIF reachability. Use connection-status show-not-connected for the next clue.
  2. Files never scanned: verify share and protocol, policy status, file size, path/extension exclusion, antivirus product integration, and whether that file operation triggers scanning. High SMB latency: correlate file-open latency with scanner CPU, request queues, scan duration and network round trip; add scanner capacity or narrow an approved scope only after measurement.
  3. Rollback during a failed pilot: restore the prior on-access policy and scanner-pool policy per the change record. If mandatory scanning blocks access because all scanners are down, involve the security owner before changing failure behavior or disabling scanning. Re-test and document the time window of reduced protection.
Verify

Record scanner connection status, affected client/share, timestamps, policy output, AV events and the restoration decision.

NetApp references