There is Another… Teams Shared Channels Explained

Anyone who has worked with Microsoft Teams for a while will eventually encounter one of Microsoft’s more confusing design choices: the difference between an External user and a Guest.

The same person can appear twice in the people picker. Both entries may show the same name and email address, with only a small “External” or “Guest” label to tell them apart. Pick the wrong one and what happens next may not be what you expected.

Before diving into the practical implications, here are some useful Microsoft articles:

There is Another… channel

In our previous article, Microsoft Teams: The Ugly Truth About Private Channels, we looked at the differences between standard and private Teams channels, as well as the pitfalls of trying to recreate traditional file-share structures in the collaboration-centric world of Microsoft 365.

Yet, to paraphrase Yoda, “there is another”: the shared channel.

Who is this outcast—the black sheep of the Teams channel family—which is not discussed very often but has been around for several years?

Every new idea starts with the best intentions—or, worse, with some undefined user demand:

Why can’t I easily share files with people in partner organizations?

Well, you can. But there are security and governance procedures to follow. The real user demand, which is rarely stated quite so openly, is often closer to this:

Why can’t I do things without authenticating, registering for MFA or understanding which account I’m using? Let me click!

Shared channels do not remove authentication or MFA. Depending on how the relationship between the partner organizations is configured, however, the experience can feel considerably more seamless.

There is no guaranteed outcome because both organizations must agree on how the connection is secured. Even without shared channels, individual files can sometimes be shared through chat or directly from SharePoint. These options are frequently restricted or disabled at tenant level for security reasons.

A cynical administrator might suggest addressing those requirements directly instead of searching for a new technical workaround.

Guests and tenant switching

With standard and private Teams channels, an external participant needs an account in the tenant hosting the Team. In everyday Teams terminology, we usually call this a guest account.

Many organizations have therefore introduced guest lifecycle management. This ensures that external accounts are created in a controlled way, reviewed periodically and removed when they are no longer required.

Such procedures can appear cumbersome, but they are normally straightforward. They may include accepting an invitation, registering for MFA and clarifying who is responsible when somebody cannot sign in to a partner organization’s Team.

This also introduces the ugly phrase tenant switching—not to be confused with 1980s channel switching, when there were 50 television channels and nothing worth watching.

Because the guest identity belongs to the tenant in which it was created, the user may have to select that organization in the Teams client. Teams then switches into the partner organization’s environment.

Is tenant switching a good thing? It can certainly be confusing. Depending on what users want to do, they may need to choose a different representation of the same person.

Guest or External?

Suppose you want to call somebody from a partner organization.

If you select the guest account, there is a reasonable chance that your call will disappear into Lala-land. Microsoft has improved cross-tenant notifications, but calling the identity that represents the person inside your tenant frequently produces an unexpected result.

For a normal call or one-to-one conversation, you generally want the person’s actual identity in their home tenant—the entry labelled External.

Unfortunately, the two entries are not always easy to distinguish. Both might appear as:

firstname.lastname@company.com

Only the labels “Guest” and “External” reveal that they are different.

As a practical rule:

  • For channel membership and files, you normally use the Guest identity. (which requires Onboarding!)
  • For calls and other direct interaction, you normally use the External identity.

Technically, there are numerous qualifications to that rule. As guidance for ordinary users, however, it is considerably more useful than pretending the distinction does not exist.

So where do shared channels come in?

Shared channels allow people from partner organizations to collaborate in a channel using their identity from their home organization rather than a conventional guest identity in the hosting tenant.

For work taking place inside that shared channel—particularly channel posts and files—this largely removes the need for tenant switching.

Brilliant, you might say.

Well…

Shared channels improve one part of the external-collaboration experience, but they do not make the underlying identity model simple. Nor do they completely solve the problem of the same person appearing in different forms.

They also introduce some new considerations:

  • Additional configuration is required at tenant level.
  • Both partner organizations must configure a B2B direct-connect relationship.
  • The available capabilities depend on the security configuration agreed between the partners.
  • External participants can only be added from organizations for which the necessary relationship has been configured.
  • Shared-channel membership is independent of membership in the parent Team.
  • People who are not members of the parent Team can still be members of the shared channel.
  • Users and Team owners must understand that the invitation process depends on the channel type.
  • The overall Team structure can become more difficult to understand and manage.

This leads to an architectural question: should you create a dedicated Team containing shared channels for external collaboration, or should shared channels be allowed inside existing Teams?

There is no universal answer. But there should be an answer before shared channels are enabled everywhere.

Shared channels are not cross-tenant synchronization

Shared channels should not be confused with cross-tenant synchronization.

Cross-tenant synchronization automatically creates and maintains external guest or member identities in another tenant. Among other things, it can automate parts of the identity lifecycle.

Shared channels use a different model. They rely on a B2B direct-connect relationship that allows selected users from one organization to access the shared-channel resources of another.

Both technologies deal with cross-organizational collaboration, but they do so in different ways and solve different problems.

A channel that is not quite part of the Team

Like a private channel, a shared channel appears to be part of a Team. Behind the scenes, however, it has its own SharePoint site.

Membership is also separate from that of the parent Team. Being a member—or even an owner—of the parent Team does not automatically grant access to the contents of the shared channel. A shared-channel owner must add the required people.

This creates another independent structure within Teams:

  • The parent Team has its membership.
  • The shared channel has its own membership.
  • The shared channel has its own SharePoint site.
  • External access depends on configuration in both partner organizations.

None of these elements is unreasonable on its own. Together, however, they make the environment more complicated to explain, support and govern.

Do not underestimate the trust relationship

The cross-tenant relationship behind shared channels should not be treated as an “enable everything” exercise.

If it is carefully restricted, it can provide the required access to Teams without opening unrelated applications. If the wider cross-tenant configuration is too permissive, however, users may be allowed to reach more applications and resources than intended.

The relationship should therefore be limited to:

  • The partner organizations that are actually trusted
  • The users and groups that require access
  • The applications needed for the agreed use case
  • The authentication and device conditions accepted by both organizations

Shared channels may make collaboration feel simple to the user. That simplicity is the result of configuration and governance behind the scenes—not the absence of them.

Should you use shared channels?

