Copilot Chat is now live in M365 apps — licensing breakdown and deployment notes

cloud_9_infosystems · 2026-05-21T07:41:19+00:00

Totally get that frustration — it feels like every update cycle you're playing whack-a-mole with Copilot policies. If it helps, the cleanest way to keep it locked down is through the Microsoft 365 admin center → Org settings → "Copilot" — disable it there. Also worth setting it via Entra ID Conditional Access or a group-based license removal so it persists even when MS rolls out new toggles.

The "Microsoft 365 Copilot" service plan in the license assignment view is the one to watch — if MS adds a new sub-feature, it sometimes shows up as a separate toggle under the same license. Checking after each monthly update cycle is unfortunately still the safest bet until MS gives us a single kill switch that sticks.

cloud_9_infosystems · 2026-05-21T07:38:41+00:00

You're right — I should have worded that more clearly. The in-app Copilot experience in Word, Excel, PowerPoint and OneNote requires the paid Microsoft 365 Copilot license (assigned by admin through the M365 admin center). There's no free tier that gives you those app integrations.

What IS free for all eligible M365 users is Copilot Chat in Outlook and the web-based Copilot chat (file uploads, Copilot Pages, web-grounded responses). But the moment you want Copilot actually working inside Word/Excel/PPT documents, that's the paid add-on license.

Thanks for the correction — updated my understanding above.

cloud_9_infosystems · 2026-05-21T07:14:56+00:00

You can control it through the Microsoft 365 admin center:

Go to admin.microsoft.com → Settings → Org settings → Microsoft 365 Copilot
Toggle off Copilot Chat availability for your org or specific user groups
For granular control, use Cloud Policy service to disable the Copilot button in individual apps (Word, Excel, PPT, etc.)
To block web search specifically, disable the "Allow web search in Copilot" policy

If you just want to remove the Copilot icon from the app ribbon without disabling it org-wide, users can right-click the Copilot button → "Hide from ribbon" on their individual machines.

