Category: Microsoft 365

Need to Know podcast–Episode 365

In this episode, we dig into Cowork Skills and why they represent a genuine shift from “AI as a novelty” to “AI as part of how work actually gets done.” Not more prompts. Not more tools. But fewer decisions, less friction, and more consistency across the business.
If you’ve ever thought “Copilot is interesting, but it’s not really embedded yet”, this episode is for you.

Brought to you by www.ciaopspatron.com

you can listen directly to this episode at:

https://ciaops.podbean.com/e/episode-365-skills-not-apps/

Subscribe via iTunes at:

https://itunes.apple.com/au/podcast/ciaops-need-to-know-podcasts/id406891445?mt=2

or Spotify:

https://open.spotify.com/show/7ejj00cOuw8977GnnE2lPb

Don’t forget to give the show a rating as well as send me any feedback or suggestions you may have for the show

Resources

CIAOPS Need to Know podcast – CIAOPS – Need to Know podcasts | CIAOPS

X – https://www.twitter.com/directorcia

director@ciaops.com

CIAOPS Blog – CIAOPS – Information about SharePoint, Microsoft 365, Azure, Mobility and Productivity from the Computer Information Agency

Join my Teams shared channel – Join my Teams Shared Channel – CIAOPS

CIAOPS Merch store – CIAOPS

Become a CIAOPS Patron – CIAOPS Patron

CIAOPS Brief – CIA Brief – CIAOPS

CIAOPS Labs – CIAOPS Labs – The Special Activities Division of the CIAOPS

Support CIAOPS – Support CIAOPS

Get your M365 questions answered via email

Please fill out this form

A special thanks to the CIAOPS Patron community for making this podcast possible. You can find the benefits of a subscription to the community and become a member at https://www.ciaopspatron.com
CIAOPS MSP Skills

Microsoft Build

Choose how OneNote opens Microsoft 365 file links

How Storm-2949 turned a compromised identity into a cloud-wide breach

Disrupting Fox Tempest: A cybercrime service that turned “verified” software into a pathway for ransomware

Exposing Fox Tempest: A malware-signing service operation

A faster, more efficient Editor experience with Narrator in Word

Launched: Microsoft 365 Copilot Adoption Hub Redesign

Copilot prompt libraries for your tenant

image

Most Copilot rollouts I see have a strange shape. The licences are bought. The admin centre is half-configured. And nobody is using it.

Six months in, a few power users are saving an hour a week. Everyone else opens Copilot, stares at a blank box, and closes the tab.

That’s not a Copilot problem. That’s a prompting problem.

And the worst part? Microsoft has already shipped the fix. Most tenants haven’t turned it on.

What is a tenant prompt library, really?

A prompt library is a list of known-good prompts pinned inside the Copilot experience itself. Your users see them when they open Copilot — in chat, in Word, in Excel, in Outlook, wherever you’ve published them.

Two layers matter for SMBs and MSPs.

The first is the Microsoft Copilot Prompt Gallery — the public set Microsoft maintains. Useful. Generic.

The second is promoted prompts — your own prompts, pushed to your own users from the Microsoft 365 admin centre. This is the layer almost nobody uses, and it’s the one that actually changes behaviour.

Think of it as the difference between handing someone a generic cookbook and putting a Post-it on their fridge that says “this is how we make pasta”.

Step-by-Step: publishing a tenant prompt library

Portal walkthrough, no PowerShell.

Open the admin centre

Sign in to the Microsoft 365 admin centre as a Global or Copilot admin. Expand Copilot in the left nav, then Settings, then Promoted prompts.

Write the prompt your users actually need

Don’t reach for a clever one. Reach for the boring one your help desk keeps explaining. “Summarise this week’s emails from my customers and group by client.” “Draft a weekly status update for my manager based on my meetings and Teams chats.” Plain English, written the way a non-technical user would actually type it.

Pin it to the right app