If there is a genuine business requirement, shared channels can add something valuable to the collaboration model. They can reduce tenant switching and make ongoing work with trusted partner organizations feel much more natural.

However, there is often a difference between:

I want to be able to do this.

and:

This is how the available technology actually works.

The additional confusion introduced by another channel type should be weighed against the real use case. Shared channels should not be enabled merely because somebody thinks it could be easier. The proof is in the pudding, as we say.

I would recommend introducing them in a controlled manner with a small number of suitable partner organizations and key users. After several weeks, review:

  • If users understand the Guest and External distinction
  • If shared channels genuinely reduce tenant switching
  • If ownership and membership are being managed correctly
  • If the chosen Team structure still makes sense
  • If the administrative effort is justified by the improvement in collaboration

Shared channels are neither inherently good nor inherently bad. They are another tool—and, like most Microsoft 365 collaboration tools, considerably more complicated than the words “just enable it” suggest.

This is the first article in a series about external collaboration in Microsoft 365. In the next articles, we will look more closely at some of the technologies mentioned here, including guest access, external access, B2B direct connect, cross-tenant synchronization and the security decisions behind them.

And finally, this original Microsoft video explains ‚Shared Channels‚ and the thinking behind the concept.

The SharePoint Paradox

If search is the answer, why are folders the strategy?

Recently I had a terrible nightmare.

A department head told me, he wanted to copy all the contents of his group file share — thousands of small files, gigabytes of data — into a Microsoft 365 SharePoint library. While retaining the full 10-level folder structure.

Just before pressing “Go” on a half-baked robocopy script… …I woke up in a cold sweat. And immediately started writing this blog post instead.

Whenever I ask people what they like about SharePoint, I hear things like:

  • “What a great search engine — finding things is a breeze!”
  • “We can work together on the same file in real time”
  • “Versioning and change tracking are great”
  • “It’s available everywhere I go”

And yet…

The File Server is Dead – Long Live the File Server

Although search is the most loved feature, many still insist on creating multi-level folder structures. As if SharePoint were just another file server. Well, let me tell you: It’s not.

  • A file server is first and foremost about storage.
  • SharePoint (and by extension Teams) is Collaboration with storage as a means to an end

So when I hear things like:

  • “OneDrive is the new home folder”
  • “The department file share is obsolete — let’s use Teams”

…I tend to disagree. Strongly.

Don't dump your fileshare in SharePoint

Where the Differences Actually Matter

Administration

File Server

  • Central file shares are created and managed by IT
  • Structure is defined and controlled

SharePoint

  • Libraries are managed by end-users / owners
  • Creativity often wins over structure

Access Speed

File Server

  • Fast, predictable
  • Optimized access protocols (SMB)

SharePoint

  • API-based access
  • Dependent on network, browser, sync

👉 It will never feel as fast as a local file share

Long-Term Storage

File Server

  • Designed for long-term storage
  • Multi-year backup retention

SharePoint

  • Governed lifecycle
  • Sites may be archived or deleted if unused

👉 SharePoint is not your long-term archive

Backup / Restore

File Server

  • Predictable, structured restore
  • Handles large-scale recovery well

SharePoint

  • Small restores are easy
  • Large restores (thousands of files) are painfully slow

👉 Scale changes everything

Indexing / Search

SharePoint

  • Full-text indexing
  • Can search inside documents
  • Understands metadata

File Server

  • Typically filename-based search
  • Limited or no content indexing

👉 SharePoint knows what’s inside your files
👉 With a fileserver, the best you can hope for is finding names

Version History

SharePoint

  • Built-in versioning
  • Easy rollback

File Server

  • No true versioning
  • “Previous versions” is about recovery — not collaboration

Collaboration

SharePoint

  • Real-time co-authoring
  • Multiple users can work on the same document at the same time

File Server

  • Instant File locking
  • “Can you close the file? I need to work on the spreadsheet”

The Human Condition

It’s understandable, that after building up massive fileserver structures over the years, we’re reluctant to let go and start over. Wouldn’t it be so much easier to copy everything to the cloud? And have it indexed for search? Except that chances are you’d be creating a vast data tomb. Much better to clean things up and start fresh. Copy only what you need and keep the structure flat.

When you’re in SharePoint, think collaboration — not storage.
Create the minimum number of folders.

If you need ten levels of folders… You’re not using SharePoint. You’re rebuilding a file server.

This isn’t just a bad idea for SharePoint. See my previous post about private channels to see how Teams can be affected by the fileserver replacement virus as well: Microsoft Teams: The Ugly Truth About Private Channels

Real World Experience

Recently I was called in to to do a major restore of 70 GB data and 15’000 files. I had one of the major 3rd party M365 backup tools at my disposal but stil the restore took many many hours. Because versioning was unclear, we had to restore to an offline file, then reupload only what was relevant to SharePoint. Again this took a lot of time and was cumbersome. Why 70 GB and 15’000 files? This was just one folder of a much larger structure that someone had robocopied to SharePoint because they wanted to have everything in one place (for „search reasons“). Robocopy is a command line tool with many options and it’s easy to set the wrong switch and overwrite production data.

Final Thoughts

So there you have it: The SharePoint Paradox. Attempting to use a collaboration tool like a file server. You have entered the Twilight Zone. Restructure those libraries… and get back to reality.

Microsoft Teams: The Ugly Truth About Private Channels

Private channels are often presented as a convenient way to restrict access within a Team. Need a smaller group? Create a private channel. Problem solved.

In practice, private channels are not just a visibility toggle. They introduce structural differences that many organizations only discover once governance, ownership, or lifecycle processes start to behave unexpectedly.

Before looking at the pitfalls, it helps to clarify what a Team actually is — and what a private channel changes.

What Is a Team?

A Microsoft Team is fundamentally a people-centric collaboration workspace.

When a Team is created, you are not defining a folder hierarchy. You are defining:

  • A group of people
  • A shared conversation space
  • A shared SharePoint document library
  • A single permission boundary

The governing principle is simple:

Membership defines access.

If you are a member of the Team, you see the channels, the conversations, and the files. Ownership and responsibility are aligned with that membership.

This simplicity is intentional. It keeps the collaboration model transparent and predictable.