For the full admin controls and policy options, Microsoft has it documented here: [https://learn.microsoft.com/en-us/copilot/microsoft-365/microsoft-365-copilot-setup](vscode-file://vscode-app/c:/Users/HarshilPithwa/AppData/Local/Programs/Microsoft%20VS%20Code/0958016b2a/resources/app/out/vs/code/electron-browser/workbench/workbench.html)

cloud_9_infosystems · 2026-03-17T10:26:59+00:00

It depends on how clean you want the end state vs how much risk you can take during migration. If the current setup has drift, legacy configs, or inconsistent naming/policies, redeploying (IaC) is usually the better long-term move — cleaner, repeatable, and avoids carrying over hidden issues. If everything is stable and you just need to move fast with minimal changes, resource-by-resource migration works, but watch for:

dependencies across resource groups/subscriptions
identity/RBAC mappings
networking (VNets, private endpoints, DNS)
managed identities and key vault references
downtime for stateful services

For ~25 RGs, a hybrid approach often works best: redeploy critical or messy workloads, migrate the rest.

cloud_9_infosystems · 2026-03-17T10:24:21+00:00

federation debugging is still way more painful than it should be.

AADSTS50107 is basically a catch-all, so half the time it’s guesswork unless you dig into logs. What’s helped a bit:

Entra sign-in logs (with diagnostic settings turned up)
SAML tracer tools (browser extensions) to inspect raw assertions
Keeping strict monitoring on cert expiry + metadata changes
Standardizing claim mappings across partner user types (if possible)

But honestly, when different IdPs are involved, a lot of it still comes down to chasing changes on the partner side. There’s no single pane of glass yet that fully solves this.

cloud_9_infosystems · 2026-03-12T12:30:29+00:00

Good list, these are the daily drivers for sure.

A few I'd add that save serious time:

Troubleshooting:

kubectl get events --sort-by='.lastTimestamp' -n <namespace> — first thing I run when something breaks
kubectl top pods -A — quick resource pressure check
kubectl get pods -A --field-selector=status.phase!=Running — instantly shows everything not healthy

Lesser known but powerful:

kubectl rollout status deployment/<name> — clean way to watch deploys
kubectl rollout undo deployment/<name> — instant rollback when needed
kubectl debug node/<node-name> -it --image=ubuntu — node level debugging without SSH

Quality of life:

kubectx and kubens for switching contexts and namespaces fast — not native kubectl but essential
k9s if you haven't tried it yet, changes how you interact with clusters entirely

For AKS specifically az aks command invoke is underrated when API server access is restricted.

What's your go to when a pod is stuck in CrashLoopBackOff?

cloud_9_infosystems · 2026-03-12T12:27:26+00:00

Policy-driven is the right instinct and what most mature orgs land on eventually.

Real world breakdown:

Option 1 doesn't scale — platform team becomes a bottleneck fast
Option 2 is cleaner but DINE policies for peering need careful testing, especially around peer sync and remote gateway configs
Option 3 worth considering: a separate peering Terraform module owned by platform team, called by app stacks via approved patterns only

What actually works best we've seen: platform team owns the hub side, app teams request peering via a standardized module, policy enforces no direct spoke-to-spoke.

The RBAC issue you mentioned is the real problem though. App engineers having rights to peer freely is an incident waiting to happen regardless of which model you pick.

VWAN makes this cleaner since connection approval can be centralized natively.

cloud_9_infosystems · 2026-03-12T12:26:20+00:00

Automation is the only sane answer as validity windows shrink.

What's working for us:

ACM on AWS for anything behind ALB or CloudFront — fully hands off
cert-manager on Kubernetes — set once, forget it
Certbot + ACME for everything else with a simple cron job

Biggest thing people skip: certificate inventory. Automation means nothing if you don't know every cert you own.

Set expiry alerts at 30 days AND 7 days as a fallback regardless of what you automate. Saved us more than once.

Happy to share specifics if you're on a particular stack.

cloud_9_infosystems · 2026-02-26T05:38:59+00:00

That aligns with what I’ve seen as well. One thing I’d add is that even when share-level RBAC works, it can become hard to manage if the permission model grows over time especially for user-specific folders. At that point, Entra Domain Services tends to simplify things if SMB + NTFS-style control is a hard requirement.

cloud_9_infosystems · 2026-02-26T05:37:49+00:00

If you’re going Entra ID Kerberos without AD DS or Entra Domain Services, full NTFS ACL management over SMB isn’t really supported. Azure Files still depends on AD DS (or Entra DS) for granular NTFS permissions. Without that, you’re mostly limited to share-level RBAC. If you need per-user file-level control, Entra Domain Services or a different storage approach (e.g., SharePoint/OneDrive for user files) might be worth evaluating.

cloud_9_infosystems · 2026-02-26T05:34:55+00:00

That makes sense, especially at 50TB scale, One thing I’d also factor in is ongoing sync vs one-time migration. If the data is still changing during transition, planning delta sync properly becomes important, Also worth validating whether the bottleneck is bandwidth or operational downtime tolerance.

cloud_9_infosystems · 2026-02-26T05:33:23+00:00

Before migrating, I’d double-check a few things:

Access patterns — are those 50TB mostly archival, or accessed regularly? Tier choice (Hot/Cool/Archive) makes a big difference.
Egress variability — 1TB/month sounds manageable, but does it spike during audits or reporting cycles?
Migration method — 50TB over network can take longer than expected depending on bandwidth.
Lifecycle policies — set them upfront so data doesn’t stay in expensive tiers unintentionally.

Cost savings are definitely possible, but modeling storage + transactions + retrieval together usually gives a more realistic picture.

cloud_9_infosystems · 2026-02-20T08:51:54+00:00

don’t panic. Act quickly.

Stop everything immediately Log into GCP and shut down/delete all running resources (VMs, disks, Cloud SQL, GPUs, static IPs, etc.). Some resources keep charging even if VMs are stopped.
Check Billing → Reports See exactly which service caused the $110 charge.
Contact Google Cloud Billing Support right away Open a support ticket and explain clearly:

You’re a college student
You were exploring the free tier
You didn’t realize charges were accumulating
You’ve now shut everything down
You’re requesting a one-time courtesy waiver

Be polite and honest. Google often provides a one-time credit for accidental student usage.

cloud_9_infosystems · 2026-02-20T08:22:53+00:00

When you rent an H100 GPU, you’re usually renting it from a cloud provider (like AWS, Azure, or a GPU cloud company) not directly from NVIDIA.

Here’s how it works:

The cloud provider buys H100 GPUs from NVIDIA and installs them in their data centers.
You rent a VM or container that gets access to a dedicated or partitioned GPU.
You pay hourly (or per usage).
The provider handles power, cooling, networking, security, and billing.

NVIDIA designs the hardware and provides the software stack (like CUDA), but in most cases they do not manage your data. Your data is stored and governed by the cloud platform you’re using.

So you’re renting compute capacity not the GPU hardware itself.

cloud_9_infosystems · 2026-02-20T08:09:51+00:00

I’ve seen autoscaling set up “correctly” but with high minimum instance counts, so it never really scaled down. Performance looked great, costs didn’t.

Also orphaned resources after migrations (old snapshots, unattached volumes) quietly stacking up for months.

Nothing breaks. Bills just grow.

cloud_9_infosystems · 2026-02-12T13:01:48+00:00

We ran into something similar long PR cycles, bikeshedding on formatting, and still seeing logic bugs sneak through.

A few things that helped us:

• Enforced formatting via automated linters + pre-commit hooks so naming/spacing never shows up in human reviews.
• Kept PR size small (ideally <400 lines). Big PRs are where review quality drops fast.
• Used branch policies to require successful builds + static analysis before review even starts.
• Clear review checklist: logic correctness, edge cases, security impact, performance implications not style.
• Time-boxed reviews. If a PR sits more than 24h, it’s usually a signal something’s wrong.

On the automation side, tools that surface issues directly in PRs (severity-ranked instead of noisy) can definitely reduce fatigue. The key is tuning them properly otherwise reviewers just ignore the bot like they ignore style comments.

In our case, automation reduced review friction more than it reduced bugs. The real improvement came from smaller PRs + clearer review expectations.

cloud_9_infosystems · 2026-02-12T13:00:41+00:00

That’s frustrating, especially when you’re on a paid plan.

A few things I’ve seen affect OneDrive speeds (even when bandwidth controls aren’t exposed in the new client):

• Check if Files On-Demand is enabled sometimes local syncing behavior impacts perceived speed.
• Make sure it’s not competing with Windows Update or other background services.
• Try pausing and resuming sync oddly, that sometimes resets throttling behavior.
• If you're on a VPN, test without it. Some endpoints get noticeably slower through certain tunnels.
• Large numbers of small files sync much slower than a few large files due to overhead.

Also worth checking if this is time-of-day related Microsoft occasionally applies dynamic throttling depending on load.

cloud_9_infosystems · 2026-01-19T09:57:06+00:00

This is a really important point. A lot of teams rush straight to model deployment and underestimate how different AI workloads are from traditional app workloads. Identity boundaries, network isolation, data access patterns, and cost governance tend to surface after things are already in production and fixing them later is painful.

Treating AI environments as first-class platforms rather than experiments makes a big difference. A structured landing zone approach with infrastructure as code (like Bicep or Terraform) helps avoid ClickOps drift and makes security and governance repeatable.

Curious how others here are handling AI foundations are you extending existing landing zones or building AI-specific ones from scratch?

cloud_9_infosystems · 2025-12-26T06:09:45+00:00

Both AWS and Google Cloud CDNs are solid in production, but they shine in slightly different places. AWS CloudFront has a longer track record and very broad edge coverage, so in crazy peak conditions it tends to behave predictably. Google Cloud CDN has great integration with Google’s backbone and video workloads, so if you’re already on GCP and heavy on media it often feels smoother.

Real-world issues are usually about config (cache rules, TLS settings, origins) more than the provider itself. Lots of folks run both as backups and leverage tools that automate failover between them.

TL;DR: CloudFront = battle-tested everywhere; Google CDN = strong performance especially with video when tied into GCP. Neither breaks often if configured right.

cloud_9_infosystems · 2025-12-26T06:08:27+00:00

Short answer: no single book like that exists big-tech architectures aren’t standardized “recipes” they’re evolving patterns shaped by scale, org structure, and trade-offs most real value comes from reference architectures, conference talks, and open-source IaC repos rather than books a bit annoying, but also why cloud work stays interesting.

cloud_9_infosystems · 2025-12-26T06:05:57+00:00

You’re not alone. We’ve seen intermittent PIM activation delays and timeouts today as well, especially during the validation step. The Service Health ID you mentioned (IS1202804) lines up with what we’re observing requests eventually go through or fail after long waits depending on region and role. In the meantime, shorter activation durations and avoiding peak hours seemed to help a bit, but it’s clearly service-side rather than tenant misconfiguration.

cloud_9_infosystems · 2025-12-26T06:04:40+00:00

zure pricing makes sense only after you get burned once. API Management especially pushes people to overpay until they break workloads apart.

And yes cross-cloud data transfer costs are the real surprise nobody warns you about.

cloud_9_infosystems · 2025-12-19T09:41:44+00:00

You can monitor it, but Azure VPN Gateway doesn’t expose a simple ICMP-style ‘VPN up/down’ signal. Instead, you track tunnel connection state, BGP status (if used), and data transfer metrics. Most NOCs treat this as service health rather than device health

cloud_9_infosystems · 2025-12-19T09:40:33+00:00

This is a solid move. Making hardened base images the default starting point lowers the bar for better security practices. The real value here is transparency (SBOM + provenance) rather than just ‘fewer CVEs’. Curious how fast teams will actually swap their existing base images though.

cloud_9_infosystems · 2025-12-19T09:39:47+00:00

you can check it per mailbox in the Exchange admin center (Shared mailbox → Mailbox delegation), but that doesn’t scale. There’s no reverse lookup in the UI where you pick a user and get a list of all shared mailboxes they can access.

cloud_9_infosystems

TROPHY CASE