You can target the prompt to Microsoft 365 Copilot chat, Word, Excel, PowerPoint, Outlook, Teams, or OneNote. Pin one prompt per app where it’s actually useful. Five great prompts beats fifty mediocre ones.

Set the audience

Use a group, not “everyone”. Roll it to a pilot. Sales gets the sales prompts. Finance gets the finance prompts. The prompt is the training material.

Publish and watch adoption move

Promoted prompts surface at the top of the Copilot prompt UI for the assigned users within a few hours. Microsoft’s Copilot Prompt Gallery documents the surfaces they show up on.

Title: Weekly client summary
App:   Microsoft 365 Copilot chat
Prompt:
Summarise emails and Teams messages from
my customers this week. Group by client.
Highlight any unanswered questions.

Notice what’s missing? No mention of how Copilot does the work. No file picker. No talk of Work IQ. The user just asks once and gets the outcome. That’s the brief.

Why this actually changes behaviour

Most adoption programmes hand out PDFs nobody reads. Promoted prompts put the training inside the product, at the moment of use.

“I don’t know what to ask Copilot for.”

That sentence kills more rollouts than any licensing or governance issue. A prompt library answers it.

Three things shift the day you publish one:

  • New users see a starting point on day one instead of a blinking cursor.

  • Power users stop reinventing the same prompt twelve different ways.

  • You finally have a measurable, governable surface to iterate on.

That last one matters for MSPs. You can review the prompt library quarterly with your client, the same way you review a security baseline. Copilot doesn’t get tired. Use that.

For the deeper guidance on what makes a prompt land, Microsoft’s own write effective prompts page is worth lifting language from when you draft yours.

One closing thought

If you’re rolling out Copilot to a client and you haven’t published a single promoted prompt, you’re charging them for a tool and shipping them a blank page.

Promoted prompts aren’t there to teach people how to use Copilot. They’re there to remove the moment of not knowing what to ask completely.

Driver & firmware update management via Intune

image

Walk into most MSP-managed Windows fleets and the update story stops at quality and feature rings.

Drivers? “Windows Update grabs those.” Firmware? “The OEM utility does that.”

That’s not a strategy. That’s three different cooks in the same kitchen, and you’re praying none of them serves up a bad BIOS on a Friday afternoon.

Here’s the real win. Intune has had a dedicated approval surface for driver and firmware updates for a while now. And almost nobody’s switched it on.

What is a driver update policy, really?

It’s a separate Intune profile that sits alongside your existing update rings. It shows you every driver and firmware update Windows Update has queued for your managed devices, and lets you decide — one at a time — whether to ship it.

Approve, pause, defer, hold back the one dodgy NIC driver while the rest go through. All in the portal.

Critically, it’s the same pipeline Windows Autopatch uses for drivers. Five-laptop accounting firm on Business Premium or 500-seat shop on M365 E3 — same surface. You need Intune Plan 1 and a Windows licence that includes the Autopatch entitlement (Business Premium and M365 E3/E5 both have it), devices must be Entra joined or Entra hybrid joined, and telemetry must be set to Required or higher. That’s the lot.

Step-by-Step: switching it on
Check your existing rings aren’t blocking drivers

This is the bit that catches people. If your existing Update Ring or Settings Catalog policy blocks drivers, the whole feature does nothing. In your update ring, set Windows driver to Allow. In the Settings Catalog, set Exclude WU Drivers in Quality Update to Allow Windows Update drivers.

Both default to Allow, but I’ve found plenty of older tenants where someone clicked Block years ago and forgot.

Open the right blade

Sign in to the Microsoft Intune admin centre → Devices → By platform → Windows → Manage updates → Windows 10 and later updates → Driver updates tab → Create profile.

Pick an approval mode

You get two:

  • Automatically approve all recommended driver updates — anything the OEM tags “recommended” gets approved on its own, with a deferral you set between 0 and 30 days.

  • Manually approve and deploy driver updates — every driver lands as Needs review and waits for you.
Approval method:   Automatically approve all recommended driver updates
Make updates       7
available after:

