Frequently asked questions

SEADpods are exclusively available to government entities, encompassing federal, state, and local organisations.

SEADpods are designed to be versatile, allowing interactions with various organisations as intended by the SEAD partner. However, certain restrictions may apply based on project specifications and security considerations as specified by the adopting agency.

Yes, projects can be linked to only the products defined by the administrator, subsequently enabling access to data by a select group of users. Much like the model seen in the shared infrastructure of the DataLab. Noting, administrators however do have access to all data loaded to the environment.

No, there is no limit to how long a SEADpod can exist. The SEADpod will remain in use by the SEAD partner until an explicit termination date is provided.  

• The SEAD environment resides on a private virtual network fronted by an Azure firewall.
• Virtual Machines (VMs) are blocked from accessing public internet and are segmented by individual workgroup levels.
• All data is encrypted in transit and at rest as we are using Azure hosted storage.
• Role Based Access Control (RBAC) is enforced.
• The SEAD environment is accessed remotely for secure desktop delivery.
• Group policy disables clipboard / device redirection for preventing data theft via Remote Desktop Protocol.
• VMs are automatically patched and we destroy and rebuild all VMs every 30 days on a rolling window.
• Basic user behaviour monitoring is enabled for auditing and reporting purposes. Session recording is not enabled by default.
• We use the Cloud Security Posture Management (CSPM) tool – InsightCloudSec, which provides information about potential misconfigurations, configuration drift and any security issues following deployment of resources.
• VMs are protected with Microsoft Defender for Endpoint Plan 2 (previously Microsoft Defender Advanced Threat Protection) which provides:
  • Threat detection.
  • Antivirus / malware scanning.
  • Preventative protection / post breach detection.
  • Automated remediation and response.
  • Vulnerability management.
  • Other next-gen protections.

Users are not able to load code or packages themselves, this responsibility sits with partner data administrators and the ABS. To ensure system security and integrity, SEAD partner administrators should refer to their SEAD Administrators Instruction Guide provided by the ABS for information on trusted sources. In addition, software is not to be provided, or attempted to be loaded to a SEADpod by partner administrators. Any request for new software must be submitted to the ABS, accompanied by a business justification.

Project and Output folders within each workspace are backed up every night and retained for 14 days. These backup snapshots are accessible to SEAD administrators.

Closed projects will also be archived after 180 days since their closed date. Data from P: (Project) and O: (Output) file shares will be moved from the Project storage account to a dedicated archive storage account. The ability to restore a project will no longer be available after the 180 days grace period and requests to restore an archived project will incur a cost.

Data input and output is managed through Azure Storage Explorer by uploading and downloading files from Azure Files Storage Accounts. Azure Storage Accounts are configured with a firewall to restrict access to an administrator's nominated network.

SEAD facilitates collaborative engagement on shared projects. SEAD partner administrators have the capability to create user accounts and strategically assign them to specific projects. It is up to the SEAD partner to determine and manage data access policies.

There are alternative options available, but this is up to the SEAD partner to manage. The choice depends on specific project requirements. 

VMs are the virtual workspaces analysts use to undertake their work in SEAD. An analyst will have one VM for each project they are a member of and can only work in one of these (the ‘Active’ VM) at any given time. This is a security measure to prevent analysts from accessing data for multiple projects simultaneously. The VMs are also called ‘Desktops’ if you are using Citrix Workspace or Azure Virtual Desktop. Only SEAD administrators can increase/decrease or assign VMs to users.

The appropriate VM size will depend on the size, complexity, and needs of the analysts working on a given project. Larger and more complex files and analytical tasks may require larger machines. We advise users to use small, medium or large machines in the first instances. There are cost implications on VM use. See Available features for more information about VM sizes and performance. Users have the ability to manage their VMs power state in SEAD.

Yes, VM GPU units are available at an additional cost.

VM Project and Output drives are backed up every night and kept for 14 days. Files outside of these drives are not recoverable.

Yes, it takes about 5 minutes to process the connection. You also need to log out of your VM to allow the system to refresh your session with the new data.

VMs are destroyed approximately every 30 days for security purposes. If the 30 day timing will interfere with the timing of your project, you can choose to destroy and rebuild earlier than 30 days at a time that suits you.

Yes, users are reminded about a rebuild three days ahead of their rebuild and again 24 hours prior.

No, there is no predetermined limit to the amount of data that can be stored in a SEADpod. By design, SEAD is a scalable environment. However, by default each project workspace is provisioned 1TB, which can be increased by administrators to 10TB of storage. Additional storage can be provided upon request to the ABS, to a maximum of 100TB per project imposed by the Azure platform. Cost management should be considered when thinking about storage applications.

Yes, system usage charges will vary depending on the forecasted usage profile, including, but not limited to, storage, number of accounts, license use and VM use.

Like DataLab, SEAD is already equipped with various software for SEAD partners to utilise at no additional cost, including R, Python, STATA, Winmerge, QGIS, and 7ZIP (for the full list of software, see Available features). However, new software or software that requires paid licensing will incur additional charges. For example, Databricks is available but will incur a cost. Other non-standard software tooling can be requested by SEAD partners for implementation in the system, and will be considered on a case by case basis. 

Yes, SEAD administrators have the ability to assign/move SAS licenses as required due to our concurrent SAS license pool arrangement. This means that if you pay for 20 concurrent licenses, the system will limit your users if over 20 try to use a SAS enabled machine at the same time. Since the licenses are pooled, up to 30, 40 or 50 users in your SEADpod can be assigned a SAS enabled machine at any given time, they just cannot be accessed concurrently. SEAD administrators can monitor this by exporting reports from the Virtual Machines page on the SEAD portal.

Yes, once confirmation to proceed with the SEAD service is provided, we can facilitate a free 30-day trial period. See Applying for the SEAD service for further information about the application process.