CliDeck
PlatformLog in
Workspace

SonicWall TSR Before Wipe: A Diagnostic Capture Checklist for Refurbish Teams

ITAD & Refurbishment
#sonicwall#ITAD#refurbishment#verification#ITAD & Refurbishment#itad#network-device-processing
← Back to Blog

Short answer

Capture a SonicWall Tech Support Report before changing the appliance if the processing agreement permits diagnostic collection. Download it through the diagnostics interface, associate it with the exact model and SonicOS version, and store it in a restricted evidence location. A TSR can support troubleshooting and grading; it does not prove that the firewall has been wiped or that every hardware component works.

Decide whether collection is allowed

A used firewall may still hold customer network details. Diagnostic collection is a separate decision from permission to reset the unit. Confirm whether your task calls for preservation, return, deletion, or no collection at all. If the policy prohibits retaining configuration-derived information, record that restriction and skip the report.

Do not interrupt a required incident-preservation process by performing a reset first. Conversely, do not retain a report indefinitely merely because it might be useful someday.

Prepare the capture

Create an internal job identifier and record the appliance model, software build, current uptime if available, and observed fault. Note whether the unit was already reset before arrival. A report from a clean configuration cannot reconstruct the customer's original failure state.

Use authorized management access on an isolated bench. If management is inaccessible, document the failure and collect the console boot observations available to you. Do not perform a destructive recovery solely to obtain a pre-reset report: after recovery, that original state is already gone.

Generate and export the report

In the SonicOS diagnostics area, locate the Tech Support Report controls. The navigation changes between generations and releases; follow the controls presented by the actual firewall rather than an old screenshot.

  1. Record the report options selected, including any additional diagnostic sections.
  2. Generate the report and allow the download to finish.
  3. Save it into the restricted job directory, using an internal asset identifier.
  4. Confirm that the downloaded file is non-empty and corresponds to this unit.
  5. Record the capture time and the workstation clock's time zone.

If policy permits a local integrity record, calculate a digest after download:

shasum -a 256 sonicwall-tsr-private.txt

Replace the filename with the real downloaded filename. A matching digest confirms that the same file is being handled; it says nothing about the accuracy or completeness of the appliance's reported state.

Verification note: capture quality is a separate pass/fail decision

Require three things before marking capture complete: correct device association, a readable or otherwise valid report file, and a known storage destination with appropriate access. If the report is empty, interrupted, or generated after an unintended reboot, mark the limitation explicitly.

Keep a separate hardware grading checklist for power stability, console access, interface link, thermal behavior, and startup errors. Do not turn a successful TSR download into an automatic hardware-pass decision.

Protect the report through reset and handoff

Treat the report as customer-sensitive even when no obvious password appears in a quick inspection. Network names, public addresses, usernames, VPN structure, and identifiers can still reveal customer information.

Store the raw file privately. Publish only short, sanitized examples when there is a specific reason, and never attach the full TSR to a resale listing. Follow the agreed retention schedule for the downloaded copy and any appliance-local copy.

The asset record should state whether capture succeeded, why it was needed, where the authorized copy resides, and what must happen to it after processing. Then continue with the SonicWall SafeMode reset checklist.

CliDeck Workspace can capture the console side of the task and preserve operator notes. Store the diagnostic bundle in your approved evidence system rather than in a public article or shared customer-facing transcript.

Safety note: This guidance applies only to devices your team owns or is authorized to process. Use the approved, device-specific procedure, customer policy, and your organization’s sanitization and evidence procedures.

Who this is for

This guide is for ITAD teams, refurbishment teams, network engineers, and operations teams who need to perform an owner-authorized reset, recovery, verification, or documented device-processing workflow on network devices that your team owns or is authorized to process.

When to use this

Use this guide when:

  • Your team owns or is authorized to process the device.
  • You need to reset, zeroize, recover, reimage, verify, or document a network device.
  • The result must be attached to an asset, resale, reuse, refurbishment, or recycling workflow.

When not to use this

Do not use this guide when:

  • You do not own or have authorization to work on the device.
  • The device is outside your approved change, recovery, or processing scope.
  • The task may expose customer data, secrets, licenses, or credentials that you are not allowed to view or store.
  • You need a certified data destruction procedure and your organization has not provided one.

Workflow

  • Confirm ownership, processing scope, device identity, and approved procedure.
  • Connect through the console or approved management path and capture the session context.
  • Run the reset, zeroize, recovery, reimage, or verification steps required by the article and vendor documentation.
  • Reboot or reconnect as needed and verify the expected clean, default, or recovered state.
  • Attach logs, verification output, exceptions, and final pass/fail/exception status to the asset record.

Verification checklist

  • Device identity matches the asset record.
  • Console or session log is attached to the asset.
  • The reset, zeroize, recovery, or reimage method is recorded.
  • The post-reboot state matches the expected clean or recovered state.
  • Verification commands and outputs are captured.
  • Exceptions or failures are quarantined instead of marked ready.

Resale and evidence checklist

Before marking the device ready for resale, capture:

  • Device model and serial number
  • Console transcript or session log
  • Reset, zeroize, reimage, or recovery method used
  • Any confirmation prompts and operator decisions
  • Post-reboot state
  • Visible default or clean-state prompt
  • Verification commands and outputs
  • Hardware alarms or boot errors
  • License, entitlement, or customer identifiers handled according to policy
  • Exceptions, failures, or quarantine decisions
  • Final pass/fail/exception status attached to the asset record

What not to publish

Do not publish raw transcripts that include customer names, public IP addresses, VPN settings, license keys, entitlement IDs, serial numbers that must remain private, passwords, tokens, certificates, or other sensitive identifiers. Keep sensitive evidence in the customer-approved internal system and publish only sanitized examples.

Common mistakes

  • Processing a device without owner authorization or the correct asset record.
  • Treating a factory reset as certified data destruction.
  • Failing to capture confirmation prompts, reboot state, verification output, or exceptions.
  • Publishing raw logs that contain customer identifiers, licenses, keys, passwords, or configuration remnants.

CliDeck workflow fit

CliDeck can help turn this procedure into a repeatable workflow. Console Server Go is useful for portable rack-side console access and shared remote support. Net Controller is better for ITAD, refurbishment, and batch processing where multiple devices need barcode tracking, approved scripts, logs, API updates, and evidence-style results.

Net Controller can help operators connect devices, scan assets, run approved workflows, capture console logs, require verification steps, and attach the result to the asset record.

FAQ

Is this a certified data destruction procedure?

No. This article describes a practical, owner-authorized workflow and verification approach. Certification depends on your organization’s process, evidence requirements, customer contract, and any formal certification program that applies.

Does CliDeck provide vendor OS images?

No. CliDeck does not distribute vendor operating system images. Recovery or reimage workflows can use images already present on the device or images provided by the customer where the customer has appropriate rights and licenses.

Should I publish the full console log?

Usually no. Keep complete evidence in the approved internal system and publish only sanitized examples. Console logs can contain serial numbers, license details, customer names, IP addresses, keys, passwords, or configuration remnants.

Can CliDeck help with this workflow?

Yes. Console Server Go helps with portable rack-side console access and shared remote support. Net Controller is better for batch ITAD, refurbishment, recovery, provisioning, barcode/API tracking, and evidence-style results.

Related guides