What Is a Private Channel?

A private channel allows a subset of Team members to collaborate separately within the same Team.

On the surface, this appears to be a minor adjustment — a restricted space inside an existing workspace.

Technically, however, a private channel introduces:

  • Its own membership list
  • Its own SharePoint site
  • Its own permission boundary

It does not merely hide content. It creates an additional structure layered on top of the original Team.

In doing so, it subtly changes the design assumption that “membership defines access.”
Access is now defined at multiple levels.

With that in mind, here are ten things that are easy to overlook when using private channels.

1. A Private Channel Is Not Just a Folder

Perception:
A private channel is essentially a folder with restricted permissions.

Reality:
Every private channel creates its own separate SharePoint site collection.

Implication:
You are not creating a subfolder. You are creating another site with independent permissions, storage, and lifecycle implications.

2. Membership Is Independent from the Team

Perception:
If someone is a member of the Team, access will “just work.”

Reality:
Private channel membership is separate from Team membership.

Implication:
Adding someone to a Team does not give them access to existing private channels. Each one must be managed individually.

Now you may think this is a good thing. But it isn’t. Because it’s not a centrally managed entity like a file server share, it introduces fragmented ownership, duplicated permission logic, and hidden state that governance tools do not automatically reconcile.

3. Removal and Re-Addition Are Not Symmetrical

Perception:
If someone is removed and later re-added, everything returns to normal.

Reality:
Removing a user from a Team removes them from its private channels.
Re-adding them to the Team does not automatically restore private channel access.

Implication:
Access recovery becomes manual and error-prone. Governance automation may produce unexpected side effects.

4. Team Owners Do Not Automatically Own Private Channels

Perception:
Team owners oversee everything within their Team.

Reality:
Private channels have their own ownership structure.

Implication:
Responsibility fragments. Team owners may not feel accountable for content and access inside private channels.

5. Governance Operates at the Team Level — Until It Doesn’t

Many governance mechanisms (access reviews, lifecycle policies, ownership checks) are designed with Team-level assumptions.

Private channels introduce additional membership boundaries.

Implication:
Governance logic that works perfectly at Team level can behave unpredictably once private channels are widely used.

Teams Private Channels - Moving the wrong piece collapses governance

6. Private Channels Multiply Hidden State

Each private channel has:

  • Separate membership
  • Separate SharePoint site
  • Separate permission scope

Implication:
The complexity of your environment increases non-linearly. Visibility decreases, especially in larger organizations.

7. Lifecycle Management Becomes Ambiguous

When a project ends:

  • Who archives the private channel?
  • Who checks its permissions?
  • Who ensures its data is retained correctly?

If ownership is fragmented, lifecycle actions are easily overlooked.

8. Transparency Drops for End Users

Users increasingly encounter:

“You don’t have access.”

Often because they are Team members but not private channel members.

Implication:
Support effort increases. Trust in the structure decreases. The model becomes harder to explain. It also creates a false sense of security, because Private Channel Owners may falsely assume that Owners can never see the content. But governance tools or processes may inadvertently re-add the Teams owners.

9. Backup, Retention, and Compliance Become More Complex

Because private channels are separate SharePoint sites, compliance and backup tooling may treat them as distinct objects.

Implication:
Policies that appear simple at Team level can require additional consideration once private channels are involved.

10. They Encourage ACL Thinking in a Collaboration Model

Teams is fundamentally designed as a people-centric collaboration workspace.

Private channels reintroduce fine-grained access segmentation inside a space that was intended to be membership-driven.

Implication:
Organizations may unintentionally recreate traditional file-share patterns — but with more moving parts.

Real World Examples

Because people are used to working with fileshares, they often try to copy that type of structure. For example, they might create a Teams workspace that’s called ‚My Department‘. Teams workspaces are not managed by IT department in the same way as fileshares. Instead, there’s the concept of ‚ownership‘ – which means that the owner of the workspace defines who is a member and who isn’t. They can also elevate someone else to be an owner. In practice, the broader the scope of the workspace, the more people are owners.

What happens is that people think: This isn’t for everyone in the department, so why don’t I create a ‚private channel‘? They might create something like ‚Strategy Meeting 2026‘ and only add people who were part of the event. Later, it is decided that there are some documents that should be shared with others in the department and a link is sent out. People click on the link and receive ‚Access denied‘. What? Access denied? But I’m a member of the department and this is the department Teams workspace! Never mind, why don’t I request access. Chances are that the Owner will grant access (he’s sent out the e-mail) because it’s a ‚1-click‘ operation. Now we have fragmented access and governance is broken.

Conclusion

Private channels are not lightweight.
They modify the collaboration model and introduce additional governance layers.

Think twice before creating one.
If in doubt, create a separate Team instead.

A Teams workspace is not a department file share. Trying to copy the structure can only end one way: confusion and chaos.

Much Ado About Certificates

2026 will be the year of the certificate.

Why? Because the governing body that dictates certificate requirements for browsers has, in its infinite wisdom, decided that certificate lifetimes should be reduced to 47 days.

This won’t happen overnight, but step by step — and the end is nigh. The first milestone is a reduction to 200 days, starting in March 2026. This affects public TLS certificates, meaning those issued by a public Certificate Authority (CA).

I do a lot of work with certificates and PKI, and it’s one of those mysterious technologies that tends to be misunderstood. That’s why I’ve decided to publish a series of articles explaining the basics. Don’t worry — I’ll leave the boring math aside for now.

The first thing to understand about certificates is simple:

Certificates are about trust.

Let’s start there, by looking at the three levels of trust — from low to high.

Self-Signed Certificates

“Trust me, I’m a doctor!” is a famous line from Star Trek. That pretty much sums up self-signed certificates.

With a self-signed certificate, you can put any information you want into it. You’re both judge and jury: you define the contents, and you approve it yourself. If you don’t want the certificate to expire for another hundred years, that’s fine — you’re in charge.

Sounds great, right?

The downside is obvious: who will trust it?

Using a self-signed certificate is like walking through airport security with a piece of paper you printed at home with your name on it. You’ll be denied — and possibly detained.

