Restrict privileged users to virus-scanning operations. Normal users should be discouraged from using privileged user credentials. This restriction can be achieved by turning off login rights for privileged users on Active Directory.
Privileged users are not required to be part of any user group that has a large number of rights in the domain, such as the administrators group or the backup operators group. Privileged users must be validated only by the storage system so that they are allowed to create Vscan server connections and access files for virus scanning.
Use the computers running Vscan servers only for virus-scanning purposes. To discourage general use, disable the Windows terminal services and other remote access provisions on these machines and grant the right to install new software on these machines only to administrators.
Dedicate Vscan servers to virus scanning and do not use them for other operations, such as backups. You might decide to run the Vscan server as a virtual machine (VM). If this is the case, ensure that the resources allocated to the VM are not shared and are enough to perform virus scanning. Consult Symantec for guidance on antivirus engine requirements.
Provide adequate CPU, memory, and disk capacity to the Vscan server to avoid resource bottlenecks. Most Vscan servers are designed to use multiple CPU core servers and to distribute the load across the CPUs. Consult Symantec for guidance on antivirus engine requirements.
Fujitsu recommends using a dedicated network with a private VLAN for the connection from the SVM to the Vscan server so that the scan traffic is not affected by other client network traffic. Create a separate NIC that is dedicated to the antivirus VLAN on the Vscan server and to the data LIF on the SVM. This step simplifies administration and troubleshooting if network issues arise. The AV traffic should be segregated using a private network. The AV server should be configured to communicate with domain controller (DC) and clustered ONTAP in one of the following ways:
- The DC should communicate to the AV servers through the private network that is used to segregate the traffic.
- The DC and AV server should communicate through a different network (not the private network mentioned previously), which is not the same as the CIFS client network.

For Kerberos authentication to work for the AV communication, create a DNS entry for the private LIFs and a service principal name on the DC corresponding to the DNS entry created for the private LIF. Use this name when adding a LIF to the AV Connector. The DNS should be able to return a unique name for each private LIF connected to the AV Connector.

IMPORTANT: If the LIF for Vscan traffic is configured on a different port than the LIF for client traffic, the Vscan LIF might fail over to another node in case of a port failure. The change will make the Vscan server not reachable from the new node and the scan notifications for file operations on the node will fail. Ensure that the Vscan server is reachable through at least one LIF on a node so that it can process scan requests for file operations performed on that node.

Connect the Fujitsu storage system and the Vscan server by using at least a 1GbE network.
For an environment with multiple Vscan servers, connect all servers that have similar high-performing network connections. Connecting the Vscan servers improves performance by allowing load sharing.
For remote sites and branch offices, Fujitsu recommends using a local Vscan server rather than a remote Vscan server because the former is a perfect candidate for high latency. If cost is a factor, use a laptop or PC for moderate virus protection. You can schedule periodic complete file system scans by sharing the volumes or qtrees and scanning them from any system in the remote site.
Use multiple Vscan servers to scan the data on the SVM for load-balancing and redundancy purposes. The amount of CIFS workload and resulting antivirus traffic vary per SVM. Monitor CIFS and virus-scanning latencies on the storage controller. Trend the results over time. If CIFS latencies and virus-scanning latencies increase due to CPU or application bottlenecks on the Vscan servers beyond trend thresholds, CIFS clients might experience long wait times. Add additional Vscan servers to distribute the load.
Install the latest version of Antivirus Connector.
Keep antivirus engines and definitions up to date. Consult Symantec for recommendations on update frequency.
In a multi-tenancy environment, a scanner pool (pool of Vscan servers) can be shared with multiple SVMs provided that the Vscan servers and the SVMs are part of the same domain or of a trusted domain.
The AV software policy for infected files should be set to delete or quarantine, which is the default value set by most AV vendors. In case the vscan-fileop-profile is set to write_only, and if an infected file is found, the file remains in the share and can be opened since opening a file will not trigger a scan. The AV scan is triggered only after the file is closed.
The scan-engine timeout value should be lesser than the scanner-pool request-timeout. If it is set to a higher value, access to files might be delayed and may eventually time out. To avoid this, configure the scan-engine timeout to 5 seconds lesser than the scanner-pool request-timeout value. See the scan engine vendor’s documentation for instructions on how to change the scan-engine timeout settings. The scanner-pool timeout can be changed by using the following command in advanced mode and by providing the appropriate value for the request-timeout parameter: vserver vscan scanner-pool modify
For an environment that is sized for on-access scanning workload and requiring the use of on-demand scanning, it is recommended to schedule the on-demand scan job in off-peak hours to avoid additional load on the existing AV infrastructure.