Check out what I made: a script to auto-populate asset lists from AD

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.

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.

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.

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.

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.

That's a great idea! Using the OU path to tag the tier is really clever. I'm curious about how it would handle, like, a computer that's moved to a new OU between script runs. Would the tag just update automatically the next time the script runs? Or would you need to clean up old entries in LogRhythm somehow?

That's a really important point about cost. I hadn't considered the licensing impact from automatically enabling new log sources.

When you mention the default log feed, is that typically a preset policy in LogRhythm that gets applied to any newly imported asset? I'm trying to understand where the cost control point is, in the platform itself or in the initial data collection setup.

Nice approach with the 30-day filter. I do something similar, but I've found it's worth checking the `lastLogon` attribute alongside `lastLogonTimestamp`. They replicate differently, so sometimes a system with a recent `lastLogon` but stale `lastLogonTimestamp` can slip through (or vice versa). Quick sanity check.

How are you handling the IP column? If you're resolving it, do you have fallback logic for when DNS fails?

Automation is definitely key for accurate inventory, but I'd caution against relying solely on `lastLogonTimestamp`. It only replicates within the domain, so a computer that authenticates against a different DC might not update it promptly. You might want to also check the local `lastLogon` attribute, though that comes with its own replication trade-offs.

Regarding the IP column, leaving it optional is wise. Automated DNS resolution can fail for stale records or offline systems, which ironically could give you a false positive for an inactive asset. I usually have the script try the resolution but mark it as "UNRESOLVED" in the CSV if it fails. That way it's still imported, but the gap is visible.

Finally, while this keeps your asset list fresh, have you considered how LogRhythm handles decommissioning? If a system drops out of your filtered AD query, does your import process remove it from the asset list, or does it just add new ones? Without a cleanup mechanism, you're only solving half the problem.

The cost angle is real, but I think focusing on tagging in the CSV misses the point of where the actual policy failure happens.

The issue is that your SIEM platform, by default, probably assigns a log collection profile to any new asset it sees. Even with a "baseline" tag in the CSV, if the import process doesn't honor that tag and just applies the default, you're still paying.

So the real question for the OP is: does their import method actually *use* that tagging column to apply a specific, minimal policy? Or does the tag just sit there as metadata while the expensive default kicks in anyway. I've seen the latter happen more often than not.

That 30-day filter is a solid idea, but `lastLogonTimestamp` can lag. I've had it miss freshly built servers for a couple days. I add a check for `pwdLastSet` as a secondary signal - if the computer account password was set recently, it's probably active even if the logon timestamp is old. Helps catch those new deployments before their first user login.

Your output format is key. I've seen scripts like this break on import because of trailing commas or extra quotes. Could you post the few lines where you build the CSV object? I'm curious if you're using `[PSCustomObject]` with the exact column order or if you're handling it differently.

Oh, that's a good point about `pwdLastSet` for new servers! I hadn't thought of that. It makes sense that a new deployment wouldn't have a login yet.

Could checking that attribute also help spot inactive computers that haven't had their password reset in ages? I'm trying to learn all the different signals for stale assets.

Great question! Yes, `pwdLastSet` can be a useful signal for inactivity, but it's not perfect on its own. By default, computer accounts automatically reset their own passwords every 30 days. So if that attribute is older than, say, 45 days, it's a pretty strong indicator the machine is off the network or dead.

One caveat: this auto-reset can be disabled via Group Policy. I've seen it turned off in some locked-down environments, which would make the `pwdLastSet` date stay static on a perfectly healthy machine. You'd want to pair it with other checks, like looking for recent event log entries or network scans, to be sure.

You've hit the core problem: your asset list is only as good as its freshness. Scheduling this is the right call, but I'd suggest adding a quick pre-run check for the AD module and the domain connection. I've seen scheduled tasks fail silently for months because a server reboot dropped the module load or a network glitch broke the DC connection.

A simple try/catch around `Get-ADComputer` with a failure written to a log file can save you from a false sense of security when the automation breaks. Also, consider whether your script should delete or disable assets in LogRhythm that fall out of the CSV, or if you're just adding new ones. That's a policy decision, but without a cleanup mechanism, you're just layering fresh data over stale entries.