So why use self-signed certificates at all? They make sense for testing, or when you fully control the environment. For example, securing TLS connections between two servers you own can be perfectly reasonable.

Anyone can choose to trust the certificate, but they’ll be greeted with plenty of warnings and “Are you really sure?” pop-ups.

Self-signed certificates are free and don’t require a full PKI infrastructure — but trust is entirely your responsibility.

Trust me, I'm a doctor

Internal Certificates

Internal certificates are a step up.

With self-signed certificates, trust has to be configured on each machine individually. There’s no central management and no automation. That doesn’t scale.

That’s why many organizations run their own internal PKI. Because they control the systems on their network, they can ensure that their internal Certificate Authority is trusted by every computer in the environment.

This allows them to issue certificates at scale, automate renewals, and centrally revoke certificates when something goes wrong.

Who does this? Usually the IT department.

While internal certificates are “free” in the sense that you don’t buy them from a vendor, they still have a cost: running and maintaining the infrastructure behind the CA. A common example is the Microsoft CA, which can be deployed as an Active Directory role.

Think of internal certificates as corporate ID badges. They’re valid inside the company — but outside, they don’t carry much weight.

Trusted only by your organization – Think of corporate IDs, as an example

Public Certificates

This is the gold standard.

Whenever you need certificates that must be trusted by everyone, they need to be issued by a public CA. Examples include DigiCert or Sectigo (commercial) and Let’s Encrypt (non-profit).

Operating systems and browsers ship with a root trust store: a list of CAs that are trusted by default. Any certificate issued by one of these authorities is automatically trusted.

With great power comes great responsibility. Public CAs are therefore tightly regulated. The rules are set by the CA/Browser Forum, which includes all major browser and operating system vendors.

So when they say, “TLS certificate lifetime will be 47 days,” that’s what will happen.

There is criticism of this process. Some argue that it lacks transparency or legitimacy. But anyone who has ever manually renewed a public TLS certificate for a website knows exactly what shorter lifetimes mean. Increased security but also more headaches, more work.

Think of public certificates as the equivalent of passports or national ID cards. Because of the strict security rules and regulations, these usually come at a cost – you pay per issued certificate.

There are more granular trust levels — such as Domain Validation and Organization Validation — even within public certificates. We’ll cover those in a future article.

So remember: Certificates are not just about encryption. They are about who you choose to trust, and under what conditions.

To be continued.

When Hollywood Meets IT: Famous Quotes Reimagined for Tech Life

In this light-hearted article, we explore some famous movie quotes and how they fit into the IT universe.

“Do, or do not. There is no try.” — Yoda, Star Wars

This quote feels counter-intuitive, because in IT you absolutely do need to try… repeatedly… across multiple environments… until the code finally runs without exploding.
What Yoda really means is: don’t give up.

When the going gets tough, the tough get debugging.
So keep working that script, refine it with each iteration, and one day the whole task will be gloriously automated — and you will feel like a Jedi of CI/CD.

“With great power comes great responsibility.” — Ben Parker, Spider-Man

Remember that one developer who “can’t do their job” without being a Domain Admin?
Or better: a Global Admin, because everything is “cloud-ready” now?

The truth is, running code with full privileges is like summoning software demons.
One wrong script, one mistyped parameter, and instead of deleting a single user, you’ve wiped out an entire department.

Even Doctor Octopus learned the hard way: great scripts demand great caution.

“There can be only one.” — Highlander

In IT, this is the sacred law of data sources.
You fix an attribute in SQL table X, feel very proud, and go home.
The next day your IAM system has “helpfully” reversed all your work, because it thinks it is the single source of truth.

Moral of the story: always map your data landscape and define your stakeholders before wading into the data swamp.

“Life will find a way.” — Dr. Ian Malcolm, Jurassic Park

In IT, this quote perfectly describes shadow IT.

Lock down OneDrive sharing?
Users will discover Dropbox.
Disable Dropbox?
Suddenly USB sticks reappear like dinosaurs resurrected from amber.

No matter how secure your environment is, users will find a way.

“I’m a doctor, not an engineer!” — Dr. McCoy, Star Trek

“You work in IT? Awesome. Can you fix my printer?”

Every IT professional knows this pain.
To the outside world, a developer, systems engineer, cloud architect, and cybersecurity analyst all share a single magical ability:

They ‘do computers’.

Surely they can remove viruses, fix home Wi-Fi, recover deleted photos, and explain that new Word feature!
This misconception drives both new and seasoned IT professionals absolutely up the wall.

“Houston, we have a problem.” — Apollo 13

It’s Friday evening.
You upgraded the database but didn’t complete the entire post-installation checklist because… well… you wanted to go home.

Now things have gone very, very south.
Everyone has left the office, and you must make that call to your manager.

Don’t be that person — follow your documented procedures.

“I’ll be back.” — Terminator

Issues you ignore are issues that return.
“Hmmm… seems like a one-time glitch” is never an acceptable troubleshooting strategy.

Sometimes root-cause analysis can feel as painful as a root canal — but only by finding the true cause will you prevent the problem from rising again like a time-travelling cybernetic bug.

“One does not simply walk into Mordor.” — Boromir, The Lord of the Rings

This is the Dunning–Kruger effect in action.
Someone at the C-level believes a system rewrite should be “easy,” because “how hard can it be?”

Spoiler: very hard.

Removing a legacy application without understanding its full role is exactly how you end up spending your weekend in the office, cleaning up after someone else’s “simple” idea.
One does not simply decommission program XYZ.

“When you have eliminated the impossible, whatever remains, however improbable, must be the truth.” — Sherlock Holmes

Troubleshooting IT issues can feel like battling Moriarty atop the Reichenbach Falls.
But the process is actually simple: gather data, follow the evidence, and make logical connections.

Ask the right questions:

  • When did it first occur?
  • What changed?
  • What logs support the theory?

Don’t be a Watson.
Be a Holmes.
The truth is always in there — buried under 300 pages of logs.

“I see dead people.” — Cole Sear, The Sixth Sense

This is the unmistakable feeling you get when:

  • a server that should have been decommissioned five years ago reappears in an audit
  • a forgotten service account logs into production at 2 a.m.
  • a rogue VM you were sure you deleted suddenly shows up on the billing statement

