CIAOPS Need to Know Microsoft 365 Webinar – June

laptop-eyes-technology-computer_thumb

Now in our tenth year!

Join me for the free monthly CIAOPS Need to Know webinar. Along with all the Microsoft Cloud news we’ll be taking a look at SharePoint Skills.

Shortly after registering you should receive an automated email from Microsoft Teams confirming your registration, including all the event details as well as a calendar invite.

You can register for the regular monthly webinar here:

June Registrations

(If you are having issues with the above link copy and paste – https://bit.ly/n2k2606 )

The details are:

CIAOPS Need to Know Webinar – June 2026
Friday 26th of June 2026
11.00am – 12.00am Sydney Time

All sessions are recorded and posted to the CIAOPS Youtube channel.

Also feel free at any stage to email me directly via director@ciaops.com with your webinar topic suggestions.

I’d also appreciate you sharing information about this webinar with anyone you feel may benefit from the session and I look forward to seeing you there.

Restricted SharePoint Search Is Not the Fix You Think It Is

image

Most people’s first reaction to Copilot and SharePoint goes something like this: “Wait — Copilot can see all of that?”

Then they panic. Then they Google. Then they find Restricted SharePoint Search and flip it on like it’s a fire extinguisher.

I get it. The instinct is right — you should care about what Copilot can reach. But RSS isn’t a security control. It’s a stalling tactic. And if you leave it on too long, it’ll cause more problems than the one you were trying to solve.

What is Restricted SharePoint Search, really?

RSS lets a SharePoint admin maintain an allowed list of up to 100 SharePoint sites. Only those sites show up in organisation-wide search results and Copilot chat responses.

That’s it. It doesn’t change a single permission on a single site. It doesn’t block anyone from accessing anything. It just hides sites from search and Copilot — unless the user has recently visited the site, or it was shared with them in Teams or Outlook. In which case, it shows up anyway.

That’s not a security boundary. That’s a curtain.

Microsoft’s own documentation on RSS says it plainly: this is designed as a short-term solution while you audit permissions and apply proper governance. It’s not meant to stay on.

Step-by-step: Setting up RSS the right way

If you’re going to use RSS — and there are situations where it makes sense — do it in this order.

Audit your active sites first

Open the SharePoint admin centre > Active sites. Filter by activity in the last 30 days. Customise columns to show page views, file counts, and last activity. Export the list to CSV. This is your starting inventory — the sites people actually use.

Review permissions on each candidate site

For every site you’re considering for the allowed list, open its details and check the Permissions tab. Look for “Everyone except external users” or company-wide groups. Those are the oversharing patterns you’re really worried about.

Enable RSS and build the allowed list

RSS is managed through PowerShell — there’s no toggle in the admin centre GUI for this one.

Set-SPOTenantRestrictedSearchMode -Mode Enabled
Add-SPOTenantRestrictedSearchAllowedList -SitesList @("https://contoso.sharepoint.com/sites/intranet","https://contoso.sharepoint.com/sites/hr")

Notice what’s missing? A portal button. That’s deliberate. Microsoft wants friction here because they don’t want you to leave this on.

Plan your exit from day one

Before you enable RSS, set a calendar reminder for 30 days out. That’s your deadline to fix the permissions that made you turn it on in the first place — and then turn it off.

When RSS backfires

Here’s where most people get into trouble. They enable RSS, breathe a sigh of relief, and forget about it. Months later, three things have gone wrong:

Search breaks for everyone. RSS doesn’t just limit Copilot — it limits all organisation-wide search. Your finance team can’t find the policy site. Your HR team can’t find the onboarding hub. Nobody told them you turned this on, so they log a ticket blaming SharePoint.

Copilot gets dumber. With only 100 sites to draw from, Copilot has less information to reference. Answers get vague. Users lose trust. You’ve just paid for Copilot licences and then blindfolded the thing.

False confidence sets in. The admin thinks the problem is solved. It isn’t. RSS doesn’t stop Copilot from surfacing content a user has already accessed. If someone opened that sensitive spreadsheet last week, Copilot can still reference it — allowed list or not.

The actual fix: permissions, not curtains

RSS buys you time. Use it. But spend that time on the thing that actually matters: fixing your SharePoint permissions.

Start with Data Access Governance reports in SharePoint Advanced Management. These reports show you exactly which sites have broad sharing, “Everyone” links, or sensitivity labels missing. That’s your real oversharing map.

Then work through it site by site. Remove company-wide sharing links. Tighten group memberships. Apply sensitivity labels where they belong. This is the work that actually makes Copilot safe — not hiding sites from search and hoping for the best.

Once permissions are clean, disable RSS. Let Copilot use the full breadth of your tenant. That’s how you get value from it.

“We turned on RSS six months ago and Copilot still isn’t helpful.”

That’s not a Copilot problem. That’s an RSS problem.

My recommendation?

Use RSS if you’re deploying Copilot to a tenant you haven’t audited yet and you need breathing room. Thirty days. Not six months. Not “until we get to it.”

Set the allowed list. Fix the permissions behind the scenes. Then take the training wheels off.

If you’re an MSP and you’re not walking clients through this sequence — temporary RSS, permission remediation, RSS removal — you’re either leaving them exposed or leaving them hobbled. Neither looks good at renewal time.

RSS isn’t there to protect your tenant. It’s there to give you a window to actually protect your tenant. Don’t confuse the window with the wall.

Maybe Lists is a better tool?

image

Most SMBs I walk into are tracking something important in the worst possible place.

An Excel file pinned to a Teams channel. A shared OneNote page. A SaaS tracker they pay for monthly because no one told them there was already one in the tenant.

Then they wonder why nothing gets logged, why two people overwrote each other’s edits, and why the boss can’t see what’s going on.

That’s not a process problem. That’s a tooling problem.

There’s a free, already-licensed, surprisingly capable tracker sitting in every Microsoft 365 plan you sell. Most of your clients have never opened it.

What is Microsoft Lists, really?

It’s a structured tracker. Rows and columns, like a spreadsheet — but every column has a type (date, person, choice, number, attachment), so nobody fat-fingers a status into the wrong column.

It lives in SharePoint underneath, surfaces in Teams as a channel tab, and has its own icon on the Microsoft 365 app launcher. Same list, three doors in.

And it brings two things Excel will never give you: a built-in form for people who shouldn’t see the whole list, and built-in rules that fire emails when things change. No Power Automate. No premium connector. No developer.

A spreadsheet in a Teams channel isn’t a tracker. It’s a graveyard with column headers.

Step-by-Step: build a working tracker in ten minutes
Open Lists from the app launcher

Hit the waffle in Microsoft 365, pick Lists, click + New list. You’re at the list creation chooser.

Pick a template, not a blank list

I know — you want to start from scratch. Don’t. Templates ship with sensible columns, conditional formatting, and views already done. Issue tracker and Work progress tracker cover most SMB scenarios. Adjust later.

Save it to a SharePoint site, not “My lists”

The one step everyone gets wrong. My lists is personal storage — the list can’t easily be moved to a team site later. Save it under the SharePoint site behind the relevant Team. Future-you will thank present-you.

Share the form, not the list

Open your new list and click Forms on the toolbar. The list’s own form pops up. Hit Share form, copy the link, send it to your client, your supplier, the new starter — anyone who shouldn’t see the whole pipeline. Their answers land as new rows. They never see the list itself.

Add a rule from the Automate menu

Click Automate > Rules > Create a rule. Pick a trigger — a column changes, a new item is created, an item is deleted, a date approaches. Pick the column, the value, the person to notify. Done. Microsoft’s own guide walks the same path.

When Status changes to Blocked
notify Assigned To

Notice what’s missing? Power Automate. Premium licensing. A developer. Rules cover the boring 80% of automation. Save Power Automate for the genuinely complex 20%.

Pin it as a tab in Teams

In the relevant channel, click + at the top, pick Lists, choose Add an existing list, paste the SharePoint URL. Now the team uses it where they already work. The official Teams guide spells it out.

Why this actually changes behaviour

“I’ll just email it to you.”

That’s the line that kills every SMB tracker. People email instead of logging.

A Lists form sitting on a channel tab fixes that in a way a spreadsheet never will. Anyone clicks + New, fills four fields, presses save. The rule emails the right person automatically. The boss opens the same list and sees everything, in real time, sortable, filterable, with history.

Meet people where they already are.

Lists isn’t there to compete with your project management tool. It’s there to replace the spreadsheet your clients are pretending is one.

If you’re rolling out Microsoft 365 Business Premium and you’re not showing clients this, you’re leaving value on the table they already paid for.

A Cleaner Way to Connect PowerShell to SharePoint Online

image

Connect-PnPOnline with a browser sign-in is fine when you’re sitting at the keyboard. It becomes a problem the moment you’re not. The script that worked beautifully on your laptop refuses to run unattended. The scheduled job that was meant to tidy up orphaned sites overnight quietly does nothing, because it’s still waiting for someone to type a password. And the moment conditional access tightens on the admin account you’ve been quietly using for automation, every script that touches SharePoint behaves like it’s been thrown out a window.

The fix has existed. The setup hasn’t.

Certificate-based app authentication for SharePoint Online has been supported by Microsoft for years. The mechanics are well documented. The trouble has always been the assembly — generate a cert, export the public key, register an app in Entra ID, paste the right GUIDs in the right boxes, find Sites.FullControl.All in the API permissions list, grant admin consent, copy the thumbprint somewhere you won’t lose it, and verify the tenant ID in three different places along the way. By the time you’ve finished, you’ve forgotten which client you were doing it for.

So I’ve written a script that does the whole sequence end to end:

  • Generates a self-signed RSA-2048 certificate in your local certificate store

  • Creates the Entra ID app registration

  • Uploads the certificate and grants Sites.FullControl.All with admin consent

  • Provisions the service principal and adds Application.Read.All on Graph so the app can read its own metadata back

  • Resolves your tenant’s SharePoint root URL automatically from the Graph verified-domains call

  • Saves tenant, app ID, site URL, and thumbprint into a JSON profile so future connections need almost no parameters

What’s normally half an hour of clicking between Entra, the SharePoint admin centre, and a Notepad full of half-remembered GUIDs runs in about ninety seconds.

I’ve been written a new script — https://github.com/directorcia/Office365/blob/master/o365-connect-pnp-cert.ps1

with full documentation here – https://github.com/directorcia/Office365/wiki/Connect-to-SharePoint-Online-with-Certificates

What the Script Actually Does

There are two modes, controlled by switches.

-GenerateLocalCertificate creates a self-signed RSA-2048 certificate in your current user’s certificate store, exports the public key as a .cer file, and optionally exports a password-protected .pfx. By default it’s valid for two years. That’s the local side of the handshake.

-UseCertificateAuth is the everyday mode. You tell it which tenant to connect to — or let it look up the details in a profile map file — and it signs into Exchange Online using that certificate. No password. No browser. No MFA dialog.

The clever bit is the third option: combining -GenerateLocalCertificate with -ProvisionEntraApp -Tenant 'contoso.onmicrosoft.com'. In a single run, the script will generate the local certificate, authenticate to Microsoft Graph via a device-code flow, create the Entra ID app registration if it doesn’t exist, upload the certificate, grant Exchange.ManageAsApp and Application.Read.All with admin consent, create the matching service principal, sign you into Exchange Online to add the app to the Organization Management role group, and save the tenant, app ID, and certificate thumbprint to a JSON profile file so future connections don’t need any of those parameters.

Getting Started

If you’re new to certificate auth, the first run is the one that matters. Drop the script onto an admin machine, open PowerShell, and run:

.\o365-connect-pnp-cert.ps1 -GenerateLocalCertificate -ProvisionEntraApp -Tenant 'yourtenant.onmicrosoft.com'

You’ll be prompted to sign in — via device code for the Graph permissions (which if you use the –copydevicecodetoclipboard, option will put the required device code straight into the clipboard to paste into the request). You need a Global Admin account.

Where this earns its keep across a client base

After that first run, connecting to a tenant looks like this:

.\o365-connect-pnp-cert.ps1 -UseCertificateAuth -Tenant ‘contoso.onmicrosoft.com’

No password. No browser. No MFA prompt. The profile file is the bit that pays you back across an MSP book. One script lives in your tooling folder, each client has its own certificate and entry in the JSON map, and Task Scheduler can finally drive things like site collection audits, sharing reports, lifecycle cleanup on Teams-connected sites, and external-user reviews without anyone watching it run. Filter by tenant or site URL on the command line and the same script services twenty different customers without you ever editing it.

One honest caveat

When you’ve just provisioned a brand-new app, give Entra fifteen to thirty minutes for the role grants to replicate before your first cert-based connect. It’s the single most common reason a fresh setup looks broken when it isn’t. The script flags this on the way out, but it’s worth saying twice.

Why Certificates Beat Passwords

The security argument is the easy one. A certificate’s private key never leaves the machine that generated it. Nothing crosses the wire that an attacker could intercept and replay. There’s no shared secret to rotate across a team, no admin password sitting in a vault that someone might extract, and no MFA bypass to engineer because the flow doesn’t involve a user account at all.

If the certificate is ever compromised, you remove the key credential from the app registration and the access is gone — no password reset required, no impact on any human admin account.

The script enforces TLS 1.2, refuses to assign RBAC if the PnP session has landed in the wrong tenant, warns when the certificate is within thirty days of expiry, and keeps the device-code value off the clipboard by default to avoid leaks on RDP or shared sessions.

The change is a quiet one. You stop thinking about who is signing in and start thinking about which certificate is presenting itself. Once your SharePoint automation is no longer at the mercy of someone else’s MFA settings or a password rotation policy, the kind of work you’re willing to schedule expands. That’s the real win — not the ninety seconds saved on setup, but the chores you finally get around to doing.

Step-by-step: Find deleted file logs for a SharePoint site

image

Option 1: Use the Microsoft Purview audit portal

This is the easiest method for most admins.

  1. Sign in to Microsoft 365

  2. Open Audit

    • In the left menu, go to Solutions > Audit.

    • If prompted, enable auditing if it isn’t already on.
  3. Start a new search

    • Select New Search.
  4. Set the date range

    • Choose the period when you think the file was deleted.

    • Be aware that audit retention depends on licensing:

      • Many non-E5 tenants keep audit data for 180 days
      • E5 and some add-on licenses can retain some audit data for 1 year by default citehttps://learn.microsoft.com/purview/audit-search#before-you-search-the-audit-log
  5. Choose activities

    • In the activity filter, look for SharePoint file deletion-related actions such as:

      • Deleted file (FileDeleted)

      • Recycled a file (FileRecycled)

      • Deleted file from recycle bin (FileDeletedFirstStageRecycleBin)

      • Deleted file from second-stage recycle bin (FileDeletedSecondStageRecycleBin) citehttps://learn.microsoft.com/purview/audit-log-activities#file-and-page-activities
  6. Filter by site, file, or user

    • Use available filters to narrow results:

      • Site URL
      • File name
      • User
    • If you know the person who deleted the file, filtering by user makes results much easier to review.
  7. Run the search

    • Click Search.
  8. Review the results

    • Open matching events to see details such as:

      • who performed the action

      • when it happened

      • the file involved

      • the site URL

      • the operation type
  9. Check the event sequence

    • A typical deletion trail may look like this:

      • FileRecycled = file moved to recycle bin

      • FileDeletedFirstStageRecycleBin = removed from first-stage recycle bin

      • FileDeletedSecondStageRecycleBin = permanently removed from second-stage recycle bin citehttps://learn.microsoft.com/purview/audit-log-activities#file-and-page-activities


What the log entries mean

For SharePoint deleted files, these are the most useful audit events:

  • FileDeleted
    A user deleted a document from a site. citehttps://learn.microsoft.com/purview/audit-log-activities#file-and-page-activities

  • FileRecycled
    A user moved a file into the SharePoint recycle bin. citehttps://learn.microsoft.com/purview/audit-log-activities#file-and-page-activities

  • FileDeletedFirstStageRecycleBin
    A user deleted a file from the site’s recycle bin. citehttps://learn.microsoft.com/purview/audit-log-activities#file-and-page-activities

  • FileDeletedSecondStageRecycleBin
    A user deleted a file from the second-stage recycle bin. citehttps://learn.microsoft.com/purview/audit-log-activities#file-and-page-activities

That sequence helps you determine whether the file is still recoverable or has been permanently removed.


Practical tip for small businesses

If you are only trying to answer:

  • Who deleted the file?
  • When was it deleted?
  • Was it permanently deleted or just moved to the recycle bin?

Then the audit search with the filters:

  • date range

  • user

  • file name

  • SharePoint activities

is usually enough.

If you are trying to restore the file as well, you should also check:

  • the site recycle bin
  • the second-stage recycle bin

because the audit log tells you what happened, but recovery depends on whether the file is still retained in one of those recycle bins.


Option 2: Use PowerShell for more detailed searches

If you prefer scripting or want to export results, Microsoft also supports using the Search-UnifiedAuditLog cmdlet in Exchange Online PowerShell to search and export audit records. citehttps://learn.microsoft.com/purview/audit-log-export-records#use-powershell-to-search-and-export-audit-log-records

High-level process:

  1. Connect to Exchange Online PowerShell.

  2. Run Search-UnifiedAuditLog for the date range.

  3. Search SharePoint-related audit records.

  4. Export the results to CSV for filtering and reporting. citehttps://learn.microsoft.com/purview/audit-log-export-records#use-powershell-to-search-and-export-audit-log-records

This is especially useful if:

  • you need a report,

  • you want to search a large range of data,

  • or you want to automate the process.


Things to check if you can’t find the log

If no results appear, check these common causes:

  1. Wrong date range

    • Expand the time window.
  2. Audit retention expired

    • Older events may no longer be available depending on license. citehttps://learn.microsoft.com/purview/audit-search#before-you-search-the-audit-log
  3. Wrong activity selected

    • Try both:

      • deleted

      • recycled

      • recycle bin deletion events
  4. Auditing not enabled

    • In most tenants this is on, but if it was disabled previously, older activity may not exist. Microsoft notes audit log ingestion can be turned on or off. citehttps://learn.microsoft.com/purview/audit-search#before-you-search-the-audit-log
  5. Looking in SharePoint site settings instead of Purview

    • File deletion history is generally tracked in the Microsoft 365 unified audit log, not as a simple “deletion report” inside the SharePoint site itself.


Simple example

If a user says, “The file Budget.xlsx disappeared from the Finance SharePoint site,” you would:

  1. Open Purview Audit
  2. Search the last 7–30 days

  3. Filter activities to:

    • FileDeleted

    • FileRecycled

    • FileDeletedFirstStageRecycleBin

    • FileDeletedSecondStageRecycleBin
  4. Filter by:

    • Site URL = Finance site

    • File name = Budget.xlsx
  5. Review who deleted it and whether it is still recoverable

Cleaning Up the Microsoft 365 Mess Nobody Wants to Talk About

image

Most MSPs don’t get called in when things are going well.

They call you when SharePoint is a disaster, Teams is unusable, and staff have quietly given up trying to “do it the Microsoft way”. Files are everywhere, no one trusts search, and every conversation about collaboration starts with an eye roll.

And here’s the uncomfortable truth:
This mess didn’t happen overnight. It was designed that way — usually by rushing a migration, skipping governance, or treating Microsoft 365 like a file server with emojis.

The Real Problem Isn’t SharePoint or Teams

When a client says “SharePoint is terrible” or “Teams doesn’t work”, they’re rarely talking about the platform.

They’re talking about:

  • Duplicate document libraries with no ownership

  • Teams created for one meeting that still exist three years later

  • Channel sprawl with no naming standards

  • Files living in chats, OneDrive, SharePoint, desktops, and “somewhere else”

  • No idea where the authoritative version of anything lives

Microsoft 365 didn’t fail them.
Implementation did.

Migration ≠ Transformation

One of the biggest mistakes I see is confusing a migration with a solution.

Too many Teams and SharePoint migrations are glorified copy‑paste exercises:

  • Lift the file server

  • Dump it into SharePoint

  • Auto‑create Teams

  • Declare success

But all you’ve done is move the mess into the cloud — and now it’s harder to clean up because people are actively working in it.

A bad on‑prem file structure is annoying.
A bad SharePoint structure actively damages productivity every single day.

Why This Is a Goldmine for MSPs (If You Handle It Right)

Here’s the opportunity most MSPs miss.

Clients don’t want another platform.
They want:

  • Less friction

  • Clear rules

  • Confidence that “this is the right place to put things”

Fixing a messy SharePoint or Teams environment isn’t a one‑off job. It’s a reset.

The best engagements I see follow a pattern:

  1. Stabilise – Stop the bleeding. Lock down creation, clean up obvious duplication, identify owners.

  2. Standardise – Define what Teams are for, what SharePoint sites are for, and when to use each.

  3. Simplify – Fewer Teams. Fewer sites. Clear naming. Clear lifecycle rules.

  4. Educate – Not training for the sake of it, but contextual guidance: “Put this here. Not there.”

This isn’t sexy work.
But it’s high‑trust, high‑value work.

Governance Is Not a Dirty Word

Every time I hear “we didn’t want to slow users down”, I know what’s coming next.

Chaos.

Lightweight governance doesn’t block productivity — it enables it. Users move faster when they’re not guessing. When they know where things go. When they trust search. When they’re not creating Teams just to avoid asking where files live.

MSPs who position governance as “making life easier” instead of “locking things down” win every time.

The Payoff

When you fix a collaboration mess properly, clients notice:

  • Meetings get shorter

  • Onboarding gets faster

  • Internal arguments about “where things are” disappear

  • Microsoft 365 finally feels like an asset, not a tax

And you stop being the MSP who “just keeps the lights on”.

You become the partner who made things work again.

That’s problem‑solving.
That’s pain‑point focus.
And that’s where real MSP value lives.

SharePoint Online–Playbook for SMB

image

To receive a FREE copy of my SharePoint Online – Playbook for Small Businesses you’ll need to sign up for, and attend, this months CIAOPS Need to Know webinar:

You can register for the regular monthly webinar here:

October Registrations

(If you are having issues with the above link copy and paste – https://bit.ly/n2k2510)

The details are:

CIAOPS Need to Know Webinar – October 2025
Friday 31st of October 2025
11.00am – 12.00am Sydney Time

more webinar details.