From 28d1d322ce2f0e8e6f10c075001eb970f6f8615a Mon Sep 17 00:00:00 2001
From: HeyItsGilbert <615265+HeyItsGilbert@users.noreply.github.com>
Date: Thu, 10 Sep 2026 06:37:29 +0000
Subject: [PATCH] Sync Meetup events

---
 content/calendar/meetup-316490583.md | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)
 create mode 100644 content/calendar/meetup-316490583.md

diff --git a/content/calendar/meetup-316490583.md b/content/calendar/meetup-316490583.md
new file mode 100644
index 000000000..e88a9e9df
--- /dev/null
+++ b/content/calendar/meetup-316490583.md
@@ -0,0 +1,17 @@
+---
+meetupEventId: "316490583"
+meetupSource: meetup
+startDate: "2026-09-16"
+title: "Intune - Not Just Another Graph Resource"
+externalUrl: "https://www.meetup.com/research-triangle-powershell-users-group/events/316490583/"
+virtual: true
+where: "TEKsystems, 4300 Edwards Mill Rd, Raleigh, NC, us"
+---
+Research Triangle PowerShell Users Group
+📝 **Synopsis:**
+
+You're likely familiar with Microsoft.Graph auth, pagination, Invoke-MgGraphRequest, etc. Intune has its own quirks on top of that. Not every policy is created equal, and something that feels like it should be a simple PATCH is a full POST. Often, we started automating before ever deploying a policy manually…
+
+📘 **Description:**
+
+Hailey will go through patterns for building Intune automation that's scalable and predictable, focusing on treating Intune like the rest of your Azure environment, aka building and using tests, deployment gates, and phased rollouts. She'll show where that thinking led: [IntuneStack](https://github.com/AllwaysHyPe/IntuneStack), a module I built that treats Intune policies like code with PR-driven dev → test → prod promotion, compliance-based success gates, OIDC auth, quality checks on every PR.