ExtremeXOS Factory Defaults for ITAD: unconfigure switch vs unconfigure switch all
Short answer
For an owner-authorized ExtremeXOS switch, choose the smallest erase scope that satisfies the work order. A normal unconfigure path returns configuration to defaults. An NVRAM erase path also overwrites selected non-volatile state and reboots. A full erase path can remove software images and render the unit unable to boot normally until an approved BootROM-rescue process restores it.
Do not use erase all as a generic resale reset. First identify the EXOS release, standalone or stack role, expected image partition, evidence requirement, and whether the unit needs a configuration reset or true image recovery.
Scope: This workflow applies only to equipment your organization owns or is explicitly authorized to process. It is not a password-bypass guide and it does not substitute for a contractual media-sanitization requirement.
Choose the erase scope
| Path | Intended result | Do not use it when |
|---|---|---|
| Unconfigure switch default path | Reset switch parameters to their normal factory baseline | The work order requires NVRAM/image recovery or the platform has a stack-specific requirement |
| Unconfigure switch all | Broader configuration-default scope, including stack-related parameters on supported releases | You have not confirmed release syntax or stack authority |
| Unconfigure switch erase nvram | Overwrite selected NVRAM state, then reboot on supported releases | You must preserve selected boot/state data or have not recorded active image context |
| Unconfigure switch erase all | Erase configuration, images, and other flash/NVRAM content | You do not have an approved BootROM-rescue plan and replacement image available |
The exact option set can differ by release and platform. Read the help for the installed image and use the approved procedure for that software train. A command from a newer manual should never be pasted into an older system without checking its local syntax.
Pre-reset checklist
- Confirm owner authorization, work order, and physical device identity.
- Isolate the switch from customer and production networks.
- Start a console transcript before the destructive command.
- Record EXOS version, BootROM version, active image partition, and stack role internally.
- Record any evidence required before configuration removal.
- Decide whether configuration default, NVRAM overwrite, or full image recovery is actually needed.
- If full erase is approved, confirm an exact model-compatible rescue image and BootROM procedure before erasing.
- Confirm stable power and console access through reboot.
- For a stack, identify the controlling context and list every member as a separate asset record.
- Keep serials, MACs, addresses, credentials, license material, customer names, and raw configuration private.
Typical read-only checks include:
show version
show switch
show configuration
If command output reveals a stack, do not assume a single member reset proves the whole stack is clean.
Configuration-default path
Use the release-supported unconfigure form when the intended outcome is a clean configuration baseline while preserving the working software path. The relevant command family is:
unconfigure switch
unconfigure switch all
The first form and the all variant have release-dependent scope. Confirm the local help and the approved runbook. Record which form you used and why it was valid for the installed EXOS release.
After reboot, verify the expected default state, image selection, console access, and stack disposition. Do not connect the device to an unmanaged customer network while verifying reset behavior.
NVRAM erase path
A supported NVRAM erase form is:
unconfigure switch erase nvram
This is more than a cosmetic clear. It overwrites non-volatile data that can include configuration selection, selected image partition, and stored messages, then causes a reboot. Capture the active image before running it, because the unit may return using its primary image rather than the image that happened to be active before reset.
Field note: In a sanitized owner-provided session on an X460G2-48p-10G4 family switch running EXOS 22.1.1.5, the command unconfigure switch erase nvram displayed a warning that non-volatile memory would be overwritten. The subsequent boot record showed a Factory Default configuration state. This is useful evidence for the NVRAM branch, but it does not validate every unconfigure variant on every EXOS release or every stack topology.
Full erase is a recovery decision
The full erase variant can remove both image partitions, configuration files, policy files, and non-volatile state. That can leave the device in a state that requires BootROM rescue before it becomes operational again.
Use it only when all conditions are satisfied:
- The work order explicitly requires full image/storage recovery.
- A compatible rescue image and BootROM procedure are available and authorized.
- The operator has stable console and power access.
- The asset record documents why the normal configuration-default or NVRAM path was insufficient.
- The expected recovery time and risk are accepted by the owner.
If any condition is missing, stop. A unit that cannot boot after an unnecessary full erase is a repair exception, not a completed wipe.
Stack and BootROM boundaries
For a stack, reset authority and retained state may be distributed across members. Work from the approved control context and verify all member records individually. Do not copy one successful console result to the entire stack.
BootROM access is an exception path, not routine evidence. Use it when a documented recovery procedure requires it or when a full erase has made normal boot unavailable. Record the reason, image source approval, recovery command sequence, and final boot result internally.
Verification before resale
| Check | Pass signal | Fail or escalation signal |
|---|---|---|
| Boot | Switch reaches normal console access on the intended image | BootROM loop, missing image, or filesystem error |
| Configuration | Factory-default baseline is displayed as expected | Prior-owner configuration, users, or management data persists |
| Stack | Each required member matches the work-order disposition | Unverified members or inherited stack state remain |
| Image state | Approved image path is readable and recorded | Unexpected partition selection or missing image |
| Evidence | Transcript shows reset choice, warning, reboot, and final checks | Only a command line or screenshot exists |
A safe public resale statement is concise: owner-authorized reset completed on a version-supported path; normal boot and clean-state checks passed; detailed evidence retained internally.
CliDeck workflow
CliDeck can enforce the decision gate before a destructive action:
- Capture version, BootROM, image, and stack context.
- Require the operator to choose configuration default, NVRAM erase, or full recovery.
- Block full erase unless a rescue plan is attached to the work order.
- Capture console warnings, reboot, and post-boot checks.
- Track every stack member separately.
- Store sanitized pass/fail evidence in the asset record.
For related workflows, compare the Ruckus ICX reset checklist, the Cisco Catalyst reset workflow, and the Arista recovery guide.
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.
Quick decision table
| Situation | Better fit | Why |
|---|---|---|
| One authorized engineer needs a quick low-risk task | Factory reset or simpler reset path | It keeps the workflow simple when no shared context, batch work, or durable evidence is required. |
| The work needs verification, handoff, or documentation | Zeroize, reimage, or documented processing workflow | It creates a clearer path for notes, logs, stop conditions, and final checks. |
| Multiple people or devices are involved | Zeroize, reimage, or documented processing workflow | Structured workflows reduce ambiguity and make it easier to prove what happened. |
When option A is enough
The simpler option is usually enough when one authorized engineer is doing a low-risk task locally, the device state is known, and the work does not require shared context, batch processing, or durable evidence.
When option B is better
The more structured option is better when the work needs repeatability, collaboration, verification, logging, asset linkage, or a safer handoff between people or teams.
Most common default
Most network console ports use 9600 8N1, but many modern switches, appliances, and server-management interfaces use 115200. Some devices use other speeds such as 38400, 19200, 57600, or 2400.
Notable exceptions
Examples:
- FortiSwitch often uses 115200.
- HPE Aruba AOS-CX often uses 115200.
- Dell OS10 often uses 115200.
- MikroTik RouterOS commonly uses 115200.
- TP-Link JetStream examples may use 38400.
- F5 BIG-IP may use 19200.
- Some UPS serial protocols may use 2400.
How to use this table
Use the table as a starting point, then verify the setting against the device label, approved device procedure, site runbook, or known-good console output. If the terminal shows unreadable characters, test the likely baud rates before assuming the cable or port is broken.
Verify against the device-specific procedure
Do not treat a reference table as a substitute for the approved device-specific procedure, site policy, or a verified device-specific runbook when the operation is risky.
How CliDeck helps
CliDeck helps teams keep console settings, notes, runbooks, and terminal sessions organized. Console Server Go can show the current UART speed on its built-in screen. Net Controller can help teams process multiple devices with standardized workflows where configured.
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
- 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.
- Brocade FastIron Factory Reset for ITAD: Config, Keys, and Boot-State Verification - Use this authorized FastIron ITAD checklist to distinguish factory-default from config erase and verify a clean boot state.
- Palo Alto Panorama-Managed Firewall Reset: Detect and Clear Managed Remnants Before Resale - Use this authorized ITAD checklist to separate PAN-OS factory-reset proof from Panorama-release verification before firewall resale.
- Check Point Appliance Factory Reset and Gaia Clean-State Checklist for ITAD - Use this release-aware ITAD checklist to select a Gaia recovery target safely, verify factory reset completion, and document a clean-state handoff.