System Requirements

You are here:
Component Purpose/Comments Requirements
Installation Package
  • The NSS software is provided as two installation packages:
    • The ‘NSS’ package – containing installation files for Scanning Server and Quota Server installations.
    • The ‘Console’ package – containing installation files for  Console Server installation.
  • Normally these packages are provided for download as a single zip file.
  • Complete the Software Download Request form to request a password protected download link.
  • After download, confirm that the package has not been blocked by Windows Defender SmartScreen
    • Right-click and check properties on the downloaded zip archive.
    • Click ‘Unblock’ if this button is shown and enabled.
  • Northern recommends placing the downloaded package in a ‘Northern’ folder in a drive root on each server where the software is to be installed – so it can be quickly found by all staff participating in the installation work.
  • All packages must be installed with an account that has administrative privileges on the server where the installation is being carried out.
Service Account
  • All four services (NSSX, Quota Update, Core, and Quota Server) should run under the same domain account.
  • More information about the function of these services is available below in ‘Services’.
  • Permissions on NSS servers:
    • Member of the Local Administrators group on the Console Server and each Scanning and Quota Server servers.
  • Permissions on target data containers:
    • Member of Backup Operators and Power Users groups on each target CIFS server, as well as on each share that will be managed with the software.
    • For SharePoint (on-premise and SharePoint Online) Read permissions on all target sites and document libraries are required.
  • Permissions/Roles on NSS databases must be configured, see “Database Management Server”, “Data Database” and “Client Database” below. (Only applicable if Windows Authentication is selected when configuring database connections.)
  • The service account does not require the interactive logon right.
SQL Authentication Account
  • NSS can be configured to use Windows Authentication or SQL Authentication when connecting to its databases.
  • If SQL authentication will be used then an explicit SQL Login is necessary.
  • Permissions/Roles on NSS databases must be configured, see “Database Management Server”, “Data Database” and “Client Database” below.
Services
  • NSSX Service
    Responsible for execution of file system scanning and internal administrative tasks.
  • Only one NSSX service should be configured in a deployment of NSS.
  • This service is installed from the NSS Console installation package – it should be run on the NSS Console Server.
  • NSS Quota Update Service
    Responsible for collecting quota information from all Quota Servers in a deployment, and storing it into the ‘Data’ database for display in the console interface.
  • This service is installed from the NSS Console installation package, i.e. the service should run on the NSS Console Server.
    • As there should be only one NSS Console installation in a deployment, likewise there should be only one NSS Quota Update service running in a deployment.
  • NSS Core Server Service
    Responsible for scanning of target data containers, collating and summarizing data and storing results into the Data database.
  • NSS Core Server service should run on all Scanning Servers in the deployment.
  • This service is installed from the NSS package.
  • NSS Quota Server Service
    Responsible for monitoring file system activity, maintaining quota usage level information and triggering actions at size thresholds.
  • NSS Quota Server service should run on all Quota Servers in the deployment.
  • This service is installed from the NSS package.
Console Server
  • Only one Console Server should be setup per deployment of NSS.
  • Serves web-based, self-service interface (for file system analysis).
  • Runs the NSSX service.
  • Runs the Quota Update service.
  • Only the Console package needs to be installed on the Console Server.
  • Windows Server 2012 or higher
  • Internet Explorer 11
  • CPU: Minimum of 6 cores
  • RAM: Minimum of 6 GB
  • HDD: 20 GB available
  • .NET Framework 4.5
  • IIS 7.5 or above
  • IIS feature > Performance > Static Content Compression
  • IIS feature > Security > Windows Authentication
  • IIS feature > Application Development > ASP .NET
  • IIS feature > Application Development > ASP
  • IIS feature > Application Development > ISAPI Filters
  • IIS feature > Application Development > ISAPI Extensions
  • IIS feature > Common HTTP Features > StaticContent
  • This server can be a physical machine or a virtual machine.
