u/tingnossu

been going down a rabbit hole on this lately. apparently only around 97 real people have ever had official LEGO minifigures made of them, though that number, varies depending on how you count variants and what qualifies as a "real person" fig versus a licensed character. either way it's a tiny slice out of something like 17,000 unique figs total, which honestly surprised me. most of them are athletes or entertainment figures, and with more sports waves landing in 2026 that ratio is slowly creeping up. the quality of the likeness varies heaps depending on the set and release type too. a CMF or exclusive set fig can look totally different from a mainline one even if it's technically the same person. the thing I keep noticing is that the best ones don't try to be photorealistic, they just nail a detail, or two that makes you go "yeah that's definitely that person." a specific hairstyle, a signature outfit, the right accessories. the ones that fall flat are usually trying to do too much with a face print that's just too small to pull off fine detail. pad printing is pretty crisp but there's only so much you can do at minifig scale. also the actor vs character debate is real. like is a LEGO Han Solo a Harrison Ford fig or just a Star Wars character fig? I'd say character, but I've seen people argue both ways. genuinely curious whether people think any of the sports figs nail it better than the entertainment ones, or if it's the other way around.

been working on a MOC based on a heritage shopfront near where I grew up, one of those narrow two-storey terracotta-tiled facades you see in older parts of the city. started off wanting to do a pretty close replica but the standard 32x32 modular footprint and, part availability forced me to make so many compromises that it's now more "vibes-based" than accurate. the roofline is close, the colour scheme is close, but the proportions are off and, I had to invent a bunch of detail that isn't actually there in real life. still happy with how it turned out though. reckon there's a genuine split in how people approach this. some builders seem to want the real thing translated as faithfully as possible, others use a building as a jumping-off point and go wherever the bricks take them. I ended up in the second camp by accident. been seeing a lot more people lately using Bricklink Studio or BrickArchitect to plan out, substitutions before committing to a build, which probably helps if you're chasing accuracy from the start. might try that approach next time. curious whether anyone here has managed to stay really accurate to a specific real-world reference, and what the biggest sticking point was when you tried. comparison shots against the original building especially welcome if you've got them.

Our org runs a mixed fleet, about 60% Linux, rest Windows and macOS, and we're, in the middle of replacing a legacy DLP setup that basically ignored anything not running Windows.

Constraints: mid-market budget, two-person security team, already deep in Microsoft 365 but not locked into Purview, and we need, USB control plus content inspection to actually work on Ubuntu and RHEL endpoints, not just check a compliance box.

Forcepoint's Linux agent support is unclear from what I've been able to find - their endpoint protection seems, to be documented for Windows and Mac only, so if anyone has real-world experience there I'd love to know. Microsoft Purview is the obvious fit for our M365 stack but I haven't been able to get a, straight answer on where their endpoint story actually lands for non-Windows, and I'm not fully confident in it. We also looked briefly at Netwrix DLP but couldn't find much verified information about their Linux support at all, which makes it a harder sell to leadership regardless.

Priority order for us: reliable Linux agent, USB and peripheral control, content-aware policies that don't need a full-time tuner, and decent M365 integration.

Curious specifically how others with Linux-heavy fleets are handling the Purview gap right now, and whether Forcepoint's Linux support has actually held up in production.

Been thinking about this since the OpenClaw CVE-2026-41329 discussion picked up. The heartbeat context inheritance angle is interesting because PAM doesn't actually fix the underlying bug, but it does change the blast radius conversation pretty significantly. From what I've seen in practice, the biggest wins come from zero standing privilege and JIT elevation rather than just vaulting credentials. If an attacker breaks the privilege boundary via context inheritance, having no persistent admin session to land in makes a real difference. The service account and automation identity gap is where I reckon most orgs are still exposed though, everyone's focused on human admins and the machine identities are sitting there with way too much standing privilege. Curious whether anyone's actually scoped PAM controls specifically around this class of issue or whether it's more just general least-privilege hygiene that happens to help. Also wondering how people are handling the detection side, session recording is useful but by the time you're reviewing recordings the damage is usually done. Have you found anything that catches the privilege escalation attempt earlier in the chain, before it completes?

took a big modular city layout to a local brick event earlier this year and honestly the setup was more stressful than building the thing. ended up using 4x8 plywood sheets on folding legs as the base, which worked fine for stability, but transport was a nightmare. had to half-disassemble a couple of sections and rebuild on-site, which i'd really rather avoid next time. been looking into whether building in standardized modular sections with consistent connection points would make that easier - things, like using Technic pin alignment or a consistent plate grid so sections can come apart and go back together cleanly. not sure if that just trades one problem for another though, especially keeping everything level across joins. for crowd protection i just used basic rope barriers, which felt a bit janky but did the job. seen people use acrylic cases for smaller sets but for a full layout that gets expensive fast and kills the open display feel. from what i've seen at bigger events lately, stanchions or a simple table setback with clear signage tends to look cleaner than rope without going full museum-case mode. curious how others handle the transport vs build-on-site tradeoff, and whether anyone's found a good middle ground for barriers that doesn't look like a construction site. also open to thoughts on lighting - noticed some of the more impressive layouts this year were leaning hard into that and it made a real difference.