Notice what’s missing? There’s no per-vendor split and no per-device override. One policy, one device — stack two driver policies on the same machine and you’ll fight yourself.

Assign and stage

Pilot group of around 10% — your own laptops, IT, one tolerant power user. Watch it for a fortnight. Then 25%. Then the rest. The per-driver pause button is your friend the first time something breaks.

Why this actually changes behaviour

Most clients have never had a driver controlled by anyone other than Windows Update itself. The first time a Lenovo BIOS update bricks a laptop at 4pm on a Friday, that’s the conversation you do not want to be having with the owner.

With a policy on, you see the update before it hits anyone. You pause it. The rest of the fleet still ships. The client doesn’t even know it happened — and that’s the point.

“But surely Windows Update already knows what’s safe?”

Windows Update knows what applies. It doesn’t know your fleet. You do.

One last wrinkle. The policy doesn’t honour the OEM’s Computer Hardware ID targeting — so managed devices can pick up a newer “recommended” driver even when the OEM reserved a CHID-matched build for that exact model. My recommendation? Use manual approval on hardware you don’t have a spare of in a drawer to test against.

Driver update policies aren’t there to give you more buttons to click. They’re there to take the OEM utility, the random Windows Update behaviour, and the 4pm Friday surprise off the table completely.

If you’re not running one on every managed tenant, you’re outsourcing your hardware change control to luck.

CIA Brief 20260523

image

Security & Threat Intelligence

Microsoft 365 Apps & Productivity

Microsoft 365 Copilot

After hours

Clarkson’s Farm Series 5 | Official Trailer – https://www.youtube.com/watch?v=GJxPc3B2osU

Editorial

If you found this valuable, the I’d appreciate a ‘like’ or perhaps a donation at https://ko-fi.com/ciaops. This helps me know that people enjoy what I have created and provides resources to allow me to create more content. If you have any feedback or suggestions around this, I’m all ears. You can also find me via email director@ciaops.com and on X (Twitter) at https://www.twitter.com/directorcia.

If you want to be part of a dedicated Microsoft Cloud community with information and interactions daily, then consider becoming a CIAOPS Patron – www.ciaopspatron.com.

Watch out for the next CIA Brief next week

Smarter Scheduling with Microsoft Bookings

image

Most of the small businesses I look at are still scheduling meetings with email.

Three back-and-forth replies. A “does Tuesday at 2 work?”. A “no sorry, Wednesday?”. A reply chain that never quite books anything.

The smarter ones have a Calendly tab open in another browser. Their bookkeeper has Calendly. Their VA has Calendly. Their accountant has Acuity. Somewhere in the mix, another subscription is being paid for.

But every one of those tenants already has Bookings sitting unused inside their Microsoft 365 plan. And almost nobody knows it comes in two flavours.

That’s not a feature gap. That’s an awareness gap.

What is Bookings, really?

Bookings is two products with the same name.

The first is Bookings with me — Microsoft also calls it Personal Bookings. It’s a per-person scheduling page tied to your Outlook calendar. Someone hits your link, picks a meeting type, picks a slot inside your real availability, and the invite lands in both calendars. No mailbox to provision. No staff list. Just you and your calendar.

The second is a shared booking page. A separate scheduling mailbox for a team, a service, or a whole business. Multiple staff, multiple services, different durations. The classic “book a haircut, pick your stylist” page — except it works just as well for “30-minute discovery call with whoever on the team is free”.

Personal page for an individual. Shared page for a business.

Most SMBs need both.

Step-by-Step: standing up your personal page
Open the Bookings app

Go to book.ms, or pin the Bookings app to the rail in Outlook on the web or Teams. On the home page you’ll see Personal booking page at the top — that’s Bookings with me. Microsoft has already published one for you with default 15- and 30-minute meeting types. The detail is in the Personal Bookings FAQ on Microsoft Learn.

Set your meeting types

Edit the defaults. Set duration, location (Teams meeting by default — toggle it off for in-person), and availability hours. Mark each one Public to put it on your link, or Private to share only as a one-off.