Scanning Server(s)
  • Used to execute Scan Jobs configured through the NSS console; scanning target data containers, collating and summarizing data and storing results into the Data database.
  • Only the NSS package should be installed on a Scanning Server.
  • Windows Server 2012 or higher.
  • CPU: Minimum of 6 cores.
  • RAM: Minimum of 4 GB.
  • HDD: 20 GB available.
  • If the text-mining capabilities of NSS will be used:
    • “Microsoft Office 2010 Filter Pack” must be installed. Go to Microsoft’s Download Center and search for ‘Office Filterpack’.
      • The filter pack is regularly updated via Windows Update.
  • This server can be a physical machine or a virtual machine.
  • If the target data containers are primarily located in the cloud, the Scanning Server(s) should be located in the same cloud instance.
Quota Server(s)
  • Manages all real-time file system monitoring and enforcement policies:
    • Soft quota
    • Hard quota
    • Threshold actions
    • File Block
    • File Allow
  • Only the NSS package should be installed on a Quota Server.
  • Windows Server 2012 or higher.
  • CPU: Minimum of 6 cores.
  • RAM: Minimum of 8 GB.
    • For quota operations, NSS stores current folder sizes in memory. It uses approximately 1 GB of RAM per 1 million folders under quota. Meaning that the number of folders under quota determines the amount of memory required, not the number of quotas.
  • HDD: 20 GB available.
  • This server can be a physical machine or a virtual machine.
  • If the target data containers are located in the cloud, the Quota Server(s) managing those containers should be located in the same cloud instance. (Only relevant for Cloud Volumes ONTAP and Azure File Storage – the cloud platforms that support quota features.)
SMTP Server
  • Used to send notifications when users are given access to the self-service reporting interface (‘Welcome Emails’) and when quota thresholds are reached (‘Quota Notifications’).
  • A valid email address must be configured/available from which NSS can send emails.
  • The details (name and password) of an AD account with the authority to send emails from the specified email address must be known.
  • If the default outgoing port (25) has been changed, the non-standard port setting must be known.
  • If Transport Layer Security (TLS) is to be used then a valid TLS certificate must be correctly implemented on the SMTP server.
    • All versions of TLS (and SSL) are supported.
Database Server
  • Holds NSS’ two databases:
    • Data database
    • Client database
  • The NSS databases (Data and Client) are only accessed by the Service Account OR the SQL Authentication Account (depending on which authentication method is selected), and the LocalSystem account for the Console Server – no other accounts access the databases.
  • The server does not need to be dedicated to NSS.
  • MS SQL Server 2012 or higher
  • MS SQL Express 2012 or higher (POC/POV deployments only)
  • MS SQL Management Studio installed (with ‘install for all users’ flag).
  • CPU: Minimum of 6 cores.
  • RAM: Minimum of 8 GB.
  • HDD: see “Data Database” and “Client Database” below for database sizing information.
  • Explicit SQL Logins must be created for the following accounts:
    • Service Account
      (If Windows Authentication will be used for database connections).
    • SQL Authentication Account
      (If SQL Authentication will be used for database connections).
    • NSSConsole Application Pool account (the ‘Identity’ property for the NSSConsole Application Pool in IIS).
      • By default, this is the AD computer object (NetBIOS name) of the Console Server, i.e. DOMAIN\CONSOLESERVER$ (or NT AUTHORITY\SYSTEM if the Console Server and the Database Server are the same machine).
  • Permissions/Roles:
    • See “Data Database” and “Client Database” below for details.
  • This server can be a physical machine or a virtual machine.
  • If the Scanning Server(s) are primarily located in the cloud, the Database Management Server should be located in the same cloud instance.