been burnt a few times now pulling in modules from the Gallery for managing third-party software and figured it's worth talking about. the big one for me was version conflicts. had a module pinned at one version in prod and a totally different one on dev because someone did an Install-Module without specifying -RequiredVersion. took way too long to figure out why the same script was behaving differently across environments. now I just always pin versions and keep a private repo rather than pulling straight from Gallery. worth calling out if you're still on MSOnline or the old AzureAD module - those are fully gone now, so if you haven't migrated to Microsoft.Graph yet that's going to be your most urgent version conflict to deal with. learned that one the hard way when automation started failing in prod. the other thing I didn't expect was how modules auto-load from PSModulePath without much fanfare. if you've got a sketchy or outdated module sitting somewhere in that path it can get pulled in without you realising. I've started being a lot more deliberate about Import-Module with explicit paths and setting $PSModuleAutoLoadingPreference to None in scripts that need to be predictable. also worth auditing what's actually in your module paths occasionally, especially on shared systems. working with stuff like PowerCLI or any vendor-specific module adds another layer too. they sometimes ship with their own dependencies that conflict with things you already have loaded. had a fun afternoon where PowerCLI's version of a shared assembly was fighting with something else in the session. ended up having to run it in a separate PS process just to isolate it. anyone else run into that kind of thing with vendor modules and found a cleaner way to handle it?

Currently working through replacing a 2019 DC that's running both the CA root and NPS for RADIUS auth. New server is 2025 with a different hostname, so I can't just reuse the name and call it a day. I've done a few DC migrations before but never one where ADCS was involved, and the GPO side of things is where I keep going in circles. From what I've read, the general consensus is to migrate rather than in-place upgrade, especially when, the CA is sitting on a DC, which I know is not ideal to begin with. Certutil for the CA backup/restore makes sense, and I'm planning to run both environments in parallel while I move clients over piecemeal. The part I'm less clear on is the GPO handling. Specifically whether I should be updating the existing cert trust GPOs or replacing them entirely for the new CA. I've seen some guidance around using GPMC's Update mode rather than creating new ones to avoid ending up with duplicates and broken, links everywhere, but I'm not sure if that applies cleanly when you're also changing the CA itself rather than just the server. Has anyone gone through a similar setup where the CA hostname changed and had to retrust clients through policy? Keen to hear how you handled the GPO side of it.

been setting up some automation for Entra ID B2B invitations across a few partner tenants and hit the usual wall where MFA just kills any ROPC-style login. ended up going the app registration + self-signed cert route, uploading the public key to the app, then authenticating via Connect-MgGraph with -CertificateThumbprint and -AppId. works cleanly for sending invites through New-MgInvitation without any interactive prompts. worth flagging if you're still on the old AzureAD module - New-AzureADMSInvitation is gone, that module was retired a while back. New-MgInvitation from the Microsoft.Graph module is the current path. also if you were using Connect-ExchangeOnline for the B2B invite piece specifically, that's the wrong connection anyway - that's Exchange-scoped. Connect-MgGraph is what you want for Graph-based B2B work. one thing I'm still figuring out is the right approach for managing the certs long term. the 10-year cert and forget it approach is a hard no for me from a detection standpoint, - long-lived credentials on service principals are exactly what I'm writing alerts for on the other side. but with TLS cert max validity now sitting at 200 days as of early 2026, manual tracking is basically dead anyway. you need rotation automation baked in from the start, not bolted on later. the alternative I keep coming back to is Azure Automation runbooks with managed identities, but MI gets genuinely messier when you're crossing tenant boundaries for B2B stuff. haven't found a clean answer there yet. anyone running this in prod for actual cross-tenant B2B automation? curious whether you stuck with certs and automated the rotation, or found a workable MI pattern, and how you're handling the Conditional Access exclusions for the service principal.

been playing through Skywalker Saga again lately and honestly it keeps pulling me back to the physical sets. finished a level last night, then spent two hours hunting down the UCS Millennium Falcon on the marketplace. there's something about the way the game is designed that just makes you want to touch actual bricks again. kind of wild how well LEGO has managed that crossover between digital and physical. the games aren't just games, they're basically ads that don't feel like ads. and it's clearly still working in 2026 because the player numbers have been climbing again recently, which honestly tracks with how active the community feels right now. I remember reading that LEGO Ideas came out of a similar philosophy, letting fans drive what gets made rather than top-down corporate deciding everything. seems like the gaming side follows the same logic. community enthusiasm feeds back into what sets get attention, and the cycle just keeps going. anyone else notice their physical collection growing suspiciously fast after a gaming binge? or is it just me buying Mandalorian sets at midnight after one too many levels.

Been dealing with a recurring headache where a module update in dev quietly breaks something in prod because nobody pinned the version properly. We've got a few different environments and the approach has been a bit inconsistent - some scripts, use -RequiredVersion, some just pull whatever's latest, and the profiles across machines are all over the place. Ended up setting up a local repo with Register-PSRepository pointing at an internal share so we can, at least control what versions are available per environment, but it still feels held together with tape. Curious what others are actually doing in practice. Do you go full version pinning for prod and let dev float on latest, or do you lock everything down everywhere and just promote versions deliberately? Also wondering if anyone's got a clean way to handle the PSModulePath customisation across different machines, without it turning into a mess - we're doing some registry tweaks but it gets fiddly. Would love to know if PSDepend or something similar is actually worth adding to the mix or if that's overkill for a mid-size setup.