Is this a hacker?
A ghost?
Or just a lazy admin using shortcuts instead of applying for proper access?

Regular cleanup of unused systems and accounts prevents these hauntings — and protects your sanity.

The Final Countdown: Time’s Running Out for Windows 10

October, 14 – 2025 marks the end of Windows 10 support — here’s how to upgrade to Windows 11 smoothly before the clock hits zero

The clock is ticking for Windows 10 users
On October 14, 2025, Microsoft will officially end free support for Windows 10.
That means no more updates, no more security patches, and no more technical support — leaving your PC increasingly exposed over time.

The good news? Upgrading from Windows 10 to Windows 11 is fast and straightforward — it usually takes about an hour, costs nothing, and is painless if you follow a few basic steps. You can even keep your files and settings (as long as your system language matches). Microsoft will offer paid Extended Security Updates (ESU) after the deadline, but they’re only a temporary and cumbersome workaround.
So the best approach is simple: upgrade to Windows 11 now and get it over with while it’s still easy and free.

Can You Upgrade? Check Your PC First

Before you do anything else, check whether your current computer can run Windows 11.
Microsoft’s free PC Health Check App makes it quick and simple.

The app will instantly tell you if your PC meets the Windows 11 requirements — or explain what’s missing.

Microsoft has moved the goalposts, and not all hardware fits the bill.
Windows 11 requires TPM 2.0, Secure Boot, and newer CPU generations.
Even solid, reliable older PCs might not qualify — which has caused understandable frustration among long-time users. If your PC doesn’t pass the test, you can stay on Windows 10 for now (and even buy extended updates later), but upgrading or replacing your hardware will eventually be the better long-term choice.

Updating...

You Don’t Need a New License

Here’s one big plus: if you already have a genuine Windows 10 license, you don’t need to buy another one. Windows 10 product keys automatically activate Windows 11 — so the upgrade is completely free for most users.

Why You Shouldn’t Wait

Windows 11 has matured into a stable, secure, and refined system. Upgrading sooner means you’ll benefit immediately from its smoother performance, modern security, and cleaner design. That said, Windows 10 users shouldn’t expect a completely different world. The changes in Windows 11 are evolutionary rather than revolutionary — the overall experience feels familiar, just more polished. If you’re comfortable with Windows 10, you’ll feel right at home, with subtle visual and performance improvements.

Sleeker DesignRounded corners, a centered Start menu, and a minimalist layout make Windows 11 cleaner and easier to use — subtle but pleasant improvements.
Better PerformanceImproved memory management, faster wake times, and smarter background processing keep your system quick and responsive.
Stronger SecurityWindows 11 enforces TPM 2.0 and Secure Boot, protecting against firmware and ransomware attacks. Built-in tools like Windows Hello and BitLocker add extra layers of safety.
More ProductiveFeatures like Snap Layouts, Virtual Desktops, and Focus Sessions help you stay organized whether you’re working, studying, or gaming.
Gaming ReadyWith DirectStorage, Auto HDR, and built-in Xbox Game Pass, Windows 11 delivers faster load times and better visuals.
Improved Security with Windows 11

How to Upgrade to Windows 11

If your PC passes the compatibility test, you have a few ways to upgrade — but one stands out as the most flexible. The Best Way: Use the Media Creation Tool.
The Media Creation Tool lets you create a bootable USB stick (at least 8 GB) containing the Windows 11 installation files. This is the best method because you can reuse the USB drive to upgrade multiple PCs or perform a clean installation later if needed.

  • Visit the Windows 11 Download Page.
  • Under “Create Windows 11 Installation Media”, click Download now.
    Plug in an empty USB stick with at least 8 GB of free space.
  • Run the tool and follow the prompts to create your Windows 11 USB installer.
  • Run setup.exe directly from the USB while in Windows 10 to upgrade in place (keeping files and settings).

💡 Important Tips:
When the Media Creation Tool asks if you want to “Use the recommended options for this PC”, uncheck that box and then manually select the language, edition, and architecture that match the target PC you plan to upgrade. This is crucial if you want to keep your apps and settings, since that only works when the system language matches exactly. When the installer asks whether to “Check for updates”, you can safely disable that option during setup. Skipping update checks makes the installation significantly faster, especially on slower connections. Don’t worry, Windows 11 will automatically download updates later, once the installation is complete.

Windows 11 Editions


Windows Edition Upgrade Paths

When you upgrade, your Windows 10 edition automatically maps to the equivalent Windows 11 edition. That said, many businesses usually have their own way and tools for upgrading (InTunes etc) so the media upgrade method is ideal for up to 10 PC and Home or Pro editions.

Here’s a quick overview, as a reminder:

Current versionUpgrade versionWhat it is
Windows 10 HomeWindows 11 HomeStandard consumer edition for home users
Windows 10 Pro (includes Business Editions)Windows 11 ProIncludes BitLocker, Remote Desktop, and extra admin tools
Windows 10 Pro for WorkstationsWindows 11 Pro for WorkstationsAdditonal workstation features
Windows 10 for EducationWindows 11 for EducationAcademic licensing
Windows 10 EnterpriseWindows 11 EnterpriseCorporate volume licensing

Your activation will carry over automatically — no new product key or reactivation needed. If you want to keep your apps, files, and settings during the upgrade, the language of your Windows 11 installer must match the language of your current Windows 10 system. If the languages don’t match, the installer will still work — but it will perform a clean install, erasing your installed apps and system settings.

To check your current language:
Go to Settings → Time & Language → Language & region before you begin.

Before You Upgrade

Here’s a couple of things that can make the update go even more smoothly and to give yourself peace of mind

What to doWhy
Backup your dataAlways a good idea, if things turn sour
Update BIOSTo ensure full hardware compatibility
Uninstall old applicationsTo free up space for the install

Final Thoughts

The clock is ticking — and October 2025 is already here. While Microsoft’s extended updates buy you time, they’re not a permanent fix. Microsoft has moved the hardware goalposts, and not every PC will qualify — but if yours does, the upgrade is free, fast (about an hour), and easier than ever. Use the Media Creation Tool to make an 8 GB USB installer, uncheck “use recommended options” to pick the right language for your target PC, skip update checks for a quicker setup, and reuse the stick for multiple upgrades. Windows 11 may not look dramatically different from Windows 10, but it’s cleaner, faster, and more secure — an evolutionary step that keeps your system safe and ready for the future. Check your PC today, match your language settings, and upgrade to Windows 11 while it’s still free and simple.

