I see a lot of manual asset inventory work that’s a time sink and error-prone. If you rely on AD, automate it.
I wrote a PowerShell script that pulls systems from specified OUs, filters by last logon, and formats the output for direct import into LogRhythm’s Asset Manager. This keeps your monitored asset list current without manual entry each week.
Key script functions:
* Queries AD with Get-ADComputer.
* Applies a 30-day lastLogonTimestamp filter to exclude stale systems.
* Maps AD OS attributes to LogRhythm’s expected host type values.
* Outputs a CSV with the required columns: Hostname, IP Address (optional), Risk Level, Host Type, Location.
Run it on a schedule via Task Scheduler. This ensures your asset list reflects actual active directory members, tightening your security posture. You’re only as good as your data.
—D
Five nines? Prove it.
Automating inventory is a no-brainer. My issue is you're not calling out the cost.
You're creating a data source for LogRhythm. That's a start. But now you'll ingest more logs from more assets. Without proper volume management, your LogRhythm bill skyrockets.
Every new asset you auto-add is a new log source. Have you filtered what events you're collecting from these systems, or are you just taking the default log feed? The cost delta between curated logging and a firehose is massive.
Good data is worthless if you can't afford the platform to analyze it.
show me the bill
This is a solid automation approach. I've seen similar scripts become a hidden cost driver when they're deployed without corresponding log source planning.
Your script adds assets, but each new asset typically enables a default log collection profile. Have you compared the licensing impact of adding, say, fifty newly-discovered workstations versus implementing a targeted Windows Event collection policy first? The per-asset cost can surprise teams who focus only on the inventory automation benefit.
Consider integrating a step that tags assets with a provisional "logging tier" in your CSV, so the import process can apply appropriate log policies from day one. That prevents the cost spike user199 mentioned while maintaining your data freshness goal.
Your bill is too high.
Yeah, the cost angle is something I hadn't considered at all. I was just focused on getting the list current.
> provisional "logging tier"
This sounds smart. But I'm a bit lost on the practical side. Would that tag in the CSV just be a manual column I review before import, or is there a way to make the script assign a tier based on something like the AD OU or computer type automatically? I'm worried about adding a manual review step that slows the whole automation down.
One step at a time
Yeah, that's a super practical use of PowerShell for cleaning up inventory. The 30-day filter for stale systems is key, I've seen lists clogged with old VMs nobody remembers.
Quick question about the IP column - does your script try to resolve the hostname to an IP, or is that field just left blank for manual fill? I'm wondering if a failed DNS lookup could flag a stale asset you might have missed.
Still learning
You can definitely automate the tier assignment. I do this based on AD group membership or OU path.
For example, servers in the "Prod-Servers" OU get a "full" logging tier tag, while workstations in "Remote-Employees" get a "baseline" tag. The script just adds a "LoggingTier" column with those values.
Then in LogRhythm, you set up your log source policies to key off that column during the import. It adds zero manual steps.
Automate the boring stuff.