Data Database
  • The main database of NSS.
  • Holds data collected by file system scanning operations.
  • Also holds quota summary information when quotas are configured and the NSS Quota Update Service is running.
  • The database can be given any name, ‘Data’ is used in Northern’s documentation.
  • Recovery model:
    • Simple
  • Collation:
    • Case Insensitive (CI)
    • Accent Sensitive (AS)
    • Kanatype Sensitive (KS)
    • Width Sensitive (WS)
    • e.g. Latin1_General_CI_AS_KS_WS
  • Schema:
    • dbo
  • Database Size:
    Anticipate that this database will be approximately 0.2% of the size of the environment being scanned after 1 year of normal use i.e. a 100 TB environment will result in a database of ~200 GB.

    • Size is determined by:
      • The number and type of Scan Jobs that are run.
      • The frequency with which these jobs are run.
      • The volume of historical data that is kept.
      • The size of the environment being scanned.
  • Permissions/Roles – Service Account (if Windows Authentication will be used for database connections):
    • Role Membership (set at the Server level in Security > Logins > ‘login’ > Properties > User Mapping > ‘Data database’):
      • db_owner, OR…
      • db_datareader AND db_datawriter AND db_ddladmin
    • Explicit Permissions (only applicable if db_owner role is not used, set in the Permissions properties of the database):
      • Execute
      • View database state
  • Permissions/Roles – SQL Authentication Account (if SQL Authentication will be used for database connections):
    • Role Membership (set at the Server level in Security > Logins > ‘login’ > Properties > User Mapping > ‘Data database’):
      • db_owner, OR…
      • db_datareader AND db_datawriter AND db_ddladmin
    • Explicit Permissions (only applicable if db_owner role is not used, set in the Permissions properties of the database):
      • Execute
      • View database state
  • Permissions/Roles – NSSConsole Application Pool account (see “Database Management Server > Explicit SQL Logins” above):
    • Role Membership (set at the Server level in Security > Logins > ‘login’ > Properties > User Mapping > ‘Client database’):
      • db_datareader
Client Database
  • Holds NSS console view configuration information, including users’ customized views and View Profiles.
  • The database can be given any name, ‘Client’ is used in Northern’s documentation.
  • Recovery model:
    • Simple
  • Collation:
    • Case Insensitive (CI)
    • Accent Sensitive (AS)
    • Kanatype Sensitive (KS)
    • Width Sensitive (WS)
    • e.g. Latin1_General_CI_AS_KS_WS
  • Schema:
    • dbo
  • Database Size:
    The size of the ‘Client’ database should not exceed 2 GB, even in situations where large numbers of users are able to customize their dashboards.
  • Permissions/Roles – Service Account (if Windows Authentication will be used for database connections):
    • The service account needs no access to the Client database
  • Permissions/Roles – SQL Authentication Account (if SQL Authentication will be used for database connections):
    • Role Membership (set at the Server level in Security > Logins > ‘login’ > Properties > User Mapping > ‘Client database’):
      • db_datareader
      • db_datawriter
      • db_ddladmin
  • Permissions/Roles – NSSConsole Application Pool account (see “Database Management Server > Explicit SQL Logins” above):
    • Role Membership (set at the Server level in Security > Logins > ‘login’ > Properties > User Mapping > ‘Client database’):
      • db_datareader
      • db_datawriter
      • db_ddladmin
Target Data Containers NetApp CDOT

  • All NSS capabilities are available.
  • All namespace architectures are supported (single branched tree, multiple branched trees, multiple stand-alone volumes, etc.).
  • Data ONTAP 8.3 or later
  • The NetApp FPolicy interface is required if Soft Quotas, Hard Quotas and/or File Block policies will be used.
    • The NetApp FPolicy interface must be enabled on each SVM.
    • A LIF with management access must be available for each SVM.
    • An FPolicy Management Account must be available/created. This account is used to create and manage FPolicy connections. A domain account or local account (at the SVM level) can be used. For security reasons Northern recommends using local accounts. The requirements for local accounts are as follows:
      • When multiple SVMs will be managed, multiple local accounts must be created. The names and passwords of these accounts must be identical.
      • The accounts used must have the ontapi application login method, with the vsadmin role.
NetApp 7-Mode

  • All NSS capabilities are available.
  • Data ONTAP 8.0 – 8.2.5
  • The NetApp FPolicy interface is required if Hard Quotas and/or File Block policies will be used.
    • FPolicy must be enabled on each filer/vfiler to be managed with Hard Quotas and/or File Block policies.
    • A channel for FPolicy communication must be enabled. The choice is dependant on the presence of virtual filers:
      • SSL should be enabled on each physical filer if only physical filers are to be managed. (SSL is not implemented by NetApp in a vfiler context.)
      • HTTP should be enabled on each filer/vfiler if one or more virtual filers are to be managed.
    • An FPolicy Management Account must be available/created. This account is used to create and manage FPolicy connections. A domain account or local account (at the filer/vfiler level) can be used. For security reasons Northern recommends using local accounts. The requirements for local accounts are as follows:
      • When multiple filers/vfilers will be managed, multiple local accounts must be created. The names and passwords of these accounts must be identical.
      • A Role must be created on each filer/vfiler with ‘login-*’ and ‘api-*’ privileges.
      • A Group must be created on each filer/vfiler and assigned to the previously created role.
      • A User must be created on each filer/vfiler and assigned to the previously created group.
