DEV Community: Senator Networks

A Microsoft 365 Onboarding and Offboarding Runbook for Small-Office Help Desks

Senator Networks — Wed, 21 Oct 2026 13:49:53 +0000

Most small-office help desks don't fail on hard problems. They fail on the boring, repeatable ones: a new hire who can't sign in on day one, a leaver whose mailbox is still forwarding to a personal Gmail three months later, a shared laptop nobody can unlock. Every one of those tickets is cheap to prevent and expensive to clean up.

This post is the onboarding and offboarding runbook we keep for Microsoft 365 tenants with 10 to 150 people, written as scripts instead of a checklist so the steps actually happen in the same order every time. Everything below uses the Microsoft Graph PowerShell SDK.

1. Connect with the smallest scopes you need

Don't run day-to-day help desk scripts as a Global Administrator. Connect with delegated scopes that match the job, and use a dedicated admin account protected by phishing-resistant MFA.

Install-Module Microsoft.Graph -Scope CurrentUser
Connect-MgGraph -Scopes "User.ReadWrite.All","Group.ReadWrite.All","Directory.Read.All"
Get-MgContext | Select-Object Account, Scopes

If a script only reads data (reports, audits), connect with User.Read.All and nothing else. It's one line of discipline that keeps a typo from becoming an incident.

2. Onboarding: groups do the work, not people

The single biggest improvement for a small help desk is to stop assigning licences, Teams, SharePoint sites and shared mailboxes one by one. Assign them to a handful of role groups once, then onboarding becomes "create user, add to role group".

$params = @{
  AccountEnabled    = $true
  DisplayName       = "Priya Shah"
  MailNickname      = "pshah"
  UserPrincipalName = "pshah@contoso.ca"
  UsageLocation     = "CA"
  PasswordProfile   = @{ ForceChangePasswordNextSignIn = $true; Password = (New-Guid).Guid }
}
$user = New-MgUser @params

# Role group carries the licence (group-based licensing) and app access
$group = Get-MgGroup -Filter "displayName eq 'Role - Accounting'"
New-MgGroupMember -GroupId $group.Id -DirectoryObjectId $user.Id

Two details that save tickets later:

