- Windows ofrece cmdlets nativos para consultar y actualizar el firmware de SSD compatibles sin necesidad de herramientas externas.
- En entornos de producción, las actualizaciones de firmware deben probarse antes en laboratorio y aplicarse siguiendo las recomendaciones del proveedor.
- Storage Spaces Direct incluye un Servicio de mantenimiento que orquesta despliegues de firmware sin detener las cargas de trabajo.
- Las imágenes de firmware deben obtenerse siempre del fabricante u OEM y nunca de fuentes de terceros para evitar daños en las unidades.
Actualizar el firmware de un SSD en Windows era, hasta hace no tanto, una tarea bastante delicada, con riesgo de caídas del sistema y tiempos de inactividad importantes. Con las versiones modernas de Windows 10 y Windows Server, Microsoft y los fabricantes han ido puliendo el proceso para que sea más predecible y, en muchos casos, se pueda hacer incluso con el servidor en producción sin que los servicios se caigan.
En este artículo vamos a ver con detalle cómo funciona la actualización de firmware de SSD en Windows, qué necesitas para que sea compatible, qué herramientas ofrece el sistema (como los cmdlets de PowerShell), y qué buenas prácticas conviene seguir antes de tocar nada en un entorno real. También veremos casos típicos de problemas (como unidades que dejan de verse tras una actualización de Windows) y cómo afrontarlos sin liarla más de la cuenta.
Qué es el firmware de un SSD y por qué actualizarlo
El firmware de un SSD es, simplificando mucho, el “sistema operativo interno” de la propia unidad. Es el código que gestiona cómo se escriben y leen los datos en las celdas de memoria, cómo se reparten los bloques, qué hace el TRIM, cómo se corrigen errores, etc. Una actualización de firmware puede corregir fallos críticos, mejorar estabilidad, e incluso pulir el rendimiento o compatibilidad con versiones nuevas de Windows.
Tradicionalmente, actualizar firmware de discos (HDD o SSD) era una operación bastante agresiva, en la que la unidad podía quedar inutilizable si algo fallaba a mitad del proceso (corte de luz, cuelgue del sistema, imagen incorrecta…). Por eso, durante años se hacía casi siempre en ventanas de mantenimiento, con el equipo parado y copias de seguridad recién verificadas.
Las versiones recientes de Windows 10 (a partir de la 1703) y Windows Server 2016 incorporan un mecanismo para que ciertas unidades SAS, SATA y NVMe puedan recibir actualizaciones de firmware controladas directamente desde el propio sistema operativo, usando comandos estándar y, en muchos casos, sin desconectar servicios ni apagar servidores completos.
En el mundo real, muchos fabricantes publican firmwares para corregir bugs muy concretos: desde fallos que hacen que el SSD deje de verse tras ciertos reinicios, hasta problemas de compatibilidad con BIOS concretas o versiones de Windows. Si tu SSD empieza a comportarse de forma rara (desaparecer de la BIOS, errores de E/S, cuelgues al azar) y el soporte del fabricante te indica que hay un firmware crítico, suele merecer la pena plantearse la actualización, pero siempre con precaución.
Compatibilidad de SSD y requisitos de hardware
Para poder actualizar el firmware de un SSD directamente desde Windows usando los mecanismos nativos, la unidad tiene que cumplir unos requisitos específicos definidos en el Hardware Lab Kit (HLK) de Microsoft para dispositivos SAS, SATA y NVMe. Estos requisitos recogen los comandos que la unidad debe soportar para que Windows pueda gestionar de forma segura la descarga y activación del nuevo firmware.
En el caso de Windows 10 y Windows Server 2016 (y posteriores), Microsoft ha añadido pruebas específicas en el HLK que permiten a los fabricantes comprobar si sus modelos cumplen con estos comandos. Si el SSD supera esas pruebas, Windows puede interactuar con su firmware mediante los cmdlets nativos, sin depender de utilidades externas del fabricante.
La parte importante para ti como usuario o administrador es que no puedes asumir que cualquier SSD es actualizable desde Windows sin más. Es necesario confirmar que el modelo concreto (y su revisión) admite el mecanismo de actualización estandarizado. Esa información no siempre figura claramente en la caja del producto, así que lo más fiable es revisar la documentación del fabricante o consultar con el proveedor de la solución de almacenamiento.
Si tu entorno utiliza chasis de servidor, cabinas, o soluciones completas de un OEM (Dell, HP, Lenovo, etc.), normalmente será ese proveedor quien indique qué revisiones de firmware son “recomendadas” o “obligatorias” para las unidades que venden de serie con sus servidores (por ejemplo, consultando las herramientas de Dell). En muchos contratos de soporte, solo dan asistencia si mantienes el firmware en la versión avalada por ellos.
En resumen: antes de lanzarte, verifica siempre con el fabricante o integrador si tu SSD admite actualizaciones de firmware desde Windows y qué versión deberías instalar. No vale “me descargo cualquier firmware que parece que es de mi modelo y pruebo”, porque es la receta perfecta para dejar la unidad inutilizable.
Cmdlets de PowerShell para gestionar el firmware de unidades
Windows incorpora dos cmdlets específicos para trabajar con el firmware de discos físicos: Get-StorageFirmwareInformation y Update-StorageFirmware. Ambos forman parte de las herramientas de administración de almacenamiento y permiten consultar capacidades y aplicar nuevas imágenes de firmware en unidades compatibles.
El cmdlet Get-StorageFirmwareInformation sirve para obtener información detallada sobre el dispositivo: si permite actualizaciones de firmware desde Windows, cuántas ranuras de firmware tiene, qué versión está activa en cada ranura y si esas ranuras son escribibles. Un ejemplo típico en una máquina con un solo SSD SATA con una única ranura sería algo así:
Get-PhysicalDisk | Get-StorageFirmwareInformation
SupportsUpdate : True
NumberOfSlots : 1
ActiveSlotNumber : 0
SlotNumber : {0}
IsSlotWritable : {True}
FirmwareVersionInSlot : {J3E16101}
En este ejemplo se ve que la unidad es actualizable desde Windows (SupportsUpdate = True), que dispone de una ranura de firmware (slot 0) y que la versión instalada en ese slot es J3E16101. Esta información es clave para saber si puedes usar los cmdlets nativos o si tendrás que recurrir a herramientas del fabricante.
Hay un matiz importante con las unidades SAS: por cómo funcionan estos dispositivos, informan siempre SupportsUpdate como True, aunque no exista una forma estándar de preguntar directamente si soportan el mecanismo de actualización que espera Windows. Esto implica que con SAS hay que ir aún con más cuidado y leer la documentación del fabricante antes de asumir que todo está soportado.
El cmdlet Update-StorageFirmware es el que realiza realmente la actualización. Permite indicar un archivo de imagen de firmware (normalmente proporcionado por el OEM o el fabricante del SSD), junto con el número de ranura (slot) donde se va a cargar y activar.
El flujo interno del proceso es el siguiente: primero, la unidad recibe la nueva imagen de firmware y la carga en un área de prueba interna. Mientras esta descarga se está realizando, la entrada/salida de datos (E/S) sigue funcionando con normalidad. Una vez que la imagen se ha recibido correctamente, se lanza la activación: en ese momento la unidad realiza una reinicialización interna, deja de atender comandos de E/S durante unos segundos y, una vez ha completado el cambio, vuelve a estar disponible con el nuevo firmware activo.
Un uso típico del cmdlet podría ser:
$pd | Update-StorageFirmware -ImagePath C:\Firmware\J3E160@3.enc -SlotNumber 0
$pd | Get-StorageFirmwareInformation
SupportsUpdate : True
NumberOfSlots : 1
ActiveSlotNumber : 0
SlotNumber : {0}
IsSlotWritable : {True}
FirmwareVersionInSlot : {J3E160@3}
Como ves, tras la actualización la versión de firmware del slot pasa a ser la nueva (J3E160@3 en este ejemplo). Durante la activación, es totalmente normal que las aplicaciones que dependan de esa unidad vean un pequeño parón o tengan que esperar a que el SSD vuelva a responder. El tiempo concreto depende del diseño de la unidad y del tipo de firmware que se está cambiando.
Microsoft ha observado en pruebas que la activación puede tardar desde menos de 5 segundos hasta más de 30 segundos. Un ejemplo de medición con Measure-Command podría dar algo similar a esto:
Measure-Command { $pd | Update-StorageFirmware -ImagePath C:\Firmware\J3E16101.enc -SlotNumber 0 }
Seconds : 5
Milliseconds : 791
TotalMilliseconds : 5791.391
En este caso, la actualización de firmware ha llevado unos 5,8 segundos, un tiempo razonable para una operación de este tipo. Planificar estos segundos de “silencio” de la unidad es esencial si esa unidad soporta servicios críticos.
Actualizar SSD en servidores y entornos de producción
En un servidor que todavía no ha entrado en producción, la recomendación clara es actualizar siempre el firmware de las unidades de disco (HDD y SSD) a la versión recomendada por el OEM o por el proveedor de la solución de hardware (quien te vende y da soporte a chasis, controladoras, SSD, etc.). De esta forma, arrancas producción con una base estable y alineada con el soporte oficial.
Una vez el servidor está en producción, la filosofía suele ser la contraria: cambiar lo mínimo posible, salvo que haya una razón de peso. En el caso del firmware de discos, esto significa que normalmente solo deberías tocarlo cuando el proveedor de soluciones indique que hay una actualización crítica que corrige un problema que puede afectarte (pérdida de datos potencial, cuelgues severos, incompatibilidad con nuevas actualizaciones de Windows, etc.).
Antes de aplicar cualquier actualización de firmware de unidad en un servidor en producción, hay una serie de pasos recomendados que conviene seguir a rajatabla. Primero, lee con calma las notas de la versión del firmware y confirma que la actualización realmente aborda problemas que puedas sufrir en tu entorno, y que no añade fallos conocidos que puedan perjudicarte más que beneficiarte.
Segundo, no actualices “a pelo” sobre el entorno productivo. Lo recomendable es disponer de un servidor de laboratorio o pruebas con un conjunto de unidades idénticas a las de producción (mismo modelo y, si es posible, misma revisión de firmware previa) y aplicar allí el nuevo firmware. Después, somete la máquina a carga intensiva (pruebas sintéticas, benchmarks, simulación de carga real) para comprobar que el comportamiento es estable.
Microsoft documenta procedimientos para hacer pruebas sintéticas con Espacios de almacenamiento (Storage Spaces) y comprobar el rendimiento y estabilidad bajo carga. Aunque tu entorno no use exactamente esa tecnología, la idea de probar firmwares bajo estrés antes de desplegarlos masivamente es perfectamente extrapolable a cualquier escenario profesional.
Actualizaciones automatizadas con Espacios de almacenamiento directo
Windows Server 2016 incorpora un Servicio de mantenimiento específico para implementaciones de Espacios de almacenamiento directo (Storage Spaces Direct), incluyendo soluciones como Azure Stack de Microsoft. Uno de los objetivos de este servicio es facilitar la gestión del hardware: supervisión de estado, versiones de firmware y actualización coordinada de unidades.
Dentro de estas capacidades, el Servicio de mantenimiento puede desplegar nuevas versiones de firmware de disco en todo un clúster de Storage Spaces Direct sin desconectar las cargas de trabajo ni provocar tiempos de inactividad relevantes para los usuarios. Esta funcionalidad se controla mediante directivas (policies) y la última palabra siempre la tiene el administrador del clúster.
El proceso de actualización orquestada es bastante sencillo conceptualmente. Primero, identificas qué unidades HDD y SSD forman parte (o esperas que formen parte) del clúster de Espacios de almacenamiento directo, y compruebas si admiten el mecanismo de actualización de firmware gestionado por Windows. Solo las unidades que cumplen estos requisitos podrán actualizarse mediante el Servicio de mantenimiento.
Después, creas un archivo XML denominado Componentes compatibles, donde enumeras las unidades que quieres gestionar (fabricante, modelo, etc.) y defines tanto las versiones de firmware permitidas (AllowedFirmware) como la versión objetivo que deseas implantar (TargetFirmware) junto con la ruta al binario de firmware:
<Components>
<Disks>
<Disk>
<Manufacturer>Contoso</Manufacturer>
<Model>XYZ9000</Model>
<AllowedFirmware>
<Version>2.0</Version>
<Version>2.1</Version>
<Version>2.2</Version>
</AllowedFirmware>
<TargetFirmware>
<Version>2.2</Version>
<BinaryPath>\\path\to\image.bin</BinaryPath>
</TargetFirmware>
</Disk>
</Disks>
</Components>
Una vez preparado el XML, lo cargas en la base de datos del clúster con PowerShell. Puedes obtener el documento actual, editarlo y volverlo a aplicar mediante comandos como estos:
$SpacesDirect = Get-StorageSubSystem Clus*
$CurrentDoc = $SpacesDirect | Get-StorageHealthSetting -Name "System.Storage.SupportedComponents.Document"
$CurrentDoc.Value | Out-File <Path>
Tras editar el archivo en tu editor favorito (Visual Studio Code, Bloc de notas, etc.), lo vuelves a cargar:
$NewDoc = Get-Content <Path> | Out-String
$SpacesDirect | Set-StorageHealthSetting -Name "System.Storage.SupportedComponents.Document" -Value $NewDoc
En ese momento, el Servicio de mantenimiento analiza el documento y detecta qué unidades no tienen aún la versión de firmware objetivo. A partir de ahí, redirige la E/S fuera de las unidades afectadas, va nodo por nodo del clúster y actualiza el firmware de esas unidades aisladas, aprovechando la resiliencia que proporciona Storage Spaces Direct al repartir los datos entre varios nodos.
Mientras el nodo se aísla y se actualiza, el clúster entra en un modo “degradado” pero funcional. Una vez completada la actualización en ese nodo, se lanza una reparación de Espacios de almacenamiento para volver a sincronizar las copias de datos entre todos los nodos, y solo cuando este proceso concluye se pasa al siguiente servidor.
Para evitar problemas por desplegar un firmware inestable en muchos nodos de golpe, el Servicio de mantenimiento introduce retrasos deliberados entre servidores. Por defecto, espera 7 días antes de actualizar el segundo nodo, y a partir de ahí aplica retrasos de 1 día para el resto (tercero, cuarto, etc.). Si durante ese tiempo detectas que el firmware nuevo es problemático, puedes detener la implementación y dejar de extenderlo al resto de servidores.
Si ya has validado el firmware en laboratorio y necesitas una implantación más rápida, estos retardos se pueden ajustar de días a horas o incluso minutos, siempre mediante las directivas de configuración del Servicio de mantenimiento. De nuevo, lo razonable en entornos críticos es ir con pies de plomo y no correr más de la cuenta.
Limitaciones: dispositivos SAN y otros escenarios
Una duda recurrente es si el mecanismo de actualización de firmware de Windows sirve también para dispositivos SAN o cabinas externas. La respuesta es clara: no. En general, los sistemas de almacenamiento SAN tienen sus propias herramientas de gestión, interfaces web o utilidades específicas del fabricante para aplicar actualizaciones de firmware.
Los cmdlets Get-StorageFirmwareInformation y Update-StorageFirmware están pensados para almacenamiento directamente conectado (direct-attached storage), es decir, unidades SATA, SAS o NVMe conectadas directamente al sistema o a través de controladoras compatibles. Para cabinas SAN, NAS avanzados o soluciones propietarias, hay que ceñirse siempre a las herramientas que proporciona el propio fabricante de la solución.
Algo similar ocurre con ciertas cajas externas USB, adaptadores o hubs. Si tienes un SSD dentro de una carcasa USB y el proceso de actualización falla, la recomendación es conectar la unidad directamente al sistema (por ejemplo, a un puerto SATA o M.2 interno) y repetir el procedimiento, ya sea con herramientas del fabricante o con los cmdlets de Windows cuando proceda.
Actualización de firmware desde USB y peculiaridades según el sistema
Muchos fabricantes de SSD ofrecen, además de utilidades para Windows, la opción de actualizar el firmware utilizando una memoria USB de arranque. En un PC clásico, esto suele funcionar siempre que el SSD esté conectado directamente al equipo y que la BIOS/UEFI permita arrancar desde la unidad USB que contiene la utilidad de actualización.
Si la unidad está montada en una carcasa externa, en un hub USB o detrás de algún adaptador intermedio, es frecuente que la herramienta de actualización no consiga comunicarse correctamente con el SSD. En esos casos, el propio fabricante suele recomendar desmontar la unidad de la carcasa y conectarla de forma directa al sistema (en una ranura M.2, en un puerto SATA, etc.) para repetir el proceso.
Algunos proveedores publican una guía específica paso a paso para actualizar desde USB, indicando cómo preparar el pendrive de arranque, qué opciones configurar en la BIOS (modo UEFI o Legacy, orden de arranque, desactivar Secure Boot si fuera necesario), y qué secuencia seguir al arrancar el entorno de actualización. Conviene seguir esas instrucciones al pie de la letra.
En el caso de sistemas Mac, varios fabricantes aclaran que, a día de hoy, no disponen de procesos oficiales basados en USB de arranque para actualizar el firmware de sus SSD. En esos entornos, normalmente la gestión del firmware se realiza con herramientas nativas del fabricante integradas en macOS (cuando existen) o bien no se ofrece la opción de actualización al usuario final.
Ejemplo de problema real: SSD que desaparece tras una actualización
No es raro encontrar casos en los que, tras una actualización importante de Windows, un SSD que hasta ayer funcionaba sin problemas deja de ser visible tanto en el sistema operativo como en la BIOS. Por ejemplo, un WD Blue SA510 de 1 TB que de repente no aparece ni en Windows 11 ni en el firmware de la placa base.
Cuando ocurre algo así, lo primero es descartar lo obvio: conexiones físicas, cables, puertos y reinicios. Probar a desconectar y volver a conectar el SSD, apagar completamente la máquina (apagado total, no suspensión), cambiar de puerto SATA o ranura M.2, revisar que la BIOS no haya deshabilitado el puerto, etc. Si todo eso no resuelve nada, la sospecha de que sea un problema de firmware del propio SSD cobra fuerza.
En algunos modelos, el fabricante puede indicar que el fallo se corrige actualizando el firmware de la unidad. El problema es que, si el SSD ni siquiera es detectable por BIOS, no vas a poder aplicar la actualización por los métodos normales. En este tipo de situaciones, las opciones pasan por contactar al soporte del fabricante, revisar si existe algún procedimiento de recuperación específico o, en el peor de los casos, tramitar un reemplazo de la unidad.
También puede ocurrir que el SSD siga detectándose en otros sistemas o en carcasas USB, pero no aparezca en una combinación concreta de placa base y versión de Windows. En esos casos, una puesta al día de firmware (tanto del SSD como de la propia actualización de la BIOS de la placa) puede devolver la compatibilidad. Si la unidad no aparece en ningún lado, lo más probable es que el daño sea más profundo y no se solucione con un simple update.
Es importante recalcar que, aunque muchas guías parezcan sencillas, no eres “menos listo” por no lanzarte a actualizar el firmware sin más. Al contrario: lo prudente en escenarios delicados es documentarse, seguir las recomendaciones del fabricante y valorar el riesgo de pérdida de datos antes de tocar nada.
Buenas prácticas y resolución de problemas frecuentes
Una de las preguntas típicas es si el mecanismo de actualización de Windows funciona con cualquier dispositivo de almacenamiento. La respuesta es que solo funcionará con unidades que implementen correctamente los comandos requeridos en su firmware. El cmdlet Get-StorageFirmwareInformation es tu aliado para verificar si la unidad declara soporte para estos comandos (en el caso de SATA y NVMe), mientras que las pruebas de HLK permiten a OEM y fabricantes validar este comportamiento antes de sacar el producto al mercado.
Otro caso conocido: tras actualizar el firmware de una unidad SATA, el sistema informa de repente que el mecanismo de actualización ya no es compatible. Esto no significa, en principio, que la unidad esté mal, salvo que el nuevo firmware haya decidido deshabilitar explícitamente las actualizaciones (algo poco habitual, pero posible). Lo normal es que estés ante un problema de caché de capacidades desactualizada en Windows.
Para forzar a Windows a reenumerar las capacidades de la unidad, puedes ejecutar el siguiente comando de PowerShell:
Update-StorageProviderCache -DiscoveryLevel Full
Este comando obliga al sistema a volver a analizar los dispositivos de almacenamiento y actualizar la copia en caché de sus capacidades. Como medida preventiva, Microsoft recomienda lanzar este comando antes de iniciar una campaña de actualizaciones de firmware o antes de completar un despliegue en un clúster de Espacios de almacenamiento directo, para reducir la probabilidad de problemas derivados de información vieja en la caché.
Otra duda habitual es qué pasa si la actualización de firmware falla. Hay varios escenarios posibles: que la unidad no soporte realmente los comandos necesarios (en cuyo caso, la nueva imagen de firmware nunca llega a activarse y la unidad sigue funcionando con la versión anterior), o que la imagen de firmware no sea válida para ese modelo o esté dañada (lo que hace que la activación falle, pero el firmware original siga operativo).
El peor escenario es que, tras la actualización, la unidad deje de responder por completo. Entonces probablemente estás ante un fallo serio del propio firmware del SSD. Por eso insistimos tantas veces en probar cualquier actualización en un entorno de laboratorio antes de llevarla a producción. Si el SSD no reacciona de ninguna forma, lo más realista es que la única solución sea sustituirlo.
Si estás usando el Servicio de mantenimiento de Storage Spaces Direct y necesitas detener una implementación de firmware en curso (por ejemplo, porque has detectado problemas en los primeros nodos), puedes deshabilitar el despliegue con este comando:
Get-StorageSubSystem Cluster* | Set-StorageHealthSetting -Name "System.Storage.PhysicalDisk.AutoFirmwareUpdate.RollOut.Enabled" -Value false
En algunos despliegues, los administradores se encuentran errores de “acceso denegado” o “ruta no encontrada” al intentar aplicar el firmware desde un archivo binario. En esos casos, revisa que todos los nodos del clúster tengan acceso a la ruta donde se encuentra la imagen de firmware. La forma más sencilla suele ser colocar el archivo en un volumen compartido de clúster, al que todos los servidores puedan acceder con permisos adecuados.
Por último, recuerda la recomendación más importante: obtener siempre la imagen de firmware directamente del OEM, del proveedor de la solución o del fabricante del SSD. No descargues firmwares de páginas de terceros ni intentes mezclar firmwares de modelos similares. Windows proporciona el mecanismo para enviar la imagen a la unidad, pero no puede garantizar la integridad ni la idoneidad de ese firmware para tu modelo concreto.
Con todo lo anterior en mente, la actualización del firmware de un SSD en Windows puede pasar de ser una operación de alto riesgo a una tarea relativamente controlada, siempre que respetes las compatibilidades, pruebes antes en laboratorio, aproveches las herramientas nativas como los cmdlets de PowerShell y el Servicio de mantenimiento, y tengas muy presentes las recomendaciones de tu proveedor de hardware.
