Connecting a tenant

Connecting a tenant takes two things: an app registration in your own Entra tenant (set up once), and the customer's consent to that app (once per tenant). You choose which features Tenvara uses in the tenant as you connect it, and the consent covers only what those features need. Tenvara then gives itself the directory roles those features need and starts the first sync.

Before you start: the app registration#

Tenvara uses one multi-tenant Entra app for every customer, for management and for Microsoft 365 backup. You create it in your own Entra tenant and enter it once.

1. Go to Settings > Microsoft 365. It opens on the Connection tab.
2. In the Entra admin centre of your own tenant, register a new app that supports accounts in any organisational directory (multi-tenant).
3. Add each address under Redirect URIs to register as a web redirect URI. Use the copy buttons beside them. They cover admin consent when connecting a tenant, partner sign-in for GDAP, and backup's own consent.
4. Add every permission listed under Every permission Tenvara needs to the app, and grant admin consent for them in your own tenant. The list is grouped (directory and users, security and sign-ins, mail, backup, Exchange, security monitoring, partner access) and each permission says what Tenvara uses it for. Partner access permissions are delegated; the rest are application permissions. The Defender for Endpoint permissions sit on Microsoft's own WindowsDefenderATP API rather than Microsoft Graph.
5. Create a client secret.
6. Back in Tenvara, enter the Application (client) id, Client secret and the Directory (tenant) id where the registration lives, press Test, then Save.

Once a secret is saved, the field says "A secret is saved. Leave blank to keep it." When backup is switched on, saving here also updates backup, so there is only one registration to maintain.

The Certificate card on the same tab is needed for what SharePoint's own admin service holds, which only accepts a certificate: the sharing checks that read the default sharing link and how long links and guest access last, and, with AI readiness, who can open each site, restricted sites and whether labels are switched on for SharePoint and OneDrive. Press Make the certificate, then add it to the app registration. Tenvara keeps its private key and renews it before it ends.

Keeping the registration up to date#

The Permissions card reads your registration and compares it with what Tenvara needs. When it lists missing permissions or redirect URIs, either:

• press Update the app registration and sign in once as an administrator of your own tenant, so Tenvara adds them for you, or
• add them in Entra yourself: Copy the list gives you each one, and Open it in Entra opens the registration's API permissions.

Then the customer tenants that need them consent again (see Choosing features and consent).

The App registration tab goes further. It checks every redirect URI, permission and consent the registration needs, whether it is multi-tenant and when its secret and certificate end, says why each problem matters, and has a Fix it for me button. Tenvara runs the check every day and raises an alert when the registration drifts. See App registration health and Fix it for me.

The Connection tab also shows when your client secret runs out once Tenvara has read the registration, and Tenvara raises an alert 30 days before (critical within 7), because every tenant stops syncing when it lapses.

Note: After consent, Tenvara gives its own app the directory roles the chosen features need in the customer tenant: Global Reader to read everything (for Audit and config drift and Control), Exchange Administrator for mailbox changes (Control and Email security) and Compliance Administrator when AI readiness is on.

Connect with an admin consent link#

This works for every customer, partner or not.

1. Go to Cloud > Tenants (or Cloud > Overview) and press Connect a tenant.
2. Leave Admin consent link selected.
3. Choose the Customer. A customer can have more than one tenant.
4. Under Features, tick what Tenvara should do in this tenant. Your defaults are ticked already; Details shows what each one needs. See Choosing features and consent.
5. Press Make the consent link.
6. Open the link yourself signed in as the customer's Global Administrator (or Privileged Role Administrator), or send it to the customer.
7. Microsoft asks the administrator to sign in and approve, then sends them back to the tenant's page, which says "Checking the consent..." with who approved it. Tenvara checks the consent in the background: it grants exactly the permissions the chosen features need, reads the tenant's name, domain and id from Microsoft's own answer, gives the app its directory roles, reads the permissions back and queues the first full sync. The page follows each step (Consent checked, Permissions given, Access proved, Permissions read back) and shows the result.

The tenant sits as Waiting for consent until then. A consent link is valid for seven days and can only be used once; if it expires, open the tenant and choose More actions > Copy a new consent link. Tenvara refuses a Microsoft tenant that is already connected to another customer.

When Microsoft is slow to catch up#

Straight after consent, Microsoft has not always told every part of its directory yet: the app it just made can be "not found" for a minute or two, or only some of the permissions show. Tenvara treats that as Microsoft catching up, not as a failure. The tenant's status says Finishing the connection, and the page says "Microsoft is still setting up access (usually a few minutes)" with the step it waits on, how many permissions it can see so far, when it tries next, and Try again now. It keeps trying in the background for up to 15 minutes, and nothing is called missing (no Consent again) until two readings of the permissions agree. Only after that window is a refusal a real failure, shown with Microsoft's own words and Retry, which re-runs every unfinished step without a new consent.

A tenant that stops part-way is still shown by its name and domain, so you can tell which one it is.

Check consent#

