Dell OS10 Support Bundle Before Wipe: What to Capture for Device Grading

Short answer

For an owner-authorized Dell OS10 switch, collect the support bundle before the wipe when the asset record needs diagnostic or grading evidence. Generate the bundle, confirm both the archive and its MD5 file, transfer them into restricted case storage, validate the checksum, and only then remove the on-switch copy if policy permits. A command that was accepted is not proof that the bundle finished.

Scope: This workflow is for switches your organization owns or is explicitly authorized to process. A support bundle can contain configuration, topology, addressing, logs, certificates, and other customer-sensitive material. Treat it as restricted evidence, never as a public resale attachment.

Pre-wipe checklist

• Match the chassis and work order without copying private identifiers into public notes.
• Confirm the installed OS10 release and record the current boot image.
• Confirm enough local storage is available for a new bundle.
• Start a captured console session and timestamp the collection window.
• Generate one support bundle and monitor its progress.
• Confirm an archive and matching MD5 file exist.
• Transfer both files to an access-controlled case folder.
• Verify the checksum after transfer.
• Record sanitized grading signals separately from the raw bundle.
• Delete the on-switch copy only after verified transfer and only if the work order allows it.
• Proceed to the authorized wipe only after the evidence step is closed.

If the console parameters are uncertain, establish a stable session first using the default console speed reference. Do not begin a long collection through a noisy or intermittently disconnecting session.

What the bundle is for

A support bundle is useful when a powered switch needs more than a cosmetic grade. It can preserve evidence of software health, recent faults, interface behavior, storage conditions, and other state that may disappear after a reset. This makes it valuable for exception handling, repair triage, RMA decisions, and higher-confidence resale grading.

It is not a public certificate of sanitization. Keep the raw archive inside the approved evidence system. The public or customer-facing asset record should contain only the allowed summary: model family, software train, collection result, checksum verification result, and disposition decision.

1. Capture identity and storage context

Start with non-destructive commands and keep the full transcript internal:

show version
show inventory
dir supportbundle

Record the software version, active image, bundle directory state, and collection start time. Sanitization should remove serial numbers, service tags, MAC addresses, IP addresses, hostnames, usernames, license identifiers, customer names, and any configuration fragments.

A previous archive may belong to another case. Do not reuse it simply because a filename exists. Either associate it with verified provenance or create a new bundle under the current work order.

2. Generate the support bundle

On OS10 10.5.2.0 and later, the standard command is:

generate support-bundle

For an older installed release, follow the command documented for that exact release. Some older OS10 procedures use:

generate support-bundle enable-all-plugin-options

Do not paste the older form blindly into a newer system, and do not start repeated jobs because the prompt returns quickly. Bundle generation is asynchronous and can take time.

3. Monitor progress instead of guessing

Use both the bundle directory and the system log:

dir supportbundle
show logging log-file | grep "SUPPORT_BUNDLE_STARTED"
show logging log-file | grep "BUNDLE_COMPLETED"

The start event proves that the job entered the collection workflow. It does not prove completion. A finished job should leave a support-bundle archive and its MD5 companion in the bundle directory, followed by a completion event.

Field note: In a sanitized owner-provided S5248F-ON session running OS10 10.5.2.7, diagnostic collection was handled as a separate pre-wipe evidence step. The useful proof was the resulting artifact and completion state—not merely command acceptance. The session also reinforced why the software version must be captured before selecting release-specific commands.

If the archive does not appear, the completion event is absent, or free space is exhausted, mark the evidence step failed. Preserve the console transcript and error state; do not claim that a bundle was collected.

4. Verify the archive and MD5 pair

After completion, run:

dir supportbundle

Your internal record should identify the newly created archive and the matching MD5 file without exposing their original names publicly. Check all of the following:

Check	Pass	Fail
Job state	A completion event follows the start event	Only a start event, timeout, or collection error
Files	Archive and matching MD5 file are present	Either file is missing
Provenance	Creation time matches the current work order	File predates the collection or provenance is unclear
Transfer	Both files arrive in restricted storage	Partial, interrupted, or unapproved destination
Integrity	Calculated checksum matches the supplied MD5	Mismatch or checksum not checked

The MD5 companion is an integrity check for transfer, not a modern authenticity guarantee. Preserve the original access controls and chain of custody around the case folder.

5. Transfer and extract it safely