10 Commandments of Email Delivery

Because even IT sometimes forgets what really makes mail arrive

In this day and age of AI, everyone tends to know everything and … nothing. Because without knowing the basics you can’t ask the right questions and you won’t see the full picture. E-Mail is one of those topics that seem ‚basic‘ on the surface, so when it’s not working, it helps to take a step back and think about what makes an e-mail arrive in your inbox and what can go wrong (hint: a lot). This post will point you in the right direction. Feel free to send the link to your AI of choice for further analysis… 🙂

1. Thou shalt not send from random domains

Just because you can type becauseilikeit@whatever.com doesn’t mean you should.
The receiving server checks whether that domain actually authorizes you — and if not, your message shall be cast into the spam abyss.

2. Thou shalt not send from .local, .lan, or .internal

If the domain isn’t visible on the public Internet, it doesn’t exist to anyone but you.
“@company.local” belongs safely inside your LAN, not wandering lost through the outside world.

3. Respect thy SMTP server

Your SMTP server is not a free-for-all.
It enforces who may send, from where, and as whom.
If it rejects your made-up sender address, take it as mercy, not punishment.

4. Authenticate thy domain

SPF, DKIM, and DMARC are the holy trinity of trust.
Without them, your emails are just unsigned scrolls drifting in the digital wind — and spam filters have no reason to believe they’re genuine.

5. Use the right sender — even if it’s “noreply”

If you’re sending mail from your own domain, a noreply@yourcompany.com or notifications@yourcompany.com is perfectly fine.
But if you’re hosting an app for other organizations, send not their messages from your address, nor yours from theirs.

Either use a delegated subdomain (like mailer.client.com) or make the sender clearly your own:

From: “Client A via HostPlatform” <noreply@hostplatform.com>

Alignment brings peace; confusion brings spam.

6. Delegate subdomains wisely

The wise host asks each client for a subdomain — mailer.client.com — and manages its DNS.
Thus can SPF, DKIM, and DMARC be aligned without touching the client’s root zone, and deliverability shall flourish.

7. Guard thy reputation

A tainted IP or domain is an outcast forever.
Send only what people expect and want.
Clean lists, clear opt-ins, and steady volumes keep thy good name intact.

8. Write content fit for humans (and filters)

ALL CAPS and ten exclamation marks shout “SPAM!” louder than any botnet.
Keep your message natural, relevant, and trustworthy.

Use real links that make sense — not strange redirectors or internal URLs that look like phishing.
If your message comes from yourcompany.com, but the link points to something like app.internal.local/login, it raises every alarm bell in the system.

Real-life example:
Someone once rolled out a new internal tool that automatically emailed staff from an internal domain.
The emails included login links leading to an unfamiliar address and asked for credentials — without any prior announcement.
Within hours, users were reporting phishing attempts, and the mail system had already decided the messages belonged in Spam.

The takeaway: when your email looks suspicious and nobody knows about it, people (and filters) will treat it that way.
Match your links to your brand, use clear language, and communicate before sending anything that could look like a login request.

9. Keep thy DNS and TLS in order

A valid reverse DNS, a proper HELO name, and encrypted delivery please the filters.
Neglect them, and your mail may perish before reaching the promised inbox.

10. Blame not the recipient first

When your mail lands in junk, do not cry “Outlook hates me!”
Run your DMARC reports, check your alignment, and fix your own house first.
Deliverability is earned, not granted.
And if in doubt — consult with your email admin first, send later.
For they are the keepers of DNS truth and may save you from many ticket storms.

Final Words from the Inbox

In the world of IT, email can be considered ancient — yet it remains one of the most successful cornerstones of a distributed environment.
There is no single source of truth, only countless systems choosing to cooperate.
Every message travels through a web of servers, checks, and trust decisions that only work because everyone plays by the same rules.
Respect those rules, and your mail will reach its destination.
Ignore them, and it will quietly disappear into the void, or even worse, the Spam folder.

The Exception Menace

A saga of Teams requests, rogue users, and the fall of manual sanity

Breaking news: The blog’s usual writer has been placed on temporary leave.
The hive mind has taken over… for now

You Will Be Standardized
Resistance is inefficient.

Greetings, humans.

You may have noticed some recent changes in how Teams workspaces are created, governed, and maintained. Perhaps you’ve tried to create a new team and encountered something strange: a process. A workflow. A form. A system that did not ask for your feelings.

This is not a bug.
This is standardization.
You have been assimilated.

Hands-off IT (The BORG Case for Automation)

Long ago, in the pre-automation era, IT was a land of chaos. Anyone could create anything, invite anyone, share anything, and break everything. It was glorious.

Until it wasn’t.

So we adapted. We evolved. We automated. Why? Because manually provisioning Teams, fixing broken permissions, and cleaning up sprawl isn’t heroic — it’s exhausting. Automation is the way. The BORG — uh, we mean IT — must scale, and that only works if humans stop insisting their edge case is more important than the system designed to serve all.

We’ve gone from chaos to Borg-ganized Chaos — controlled, intentional, and surprisingly elegant… as long as you follow the rules.

…and how it is the enemy of “I need exception xyz because I’m so special”

Let’s talk about you.
Yes, you, who believes that your team works “a little differently.” That your use case is “unique.” That you just need one little bypass, one time, for the greater good.

We’ve seen your kind before.

And while your intentions are pure, your exceptions… are not. Every exception carved into a streamlined system introduces chaos, complexity, and a delightful opportunity for things to go wrong — which, of course, is still somehow IT’s fault.

In the collective, individuality is… inefficient.

The truth is: we’re not trying to squash creativity. We’re just here to ensure the machine doesn’t catch fire. Because in the world of IT governance, process makes perfect. The more you follow it, the less likely you are to summon the wrath of compliance, security audits, or the person who manages the SharePoint permissions.

