Creating and Administering a Microsoft Entra Tenant
Third in this series on Microsoft Entra ID, moving from concepts into the hands-on side: creating and customising a tenant, then delegating administration within it through administrative units.
Setting up and customising a tenant
Creating a new tenant
Tenant creation is a short wizard: navigate to the gear icon and select Manage tenants, select Create, and choose Azure Active Directory as the default option. You then configure the tenant with an organisation name and a domain name — the domain name has to be unique and available — and choose a region for it. The region choice isn't just about latency: consider the data protection laws that apply where the tenant's data will live, and pick a region appropriate for the organisation. The whole process takes a few minutes to complete.
Adding a custom domain
A custom domain lets you associate your organisation's own domain name with the tenant, so you can create user accounts like user@yourdomain.com instead of the default onmicrosoft.com address. To add one, navigate to Manage tenants → Custom domain names and add your organisation's domain. To prove ownership, you add either a TXT or MX record to the domain's DNS settings at your registrar (Namecheap, in the lab's case), then wait for DNS propagation — typically 12–24 hours — before the domain verifies. Once verified, you can promote the custom domain to primary, which changes the default domain used for user creation and other operations going forward. After that, new user accounts can use the organisation's domain name directly.
Switching between tenants
You can switch tenants either through the gear icon (Manage tenants) or through your profile picture in the top right of the Azure portal, which also lets you jump to favourite tenants or browse all directories you have access to. It's worth being deliberate about this — make sure you're working in the correct tenant, especially the one you're actually the administrator of, before performing any action. Tenant-switching mistakes are an easy way to make a change in the wrong environment.
Tenant ID and licensing
The Tenant ID is a unique identifier for the tenant, and you'll need it for scripts and commands run against PowerShell or the Azure CLI — it's on the tenant's overview screen. On licensing: the Free edition of Microsoft Entra ID has real limitations, and a premium licence (P1 or P2) unlocks additional features — see the licensing tiers post earlier in this series for the full breakdown of what each tier adds.
Administrative units
Administrative units let administrators logically group Microsoft Entra resources — users, groups, devices — and delegate administrative permissions to a specific scope within the organisation. This is particularly useful for organisations with independent divisions or geographically dispersed teams, since it enhances security and simplifies administration by narrowing what a given admin role can actually touch. A user can belong to multiple administrative units at once.
A few constraints worth knowing: administrative units cannot be nested, and the feature currently isn't available in Microsoft Entra ID Governance. Adding a group to an administrative unit manages the group itself — its name and its membership — but not the individual members of that group; to manage members directly (their properties, authentication methods, or passwords), an admin needs direct access to those users or devices, not just to the group.
That distinction plays out concretely for a User Administrator scoped to an administrative unit: they can manage the group's name and its membership, but they cannot manage individual members' user properties, authentication methods, or reset their passwords — unless those users are also added directly as members of the administrative unit, on top of being members of the group.
Licensing follows the same pattern as elsewhere: an administrative unit administrator needs a Microsoft Entra ID P1 licence, an administrative unit member only needs Free, and if you're using dynamic membership rules for the administrative unit, each member needs P1. These specifics match current Microsoft Entra licensing guidance. Administrative units can be managed through the Microsoft Entra admin centre, PowerShell cmdlets and scripts, or the Microsoft Graph API.
Planning administrative units tends to move through recognisable stages: initial adoption (creating units against early criteria, with the count growing as criteria get refined), pruning (deleting units no longer needed once criteria settle), and stabilisation (the structure is defined and the unit count holds steady). The best practice is to plan units with cross-Microsoft 365 service usage in mind from the start, to get the most value out of them.
On current capabilities: a Privileged Role Administrator can create units, add members, manage users and devices via dynamic rules, and assign scoped administrators. Administrative unit-scoped admins can use the Microsoft 365 admin centre for basic user management, while group administrators can manage groups via PowerShell, Microsoft Graph, and the Microsoft 365 admin centre. The Guest Inviter role grants only the specific ability to invite external users — a clean example of least privilege in practice (guest invitations themselves are covered in more detail in the devices and guest users post later in this series). One scope limitation to keep in mind: administrative units only constrain management permissions — users can still browse resources outside their assigned units under default permissions, and this filtering applies in the Microsoft 365 admin centre but not in the Microsoft Entra admin centre, PowerShell, or other services.