Use a transfer method approved for the bench and supported by the installed release, such as SCP, SFTP, HTTPS, or controlled removable media. Use release-specific syntax from the approved runbook; avoid improvising credentials or destinations in a captured public transcript.

Transfer the archive and checksum file together. On the evidence workstation:

1. Place them in a new, access-controlled case directory.
2. Calculate the archive checksum and compare it with the supplied MD5 value.
3. Scan the archive under the organization's evidence-handling policy.
4. If extraction is required, extract only inside an isolated case directory with current archive tooling.
5. Review only the minimum files required for grading or triage.
6. Keep the raw archive out of public tickets, resale listings, and shared chat.

Do not upload the bundle to a public file service. Do not paste configuration or log excerpts into a resale record merely to demonstrate that collection succeeded.

6. Remove the on-switch copy only after verification

Once the off-device copy is verified and retention policy is satisfied, the approved cleanup form is:

delete supportbundle://<verified-bundle-file>

Replace the placeholder using the exact filename shown by the device. Confirm the target before executing it. Then check the directory again:

dir supportbundle

If the work order requires preservation on the device until a later checkpoint, leave it in place and document that decision. Cleanup is not more important than evidence retention.

What never belongs in a public resale record

Do not publish the raw bundle or unsanitized transcript. Exclude:

• complete running or startup configuration;
• customer, site, user, and hostname information;
• management, peer, and service IP addresses;
• MAC addresses and private asset identifiers;
• serial numbers or service tags when policy treats them as restricted;
• license, entitlement, certificate, and key material;
• passwords, tokens, communities, hashes, and authentication settings;
• routing neighbors, VLAN design, topology, and log lines that reveal the prior environment.

A safe public note is short: support bundle completed, transfer integrity verified, restricted artifact retained under the work order, and no raw diagnostic data published.

Device-grading signals

The bundle complements—not replaces—simple bench observations. Use it to support a disposition decision:

• Pass for normal processing: collection completes, archive integrity verifies, no blocking storage or boot errors appear, and the switch remains stable through the evidence window.
• Conditional pass: collection completes but the transcript shows recoverable warnings or a non-current image that must be disclosed internally.
• Repair or quarantine: repeated collection failure, filesystem errors, unexplained reloads, critical hardware faults, or evidence that cannot be associated with the current asset.
• Stop and escalate: ownership is unclear, the artifact exposes regulated data, or policy requires immediate isolation instead of continued diagnostics.

For another vendor's pre-wipe diagnostic pattern, compare the FortiGate TAC report checklist and the Palo Alto tech support file workflow.

CliDeck evidence workflow

CliDeck can turn this into a repeatable bench step without making the raw bundle public:

1. Scan the asset and open the owner-approved work order.
2. Start a timestamped console transcript.
3. Run the non-destructive identity and storage checks.
4. Require an operator confirmation before starting bundle generation.
5. Capture the start event, directory listing, completion event, and sanitized result.
6. Attach the checksum result and restricted artifact location to the internal asset record.
7. Gate the wipe step on a completed evidence checklist.
8. Close with pass, conditional pass, repair, quarantine, or escalation.

The evidence record should prove what was attempted, which release context was used, whether the artifact completed, whether transfer integrity matched, who authorized the workflow, and what disposition followed. That is stronger than a screenshot and safer than publishing the diagnostic archive itself.

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

• ExtremeXOS Factory Defaults for ITAD: unconfigure switch vs unconfigure switch all - Choose the safe ExtremeXOS unconfigure switch path for resale. Covers NVRAM versus full erase, stack limits, reboot behavior, and clean-state verification.
• Ubiquiti UniFi Factory Reset: Adoption Cleanup and Resale Verification - Reset an owned UniFi switch safely, distinguish local factory defaults from controller-side adoption cleanup, and verify the device before resale.
• Ruckus ICX / FastIron Factory Reset for ITAD: Version-Safe Wipe and Verification Checklist - Reset an owned Ruckus ICX or FastIron switch safely with a release-aware command gate, stack checks, reload evidence, and post-wipe verification.
• NIST SP 800-88 Rev. 2: A Defensible Media Sanitization Process - Build an asset-level sanitization workflow with method selection, execution evidence, verification, validation and clear exception handling.
• Aruba Instant AP Factory Reset: Isolate the Device and Verify the Fresh Baseline - For an owned Aruba Instant AOS-8 access point, use the supported factory-reset procedure for the exact model and software.