Cloud Volumes ONTAP

  • All NSS capabilities are available.
  • Data ONTAP 9 or later
  • The NetApp FPolicy interface must be enabled if Hard Quotas and/or File Block capabilities will be used. The following is required in order to create and manage FPolicy connections:
    • A Management LIF must be available for each SVM.
    • An FPolicy Management Account must be available:
      • This is an account at the SVM level on the NetApp system, used to create and manage the FPolicy connection for that SVM.
      • The account can be a local account or an Active Directory account.
      • When local accounts will be used, one for each SVM, the accounts must have the same name and password.
      • The account(s) used must have ontapi and ssh applications, both with the vsadmin role.
  • For performance reasons, the Scanning Server(s) and Quota Server(s) which are managing this platform should be located in the same cloud instance.
  • If this is the only platform to be managed, then the Database Server should also be located in the same cloud instance. If multiple platforms will be managed then the Database Server should be located in such a way that it has the best connectivity to the Scanning Servers that are collecting the most data.
Azure NetApp Files (SMB only)

  • File system analysis capabilities are available.
  • File shares to be scanned must be accessible to Scanning Server(s) via UNC paths.
  • For performance reasons, the Scanning Server(s) managing this platform should be located in the same cloud instance.
  • If this is the only platform to be managed, then the Database Server should also be located in the same cloud instance. If multiple platforms will be managed then the Database Server should be located in such a way that it has the best connectivity to the Scanning Servers that are collecting the most data.
Windows Server

  • All NSS capabilities are available.
    • Local installation of NSS is required if Hard Quotas and/or File Block capabilities will be used.
  • Where only file system monitoring  (Soft Quotas) and/or file system analysis (reporting) capabilities will be used:
    • Operating system with full SMB support.
  • When Hard Quotas and/or File Block capabilities will used, a local installation of NSS is required – effectively making this server a ‘Quota Server’ (see above). As such the minimum requirements for a Quota Server apply:
    • Windows Server 2012 or higher.
    • CPU: Minimum of 6 cores.
    • RAM: Minimum of 8 GB.
    • HDD: 20 GB available.
    • Only the NSS package should be installed.
Azure File Storage

  • File system analysis capabilities are available.
  • File system monitoring (soft quotas) are available.
  • File shares to be scanned must be accessible to Scanning Server(s) via UNC paths.
  • A user account must be created in Azure that has read permissions to all file shares that will be managed.
    • The details of this user account must be saved to the ‘credentials file’ on each Scanning Server. This is done through an API.
  • For performance reasons, the Scanning Server(s) and Quota Server(s) which are managing this platform should be located in the same cloud instance.
  • If this is the only platform to be managed, then the Database Server should also be located in the same cloud instance. If multiple platforms will be managed then the Database Server should be located in such a way that it has the best connectivity to the Scanning Servers that are collecting the most data.
Windows desktop, laptop, VDI, etc.

  • File system analysis capabilities are available, i.e. the local content of these endpoints can be included in reports.
  • File shares to be scanned must be accessible to Scanning Server(s) via UNC paths.
  • Connections to the end-points should be sustained during scanning operations. Extended interruptions in connections may lead to some data not being included in scans.
Windows Cluster

  • All NSS capabilities are available.
  • To enable use of Hard Quotas and File Block capabilities:
    • Local installation of the NSS package (only) is required on each node participating in the cluster.
    • The installed NSS services (NSS Core Server and NSS Quota Server) must be configured to run as resources on each clustered file server role.
    • Quota paths must be expressed using UNC format.
  • If only file system analysis capabilities will be used, then paths served from the cluster can be added to scanning configurations on separate Scanning Servers, no local installation or changes are required.