Add a buffer

This is the setting people miss. Buffer time before and after each appointment is what stops your day collapsing into back-to-backs. Five or ten minutes on every meeting type. Buffer behaviour lives under Configure service availability.

Drop the link into your signature

Copy the public URL. Paste it into your Outlook signature:

https://outlook.office.com/bookwithme/user@yourdomain.com/

Notice what’s missing? No “let me know what works”. No “looking forward to hearing back”. The link does the asking.

Step-by-Step: standing up a shared page
Create the page

In Bookings, under Shared Bookings, choose Create booking page. Start from scratch unless you’ve got a template to clone. Fill in business name, logo, and hours — the setup walkthrough on Microsoft Learn lists the four required pieces.

Add staff and services

Add bookable staff. For each one, leave Events on Microsoft 365 calendar affect availability on so their Outlook calendar drives free/busy. Then create services — a service is a bookable thing (“30-min discovery”, “60-min onboarding”) with its own duration, buffer, and reminder cadence.

Decide who can be self-served

Turn off self-service for anything strangers shouldn’t book. Mark internal-only services Private.

Why this actually changes behaviour

“Hey, got a few minutes next week?” becomes “Sure — book a time.”

That one swap is the whole post.

The personal page kills the email tennis between you and your contacts. The shared page kills it between your clients and your team. The calendar becomes the source of truth, not the inbox.

Here’s the real win: it’s already in the licence. Business Basic, Business Standard, Business Premium, the E plans — Bookings is there. Calendly is not.

If your clients are still booking meetings by email, they’re paying for two things and using one of them.

Bookings isn’t there to schedule meetings. It’s there to stop scheduling them at all.

Windows Update for Business rings via Intune

image

Most of the Windows patching pain I see at SMB sites isn’t a Windows problem. It’s a governance problem.

Devices are enrolled. Updates are technically arriving. But there’s no ring. No pilot. No deadline. Patch Tuesday lands, somebody’s accounting machine reboots in the middle of a BAS run, the partner blames “Windows”, and the whole patching conversation gets put off for another quarter.

That’s not a tooling gap. That’s a configuration gap.

And here’s the kicker — Microsoft renamed the whole thing in April 2025. Windows Update for Business is now Windows Update Client Policies, and the deployment service is folded into Windows Autopatch, which is now included with Microsoft 365 Business Premium. If you’re still hand-rolling rings on a Business Premium tenant and ignoring Autopatch, you’re doing more work than you need to.

What update rings really are

An update ring is a Windows Update client policy. It tells the Windows Update client on the device when to look, how long to wait, when to install, and when to reboot. Nothing more.

It’s not a patch repository. It’s not a scanner. It’s a set of timing instructions the device honours when it talks to Microsoft’s update endpoints.

Once you accept that, the rest gets simpler. You’re not pushing patches. You’re staging trust.

Step-by-Step: build a three-ring rollout in Intune

Portal only. No PowerShell.

Open the unified updates dashboard

Sign in to intune.microsoft.com, then go to Devices > By platform > Windows > Manage updates > Windows updates and click the Update rings tab. This is the new unified surface — Microsoft’s docs on managing update rings live here.

Create the Pilot ring

Click Create profile. Name it WUR – Pilot. Quality update deferral: 0 days. Feature update deferral: 0 days. Automatic update behaviour: Auto install at maintenance time. Deadline for quality: 2. Deadline for feature: 2. Grace period: 2.

Assign to a device group of 3-5 representative machines. Not user groups. Devices.

Create the Broad ring

Same shape. Name it WUR – Broad. Quality deferral: 3. Feature deferral: 7. Same deadline/grace as Pilot. Assign to the bulk of your fleet.

Create the Critical ring

WUR – Critical. Quality deferral: 7. Feature deferral: 30. Assign to the boss’s machine, the EFTPOS PC, the design workstation — whatever you can’t afford to surprise.

Three rings. That’s it. Don’t build five.

The deferral / deadline / grace mental model

