Automation I've built, engagements I've led, and things I build on my own time.

Situation

Analysts copied threat details out of the EDR console into tickets by hand. Customer notes varied from one analyst to the next, and verdicts and exclusions were separate steps.

What I built

Three chained packages:

• Enrichment. Pulls the full threat bundle and posts an internal note. Sets the ticket's company, type, and subtype for the board, then finds the right agreement. Notes cover lateral movement and handle blank users and file paths with trailing empty parentheses.
• Verdict. The engineer picks a verdict. The package posts a standardized customer note, sets the verdict in SentinelOne, and writes the ticket number back to SentinelOne as a note. On a false positive it unquarantines automatically and reminds the engineer about exclusions.
• Exclusions. Adds hash or path exclusions scoped to a site or group.

How it works

• Runs two ways: an engineer starts it from the ticket chat, or a new ticket or any ConnectWise ticket action triggers it automatically.
• Resolves the right SentinelOne portal and API token per customer, across several consoles.
• Board-aware logic handles different markets and agreement types.
• Hostname searches are scoped from the PSA company to the matching SentinelOne site, so lookups across portals stay clean.
• Fixed an unquarantine bug by checking the vendor's Swagger spec for the exact action name.

Situation

Phishing triage meant manual entity lookups, hand-built notes, and a restore-or-decline call with no consistent customer message.

What I built

• Enrichment. Builds a full entity note: defanged links, the sending IP with whois, and SPF failures flagged at the vendor layer. Maps the Avanan tenant to the PSA company, sets ticket type and subtype, assigns the agreement, and restores the original requester on CC after patching the ticket.
• Restore decision. The engineer approves or declines through a form. The package posts a customer note and calls the real restore, decline, or quarantine action. On approval it offers to chain into the allowlist.
• Allowlist. Phishing and spam lists, tenant-wide or recipient-scoped, including domain-only entries. Warns before submitting if SPF failed.
• Email download. Uploads the message to the ticket as a document. Delete-after-upload is waiting on a permissions change.

How it works

• Signs every request with SHA-256 over the request ID, app ID, date, endpoint, and secret. The allowlist endpoint needs the full path and query string in the signature.
• Found an undocumented company-name field on the tenants endpoint and used it as a clean tenant-to-company mapping.
• Ran two search endpoints side by side to check a vendor support claim against the vendor's own published docs.
• Fixed customer notes that weren't emailing the contact list. Ticket-level automatic-email flags defaulted to false.
• Built so the enrichment package can be copied to other boards and markets once the first is stable.

Situation

Retiring a device meant working through several consoles by hand, each with its own search quirks.

What I built

One package that starts from a hostname. It finds the device in SentinelOne and uninstalls the agent, unlinks and deletes it in Tenable, and finds it in NinjaOne. If a hostname matches more than one organization, it lists every match for manual review.

How it works

• Scopes each search from the PSA company to the right site, so it never touches the wrong customer.
• Fixed a skip cascade, so one platform with no match no longer stops the rest of the run.
• Tenable matching returned nothing at first. The asset field is a NetBIOS name, not an FQDN, so the filter changed. Companies now match on Tenable's custom name, exactly equal to the PSA company name, after aligning all child accounts.
• Tested live against both online and offline devices.

Situation

Travelers had to be added to a travel-allowed group on their leave date and removed on their return date. The first version was hardcoded to one customer.

What I built

The engineer picks the user and the group from dropdowns built live from the client's tenant. The package adds the user at the start of the leave date and removes them at the end of the return date, with internal notes at setup, on add, and on removal. A same-day trip adds the user immediately and confirms in chat.

How it works

• Dynamic forms through the platform's form_def property. Users are enabled, non-guest accounts from Graph. Groups are travel groups Graph can add members to, excluding synced, dynamic, and mail-enabled security groups.
• Validates dates and stops if leave and return are the same day, out of order, or already past.
• Fixed a time zone bug. The date picker returns midnight UTC, which scheduled removals for the evening before the return date. It now adds at 12:00 AM and removes at 11:59 PM in a fixed local time zone, converted to UTC for the scheduler.

Situation

Mailbox storage questions meant signing in to the admin center for each client.

What I built

The engineer picks a user or shared mailbox from a live list that shows archive on or off next to each name. The package reports primary storage against quota, item count, deleted items, and archive status, size, and auto-expanding state. It then asks whether to enable the archive and logs everything to the ticket.

How it works

• Client-scoped Graph and Exchange Online tokens, with the tenant's onmicrosoft domain resolved automatically.
• Exchange cmdlets run through the same admin API invoke pattern as the platform's built-in activities.
• Fixed a missing-data bug. Get-Mailbox by identity returns a trimmed object without archive fields, and a helper wrapped its return value in an array. A filtered lookup and a corrected return fixed both.

New builds

• New firewall deployments across Palo Alto, Fortinet, Cisco, Meraki, WatchGuard, UniFi, and others.
• Palo Alto HA pairs from the PA-200 to PA-1400 range, onboarded to Panorama.
• More than one Panorama built from scratch, both on-premises and hosted in Azure.
• Wireless deployments on Meraki and UniFi.
• SD-WAN across branch and multi-hub topologies, and TLS decryption.

Migrations

• Cross-vendor firewall migrations, moving clients from one platform to another.
• Palo Alto to Palo Alto hardware migrations, including multi-site rollouts.
• Switch migrations and refreshes.
• Office network relocations and segmentation with new VLANs and DMZs.

Situation

Recurring work across many clients. Workloads moving to Azure from AWS and on-premises servers. Organizations moving into Microsoft 365 from Gmail and other tenants. Machines moving from local accounts or on-prem AD to Entra ID join or hybrid join.

Approach

Inventory first: workloads and their dependencies, users and mailboxes, DNS, devices and the GPOs they rely on. Then a cutover plan with a rollback path. For mail, domain and MX changes are sequenced so mail keeps flowing, with SPF, DKIM, and DMARC set up for the new platform. For devices, identity moves first, GPOs become Intune configuration profiles, and Conditional Access is enforced once the fleet is compliant.

What I built

• Azure IaaS environments, and lift-and-shift migrations into them.
• Target tenants, mailbox and data migrations, and domain cutovers.
• Entra ID and hybrid join, Intune MDM and MAM on every platform, and SSO for cloud apps with Entra ID as the identity provider.