New Microsoft image model

I have a standard image prompt that I use to test Ai models. The previous iteration with MAI-Image-2.5-Flash and MAI-Image-2.5 is here:

https://blog.ciaops.com/2026/06/04/latest-microsoft-image-models/

Before that with MAI-Image-1.5 and Flux.2 Flex is here:

https://blog.ciaops.com/2026/05/16/copilot-image-generation-in-powerpoint/

the previous attempts:

https://blog.ciaops.com/2026/05/05/revisiting-copilot-image-generation-analysis/

and the first attempt:

https://blog.ciaops.com/2026/03/07/image-generation-analysis/

Microsoft has just released a new models and here is what I got when I used them:

MAI-Image-2.5-Pro

MAI_62dbc50ed84cdf44

It will be soon available across Microsoft 365 services and desktop apps. You can read more about the new models here:

https://microsoft.ai/news/introducing-mai-image-2-5-pro-and-mai-voice-2-flash/

When the Fix Stops Being a Fix: Troubleshooting in the Age of Probabilistic IT

image

For most of my working life, troubleshooting an SMB environment was a hunt for a single, knowable cause. Something was broken, and somewhere there was a reason. A permission was wrong. A DNS record pointed at the wrong place. A service had stopped. You worked the chain backwards, found the link that had failed, fixed it, and the problem went away. The same input produced the same output, every time. That was the quiet contract underneath everything we did. IT was deterministic, and our whole troubleshooting craft was built on that assumption.

That contract is now breaking, and AI is the reason. The more our clients lean on tools like Microsoft 365 Copilot, the more we find ourselves chasing problems that don’t have a single cause and don’t behave the same way twice. We’ve spent decades learning to solve deterministic problems. We’re now being asked to solve probabilistic ones, and most MSPs haven’t noticed the ground shift under their feet.

“It Worked Yesterday” Now Means Something Different

Here’s the scenario I keep running into. A client calls because Copilot gave them a wrong answer. It summarised a meeting and missed the one decision that mattered. Or it drafted a reply in Outlook that referenced a document the user swears they never mentioned. Yesterday it was brilliant. Today it’s confidently wrong. Nothing changed on your side. No update shipped. No setting moved.

Under the old model, “it worked yesterday and not today” was a clue. It told you something had changed, and you went looking for the change. With AI in the mix, that same sentence tells you almost nothing. Large language models are probabilistic by design. The same prompt can produce a different response on Tuesday than it did on Monday, and that’s not a bug you can ticket your way out of. It’s how the technology actually works.

So when a client reports that “Copilot is broken,” your first instinct — find what changed — quietly fails you. There may be nothing to find. The behaviour you’re chasing isn’t a fault in the wiring. It’s variance in the output. And variance doesn’t sit still long enough to be caught with the tools we’ve always used.

The Cause Isn’t Always in the System

The harder adjustment is accepting that the problem often isn’t technical at all. When Copilot returns a poor result, the cause is frequently the question, not the code. A vague prompt, missing context, the wrong document open in the background, permissions that quietly scope what Copilot can and can’t see — these shape the answer far more than any registry key ever did.

I had a client convinced Copilot in Teams couldn’t read their project files. The real issue was that the files lived in a SharePoint site the user didn’t have access to, so Copilot, correctly, never touched them. The system was working exactly as designed. The human’s mental model was the thing that was broken. There was no error in any log, because there was no error. Try writing that up in a standard ticket resolution.

This is the part that unsettles seasoned engineers. We are trained to distrust “user error” as a lazy diagnosis. But with AI, the boundary between the tool and the person using it has genuinely blurred. The quality of what Copilot produces is now a function of context, phrasing, data access, and the user’s own clarity of thought. Half of real-world “AI problems” are actually grounding problems — Copilot simply wasn’t given the right material to work with. You can’t fix that with a script. You fix it by teaching.

From Repair to Probability Management

So what does troubleshooting look like when certainty is gone? It looks less like repair and more like managing probability. Instead of asking “what’s broken,” you start asking “why is this likely happening, and how do we make the good outcome more likely next time.”

That changes the work in practical ways. You start checking what Copilot can actually see — the SharePoint and OneDrive permissions, the Purview sensitivity labels, the data the user assumes is in scope but isn’t. You look at how the question was asked, not just what the system returned. You reproduce the issue several times, because one bad answer is an anecdote, not a pattern. You document tendencies rather than root causes, because a tendency is often the most honest thing you can record.

