Skip to toolbar
Select Page


Computers perform many roles. Administrative computing, communications, design, drawing programming, data acquisition, analysis, teaching, play, and test beds.

The software (applications) that runs on a computer will affect the choice of hardware and operating system.

The number of specific configurations maintained across the faculty is potentially huge! So it is useful to describe a computer in terms of a set of services, and to think of the processes involved in deploying and maintaining this equipment in a modular way.

This forms the basis of a Standard Operating Environment or SOE.


There are numerous reasons for developing, maintaining and insisting on an SOE:

  • mobile skills
    the same skill sets will work on any system across the organisation!
  • more responsive services
    the same fundamental services are accessed using common approaches.
  • easier training and support
    A common substrate of tools and processes makes it a lot easier to maintain support and training across a large fleet.
  • easier management
    Factory style production lines, policy driven configuration
  • regulatory compliance
    Monitoring, reporting, audit is easier where a common substrate of tools is used across the fleet.


Any deployed instance of a computer:

  • should work
  • should be able to do the work expected within any defined performance metrics
  • should be safe
  • should be legal

Nitty Gritty

Operating system

It is expected that the operating system deployed on a computer will support the requirements of the purpose for which the machine is deployed, but that it will also support the demands placed on the system by the environment into which it is being deployed.

University policy requires some level of authentication and an ability to manage and monitor access on to and out of the hardware.


It is expected that appropriate drivers will be used and properly installed so that the equipment functions correctly and can reliably make use of local services provided by the hardware layer in the system.

Where possible, officially supported drivers provided by the operating system or hardware manufacturer should be deployed. Once working correctly, updates to these drivers need to be managed -a suitable policy for such updates may need to be negotiated with the regular user or beneficiary of the system.

The standard set of services

Whatever hardware and software choices are made, staff computers use a common set of services.


It is standard for staff systems to be connected to the University network in some fashion. The key protocol used is IP (Internet Protocol). IPv4 is standard, but there is a growing use of IPv6. The IPv4 protocol supports the network standards implemented by the University and facilitates access to services anywhere on the internet. IPv4 addresses are specific to networks in distinct (generally) geographic locations across campus. Systems that move around campus may need specific IP configurations for each interface within each network.

The network service includes the ability to use campus based services from off campus.

Staff systems need to be configured for internet use (even if firewall settings will block the system’s access to off campus services), and appropriate internet addresses somehow assigned for the interfaces that may be used. Portable computing equipment will probably need wired and wireless interfaces configured for on and off campus use.


Authentication is the verification of identity. In the context of a staff computer this generally means logging on.

The policy for authentication in the Faculty of Science is that staff and students should be using the University username and password. This set of credentials is known by a number of names including: UPI and password; NetAccount username and password; EC login; UOA login; NetLogin; CECIL login; nDeva Login.

The most straightforward way to deploy this authentication mechanism on a Science system is to connect the computer to the local active directory, SFAC. The trust relationship between SFAC and the University directory means that the University credentials can be used to authenticate and authorize access to Science resources.

As a Windows directory, SFAC provides mechanisms for kerberos and LDAP authentication and authorisation that can be used by the commonly deployed operating systems as well as applications.

Each instance of a system should be unique! Dual boot and virtual systems that are used simultaneously or variously (ie. swapping backwards and forwards between one or other at an interval where reimaging would be undesirable) are unique environments that should be connected to the SFAC domain individually.

In the future we will move away from SFAC to the UOA directory.  UOA should provide the same services as SFAC.

File services (network storage)

Science staff, graduate students and some guest and visitors are provided with space on the Science file server, files.fos (more properly This personal folder may be accessed through a share named with the UPI of the owner.

In addition to personal space, files.fos provides access to shared areas for general file exchange within departments, research groups and across the faculty and wider University. This space is accessed through the science-faculty share.

Web sites managed within the Science IT infrastructure can be accessed via the web share on files.fos.

See Drive mappings for Science staff for more information on the standard shares accessed through files.fos.

Files.fos delivers access through a number of file sharing protocols. These are suited to various styles of access.

The standard protocol for attaching to files.fos is SMB (also referred to as CIFS). This is the standard protocol used by Windows for file sharing, and is available in default installations of Ubuntu (9) and OS X (10.3+).

Off campus access to parts of files.fos is possible using DAV (distributed authoring and versioning). This mechanism uses web protocols that can be passed through firewalls. SSH can be used for off campus access as well, see Connecting using sshfs.

Files.fos can be attached to using NFS. This is more useful for server-server linkages.

See Files.fos for more information on connecting to files.fos.

As we move into the post-migration phase of the Roles and Responsibilities programme, files.fos will be deprecated in favour of the ITS managed SONAS platform. Staff and students will use University authentication to connect to a common file service using SMB/CIFS.

Additional file services can be found on and, the appropriate information for those services is provided in the links.


The University’s enterprise Copy and Print Service CAPS provides a centrally managed and consistent framework for end user access to non-specialised printing capability.

Internet and Communications

Staff should have unrestricted access to the internet through the appropriate firewall changes in Rincewind.  Students should have access to the internet via the NetAccount Client (relevant information for students here).


The application set and services an environment provides will be different depending on its use.  However there are a set of policies (fundamentals provided above) that must be adhered to, and perhaps a set of niceties for a standard environment.

There will be a core set which will be common to all environments, this is being developed as part of the “One Windows” project.  It is expected that the specific requirements for the machine will determine a range of discretionary applications and tools, that will be added.  It is envisioned that these will also be drawn from a common pool.

This is similar to our current SCCM implementation.  There is a base image of applications and configurations that is added to at build time, by a standard set of applications for each environment.

Examples of core applications are given below, and how they enable the environment to conform to the policies given above.


Currently the centralised antivirus is ESET NOD32 for Windows machines and Sophos for OSX  machines, although OSX machines may shortly be moving to NOD32 also.  There is currently no defined antivirus for Unix based machines.  This is to comply with the safe findamental.

Asset Management

The University uses the Sassafras K2 Software Asset management software, whose client must be installed on all machines which support it (read: Windows, OSX).  This is to comply with the legal fundamental.