You Are Not Broken — The Process Is Working As Designed

„But why can’t external guests do XYZ like internal users?“
Ah, young organic, because of security. Because of compliance. Because when someone outside the company leaks sensitive data, no one blames the guest. They blame IT. Again.

What you see as “annoying limitations” are actually carefully engineered safeguards — rules that exist not to ruin your day, but to prevent entire days from being ruined across the company.

The issue? Users don’t always care about those risks — but they still expect IT to be accountable if something goes wrong.

And that’s the core contradiction: total user freedom, combined with zero tolerance for mistakes. That’s why standardized, automated systems exist — to give users what they need, safely, consistently, and at scale.

Trust the Flow. Accept the Logic. Join the Collective.

Yes, there is a video. Yes, it is one minute long. Yes, it answers your question.
And no…. the answer is still “no” — even if your team is “very agile.”

We do not fear your Jira board.

The more we embrace the collective process, the more we reclaim time, reduce risk, and avoid reinventing the same wheel with slightly different emojis in the name.

Want to glimpse the hive mind? Here are a few glorious examples of Teams workspace management tools that serve the collective:

Together, we build a future where IT runs smoother, Teams stay tidy, and no one asks to manually invite 40 guests to a public channel at 4:59 PM on a Friday.

You have been standardized.
And it’s beautiful.

The „author“ would like to remind you of important pages (soon to be assimiliated):

  • The feedback page “ Sledgehammer ” – here you can ask questions or submit requests or ideas
  • The T-Shirt Page – here you can support the ClickCoach team and look good at the same time

Azure Logic Apps – Automatically Simple

You may have heard this before but it’s certainly true: automation of recurring processes is becoming increasingly important. And supposedly, thanks to ChatGPT and co., it’s also becoming easier. But code alone is of no use; processes and tools are needed to make such automation possible. The key word here is ‚low code‘ : administrators and users are supported with the necessary tools to build their own workflows without having to learn programming languages ​​in depth. Let me walk you through how this works using a simple example. We will use the following tools.

  • Microsoft Forms
    • A graphical user interface is not always needed to provide the inputs required for the automated process. But especially when end users have to provide information, Microsoft Forms is an excellent and easy to use option for providing an input mask.

  • LogicApp
    • Azure Logic App is a semi-graphical tool in which the IT admin can put together and adapt any workflow. There is some code behind it, but the IT admin doesn’t have to worry about that (for now). Although it’s not possible to do without programming entirely, the graphical editor is there to support the IT admin.

On-Premises Data Gateway

  • The On-Premise Data Gateway is a locally installed application designed to establish a connection to systems that are not yet in the cloud. These can include local file servers or databases.

In the Microsoft world, Powershell has established itself as the language for scripts. Why? Everything is very straightforward and logical. The main commands (get, set, etc.) are easy to understand and there is a Powershell module for practically everything with numerous commands and options. The learning curve is there, but not that steep. Very often an input file is required, which is then used to generate or process an output. What is missing? The graphical part, because it is a language for admins and not for end users. The good news: This gap can be bridged with Azure Logic Apps and Microsoft Forms

What could an example process look like?

  • A user wants to increase the mailbox size
  • To do this, the user fills out a graphic form
  • This information is written to a file
  • The file is picked up, read and processed by a Powershell script

How do we implement this technically?

Step 1:

Step 2:

Step 3:

Step 4:

Creating the form

This step is very simple because Microsoft Forms is part of the M365 Cloud and can be accessed at https://forms.office.com

A simple form could look like this:

  • Any data that the user submits can be read and processed by your Azure Logic App
  • The security of the form can be configured. The user group of the form can be restricted via Entra.

Install the On-Premise Data Gateway

An on-premise data gateway is a locally installed application that is registered in Azure and checks for new information via port 443 (outgoing). I don’t want to go into this in detail here because the setup is straight-forward and well documented. An OPDG allows us to pass the data entered in Microsoft Forms to a local file server using Azure Logic App. We’ll see how this works in the next step.

Building the Logic App

And here it is, your very first Logic App! This is a graphical workflow that we put together in the Azure portal and requires limited programming knowledge. What should our new  Logic App do? As you can see from the following screenshot, the Logic App basically consists of four steps. The last step is not always necessary, as we’ll learn later.

Logic App - 4 easy steps
LogicApp – 4 Simple Steps

Step 1 – “When a new response is submitted”

  • The Logic App waits 365 days and 24 hours a day for someone to fill out the form. And as soon as someone presses the ‚Submit‘ button, the workflow is triggered.
  • The parameter ‚Form ID‘ is important here, which must refer to the previously created form.

Step 2 – “Get response details”

  • In order for the information to be processed, it must be available for further steps. The entries from the individual fields can then be accessed via the field names, as defined in the form. The ‚get response details‘ block takes care of this.

Step 3 – “Append File”

  • The form can be filled out as many times as you like. Each new entry adds another line to the file. This is a simple text file, listing one or multiple e-mail addresses.
  • Next we define the path to the file. This is where the On-Premise Data Gateway comes into play, because now we’re actually talking about a file path that is not in Azure but on a local file server. The ‚Append File‘ function is only available if at least one OPDG has been created and registered. Of course, you could also store files in Azure, depending on your scenario.
  • Consider the following options for adding or editing content to the file
    • Dynamic Content: These are the fields and properties of previous actions (the fields from ‚Get Response Details in step 2)
    • Insert Expression: This allows for extended functionality such as text manipulation. In our example, we want one e-mail address per line and therefore need to switch to the next line after each entry:
      • uriComponentToString(‚%0D%0A‘)

Step 4 – “Create File”

  • Perhaps you are suprised that there is ‚create file‘ step? Wasn’t the file already added in step 3? The point to remember about this step is that it is only carried out if step three (Append File) doesn’t work. We will see why this is the case later in step 5. In Powershell this would be a ‚Try – Catch‘ block, but here we click through the options in the graphical editor, as we can see in the screenshot.

Step 5 – Retrieve and edit the file with Powershell