It also changes what you sell. The deterministic world rewarded MSPs who could find and fix. The probabilistic world rewards MSPs who can guide, set expectations, and shape how AI gets used across a client’s day. The value moves from the repair to the relationship.

Sitting With Uncertainty

None of this means our old skills are worthless. Plenty of SMB problems are still gloriously deterministic — a licence didn’t assign, a mailbox didn’t migrate, a Conditional Access policy locked someone out. Find it, fix it, move on. That work isn’t going anywhere.

But a growing slice of what lands in your queue now has no clean answer, and pretending otherwise only frustrates everyone. The MSPs who’ll do well from here are the ones who can hold two modes at once — the precision of the engineer and the judgement of an advisor who’s comfortable saying “here’s what’s most likely, and here’s how we improve the odds.” Learning to sit with that uncertainty, rather than fight it, might be the most valuable troubleshooting skill of the next decade. I’m still getting used to it myself.

The Robots Didn’t Kill Sales. Relevance Did.

image

Let me be upfront: this isn’t a post about watching other people lose their footing. I’ve seen it happen — quietly, without announcement — but pointing at cautionary tales reads as smugness, and it doesn’t help anyone. What does help is understanding the mechanism. Because the mechanism doesn’t care whose career it applies to, including mine.

The Slow Fade

When AI started making headlines, a certain explanation took hold in IT circles: the robots came and took over. Clients automated their way out of needing you. Algorithms undercut your value. Technology made your expertise redundant overnight.

I’ve sat in rooms where that story got told with great conviction. And I understand the appeal — it’s clean, it’s external, and it lets everyone off the hook.

But I don’t think it’s the real story. At least not for most people.

What I’ve actually watched happen is something quieter, and frankly more avoidable. Skilled people — genuinely skilled, with real depth — stopping. Stopping posting, stopping presenting, stopping sharing what they were learning. Getting busy, or burned out, or simply assuming that reputation would carry. And then discovering, over months rather than days, that the market had quietly moved on.

The market doesn’t issue a formal notice. It just stops calling.

Presence Is a Practice, Not a Trophy

Here’s the thing about credibility in professional services: it behaves more like a subscription than an asset. You don’t acquire it once and keep it indefinitely. You maintain it — week by week, post by post, conversation by conversation — by staying present in the space where your clients and prospects are paying attention.

The people I see holding their ground right now aren’t necessarily the most technically brilliant. What they share is a habit of doing something worth knowing about and then talking about it. They’ve been working through how Copilot in Teams handles a fast-paced client meeting — the kind where the conversation moves faster than anyone can type — and they write up what actually happened. Not a polished case study. A genuine account of what worked, what surprised them, what the documentation didn’t quite prepare them for.

That’s what gets shared. That’s what gets remembered. That’s what gets you back into the conversation when a prospect is deciding who to ring.

The alternative — doing excellent work quietly, trusting that results will speak for themselves — used to be viable. It worked when markets were smaller and word of mouth moved reliably. I’m not sure it works the same way now. Attention spans are shorter, competition is louder, and the gap between the visible and the invisible keeps widening faster than most people expect.

The AI Angle Nobody Wants to Admit

Here’s where I’ll give the “robots did it” crowd a partial concession: the shift toward AI tools has accelerated everything. But not quite in the way most people mean.

What it’s accelerated is the gap between people who are actively inside the change and people who are observing it from a safe distance. Clients are asking questions about Copilot, about automation, about what Microsoft 365 actually means for how their team works day to day. The people who get those calls are the ones who have been publicly working through those questions — who’ve shared what Microsoft 365 Business Premium looks like in practice for a 40-person firm, or explained what Copilot in Outlook actually does to a full inbox on a Monday morning, drawing from real client experience rather than a vendor one-pager.

The others get found too. Just by someone else.

So if you’re waiting until you feel fully prepared to share — waiting for the perfect case study, the right moment, enough certainty — I’d gently push back on that. The market is not waiting with you. It’s watching whoever is showing up.

The Account Runs Down

I think of staying relevant the way I think about any recurring obligation: you can miss a payment here or there without immediate consequence, but the balance erodes. And by the time you notice the problem, you’re already working against a deficit. Rebuilding takes longer than maintaining ever did.

The fix is not complicated, even if it takes discipline. Engage with something genuinely new — a client challenge, a corner of the Microsoft 365 stack you haven’t properly explored, a question your market keeps circling. Arrive at a real view. Then share it, in your own voice, without waiting until it’s polished enough to be mistaken for marketing material.