Set UsageLocation before licensing. Licence assignment fails silently in group-based licensing if it's missing, and the new hire shows up on Monday with no mailbox.
Send the temporary password out of band (a phone call or the manager's hands), never to the personal email the person used to apply.

3. Pre-stage the device, not just the account

An account without a ready laptop is still a day-one ticket. If the devices are enrolled in Intune with Windows Autopilot, assign the device to the user before it ships so the first sign-in pulls policy, apps and OneDrive Known Folder Move on its own. If you're not on Autopilot yet, at least keep a written image checklist: BitLocker on, local admin removed, updates current, the line-of-business apps installed and tested.

4. Offboarding: order matters

Offboarding is where small businesses leak data. The order below closes access first, preserves data second, and cleans up last.

$upn  = "former.employee@contoso.ca"
$user = Get-MgUser -UserId $upn

# 1. Block sign-in and kill existing sessions
Update-MgUser -UserId $user.Id -AccountEnabled:$false
Revoke-MgUserSignInSession -UserId $user.Id

# 2. Record group memberships before removing them (you will be asked later)
Get-MgUserMemberOf -UserId $user.Id -All |
  Select-Object Id, @{n='Name';e={$_.AdditionalProperties.displayName}} |
  Export-Csv ".\$($user.MailNickname)-groups.csv" -NoTypeInformation

# 3. Remove from groups (licences drop with the role group)
Get-MgUserMemberOf -UserId $user.Id -All | ForEach-Object {
  Remove-MgGroupMemberByRef -GroupId $_.Id -DirectoryObjectId $user.Id -ErrorAction SilentlyContinue
}

Then, in Exchange Online PowerShell, convert the mailbox to shared (so it stays searchable without a licence, within the size limit) and check for forwarding rules the person set themselves:

Connect-ExchangeOnline
Set-Mailbox -Identity $upn -Type Shared
Get-InboxRule -Mailbox $upn | Where-Object { $_.ForwardTo -or $_.RedirectTo -or $_.ForwardAsAttachmentTo }
Set-Mailbox -Identity $upn -ForwardingSmtpAddress $null -DeliverToMailboxAndForward $false

That forwarding check is the step people skip, and it's the one that matters most when someone leaves on bad terms.

5. Make the help desk the system of record

Scripts only help if someone can see what happened. Log every run, who ran it and for which user, to a place the whole team can read:

Start-Transcript -Path "\\fileserver\it-logs\offboard-$($user.MailNickname)-$(Get-Date -Format yyyyMMdd-HHmm).txt"
# ... runbook steps ...
Stop-Transcript

Attach the transcript to the ticket. Six months later, when an auditor or a lawyer asks "when exactly did this person lose access?", the answer is one search away instead of a guess.

6. What to measure

For a small help desk, three numbers tell you most of what you need:

Day-one success rate: new hires who could sign in, open email and reach their files on their first morning.
Time to revoke: minutes from "HR says they're gone" to sign-in blocked and sessions revoked. Aim for under 15.
Repeat tickets: the same issue from the same person within 30 days. A high number means you're closing tickets, not fixing problems.

Wrapping up

None of this needs expensive tooling. It needs the steps written down once, run the same way every time, and logged. That's the approach our IT help desk Toronto engineers use for small and mid-sized offices, and the scripts above are a good starting point for any team running Microsoft 365, wherever you are.

Disclosure: I work at Senator Networks, a managed IT provider. The scripts are generic Microsoft Graph and Exchange Online PowerShell and work in any tenant; test them against a non-production user first.

Keeping Canadian Data in Canada: A Practical Setup for Small-Business Web Apps

Senator Networks — Tue, 20 Oct 2026 13:32:14 +0000

Most of the custom apps we scope for Canadian small and mid-sized businesses start the same way: someone asks for a client portal, an intake form or an internal dashboard, and halfway through the first meeting the question comes up: "Does our data have to stay in Canada?"

The honest answer is "it depends", but the engineering answer is that keeping it in Canada is cheap to do on day one and painful to do later. This post is the checklist we use to pin a small web app to Canadian infrastructure from the start, with the config snippets that make it stick.

1. Know what the rules actually say

Before touching Terraform, get the requirement straight, because "data residency" gets used loosely.

PIPEDA (federal private-sector privacy law) does not ban storing personal data outside Canada. It makes you accountable for it, and expects you to tell people when their data may be processed in another country.
Ontario's PHIPA applies to personal health information. Health custodians and their agents usually end up requiring Canadian storage in their contracts, even where the statute doesn't strictly demand it.
Federally regulated financial institutions follow OSFI guidelines on outsourcing and technology risk, and their vendor questionnaires will ask exactly where data and backups live.
Public-sector clients (municipalities, school boards, some provincial agencies) frequently write Canadian residency into the RFP itself.

So the real driver is usually a contract or a customer's procurement team, not the law alone. Ask for the clause in writing, because it tells you whether backups, logs and support access are covered too.

2. Pick regions that are actually in Canada

All three big clouds have Canadian regions, and two of them have a region in or near Toronto:

Provider	Region	Location
Azure	Canada Central	Toronto
Azure	Canada East	Quebec City
AWS	ca-central-1	Montreal area
AWS	ca-west-1	Calgary
Google Cloud	northamerica-northeast2	Toronto
Google Cloud	northamerica-northeast1	Montreal

For a Toronto business, Azure Canada Central or GCP northamerica-northeast2 keeps latency low for staff and customers, and a second Canadian region gives you somewhere to put backups without leaving the country.

3. Pin the region in code, not in a wiki

The most common way data leaks out of Canada is not a breach. It's a developer creating one "temporary" resource in the default region. Make the allowed regions a hard rule.

On Azure, an allowedLocations policy assignment at the subscription level does this:

{
  "if": {
    "not": {
      "field": "location",
      "in": ["canadacentral", "canadaeast", "global"]
    }
  },
  "then": { "effect": "deny" }
}

On AWS, a Service Control Policy with an aws:RequestedRegion condition does the same job. In Terraform, fail fast in the module itself:

variable "location" {
  type    = string
  default = "canadacentral"

  validation {
    condition     = contains(["canadacentral", "canadaeast"], var.location)
    error_message = "This app must be deployed to a Canadian region."
  }
}

The validation catches mistakes in review. The cloud policy catches anything created by hand in the portal.

4. Check the services that quietly go global

Pinning your compute and database is the easy part. These are the pieces that tend to slip:

Backups and geo-replication. Azure's paired region for Canada Central is Canada East, so geo-redundant storage stays in Canada. Double-check the pairing for any other provider or region you use.
Email and SMS providers. Transactional email services often process and store message bodies in the US. If your portal emails documents, link to them instead of attaching them.
Error tracking and logging SaaS. A stack trace can contain a name, an email or a health card number. Scrub request bodies before they leave, or pick a vendor with a Canadian or self-hosted option.
CDNs. Static assets cached worldwide are fine. Authenticated API responses should be marked Cache-Control: private, no-store so the edge never stores them.
AI features. If you add summarisation or a chatbot, check which region the model endpoint runs in. Several managed AI services are available in Canadian regions now, but the default is often a US one.

A small Express middleware is enough to stop personal data ending up in a CDN cache:

app.use('/api', (req, res, next) => {
  res.set('Cache-Control', 'private, no-store');
  next();
});

5. Encrypt, and decide who holds the keys

Encryption at rest is on by default for the managed databases on all three clouds. The stronger answer for a regulated client is a customer-managed key in a Canadian Key Vault or KMS instance, so the key itself never leaves the region either. It adds a little operational work (key rotation, access policies) but it's the line in the security questionnaire that ends the conversation fastest.

6. Write it down for the customer

Last step, and the one teams skip: a one-page data map. List each component, the region it runs in, where its backups go, and which third parties can see the data. When the next procurement questionnaire arrives, you answer it in ten minutes instead of a week.

Wrapping up

None of this is exotic. Region validation, a deny policy, a review of the "quietly global" services and a data map cover what most Canadian SMB apps need. Doing it before the first deploy costs an afternoon. Doing it after launch means migrating databases.

We build and support apps like these for businesses across the GTA; if that's useful context, here's our page on app development Toronto projects. Questions or corrections on any of the above are welcome in the comments.

Disclosure: this post is published by Senator Networks, a Toronto IT services and app development company.