People get this wrong constantly. Here’s the model in one block.

Deferral  → how many days AFTER Microsoft releases the update
            before the device is even offered it.
Deadline  → how many days AFTER the device sees the update
            before it's force-installed.
Grace     → how many days AFTER install before reboot is forced.

Notice what’s missing? Patch Tuesday as a reference point. The deadline counts from when that device scanned and saw the update — not the calendar. Microsoft moved to this model deliberately to make restart timing predictable across a fleet.

Set them. Don’t leave any of the three blank. Blank means forever on a sleepy laptop.

Why this actually changes behaviour

The mistake isn’t choosing the wrong deferral. The mistake is leaving the pause button in users’ hands.

In the ring settings, set Option to pause Windows updates to Disable. Otherwise a user can park their patches for 35 days, and you’ll find out at the next quarterly review.

Set automatic update behaviour to Auto install at maintenance time with active hours configured. The device patches itself. The user keeps their day. The MSP stops being the villain.

“Why do my updates keep nagging me?”

They don’t, anymore. You set active hours. The reboot finds its time, not yours.

Copilot doesn’t get tired. Neither does Windows Update. Use that.

A word on Autopatch

If the tenant is Business Premium, you now get the full Windows Autopatch service — rings auto-built, rollback on signal, 95% currency SLO. On those tenants, don’t assign hand-built rings to Autopatch-managed devices. They’ll fight each other.

My recommendation? Business Premium tenants → Autopatch. Everything else → three rings, the shape above, locked down so users can’t pause.

Update rings aren’t there to slow patching down. They’re there to remove the conversation about patching completely.

If your clients are still asking when their machines will reboot, you haven’t finished the job.

AI Didn’t Remove Programming – It Lowered the Bar

image

One of the most dangerous misunderstandings I hear is:
“AI means we don’t need programming anymore.”

The opposite is true.

We need more programming literacy—just a different kind.

AI doesn’t replace logic, structure, or clarity. It amplifies them. When an AI tool “writes code” for you, what it’s really doing is translating your intent into something executable. If your intent is vague, messy, or logically broken, the output will be too.

MSPs already see this in practice:

  • A poorly described Power Automate flow that works once and then quietly breaks.

  • An AI-generated script that technically runs but makes unsafe assumptions.

  • A Copilot prompt that looks clever but produces useless business output.

The common issue isn’t the tool. It’s the thinking behind the instructions.

Understanding basic concepts—inputs, outputs, conditions, loops, exceptions—has never been more important. The difference now is you don’t need to memorise syntax. You need to think clearly and explain cleanly.

This Is a Business Advantage, Not a Technical Party Trick

Here’s where many MSPs miss the opportunity.

They see AI-assisted “programming” as something clever techs play with internally. In reality, it’s fast becoming a deliverable business capability.

Think about your SMB clients:

  • They know their processes are inefficient.

  • They can explain what they want, but not how to build it.

  • They don’t want a six‑month dev project for a simple workflow problem.

An MSP that can sit with a client, map a process in plain English, and turn it into an automated solution is no longer just “support”. You’re helping redesign how the business operates.

And the simplicity is the point.

A one‑page English description that becomes:

  • A ticket triage workflow

  • An onboarding checklist generator

  • A management report assembler

  • A light internal chatbot using their own documents

None of that needs hardcore development skills anymore—but all of it still needs structured thinking.

Your Team Doesn’t Need Coding Skills – They Need Programming Awareness

This is where MSP leaders need to be deliberate.

You don’t suddenly need Python experts across your service desk. What you do need is:

  • Staff who can break problems into steps

  • People who can explain outcomes unambiguously

  • A shared understanding of how logic flows

If your team can already document SOPs well, they are halfway there.

I’ve seen MSPs get real value by:

  • Treating AI prompts like mini specifications, not chat questions

  • Reviewing AI-generated automations as a team, not blindly deploying them

  • Teaching junior staff how to describe a problem, not just which tool to click

Those are capability investments, not tool training.