Work on things that matter. Then put them where the people who should know can find them.

That’s the whole playbook.

The careers that fade aren’t usually the ones that got disrupted by technology. They’re the ones that went quiet. The ones that assumed the work would carry its own story forward.

It doesn’t. You have to carry it.

Don’t go quiet.

AI Governance Starts Before Copilot Does

image

Most AI conversations with business owners start in the wrong place. They ask whether Microsoft 365 Copilot is worth buying. I think the better question is whether the business is ready for what Copilot will reveal.

I have seen the same pattern often enough now. A client gets excited about Copilot in Outlook, Teams, Word and Excel. Someone wants meeting summaries. Someone else wants faster proposals. The owner wants staff to stop using random public AI tools with company data. All fair enough. But then we look underneath and find the real issue: years of loose permissions, old Teams, forgotten SharePoint sites, stale guests and no clear policy on what staff should or should not ask an AI system to do.

That is where AI governance starts.

Governance is not a document no one reads

A policy is useful, but only if it changes behaviour. If the policy says “use AI responsibly” and nothing else, it has failed before it starts.

For Copilot, I want plain rules. What data can be used? What data must not be used? When does a human need to review the answer? Who owns the final output? What happens if Copilot surfaces something the user did not expect to see?

That last question matters. Copilot does not need to break into your tenant to create a problem. If a user already has access to a file, Copilot may be able to use that file as part of an answer. The silent risk is not Copilot ignoring permissions. The risk is that the permissions were never cleaned up in the first place.

The technology follows the tenant

This is why I keep coming back to the Microsoft 365 basics. Entra ID, MFA, Conditional Access, SharePoint permissions, Teams lifecycle, Purview sensitivity labels and Data Loss Prevention are not side issues. They are the foundation.

If identity is weak, every AI answer sits on a weak account. If SharePoint is overshared, Copilot can make that oversharing easier to discover. If labels do not exist, users have no clear signal that a document is sensitive. If DLP is sitting in test mode forever, the business has a policy theatre problem, not a protection model.

I would rather see a small, controlled Copilot pilot in a tidy tenant than a broad deployment in a messy one. Start with a few users. Pick real scenarios. Meeting follow-ups in Teams. Draft replies in Outlook. Summaries from known SharePoint libraries. Then watch what happens. What worked? What surprised people? What data did Copilot find that no one expected?

Guardrails should be practical

The best guardrails are boring. That is a compliment.

Require MFA. Tighten external sharing. Review old guests. Publish simple sensitivity labels. Apply DLP where it matters. Use Restricted SharePoint Search where the content estate needs time to be cleaned up. Train users to verify answers before sending anything to a client. Make it normal to say, “Copilot drafted this, but I approved it.”

That is not anti-AI. That is responsible adoption.

The businesses that do this well will not be the ones with the flashiest prompts. They will be the ones that treat Copilot as part of their operating model. Policy, security, people and process all moving together.

My view is simple. Do not start with the licence. Start with the trust model. If you can trust the identity, the data, the permissions and the controls, then Copilot becomes much easier to use with confidence.

AI governance is not there to slow the business down. It is there so the business can move without pretending the risks are someone else’s problem.

When the Product Is the Answer

MAI_d2738865c0ceccd4

A few years ago, I paid real money for an online course about something I could have googled. Not because the information wasn’t out there — it was — but because someone had packaged it up into a tidy sequence, with a PDF checklist at the end. That felt like value. I’d trade some cash for the shortcut.

I’m not sure that trade still makes sense.

There’s a question worth sitting with if you sell courses, run a newsletter, or operate any kind of advice business: what exactly are you selling? If the core of your offer is “I know how to do X, and for a fee, I’ll explain it to you,” then you’re competing — right now, today — with a chat interface that will do the same thing for free, in plain language, at any hour, and answer every follow-up question without sighing.

That’s not pessimism. It’s just arithmetic.

The Commodity Shift

The thing is, knowledge transfer was already becoming cheaper. YouTube, forums, documentation sites — the raw material was free or nearly so long before any of us had heard of a large language model. What the structured course or the curated newsletter offered was organisation and trust. Someone had done the sorting for you.

AI has now taken that arrangement apart. Ask Copilot in Microsoft 365 how to build a pivot table, how to structure a client proposal, how to read a balance sheet, or how to write a meeting agenda — and you’ll get a clear, accurate, step-by-step answer in seconds. It knows context. It remembers what you asked two prompts ago. It adjusts when you say “that’s too complicated, simplify it.” The experience of learning from it is genuinely conversational in a way that a pre-recorded video module is not.