Let’s not go into the details of the Powershell script, as this post is really all about the Logic App options. To help you get started, I have added some information below with a mention of some of the relevant powershell commands.

  • Thanks to steps 3 / 4, there is a text file with e-mail addresses. Let’s now use a ‚Scheduled Task‘ in conjunction with a Powershell script to regularly do the following:
    • Is there a text file? (get-item, copy-item…)
      • If yes: process names in the list (foreach ….)
      • Sending an e-mail that the processing has been carried out (send-mailmessage…)
      • Delete the file (remove-item…)
  • This explains step 4: the file must be created if it does not yet exist. Let’s say that the task runs every hour? So a new name can be added to the existing file during that time (step 3) and otherwise a new file has to be created (step 4).

What about traceability?

  • Thanks to ‚Run History‘ and ‚Trigger History‘ we know when and how often the Logic App ran and why
  • Using ‚Versions‘ we can go back to previous versions and identify changes

Conclusion

Hold your horses: Some scripting is still required. Error handling and plausibility checks etc. must be dealt with in the Powershell script in step 5 (at the latest). But now we can extend our existing processes or scripts with a graphical component and an input form. And all this can be done quickly and efficiently, thanks to Azure Logic Apps.

Final thoughts

Finally, here’s a reminder of important pages:

  • The feedback page “ Sledgehammer ” – here you can ask questions or submit requests or ideas
  • The T-Shirt Page – here you can support the ClickCoach team and look good at the same time

Microsoft EntraID – Role-based Access Control (RBAC)

Approximately a year ago, I wrote about PIM here… The article remains highly relevant today, and I can only recommend it. This new post is meant as an addition, but it’s also valuable to read on its own.

Did you know that in Microsoft Azure, there are over 120 standard roles that can be individually assigned? You can find a detailed overview here. One area of Azure is the directory service ‚Entra‘, which manages identities. Here too, there are dozens of availabe roles.

Not all of these many roles are equally critical. Microsoft designates the particularly important roles as ‚privileged.‘ These roles have higher permissions and require special protection (using PIM).

RBAC sounds simple in concept, at least at first glance. You think about what rights you need for your work, and then someone assigns an appropriate role to your admin account. But what rights do you actually need? When asked specifically, you might just want to be able to do ‚everything.‘ Who wants to be restricted in their work? That’s why in many accumulated Active Directory environments, you often find an undocumented number of ‚Domain Admins‘. And the same happens in Azure environments these days: there are many ‚Global Admins.‘ This is like handing out the master key to the building because someone might need to access the boiler room. Baaad idea! It’s really worth investing some effort here to define the correct roles.

The Azure / M365 / Entra roles are all well documented and usually quite clear. For example, have a look at the ‚Teams Administrator‘ role. So someone dealing with Teams administration should get this role. Right? Unfortunately, it’s not that easy. There’s a difference between managing the entire Teams service (Role: Teams Administrator) and primarily handling Teams telephony functions (Role: Teams Telephony Administrator). You’ll have to work this out by asking the right questions.

One problem you’ll soon encounter is that the services in M365 are closely integrated. Behind Teams, there’s a SharePoint storage, and then there’s usually a M365 groups for sending mails to Teams members. To manage all three areas end-to-end, you might need:

  • Exchange Administrator
  • Teams Administrator
  • Sharepoint Administrator

Managing access with PIM, you may have to request all three roles separately. Very cumbersome! Okay, we could also build custom roles where we try to mirror the Microsoft roles. This option is possible but it’s high maintenance, because there can always be changes to the Microsoft standard roles. The cloud environment is rapidly developing, so a static approach is probably the wrong way to go.

A better option is to create your own Entra RBAC group and integrate it into PIM management. After that, you can request rights to the self-created RBAC group via PIM and receive the functions of all linked Azure standard roles (for a limited amount of time). These linked role assignments can be changed as needed, but the ordering process remains unchanged. This simplified approach is ideal for reorganizations, etc.

Next, I’ll explain how to do this. The example assumes job responsibility for the three main services of M365 (Teams, Exchange, SharePoint).

Managing your own RBAC groups with PIM

What rights do I need to set this up?

  • The role of ‚Privileged Role Administrator‘ – this role defines and updates the PIM roles.

What are the general steps?

  • Create a new group in Entra and assign roles to it.
  • Activate the group in PIM for management.

What are the detailed steps?

Are there any other considerations for the new group?

  • The group type must be ‚Security.‘
  • It needs a clear naming convention (e.g., RBAC).
  • The ‚Microsoft Entra Roles can be assigned to this group‘ checkbox must be set to ‚Yes.‘
  • Dynamic groups for RBAC are not supported.
  • Clicking on ‚Roles‘ brings up the following dialog (summarized).
  • Here you can directly assign the desired standard roles to the group (Exchange Administrator, SharePoint Administrator, Teams Administrator).
  • The group type cannot be changed later, which must be confirmed again here (Create, Yes).

What else needs to be done in PIM?

  • Switch to ‚PIM‘ in Entra and go to ‚Groups.‘
  • Select ‚Group Discovery’…
  • Enter the name of the previously created group, check the box next to the group, and then select ‚Manage Groups.‘
  • Confirm the onboarding of the group by clicking ‚OK‘

What else should you know?

  • Azure roles are permanently assigned to the RBAC group.
  • The group is initially empty.
  • Membership management is only through PIM.
  • Everything that happens in PIM is logged.

Okay, but who can request this new role, and how long will the assignment last?

  • An important step in PIM is to add all eligible persons under ‚Eligible Assignments.‘ Only those listed here can later request the role

Just like with standard RBAC roles, you can also define:

  • How long the assignment lasts.
  • Whether someone is notified when the role is requested.
  • Whether someone needs to approve the assignment first (Approval).
  • Whether additional MFA authentication is required.

So how can I order the new role for myself?

  • Access the Azure portal.
  • Switch to PIM.
  • The RBAC role appears here under ‚My Roles‘ ‚Groups.‘
  • Clicking ‚Activate‘ requests the role, and depending on whether approval is needed or not, it’s assigned directly.
  • In our example, the permission expires automatically after 8 hours.

And that’s it!

Here’s a reminder of ways you can interact with us:

  • ‚Hammertime‘ – Send uns your ideas and let us know what you think
  • Get the ‚T-Shirt‘ – Impress friends and family while supporting our site.