A PowerShell Framework for Enterprise Asset Management
When I stepped into the Tool lead administrator role for ABB’s global BarScan asset management infrastructure, I inherited a fragmented and manual environment. Nine servers were spread across three international data centers, each relying on daily manual checklists for backups, regional exports, and monitoring. Troubleshooting was reactive, processes were error-prone, and visibility was limited. The solution required more than just writing scripts—it demanded building a coherent, automated system from the ground up.
Here’s how I transformed that operational complexity into a reliable, self-monitoring ecosystem using PowerShell.
1. Asset Log Report — centralized asset-change logging
Purpose
Generate an Asset Log Report from Barscan that shows backend changes to asset records (who changed what and when) for either a specific country or for all Barscan assets.
Problem (old process)
Analysts had to log into Barscan, manually select the report, add fields, run the report and save it. Requests came frequently and took time each time a report was needed.
What I automated
A PowerShell script automates the full sequence: authenticate to Barscan, select the Asset Log report, apply configured field selections, generate the output in the requested file format, and place the file at a pre-defined network path (central point). The script accepts parameters for country scope and file format so one script handles single-country and global requests.
Operational details — what matters to operators
Inputs: country (all), desired fields (preconfigured), file format, destination path.
Outputs: timestamped report file in the chosen format placed at the central storage path.
Invocation: can be run by analysts or scheduled via Windows Task Scheduler.
Logging: the script writes an execution log (success/failure, run time, record count), and returns a non-zero exit code on failure.
Access: script uses stored service credentials (Windows Credential Manager or secure PS credential store) to avoid exposing passwords.
Benefit
Approx. ~15 man-hours saved per month. Faster delivery, fewer manual mistakes, and a single authoritative file location for audit.
2. Barscan Backup File — make daily Barscan files available from any server
Purpose
Make daily Barscan backup files (previously tied to a single server) accessible from any server.
Problem (old process)
Daily backup files were generated on a particular server only. To access the files you needed to log on to that server — not ideal for on-call staff or when that server is offline.
What I automated
A PowerShell automation that locates the daily backup files on the source servers, copies them to a central file share (or a selected target server), and updates a simple index so teams can open the files from any authorised server.
Operational details — what matters to operators
Inputs: source server name, target server/share, date.
Behavior: the script can be run against a single server or iterate a list, it verifies file integrity after copy.
Invocation: can be scheduled to run after backups complete.
Failover: if a copy fails, the script retries and logs the error, persistent failures raise an alert.
Permissions: uses service account with read access on source and write on central share.
Benefit
Approx. ~2 man-hours saved per month. Improves accessibility and reduces dependency on a single server.
3. Catalog Report — quick access to catalog and model data
Purpose
Produce a Catalog Report from Barscan containing catalog number, model, description and other attributes — for a single country or for all catalogs.
Problem (old process)
Manual report generation: log into Barscan, select fields, run report; repeating work for frequently consulted catalog lookups.
What I automated
A parameterised PowerShell tool that runs the Catalog report remotely, collects the requested fields, formats the output, and deposits the file in the chosen path. The script supports filtering by country and output type selection.
Operational details — what matters to operators
Inputs: country filter, fields required (preset templates available), file type (CSV/Excel), destination directory.
Outputs: clean, column-normalised file that’s easy to consume in Excel or to feed into other tools (inventory reconciliation, procurement).
Reuse: templates for “short” and “full” catalog exports reduce friction for daily tasks.
Benefit
Approx. ~4 man-hours saved per month. Reduces time to lookup and ensures consistent column ordering and formatting.
4. Location Report — standardised location and room-tag exports
Purpose
Export Barscan location data (stock location, room tag, business unit and related attributes) per country or globally.
Problem (old process)
People manually produced location exports when needed, often with inconsistent field selections and naming conventions.
What I automated
PowerShell script to generate Location Reports consistently: authenticate, select predefined location fields, filter by country if required, produce the output file, and save it to the central path.
Operational details — what matters to operators
Inputs: country scope (single/all), required fields template, output format, destination path.
Outputs: normalized location data suitable for reconciliation with asset inventories or facility maps.
Reliability: script validates that room tags are present for required records and logs anomalies for manual review.
Benefit
Approx. ~4 man-hours saved per month. Standardises reporting and reduces manual correction effort downstream.
5. User Log Report — audit user activity in Barscan
Purpose
Produce a report of user activity in Barscan: login counts, timestamps and other audit details — either for a country or global user base.
Problem (old process)
Finding who logged in, when, and how often meant manually running logs and collating data — a repetitive task for security and support requests.
What I automated
PowerShell automation that queries the Barscan logging/audit endpoints (or report interface), collects required user activity data filtered by country if needed, and writes a timestamped export to the central path.
Operational details — what matters to operators
Inputs: country, date range, file format, destination.
Outputs: per-user activity logs that can feed audits, investigations or capacity planning.
Security: script runs with least-privilege account and produces redacted export when necessary.
Alerts: thresholds (e.g., sudden spike in failed login attempts) can be wired into alerting logic.
Benefit
Approx.. ~8 man-hours saved per month (slide figure). Faster investigations and a repeatable audit trail.
Common technical
Platform & approach: PowerShell scripts run on Windows servers, parameterised to accept country, date, file type, destination and server name. Execution is possible ad-hoc or via scheduled tasks.
Security: use Windows Credential Manager or a vault to store service credentials. Scripts should run under a service account with minimal necessary permissions. Avoid hard-coded passwords.
Logging & retries: each script writes execution logs and returns non-zero exit codes on errors. Implement basic retry logic for transient network/file share errors.
Central storage: all outputs land in a central path (single source of truth) so downstream teams always use the latest export.
Monitoring: add simple health checks and email/Teams notifications for failures or size anomalies.
Conclusion
These automations cut repetitive manual work, shorten turnaround for data requests, and centralise the outputs so other teams can reliably consume the data. I built them to be simple to operate (parameters + scheduler), secure (least privilege, credential store), and easy to extend. If you’d like, I can attach a sanitised example PowerShell template and a short how-to for running each report from Task Scheduler — or publish the sanitized code examples alongside this post.