For anyone whose business rests primarily on the instruction layer — here’s how to do the thing — that shift deserves honest attention.

What Doesn’t Commoditise

I don’t think this means the advice economy is finished. But I do think it clarifies what was always the actual product, beneath the packaging.

What an AI won’t give you is accountability. It won’t check whether you actually implemented what it told you, or notice that you’ve been stuck on step three for six weeks because there’s something uncomfortable underneath the technical question. A good advisor, coach, or community does that.

It also won’t give you judgement built from real exposure to your specific industry, your clients, your context. I can ask Copilot about pricing strategy for an MSP, and I’ll get a reasonable answer. But the answer from someone who has personally renegotiated forty MSP contracts and remembers what went wrong — that carries a different weight.

The value proposition that survives isn’t “I’ll explain the concept.” It’s “I’ve seen this pattern before, here’s what it usually means, and here’s what I’d actually do.” That’s the part that takes years to earn and can’t be scraped.

What I’m Watching

My own approach has shifted. The things I now put into writing — whether that’s a post, a session, or anything structured — I try to hold to a higher bar than “here’s how to do X.” Anyone can get that from Copilot. What I’m aiming for is the observation behind the explanation: the why, the tradeoff, the thing that only becomes clear once you’ve been surprised by the edge case.

The knowledge economy isn’t dying. It’s just shedding the parts that were never really the point.

Stop Hoping Your Team Will “Figure Out Copilot”

mastery-cover

Microsoft 365 Copilot is one of the most powerful productivity tools Microsoft has ever released. Yet many organisations are still struggling to get consistent value from it.

Why?

Because giving people access to Copilot is not the same as teaching them how to use it effectively.

The reality is that most users start with enthusiasm, ask a few basic prompts, get mixed results, and then drift back to their old ways of working. The opportunity remains, but the outcomes never arrive.

That’s exactly why I created the Microsoft 365 Copilot Team Training Guide.


Moving Beyond Random Prompting

Successful Copilot users don’t rely on luck.

They understand:

  • How to structure prompts

  • Which Copilot tool to use for specific tasks

  • How to refine outputs

  • How to work with Copilot rather than simply ask questions

  • How to safely use AI within a business environment

This guide provides practical, repeatable approaches that teams can use every day rather than theoretical discussions about AI.

What’s Included?

The guide covers:

  • Microsoft Word

  • Outlook

  • Teams

  • PowerPoint

  • Excel

  • Copilot Chat

You’ll also learn practical prompting techniques, prompt frameworks, governance considerations, adoption strategies, and ways to measure success across your organisation.

Unlike many AI resources that focus on concepts, every principle is designed to be immediately applied with examples, expected outcomes, tips, and common mistakes to avoid.

Designed For Real Teams

Whether you’re:

  • A business owner investing in Copilot licences

  • An IT manager responsible for adoption

  • A team leader looking to improve productivity

  • An MSP helping clients get value from Copilot

  • A user wanting to work smarter

This guide provides a structured path to getting measurable results from Microsoft 365 Copilot.

Copilot Success Requires More Than a Licence

The organisations seeing the biggest productivity gains are not necessarily those with the most licences.

They’re the organisations that invest in education, consistency, and repeatable ways of working.

The good news is that learning how to use Copilot effectively doesn’t need to be complicated. With the right guidance, your team can quickly move from experimentation to real business outcomes.

Ready to Become a Copilot Champion?

If you want a practical, no-nonsense guide that helps your team use Microsoft 365 Copilot more effectively, then the Microsoft 365 Copilot Team Training Guide is for you.

Get your copy here: Microsoft 365 Copilot Team Training Guide

Stop experimenting. Start mastering Copilot.

Your organisation has already invested in AI. Now it’s time to make sure everyone knows how to use it.

The Content That Changes What You Want

MAI_65487d8c9a3c1631

For years I measured a good session by how much I crammed into it. Steps, screenshots, settings, the lot. If someone walked out with a longer to-do list than they arrived with, I’d done my job. I don’t see it that way anymore.

The shift happened quietly. I started noticing that the sessions people remembered weren’t the ones where I taught the most. They were the ones where something clicked and a person suddenly wanted to work differently. The instruction was almost beside the point. What stuck was the wanting.