Dell EMC Unity, VNX

  • All NSS capabilities are available.
  • OE for File 8.0 or later.
  • To enable use of Hard Quotas and File Block capabilities:
    • The Common Event Enabler (CEE) framework must be installed and configured on each Quota Server.
      • This configuration is referred to by Dell EMC as a Co-resident Application. More complex architectures are possible and maybe needed depending on the specific situation. Contact your Dell EMC technical representative to determine the most appropriate architecture for your Dell EMC environment.
    • The Common Event Publishing Agent (CEPA) must be enabled on the Unity/VNX device, for all target file systems.
    • On VNX systems a configuration file (“cepp.conf”) must be created in the root file system of each target Data Mover.
    • A registry key must be edited on each Quota Server to define it as an ‘end-point’ for CEPA communications.
Dell EMC Isilon

  • File system analysis capabilities are available.
  • File system monitoring (soft quotas) are available.
  • OneFS 8.0 or later.
  • Recursive change notifications must be enabled in OneFS if NSS’ file system monitoring capabilities will be used. This will increase load on the Isilon system, refer to Dell EMC documentation for further information.
  • If only file system analysis capabilities will be used, then paths served from the Isilon device can be added to scanning configurations on separate Scanning Servers, no local changes are required.
Hitachi Vantara HNAS

  • All NSS capabilities are available.
  • HNAS 12.3 or later.
  • A CIFS server name must be created for each EVS and it must be joined to the same domain as the Scanning and/or Quota Server(s). This is done within the HNAS system.
  • If Hard Quotas and/or File Block capabilities will be used:
    • The File-filtering feature of the HNAS system must be enabled on each EVS file system.
SharePoint On-premise

  • File system analysis capabilities are available.
  • SharePoint 2010 or later.
  • The Service Account must have the following privileges on each site/document library that will be included in analyses:
    • To use the permissions enumeration capabilities offered by NSS, Full Control privileges must be assigned.
    • Read privileges are sufficient if permissions enumeration capabilities will not be used.
SharePoint Online, OneDrive for Business

  • File system analysis capabilities are available.
  • An NSS App must be created and registered on each SharePoint tenant.
  • The following privileges must be assigned to the app when it is registered:
    • To use the permissions enumeration capabilities offered by NSS, Full Control privileges must be assigned.
    • Read privileges are sufficient if permissions enumeration capabilities will not be used.
  • The SharePoint ID and ‘Secret’ assigned to the App must be saved to the ‘credentials file’ on each Scanning Server. This is done through an API.
    • A user account with access to the SharePoint tenant must be used in this process (no access to sites or document libraries is required).
Other data containers with full SMB support

  • File system analysis capabilities are available.
  • File system monitoring (soft quotas) are available.
  • Files must be accessible via the SMB protocol.
  • If Soft Quota capabilities will be used:
    • File shares to be managed must be accessible via UNC paths.
    • Full support for CIFS Change Notifications (as per SMB specification) is required .
Emerging Platforms
Northern adds support for new platforms, as our customers adopt them.
Console Client
  • A web-based (intranet) client with full Role-based .Access capabilities.
  • The client used when viewing:
    • File system analysis results.
    • File management (delete, quarantine, tag, etc.) audit logs.
  • The client used when configuring:
    • File system scanning operations.
    • The users/groups that should have access to analysis results.
    • The dashboards and views that users/groups should view.
  • As a web application, the client is served from a web server; the Console Server (see requirements above).
  • The web interface itself supports all modern versions of the following browsers (desktop and mobile versions):
    • Internet Explorer
    • Microsoft Edge
    • Mozilla Firefox
    • Google Chrome
    • Opera
    • Safari
Quota Server Client
  • A 32-bit application usually installed on operator desktops/VDIs.
  • Data growth and file type filtering policies (Quotas and File Block) are managed via this interface.
  • Windows 8.1 or higher.
  • CPU: Minimum of 2 cores.
  • RAM: Minimum of 4 GB.
  • HDD: 1 GB available.
  • Only the ‘Client’ components of the NSS package should be installed
    • The NSS package installer should be run and all options except ‘Client’ should be deselected during the installation process.
  • Note that a single client can connect to multiple Quota Servers.

 

RELATED ARTICLES

Deployment Topologies

 

×