Scenario
Worked example: monitor SMB file opens on volume vol_projects in svm_prod using two vendor FPolicy servers at documentation addresses 192.0.2.61 and 192.0.2.62. This external-engine example assumes the vendor supports synchronous responses; choose authentication, port and mandatory behavior according to its tested integration. Native extension blocking is a separate option.
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. Define the use case and outage behavior
- Decide whether the objective is audit/observation, classification, ransomware analytics or file blocking. The FPolicy server product must support the chosen ONTAP release and event type. Identify the SVM, protocol, exact operations, volumes or shares, and expected event rate; watching every read/write can create unnecessary load.
- For synchronous mandatory screening, file access can be denied if all external servers are down or do not answer in time. Decide this deliberately and document the product timeout, server redundancy, security certificates and failure runbook. For simple extension blocking with the native ONTAP engine, no external FPolicy server is required.
- Use a limited test volume and client first. Confirm the user-facing effect of a denied file operation, your change authority, and an immediate disable command.
Verify
Worksheet records use case, server IPs, transport/security option, event operations, scope, priority, response mode and outage decision.
2. Prepare external servers and connectivity
- Install and configure the vendor FPolicy service on two hosts; determine listening port, certificates and SSL option supported by both vendor and ONTAP. The no-auth setting in the illustrative command below provides no external communication authentication; choose a secure vendor-supported option in production.
- Open the required network path from participating ONTAP nodes to each FPolicy server and establish DNS/time/certificate trust as appropriate. If the product needs privileged file reads, configure that only as documented by the vendor and grant minimum scope.
Read-only planning
network interface show -vserver svm_prod
vserver fpolicy policy external-engine show -vserver svm_prodVerify
Vendor services listen on both hosts and the agreed authentication and failover design is documented.
3. Build the external engine and SMB event
- Create an external engine on svm_prod pointing at both approved FPolicy servers. The demonstration uses port 6789 and no-auth to show CLI structure; use the vendor-prescribed port and SSL configuration in production.
- Create an event for SMB opens only. Add other operations only when the business requirement and product support call for them. Verify the event and engine definitions before associating a policy.
Illustrative external-engine commands · no-auth is for a controlled lab
vserver fpolicy policy external-engine create -vserver svm_prod -engine-name engine_demo -primary-servers 192.0.2.61,192.0.2.62 -port 6789 -ssl-option no-auth
vserver fpolicy policy event create -vserver svm_prod -event-name smb_open_demo -protocol cifs -file-operations open
vserver fpolicy policy external-engine show -vserver svm_prod -engine-name engine_demo
vserver fpolicy policy event show -vserver svm_prod -event-name smb_open_demoVerify
The same SVM owns the event and engine; server addresses, port and monitored operation match the worksheet.
4. Create policy, narrow scope and enable
- Associate the event and engine in a policy. Choose mandatory or non-mandatory screening based on the approved failure mode; inspect policy defaults instead of assuming them. Create a scope including only vol_projects. Exclusion lists take precedence over include lists, so inspect all scope fields.
- Enable with an explicit sequence number after the vendor server is reachable. If multiple FPolicy policies monitor the same event, review priority and the fact that native policies have special priority behavior. Turn on traffic for one test client, then broaden only after measurement.
Example configuration · inspect mandatory and privilege defaults
vserver fpolicy policy create -vserver svm_prod -policy-name policy_demo -events smb_open_demo -engine engine_demo
vserver fpolicy policy show -vserver svm_prod -policy-name policy_demo
vserver fpolicy policy scope create -vserver svm_prod -policy-name policy_demo -volumes-to-include vol_projects
vserver fpolicy policy scope show -vserver svm_prod -policy-name policy_demo
vserver fpolicy enable -vserver svm_prod -policy-name policy_demo -sequence-number 1
vserver fpolicy show -vserver svm_prodVerify
Policy shows on, scope contains only the intended volume, and vendor server receives test notifications.
5. Validate event delivery and client impact
- From an authorized SMB client, open one file in vol_projects and another in an out-of-scope volume. Confirm the vendor FPolicy server sees the first and does not see the second; compare timestamps and client response latency. Test the product action for permitted and denied operations with disposable files.
- Check connection status and policy state on every participating node. A policy that shows on can still have disconnected external servers. Record baseline event rate, queue/backpressure metrics from the vendor, and file-open latency before production expansion.
Read-only validation
vserver fpolicy show -vserver svm_prod
vserver fpolicy show-engine -vserver svm_prod
vserver fpolicy policy scope show -vserver svm_prod -policy-name policy_demoVerify
Vendor events match the intended scope and operation; no unexpected file-open denial or latency regression.
6. Native file-blocking alternative
- If the goal is only to block chosen extensions, use a native engine policy instead of creating an external engine. Create the relevant file-operation event, associate engine native, and configure a carefully reviewed scope including the intended extensions and volume/share.
- Directory behavior and extension matching need a separate validation test; do not assume that the external-server scope settings have identical behavior for the native engine. Follow the NetApp native-engine guidance and test both files and directories before enabling broadly.
Example native policy creation only · scope and enablement require design
vserver fpolicy policy create -vserver svm_prod -policy-name native_demo -events smb_open_demo -engine native
vserver fpolicy policy show -vserver svm_prod -policy-name native_demoVerify
Native policy is kept disabled until extension scope and directory behavior pass controlled tests.
7. Troubleshoot and restore service
- No events: verify policy on, matching event operation and protocol, inclusion/exclusion scope, SVM, and external server connection. For a disconnected server, check FPolicy service, port, routing, certificates and logs. If clients hang or receive access denied, correlate server timeouts and policy mandatory setting before changing unrelated SMB permissions.
- If the pilot causes unacceptable client impact, disable only the affected policy using the approved rollback, then confirm file operations recover and vendor notifications stop. Preserve logs and investigate why the request or response failed. Re-enable only after the product and operations owners agree.
Controlled rollback example
vserver fpolicy disable -vserver svm_prod -policy-name policy_demo
vserver fpolicy show -vserver svm_prodVerify
Affected client operation recovers and the disabled policy no longer monitors access.