Knowing how isn’t the same as wanting to

You can show someone exactly how to do a thing and watch them never do it. We’ve all run that webinar. The hands-on steps are perfect, the recording goes up, and three weeks later nothing has changed in their business. The knowledge landed. The desire never did.

I see this constantly with Microsoft 365 Copilot. I can demonstrate how to summarise a long thread in Outlook, how to pull the action items out of a Teams meeting, how to draft a first version of a proposal in Word. People nod. They get it. But the ones who actually change are the ones who leave thinking, “I never want to scroll through forty unread emails by hand again.” That sentence isn’t instruction. It’s appetite. And appetite is what does the work after the session ends.

The job is to make the better way feel obvious

So now, when I’m putting together a workshop or a video or even a short email to a client, I’m not really asking what I should teach. I’m asking what I want them to start wanting once it’s over.

That changes how I build the thing. Instead of opening with a feature, I open with a moment they recognise — the Friday afternoon spent rebuilding a status report they’ve already written four times this month. Then I show Copilot pulling that report together from the documents already sitting in their SharePoint, in about a minute. I’m not listing what it can do. I’m letting them feel the gap between how they work now and how they could. Close that gap in front of someone and they don’t need convincing. They’ve already decided.

The same logic runs through everything I put out. A YouTube clip, a Loop page I share with a patron group, a single line in a newsletter — they all work better when they leave a person slightly dissatisfied with their current way of doing things, in the best possible sense.

What I’m watching now

The tooling has never been easier to demonstrate. Copilot will happily show off. The harder, more interesting question is whether the content around it makes anyone actually want a different working life.

That’s the part I keep returning to. Teaching the steps is the easy half. Teaching someone to want the outcome — that’s where the real change starts, and it’s the bit I’m still learning to do better.

The AI question worth sitting with

MAI_0e92852ba5b3a913

A while back, over coffee, someone asked me which clever AI trick had impressed me most this year. I disappointed them. The thing that stuck with me wasn’t a trick at all. It was a question I now ask myself most afternoons: of everything I did today, how much of it didn’t actually need me?

It’s an uncomfortable question, and it should be. Sit with it long enough and you start noticing how much of your week is just movement — chasing the same status update, rewriting the same kind of email, copying numbers from one place to another. Honest work, sure. But not the work only you can do.

The instinct to hold on

Most people, when they feel AI getting close to their job, pull their work in tighter. They guard it. They want to prove the human bit still matters. I understand the reflex, but I think it’s backwards. The value was never in the doing. It was in knowing what was worth doing in the first place.

The people I admire most are doing the opposite. They’re hunting for things to hand over. They treat every repetitive task as a candidate for handover, not a badge of how busy they are. When a reply lands that says the same thing they’ve written forty times, they don’t write it again — they ask Copilot in Outlook to draft it and spend their attention on the one paragraph that’s genuinely new. When a long Teams thread needs catching up on, they let Copilot summarise it and read the summary, not the forty messages.

That’s not laziness. That’s deciding where your judgement is actually worth spending. Every hour you claw back from the routine is an hour you can point at something that actually moves the business.

Hand it over once, properly

Here’s the part most people miss, though. Handing a task to AI once is a parlour trick. The real shift happens when you stop doing the task and start building the thing that does the task.

I’ve watched a business owner take the monthly client report — the one that ate a Friday afternoon every month — and rebuild it as a flow. Power Automate pulls the numbers, Copilot drafts the commentary in the same tone she’d use, and the whole thing lands in a SharePoint folder before she’s had her second coffee. She doesn’t make the report any more. She looks after the thing that makes the report.

And that’s the bit worth understanding. Once the work runs on its own, your job changes. You’re no longer the one producing the output — you’re the one watching the machine that produces it, and adjusting it when it drifts. When the tone goes a bit flat, you fix the instructions, not the document. When the numbers look off, you check the flow, not the spreadsheet. Your effort moves up a level.

That’s where the real return sits. Not in doing the task faster. In stepping back from the task entirely and tending the system instead.

What I’m watching now

None of this happens by accident. It takes a deliberate habit of asking, over and over, what you did yesterday that you shouldn’t be doing tomorrow. Most people never ask. They’re too busy doing. And the irony is the busier you are, the more of your day is probably the kind of work you could give away.

So I’ll leave you with the same uncomfortable question. Look back at yesterday. Find the hour a machine could have run without you. Then go and build the thing that runs it — and free yourself up for the work that actually needs a human in the chair.