Been doing a fair bit of bulk hostname-to-IP resolution lately for some identity threat investigation work and figured I'd share what actually works. If you're still piping nslookup output through Select-String to parse it, just stop. It breaks constantly, the output format isn't consistent across environments, and it's genuinely painful to maintain. Resolve-DnsName is the way to go. You get proper objects back, it pipes cleanly, and you can do things like: Get-Content hostnames.txt |, ForEach-Object { Resolve-DnsName $_ -ErrorAction SilentlyContinue } and export the whole thing to CSV without any regex nonsense. For reverse lookups I've been using Resolve-DnsName with -Type PTR or just [System.Net.Dns]::GetHostAddresses() depending on whether I need the extra object properties. The one thing that does bite you on bulk jobs is timeouts, especially in enterprise networks where DNS can be flaky. I've started wrapping calls in try/catch blocks and logging the failures separately so I can see which hosts consistently time out rather than just silently dropping them. That distinction actually matters in identity threat work because a host that never resolves is worth a second look. For really large lists, Start-ThreadJob is worth considering if you want to parallelize without pulling in external dependencies. For most of what I do a few thousand hosts is fine with the, basic ForEach-Object approach, but once you're pushing beyond that the sequential wait adds up fast. Curious whether anyone has a clean pattern for handling partial failures in bulk lookups without it getting messy, because my current error handling works but it's not pretty.

been writing a bunch of identity-related scripts lately that take multi-value inputs, things like passing multiple AD groups or, multiple principal types to a single param, and ValidateSet on its own gets a bit awkward when you're accepting arrays. the tab completion is great but validation behavior can differ depending on how the argument gets passed, especially, the -File vs -Command invocation difference when someone's calling your script from another script vs running it interactively. that parsing gap is where I've seen things go sideways. one thing worth clarifying though: for [string[]] params, ValidateSet actually does validate each array element against, the set individually, so adding a ValidateScript block that loops through each element is technically redundant. I had assumed it was catching extra cases but it's really just duplicating what's already happening. where ValidateScript still earns its place is if you need logic that ValidateSet can't express, like cross-element constraints or case-sensitivity rules specific to your environment. the other thing I ran into is that ErrorMessage on ValidateSet is genuinely worth using if your scripts get handed to other people. way better than them getting a cryptic validation error with no context about what values are actually accepted. also been looking more at IValidateSetValuesGenerator for cases where the valid values aren't known at authoring time, like pulling current group names from AD at runtime. curious if anyone's using that pattern in production and whether the performance hit on large directories, is noticeable, or if you've landed on enum-based validation instead when the values are fixed and stable.

IBM dropping a managed ITDR service at RSA got me thinking about a choice my team keeps circling, back to: native Microsoft Defender for Identity versus a dedicated ITDR platform, especially in hybrid AD plus Entra environments.

Defender for Identity is hard to beat on integration, it's already in the tenant, signals feed straight into Sentinel, and the setup overhead is low. The cost is coverage depth, it leans heavily on what Microsoft telemetry surfaces and you're stuck in that ecosystem if gaps show up.

A dedicated platform like what we evaluated with Netwrix ITDR gives you cross-IdP visibility and granular, recovery options, but it's another agent to manage and another vendor relationship to justify to leadership.

For my team, recovery fidelity and AD CS attack detection weight heavier than convenience, because a misconfigured certificate template can undo weeks of hardening work quietly.

I'm less interested in which is "better" and more curious whether teams running lean SOCs actually find the dedicated, platform worth the operational overhead, or if native tooling plus tight Conditional Access policies is genuinely enough at that scale.

The CVE-2025-55241 vulnerability (a critical elevation-of-privilege issue in Microsoft Azure Entra ID involving actor token abuse and cross-tenant impersonation, not a SharePoint exposure) has me revisiting, our detection coverage for credential theft that pivots through AD-integrated apps, specifically Actor Token abuse and service account compromise that can follow an Entra ID foothold.

We run Defender for Identity today and it catches a lot, but the gap I keep hitting is granular recovery when an Entra ID account gets manipulated mid-incident. Native MDI gives you the detection signal but leaves the remediation workflow pretty manual.

I've looked at Semperis DSP (though I haven't been able to fully verify their specific strengths and weaknesses around Entra attribute-level, rollback) and Netwrix ITDR (similarly, I haven't been able to confirm the specifics of their individual attribute recovery capabilities for Entra). Both have trade-offs on pricing and deployment complexity for a lean team.

Priority factors for us: detection fidelity on privilege escalation post-Entra compromise, Entra ID recovery, granularity, AD CS attack coverage, and how well it integrates with an existing Sentinel deployment.

Curious whether teams here are sticking with the native Defender stack or layering something on top specifically for the recovery side of the house.