Organisations implementing Office 365 probably already have some form of IT support. This support may range from single individuals through to complex IT ‘shops’, or it may be outsourced.
This post:
- Describes the change from traditional on-premise IT admin to the new world of Office 365 administration, and the admins that are needed.
- Highlights that Office 365 includes new applications or features that were never part of the on-premise environment and so new skills may be required.
- Describes the various Office 365 admin roles, and why these should having distinct naming conventions and be cloud-only.
- Recommends that admin roles are defined in Office 365 governance documentation.
Transitioning from on-premise IT to Office 365
Traditional on-premise IT tended to be focussed on network infrastructure (servers and networks) and Exchange. Depending on the size of the organisation, it might have a single IT specialist or a more complex IT structure with a range of administrators managing different aspects of the network.
When Office 365 is implemented some on-premise infrastructure will likely remain and need to be supported, while some of the previous on-premise administration skills will ‘move’ to the respective online version, for example Exchange to Exchange Online.
Office 365 includes a range of applications some of which are likely to be new to previous on-premise IT administrators. For example:
- Home or personal drives will be migrated to OneDrive for Business
- All or some parts of the network file shares will be migrated to SharePoint Online
- MS Teams is likely to replace any existing messaging apps such as Skype
- Retention policies can be applied across the core Office 365 workloads
- Security policies can be implemented
- Yammer may be used as the enterprise social networking platform
- Audit logs and eDiscovery are now available
Each of these (and other options) require new skills that may not exist in the existing IT support structures.
Additionally, some traditional IT activities such as backup don’t exist in Office 365. There is likely to be a tendency to try to re-create those on-premise solutions when other options (such as retention management) may be just as effective.
Office 365 Admin roles – Cloud only
Office 365 is entirely based in the Microsoft cloud environment. Office 365 admin roles have no access to any on-premise environment.
Accordingly, key Office 365 admin roles (Exchange, SharePoint/OneDrive, MS Teams, Security and Compliance) should exist only in the cloud and be named accordingly.
Examples of cloud-only admin account names:
- ADM_O365_GA_username@tenantname.onmicrosoft.com (Global Admin)
- ADM_O365_EXO_username@tenantname.onmicrosoft.com (Exchange Admin)
- ADM_O365_SPO_username@tenantname.onmicrosoft.com (SharePoint Admin)
- ADM_O365_SEC_username@tenantname.onmicrosoft.com (Security Admin)
A person with global records management responsibility might also need elevated privileges. The account could be:
- ADM_O365_REC_username@tenantname.onmicrosoft.com (Records Admin)
There are a couple of exceptions to this model:
- Reader admin. Office 365 includes various ‘reader’ admin accounts that give an account read-only access to things like the Office 365 Message Centre only. It may be acceptable to assign reader admin to a standard user account.
- Yammer Admin. Yammer admin has limited funcionality. A Yammer admin sees additional options via the cog/gear icon but otherwise has no elevated privileges. Therefore, a Yammer admin could be assigned to a standard user account.
In every case, every Admin role must have the user name included; there should be no generic admin accounts, ever.
Primary Admin role – Global Administrators
The highest level admin role in Office 365 is the Global Administrator (GA). GAs have access to everything across Office 365 in the same way that an on-premise administrator had access to everything.
A common mistake in organisations that are new to Office 365 is to assign a GA role to a standard user account, often the person or individuals with similar privileges in the on-premise environment.
Microsoft recommend the following:
- There should only be two or three GAs, no more than five (maximum) with very strong passwords. GA admin activity should be minimal.
- Use multi-factor authentication for GA accounts.
- Only sign in with the dedicated global administrator accounts when carrying out tasks that require global administrator privileges.
- Carry out other Office 365 administration (Exchange, SharePoint etc) with other administration roles (see below).
Other Office 365 admin roles
A range of other admin roles can be assigned in Office 365. The primary admin roles are for Exchange, SharePoint and MS Teams. Secondary admin roles (that may be performed by the GA in smaller IT shops) are the global reader, help desk and service support admins, and user admin.
In addition to the primary roles above, there are also a range of other admin roles that can be assigned, including the following (plus at least the same amount again).
- Dynamics 365 admin
- Groups admin
- Kaizala admin
- Office apps admin
- PowerBI admin
- Power Platform admin
- Search admin
- Cloud device admin
- Intune admin
- Licence admin
- Password admin
- Billing admin
- Compliance admin
- Security admin
The need for each of these admins will depend on the size and structure of the organisation.
So, who does what?
Despite the multiplicity of admin roles, the reality is that most organisations will only have the following and create and assign other admin roles (e.g., Licence Admin, Help Desk admin, Billing Admin) or access (e.g., Global Reader), as required.
- Global Admins (2 – 5)
- Exchange Admin
- SharePoint Admin
- MS Teams Admin
- Security/Compliance Admin
There is likely to be some overlap between these roles, especially in relation to the creation and management of Office 365 Groups (if their creation, and therefore also the creation of new Teams in MS Teams, is controlled) and the creation and implementation of retention policies from the Security and Compliance admin centre, as shown in the diagram below.
Governance documentation
However the admin roles are configured, these should be defined in the organisation’s Office 365 governance documentation which should define, for each role:
- Naming convention
- Responsibilities
- Name of actual person with that role