The MSPs Who Win Will Treat This as a Core Skill

We’ve crossed a line. Programming is no longer gated by language barriers—it’s gated by thinking quality.

That changes what “technical literacy” means for MSPs.

The firms that thrive over the next few years won’t be the ones chasing every new AI tool. They’ll be the ones that:

  • Build strong internal habits around logical thinking

  • Help clients translate business problems into clear instructions

  • Package simple automation as repeatable, billable outcomes

If English is now the language of code, the question is simple:

Are you teaching your people how to speak it clearly—or assuming the tools will do that for them?

That’s a strategic choice every MSP leader needs to make, sooner rather than later.

Named locations + Conditional Access location-based policies

image

Most MSPs I talk to have a Conditional Access policy that blocks “high-risk countries”. They built it once, switched it on, and never looked at it again.

Then they sleep well at night.

That’s the problem.

A country block on its own is theatre. The attacker is on a VPN egress inside a country you allow, or a residential proxy, or a mailbox client that already has a refresh token. Named locations are useful — but only if you understand what they actually do, and where they fall down.

What is a named location, really?

A named location is a label. That’s it.

You’re telling Entra ID, “this IP range is my office”, or “these countries are where my staff actually work”. The location doesn’t enforce anything on its own. It’s a building block you then reference inside a Conditional Access policy.

The policy does the work. You decide whether to block, require MFA, or skip a control. The location is just the where.

And here’s the bit that bites people. Location is evaluated after first-factor authentication. The password’s already gone. Conditional Access then decides what happens next. Treat named locations as a layer, not a perimeter.

Step-by-Step: Setting up a country block that actually earns its keep

Portal path only. Report-only first — non-negotiable.

Open Named locations

Sign in to the Microsoft Entra admin centre as a Conditional Access Administrator. Go to Protection > Conditional Access > Named locations.

Create a Countries location

Click + Countries location. Name it something obvious — “Allowed countries — AU only” beats “Country Block 1”. Pick the country (or countries) where your staff actually sign in. Tick Include unknown areas if you want the location to also catch IPs the geo-database can’t classify. I leave that off for allow-lists and on for block-lists. Save.

Create the policy

Go to Policies > New policy. Name it. Under Users, pick All users — then exclude your break-glass accounts. Always. Under Target resources, pick All resources.

Set the network condition

Under Network, set Configure to Yes. Include Any network or location, then under Exclude select Selected networks and locations and pick your “Allowed countries” entry. That gives you “block everything outside my country”.

Grant

Under Access controls > Grant, choose Block access.

Switch to Report-only and review

Set Enable policy to Report-only. Create. Then watch the sign-in logs for at least 48 hours. The report-only results tell you exactly which users would have been blocked. Anyone surprising in there? Investigate. Then flip the policy on.

Why this actually changes behaviour

Here’s the real win. Once you’ve got clean named locations, every other CA policy gets sharper.

The “skip MFA from a trusted location” pattern — careful with that. Marking your office public IP as trusted feels like a productivity gift to users. It’s also the exact thing an attacker on your guest Wi-Fi or a compromised contractor on your VPN will piggyback. My recommendation? Don’t mark anything as trusted unless you have a strong reason and you’ve documented it. Use sign-in frequency and authentication strength to soften MFA friction instead.

“But our staff hate MFA prompts in the office.” Then fix the prompts. Don’t punch a hole in the wall.

The other classic trap is the corporate VPN. If everyone egresses through one public IP in a country you’ve blocked, you’ve just locked your own staff out. Map your VPN exits before you write the policy. Read the network assignment conditions before you write the policy, not after.

Notice what’s missing from all of this? PowerShell. You don’t need it. The portal does the job, and the audit trail is clearer.

A country block doesn’t stop attackers. It thins the noise so the rest of your stack can do real work. If you’re not showing your clients this — and explaining why “trusted location” is a loaded word — you’re leaving security maturity on the table.

That’s the job. Use named locations for that, and not for the warm feeling a checkbox gave you.