ESD Summary Tool
At the Marine Corps Enterprise Service Desk, a routine call can require a surprising amount of searching. An analyst might need a user's account status and group memberships, a workstation's serial number and OU, or a printer's server and location. The information is available, but gathering it can mean moving between several administrative screens while the caller waits.
I built the ESD Summary Tool in my spare time to bring those recurring lookups into one PowerShell workflow. An analyst chooses what to look up, enters the information they have, and gets a formatted summary they can use to troubleshoot or document the ticket. The goal was simple: spend less of the call hunting for context and more of it solving the problem.
Stack: PowerShell 7.3+, Active Directory PowerShell module, Windows, and a domain-joined workstation with appropriate read access.
The repeated work
The same handful of questions came up across many calls, but the path to an answer changed with the object in question. A user lookup could involve account state, groups, Microsoft 365 or Adobe-related memberships, and Exchange attributes. A workstation lookup might start with a name or serial number and end with its operating system, IP address, last logon, and location in Active Directory. Printer issues called for a queue, server, driver, address, and physical location.
Each lookup was manageable on its own. Repeating the navigation throughout the day was the part I wanted to improve.
Building one place to start
I organized the script around a menu for user, workstation, and printer summaries, with a separate view of the analyst workstation's CPU and memory. The menu makes the common paths easy to find; the underlying PowerShell functions can also be called directly.
For workstation searches, the tool tries an exact match before widening to a prefix and then a contains search. That gives a precise query the fastest path while still helping when an analyst has only part of a name. When a search returns several candidates, an interactive grid lets the analyst choose the right record rather than guessing. A formatted summary can be copied to the clipboard for a ticket update.
A printer call shows why those small choices matter. An analyst can search for the queue, see its server, location, driver, and IP address, then put the relevant details in the ticket without repeating the lookup in another window. The tool does not resolve the printer issue by itself; it gives the analyst a clearer starting point.
A short team rollout
The first version handled basic lookups. I later refactored it into reusable functions, improved the search paths and error handling, and made the output more useful for documentation. The menu is a front end for functions that can also support other scripts.
The tool was deployed to at least 12 analysts on its first day. That mattered more to me than a long feature list: other people working the same queue could use it for the same friction I had noticed. The original workflow took several screens and minutes of navigation; the consolidated lookup returned the relevant summary in seconds. I have not run a controlled timing study across call types, so I would treat the time saved per call as an observation rather than a measured average.
What I took away
This project taught me to look for the repeated steps inside a job before trying to automate the whole job. Search order, handling ambiguous results, and producing ticket-ready output were as important as retrieving the data. Those decisions made the script useful during a live call.
The tool depends on a Windows domain environment, PowerShell 7.3+, and the Active Directory module, and its licensing and Exchange details reflect the environment it was built for. An organization adapting it would need to review those assumptions. I would also like to measure lookup times more systematically and add repeatable tests around the search and formatting functions.
What happened after the pilot
When I started, there was no explicit rule for or against analysts using scripts, and a couple of colleagues had written small ones for their own tasks. I built this one in my spare time because it looked like the highest-value improvement I could make to the calls we handled every day. The prototype was in use for a few weeks. Management then decided to disallow custom scripts in production, and the team stopped using it. I asked to continue and develop the tool further, explaining that it ran with read-only access through a non-admin account and saved time during calls. My request was denied.
Management eventually released an official toolbox approved for analysts to use in production. I cannot say that my script initiated its development. What my pilot did show was that bringing these routine lookups into one workflow could make an analyst's job easier.
The ESD Summary Tool is no longer used in production. I still consider it a meaningful project: I found a recurring problem in my own work, built and shared a solution, and saw how useful it was to colleagues. It also taught me something I did not expect to learn from a script: before building a tool for a team, find out what the team's policy is, because a good tool can still be the wrong one for the environment. The production decision is part of the story, not a reason to leave the project out.