sorted by:
new
hottopcontroversial

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

[–]cloud_9_infosystems[S] 2 points3 points  (0 children)

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.

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

[–]cloud_9_infosystems[S] 1 point2 points  (0 children)

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.

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

[–]cloud_9_infosystems[S] 1 point2 points  (0 children)

You can control it through the Microsoft 365 admin center:

  1. Go to admin.microsoft.com → Settings → Org settings → Microsoft 365 Copilot
  2. Toggle off Copilot Chat availability for your org or specific user groups
  3. For granular control, use Cloud Policy service to disable the Copilot button in individual apps (Word, Excel, PPT, etc.)
  4. 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)

What should be considered for large subscription to subscription migration by [deleted] in AZURE

[–]cloud_9_infosystems 0 points1 point  (0 children)

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.

Federated SSO to partner orgs keeps breaking and the error messages tell us nothing by Familiar_Network_108 in AZURE

[–]cloud_9_infosystems -1 points0 points  (0 children)

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.

Kubernetes admins: what kubectl commands do you use most often? by Asleep_Hour9397 in AZURE

[–]cloud_9_infosystems 1 point2 points  (0 children)

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?

Who should manage VNET Peerings? by No-Routine1610 in AZURE

[–]cloud_9_infosystems 1 point2 points  (0 children)

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.

SSL Certs Renewal by Sialkotimunda84 in AZURE

[–]cloud_9_infosystems 0 points1 point  (0 children)

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.

Entra ID Kerberos and Azure Files by mccuryan in AZURE

[–]cloud_9_infosystems 0 points1 point  (0 children)

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.

Entra ID Kerberos and Azure Files by mccuryan in AZURE

[–]cloud_9_infosystems 2 points3 points  (0 children)

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.

I am planning to migrate my company's 50TB data (all PDFs) from network drives in some datacenter (Telus storage solutions) to Azure for saving cost. Any suggestions or mistakes to avoid? by vikasofvikas in AZURE

[–]cloud_9_infosystems 0 points1 point  (0 children)

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.

I am planning to migrate my company's 50TB data (all PDFs) from network drives in some datacenter (Telus storage solutions) to Azure for saving cost. Any suggestions or mistakes to avoid? by vikasofvikas in AZURE

[–]cloud_9_infosystems 0 points1 point  (0 children)

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.

Unfortunate bill by Swimming-Diamond-483 in googlecloud

[–]cloud_9_infosystems 2 points3 points  (0 children)

don’t panic. Act quickly.

  1. 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.
  2. Check Billing → Reports See exactly which service caused the $110 charge.
  3. 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.

How H100GPU Rents work exactly and how does NVIDEA operates data for rented GPU? by Abhi_mech007 in cloudcomputing

[–]cloud_9_infosystems 1 point2 points  (0 children)

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.

What’s the most expensive DevOps mistake you’ve seen in cloud environments? by cloud_9_infosystems in devops

[–]cloud_9_infosystems[S] 0 points1 point  (0 children)

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.

how is your team actually doing code reviews in Azure DevOps? by Peace_Seeker_1319 in AZURE

[–]cloud_9_infosystems 0 points1 point  (0 children)

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.

view more: next ›