If the administrator consented but the tenant still says it is waiting (the browser was closed before Microsoft sent them back, for example), open the tenant and press Check consent. Tenvara asks Microsoft, in the background, whether the app was granted permissions in that tenant. If it was, the tenant connects. If not, the page says why ("Microsoft has no consent for ... in this tenant yet") and offers Copy a new consent link.

Connected by#

The tenant's header says how it was really connected: Admin consent, through partner access (GDAP) or Partner Center, or Not connected yet before it has ever connected. A failed attempt one way never labels a tenant connected the other way.

Connect through partner access (GDAP)#

If you are a Microsoft partner, sign in once with your own partner account and customers you reach through GDAP can be connected without a consent link.

Sign in as a partner (once)#

1. Go to Settings > Microsoft 365, the Connection tab, and scroll to Partner access (GDAP).
2. Sign in as a partner administrator. The card then shows Connected, who signed in and when.
3. Use Sign in again if the sign-in stops working, or Disconnect to remove it.

Partner access needs its own delegated permissions on your app registration. The App registration tab lists them once partner access is in use, and Fix it for me adds them.

Connect a customer#

1. Press Connect a tenant and choose From GDAP.
2. Choose the Features for the tenant.
3. Check or change the Tenvara customer beside the one you want and press Connect.

Tenvara consents its app in the customer tenant for the chosen features through your partner access, grants its directory roles and starts the first sync.

When a connect through partner access fails, the dialog says exactly why rather than asking you to sign in again: your registration lacks the Partner Center permission, the permission is listed but your own tenant has not granted it, there is no partner relationship with that customer, or the relationship does not hold the roles the connection needs. Where your registration is the cause it offers Fix it for me straight away, started for that customer, which adds the permission, grants it in your own tenant and then tries that customer's connection again. It also offers the admin consent link at once, with Copy the consent link and Open it now, so you can finish the connection the other way.

Listing and connecting customers through partner access reaches every customer, so it needs someone who works with every customer.

Ignoring a partner tenant#

Every customer tenant you reach through partner access shows in the From GDAP list until it is connected. For one you never want to connect (a former client, or a relationship kept for another reason), press Ignore on its row and give a reason. It leaves the list; Show N ignored brings the ignored ones back, and Settings > Microsoft 365, the Connection tab, lists them under Partner access (GDAP) with who ignored each, when and why, and Un-ignore. Connecting an ignored tenant takes the ignore off first. See Found, adopted and ignored.

List only#

The List only switch on the Partner access (GDAP) card keeps partner access for looking, not acting. While it is on, Tenvara still reads your relationships and alerts before they end, but connecting customers, turning on features through GDAP, publishing the Teams app and ending relationships are refused, each with the reason, until you switch it off. Connect in the From GDAP list is disabled and says why. Only an administrator can change the switch, and the change is in the audit log. Signing in again keeps it as it was.

Use it when your partner relationships hold more roles than you want a tool to use, and connect customers with consent links instead.

Tenant statuses#

When Microsoft refuses a sign-in or consent, Tenvara shows its reason in plain words (for example that the person is not an administrator, or that Microsoft is still updating the app) and offers Try again when another attempt can work.

When Microsoft refuses just one area of a tenant (service health, for example) while the rest reads, the tenant stays Connected. That area gets its own warning, its tab says what has not been read and since when, and the warning clears by itself once the area reads again.

Tip: Straight after consent, Microsoft can take a few minutes to apply the permissions. The sync history then says "Microsoft is still applying the permissions from the consent. Retrying shortly." and tries again every two minutes. No alert is raised for this.

Microsoft Defender and the first backup#

The first full backup of a tenant reads a lot of mail and files through your app, often soon after a new secret was added, and Microsoft Defender may report it as unusual activity. Tenvara recognises its own app in each tenant and labels such alerts as expected when they line up with its own jobs. Anything it cannot explain stays an alert. The connect dialog reminds you of this.

Consenting again#

When Tenvara needs a permission the tenant has not granted, or you turn on a feature that needs more, the tenant shows Consent again or Consent for it. The link asks only for what is missing. See Choosing features and consent.

Set up in Microsoft 365 first#

Admin consent cannot grant permissions on a Microsoft service that has never been set up in the tenant. The usual case is Microsoft Defender for Endpoint: its permissions only exist once a global admin has opened security.microsoft.com once (Business Premium includes Defender for Business). Rather than sending you round the consent loop, the tenant page shows such a service under Set up in Microsoft 365 first, with the step to take in that tenant and Check again, and no Consent again. Exchange Online, SharePoint Online and the audit log's management service work the same way. Once the service is set up, Check again reads the consent again and the step goes.

A feature that depends on a licence the tenant does not have, such as Defender for Endpoint, says Not in this tenant's licences and asks for nothing.

After connecting#

The first sync reads the directory, licences, security settings, mailboxes and the tenant's whole last week of sign-ins. Open the tenant from Cloud > Tenants to see the result: see Tenants and the tenant page. The tenant's Settings tab shows the Microsoft tenant id, initial domain, how it was connected, when consent was given and whether each directory role was granted.

To leave a tenant out of every sync, check, bulk action and schedule without removing it (for example while a customer is leaving), open it and choose More actions > Exclude from automation. More actions > Remove tenant removes it altogether and needs an administrator.