Technical Guide: How to perform an RMA replacement of a FortiGate
| Description | This article describes the process of performing an RMA replacement of a defective FortiGate, including:
While this process is similar for Fortinet products in general, this article is written specifically for handling FortiGates. |
| Scope | FortiGate, RMA. |
| Solution | Before anything else, review the FortiCompanion to RMA Services document available for download from the Fortinet Support Site's documents section. This document includes detailed information for everything related to the Fortinet RMA process, including the scope of support included in each tier of Hardware Support (Return and Replace, Advanced Replacement, Priority RMA (PRMA) and Secure RMA), explanations/definitions for RMA ticket statuses, and guidance on how Fortinet handles defective units that clients have returned as part of the RMA process.
Table of Contents:
Initial steps for determining if an RMA replacement is required. To determine if a FortiGate is facing a hardware issue that can warrant an RMA replacement, collect the information requested in Technical Tip: Required information for FortiGate RMA verification before opening a TAC ticket (this reduces the time needed to perform an RMA). Note that it is mandatory to have someone on-site with the FortiGate when validating, as RMA verification requires that someone be able to make physical network/serial console connections to the FortiGate, check status LEDs, take pictures, etc.
As a reminder, RMA replacements are used specifically to resolve hardware-related issues with the FortiGate and other Fortinet products) Software-specific issues are highly unlikely to be resolved by an RMA replacement and will generally be denied unless there are clear indicators that they are caused by hardware issues.
For example, kernel panics on the FortiGate may be caused by hardware issues (and with confirmation from Fortinet TAC can warrant hardware replacement), whereas FortiGates entering conserve mode largely occur due to software-related problems (and so hardware replacement will not resolve the issue).
Important Note 1: All RMA requests require Fortinet TAC to verify the hardware failure based on gathered evidence (discussed further below). However, clients whose FortiGates have Priority RMA (PRMA) can choose to refuse troubleshooting and proceed straight to RMA.
Important Note 2: Per the Fortinet Product License Agreement / EULA, FortiGates subjected to abnormal physical or electrical stress, misuse, negligence, or accident are not eligible for RMA. This can include units that have been subjected to lightning strikes, and is true for all levels of RMA Hardware Support (see '7. Disclaimer of Other Warranties and Restrictions' in the above EULA).
If there are enough indicators present to confirm that a hardware issue is present and that an RMA is justified, then gather the evidence and move to the next section of this guide.
Before opening a ticket, ensure that all evidence gathered from following Technical Tip: Required information for FortiGate RMA verification is on hand and available to be uploaded. The previous section mentions this, but presenting the following to TAC can expedite the handling of RMA cases:
Additionally, it is recommended to explicitly state the following in the initial ticket statement, even if the information is generally included when opening the ticket:
Opening a ticket with Fortinet TAC/RMA. Generally speaking, it is recommended to open a Technical Support Ticket when initiating a request for a FortiGate RMA, rather than starting with a DOA/RMA Ticket. This is because Fortinet RMA requires that TAC works with the client to validate that a hardware replacement is required, and so cases that are opened as DOA/RMA will often be moved back to TAC if it is unclear that there is a confirmed hardware issue.
When opening a Technical Support Ticket, ensure that all of the evidence and responses gathered from Technical Tip: Required information for FortiGate RMA verification is uploaded to the ticket. With sufficient evidence available at the beginning of the ticket, TAC can be confident that a hardware issue does in fact exist and the ticket can be moved more quickly to the RMA team for further handling.
To open a ticket to request RMA, log into the Fortinet Support Site (using a user account that has permission to open FortiCare tickets), select the Support dropdown in the upper navigation bar, then select FortiCare -> Manage Tickets. Next, select the New Ticket button on the right side, then select Technical Support Ticket -> Submit Ticket. Follow the steps specified by the Fortinet Support site, and ensure that a detailed explanation is provided in the Comment section, and that the files gathered previously are successfully uploaded as Attachments. Include troubleshooting contact details and availability in case additional information is needed to verify a hardware issue.
Note: In cases where there is very clear evidence of a hardware issue (such as dead-on-arrival (DOA) hardware), it can be OK to open a DOA/RMA Ticket directly, rather than going through a Technical Support Ticket for validation. Make sure to have this evidence available on the ticket; it may be redirected to TAC for validation.
Once validation of the hardware issue is completed, TAC will move the ticket over to the RMA team. The RMA ticket will prompt clients to confirm the shipping and billing address to be used, and it will also ask if the RMA team should 'Automatically transfer all active services and support contracts to a new unit'.
If this option is selected, then Fortinet will automatically register the replacement unit when it is shipped out, and Fortinet will also automatically transfer all contracts and licenses associated with the defective unit to the replacement unit.
Important: Do not select this option if the defective FortiGate is still active in production and handling traffic, either as a standalone unit or as an active member of an HA cluster. If the licenses are transferred away from the defective FortiGate, then license-dependent features like FortiGuard Category lookups for Web Filtering will stop functioning, which could lead to further impact on the network. Only select the above option if the defective FortiGate is already fully offline and/or removed from the production environment. See also: RMA Note: Contract and Service Auto Transfer Option
If the above option is not checked, then the licensing will remain with the defective FortiGate for the time being. The RMA ticket will include steps so that clients can initiate the license/contract transfer after the replacement FortiGate is received (see also: Customer Service Tip: How to register Fortinet products in the Fortinet Support Portal).
Preparing and deploying the replacement FortiGate. Once the replacement FortiGate is received, it will need to be prepared to take the place of the defective FortiGate. How this should be approached will depend on the circumstances of the current deployment, but the first step is to migrate the existing configuration:
Once a configuration backup is available, the next step is to ensure that the replacement FortiGate is running the same firmware version as the original defective FortiGate. To do this, there are several options available:
Once the replacement FortiGate is running the same version as the original FortiGate, the configuration backup can be restored. In cases where a config backup is not available, the administrator will need to manually re-configure the FortiGate before deploying the replacement (see 'Getting started' linked above). For more in-depth instructions for restoring FortiGates after RMA (standalone, HA, and chassis), refer to the following KB articles:
Once the replacement FortiGate is configured, it is ready to take the place of the original defective FortiGate. It is strongly recommended to schedule a maintenance window for this operation and to have someone available onsite that has physical access to the FortiGate as well as a workstation/laptop with an Internet connection (for example, using a cellular hotspot). This is especially necessary if TAC assistance is required, as Fortinet TAC can only assist if some kind of administrative access to the FortiGate is available (otherwise, troubleshooting cannot occur).
Note regarding FortiToken on the FortiGate: When a FortiGate is replaced via RMA, any FortiTokens assigned to users on the FortiGate must be deleted, re-registered, and re-assigned (it is not possible to restore the configuration backup and have functioning FortiTokens on the new FortiGate). Refer to the following KB articles regarding FortiToken registration, transfer, and re-assignment following RMA:
Returning the defective FortiGate and completing the RMA. After the replacement FortiGate is deployed to production, the defective FortiGate must be returned to Fortinet. Note that while Fortinet covers the cost of shipping the replacement unit to the client, the client is responsible for any import duties, taxes, or other fees associated with receiving this shipment. Additionally, the cost of return shipping for the defective FortiGate is also the responsibility of the client, unless the FortiGate has Priority RMA (in which case Fortinet also covers the cost of return shipping). Follow the instructions provided on the RMA ticket for shipping the defective FortiGate back to Fortinet.
Note regarding data deletion: As discussed in the FortiCompanion to RMA Services document (under 'Handling Procedure for Customer-Returned Product'), all products returned to Fortinet have their media formatted and configuration reset to factory defaults. From there, the product has the hardware failure verified, and the unit is either refurbished if viable or scrapped by a certified vendor if not (this includes physical destruction of data media).
Users in need of maximum security should strongly consider purchasing the Secure RMA service, which allows for the non-return of defective hardware and the protection of data from within the client's premises. This is a separate supplementary license that can be added per product for all RMA replacement levels. |