AgenteAgent

Agente multiplataforma de Observer RMM (Windows, Linux, macOS). Binarios adjuntos abajo y publicados también en el CDN agents.observer.cl.

Esta versión trae el borrado seguro selectivo (wipe A2): ante una orden del servidor, el agente sobrescribe, rompe los metadatos y elimina las rutas designadas, y verifica por relectura —ruta por ruta— que el archivo ya no está. Es la primera acción destructiva del agente. Acompaña a la consola Observer RMM 1.4.18, donde se ordena, se confirma a dos personas y se certifica el borrado.

Cambios en esta versión

• Borrado seguro por-SO. En Windows y Linux el agente sobrescribe el contenido con datos aleatorios, fuerza el volcado a disco, rompe los metadatos (renombra y trunca) y elimina. No sigue enlaces simbólicos: borra el enlace, nunca su destino. macOS queda fuera de esta modalidad por su sistema de archivos.
• Verificación por relectura, todo o nada. Tras borrar, el agente reintenta leer cada ruta: reporta verificado sólo si todas quedaron ausentes. Residuo, error por-ruta o lista vacía dejan la orden no verificada —nunca un «ok falso»—, y el servidor no emite certificado.
• Simulacro en seco. Reconoce el modo simulacro: enumera el plan de lo que borraría sin tocar el disco.
• Idempotente. La orden viaja con un identificador único; si el equipo reconecta y la recibe de nuevo, no repite el efecto.
• Sin código de terceros. El borrado seguro se implementa sólo con la biblioteca estándar del lenguaje; no invoca herramientas externas (cero dependencias GPL).

Lo que se verificó antes de publicar

Plataformas

• Windows — 64 bits y 32 bits (instaladores)
• Linux — amd64, 386, arm64, arm
• macOS — arm64 (Apple Silicon) y amd64 (Intel)

Instalación

La actualización es automática: la flota toma esta versión desde la consola cuando se publica como la versión ofrecida. No hace falta bajar el binario de esta página ni reinstalar. El despacho destructivo permanece deshabilitado en el servidor (ERASE_DESTRUCTIVE_DISPATCH_ENABLED) hasta el simulacro en seco obligatorio sobre un equipo de descarte; hasta entonces el agente no ejecuta ningún borrado real. Contra una consola anterior, el agente se comporta como antes.

---

_Software de uso interno de BrainCorp. Todos los derechos reservados._

Agente multiplataforma de Observer RMM (Windows, Linux, macOS). Binarios adjuntos abajo y publicados también en el CDN agents.observer.cl.

Esta versión trae la recuperación de archivos antes de borrar (fileretrieval): el agente, ante una orden del servidor, enumera las rutas indicadas y sube los archivos por el canal cifrado de la evidencia del modo perdido. Es una acción no destructiva. Acompaña a la consola Observer RMM 1.4.17, donde se ordena y se descarga la recuperación.

Cambios en esta versión

• Recuperación de archivos. El agente recibe la orden, expande las rutas —archivos sueltos y carpetas recursivas— respetando el tope de número de archivos, y sube cada uno al servidor por el canal cifrado. Reconoce el simulacro en seco: reporta el plan de lo que recuperaría sin subir nada.
• Idempotente y prolijo. La orden viaja con un identificador único: si el equipo reconecta y la recibe de nuevo, no vuelve a subir lo ya subido. Se detiene solo si el servidor indica que la orden terminó o si se excede el tope.
• Sólo lectura. El agente no borra ni modifica nada en el equipo: sólo lee las rutas indicadas y las envía. El bloque destructivo del agente sigue cerrado.
• Sin dependencias nuevas. Un agente que reciba la orden de un servidor viejo la ignora sin romperse; nada nuevo sale del equipo salvo por una orden explícita.

Lo que se verificó antes de publicar

Plataformas

• Windows — 64 bits y 32 bits (instaladores)
• Linux — amd64, 386, arm64, arm
• macOS — arm64 (Apple Silicon) y amd64 (Intel)

Instalación

La actualización es automática: la flota toma esta versión desde la consola cuando se publica como la versión ofrecida. No hace falta bajar el binario de esta página ni reinstalar; la recuperación se aplica cuando la consola 1.4.17 (o posterior) la ordena. Contra una consola anterior, el agente se comporta como antes.

---

_Software de uso interno de BrainCorp. Todos los derechos reservados._

Agente multiplataforma de Observer RMM (Windows, Linux, macOS). Binarios adjuntos abajo y publicados también en el CDN agents.observer.cl.

Esta versión trae el keep-awake por geocerca —un equipo que sale de su zona autorizada se mantiene despierto para seguir reportando— junto con la reconexión por redes WiFi abiertas para recuperar equipos que quedaron sin conexión, y completa la no-suspensión reactiva del modo perdido en macOS, que hasta ahora estaba sólo en Windows y Linux. Acompaña a la consola Observer RMM 1.4.15, donde se configuran la geocerca, la línea base de "no dormir" y el interruptor de WiFi abierta.

Cambios en esta versión

• No-suspensión por geocerca. Cuando el servidor determina que el equipo está fuera de su geocerca, el agente impide la suspensión y la hibernación para que no deje de reportar ubicación; al volver a la zona, la libera. Es multi-fuente y reconciliada: si el equipo está perdido y además fuera de zona, recuperarlo de "perdido" no lo deja dormir mientras siga fuera —sólo se libera cuando ninguna fuente pide mantenerlo despierto—.
• Línea base de "no dormir" con reversión limpia. El agente aplica y sostiene una línea base de no-suspensión configurada desde la consola, y la revierte al desinstalarse, sin dejar la configuración de energía trabada.
• Reconexión por redes WiFi abiertas. Un equipo sin conexión puede reconectarse por redes WiFi abiertas y resolver portales cautivos para volver a reportar (Windows y Linux; en macOS es no-operativo por ahora). Está gobernado por un interruptor global que viene activado y se puede desactivar. El instalador de Windows además reasegura la reconexión WiFi tras reiniciar (perfil de todos los usuarios con conexión automática) y suma una guarda de conectividad en el arranque en frío.
• No-suspensión reactiva del modo perdido en macOS. Completa Windows y Linux: un Mac marcado como perdido ahora no se suspende mientras dura el caso —vía el mecanismo del sistema (caffeinate), sostenido mientras el caso esté abierto— y se libera de forma limpia al recuperar, sin tocar la configuración de energía persistente.
• Registro por fuente. El agente anota por qué está despierto (modo perdido, geocerca o ambos) en su bitácora, para leer el origen de cada acción sin ambigüedad.
• Sin dependencias nuevas ni tráfico nuevo. Un agente que reciba la configuración de un servidor viejo la ignora sin romperse; nada nuevo sale del equipo.

Lo que se verificó antes de publicar

Plataformas

• Windows — 64 bits y 32 bits (instaladores)
• Linux — amd64, 386, arm64, arm
• macOS — arm64 (Apple Silicon) y amd64 (Intel)

Instalación

La actualización es automática: la flota toma esta versión desde la consola cuando se publica como la versión ofrecida. No hace falta bajar el binario de esta página ni reinstalar; las capacidades nuevas se aplican cuando la consola 1.4.15 (o posterior) las activa. Contra una consola anterior, el agente se comporta como antes.

---

_Software de uso interno de BrainCorp. Todos los derechos reservados._

Agente multiplataforma de Observer RMM (Windows, Linux, macOS). Binarios adjuntos abajo y publicados también en el CDN agents.observer.cl.

Esta versión completa dos piezas de la cascada de contramedidas del modo perdido/robado que introdujo la 2.16.0: ahora la alarma antirrobo suena sola cuando la consola marca un equipo como perdido con la alarma habilitada —antes eso sólo pasaba con el botón manual— y la no-hibernación llega a Linux, para que un equipo Linux perdido no se duerma y siga reportando ubicación. Acompaña a la consola Observer RMM 1.4.14, donde se configura la cascada en tres niveles (global, por equipo, por caso).

Cambios en esta versión

• Corregido: la alarma antirrobo ahora suena al marcar el equipo como perdido. Antes, un equipo marcado como perdido con la alarma habilitada en la cascada no sonaba —la alarma sólo funcionaba apretando el botón manual—. Ahora, al marcar el equipo, si la cascada trae la alarma encendida, el agente la hace sonar de inmediato al volumen máximo y sin límite de tiempo (es una acción de robo: no se deja a medias ni a volumen bajo). Recuperar el equipo la silencia y restaura el volumen que tenía antes.
• No-hibernación en Linux con reversión limpia. Para que un equipo Linux perdido no deje de reportar por dormirse, el agente ahora impide la suspensión y la hibernación —tanto por inactividad como al cerrar la tapa— mientras dura el caso, usando el mecanismo del sistema (systemd/logind). Al recuperar, lo libera por completo, sin dejar nada trabado ni tocar la configuración de energía del equipo. Es el equivalente de la no-hibernación que la 2.16.0 trajo para Windows.
• El bloqueo de pantalla de la cascada ya funcionaba en Linux. El bloqueo silencioso y diferido reutiliza el bloqueo de sesión nativo, que en Linux ya estaba operativo desde el modo perdido; esta versión sólo suma la no-suspensión.
• Sin dependencias nuevas ni tráfico nuevo. Un agente que reciba la configuración de un servidor viejo la ignora sin romperse; nada nuevo sale del equipo.
• macOS: la no-suspensión de la cascada sigue pendiente para macOS y llega en una fase posterior; el resto del modo perdido no cambia en esa plataforma.

Lo que se verificó antes de publicar

Plataformas

• Windows — 64 bits y 32 bits (instaladores)
• Linux — amd64, 386, arm64, arm
• macOS — arm64 (Apple Silicon) y amd64 (Intel)

Instalación

La actualización es automática: la flota toma esta versión desde la consola cuando se publica como la versión ofrecida. No hace falta bajar el binario de esta página ni reinstalar; las contramedidas nuevas sólo se aplican cuando la consola 1.4.14 (o posterior) marca el equipo como perdido y la cascada las activa. Contra una consola anterior, el agente se comporta como antes.

---

_Software de uso interno de BrainCorp. Todos los derechos reservados._

Agente multiplataforma de Observer RMM (Windows, Linux, macOS). Binarios adjuntos abajo y publicados también en el CDN agents.observer.cl.

Esta versión suma la parte de agente de la cascada de contramedidas del modo perdido/robado: cuando la consola marca un equipo como perdido, el agente ya no sólo sube la frecuencia de ubicación —ahora ejecuta las contramedidas que la consola resolvió (bloqueo de pantalla diferido, encendido de la cámara para el caso y no-hibernación en Windows), y las revierte al recuperar. Acompaña a la consola Observer RMM 1.4.14, que es donde se configuran esas contramedidas en tres niveles.

Cambios en esta versión

• Bloqueo de pantalla silencioso y diferido. Al marcar el equipo, el agente agenda el bloqueo para dentro de la ventana que fijó la consola, en vez de bloquear al instante: primero se recolecta evidencia (pantalla, cámara, ubicación) y recién al vencer la ventana se bloquea la sesión. Si el equipo se marca como recuperado dentro de esa ventana, el bloqueo pendiente se cancela. Reutiliza el mismo bloqueo de sesión que ya existía.
• Encendido de la cámara para el caso. Mientras el equipo está perdido, el agente puede tomar la foto de la cámara aunque el interruptor global de cámara esté apagado, si la consola lo indicó para el caso. El override vale sólo durante el caso activo; al recuperar, vuelve a mandar la configuración global.
• No-hibernación con reversión limpia (Windows). Para que un equipo perdido no deje de reportar por quedarse dormido, el agente duplica el esquema de energía activo, endurece la copia (sin suspensión, hibernación ni apagado de disco/monitor) y la activa. Al recuperar, restaura exactamente el esquema anterior y borra la copia. Los identificadores del esquema se guardan en disco, así que la reversión sobrevive a un reinicio del equipo.
• La cascada sobrevive al reinicio. La configuración resuelta de contramedidas se persiste junto al estado del modo perdido y se retoma al arrancar, sin esperar a hablar con el servidor.
• Ninguna contramedida queda pegada. Recuperar el equipo revierte la energía, cancela el bloqueo pendiente y apaga el override de cámara.
• macOS y Linux: en esta versión la no-hibernación y el bloqueo de la cascada son sólo Windows (no-op en macOS/Linux); llegan en una fase posterior. El resto del modo perdido no cambia en esas plataformas.
• Sin dependencias nuevas ni tráfico nuevo. Un agente que reciba la configuración de un servidor viejo la ignora sin romperse.

Lo que se verificó antes de publicar

Verificación del efecto en terreno (bloqueo tras la ventana en un equipo real, powercfg sin hibernación con su reversión, cámara con el global apagado): se cierra por separado con este agente desplegado, junto con el E2E de la consola 1.4.14.

Notas de actualización

• La actualización es automática y no cambia ninguna configuración existente.
• Las contramedidas nuevas sólo se aplican cuando la consola 1.4.14 (o posterior) marca el equipo como perdido y la configuración de la cascada las activa; contra una consola anterior, el agente se comporta como antes.

Agente multiplataforma de Observer RMM (Windows, Linux, macOS). Binarios adjuntos abajo y publicados también en el CDN agents.observer.cl.

Versión de robustez para el cifrado de disco en Windows. El estado de cifrado de cada volumen se sigue informando con normalidad; se posterga la lectura del detalle de protectores (cuántos y de qué tipo) y el porcentaje de avance, porque esa lectura podía afectar la estabilidad del agente en ciertos equipos. No cambia nada más, y Linux y macOS no cambian.

Cambios en esta versión

• El estado de cifrado se informa igual que siempre. Por cada volumen sigue viajando si está protegido, si el cifrado está completo o en curso, con qué algoritmo, y cuál es el disco del sistema. La respuesta a «¿qué equipos están sin cifrar?» no se ve afectada.
• Se posterga el detalle de protectores y el porcentaje de avance. Esa lectura usa una vía de consulta de Windows que, en equipos reales, podía dejar inestable al agente. Hasta rehacerla de forma segura, el agente informa esos campos como «sin dato» en vez de arriesgar la estabilidad del inventario. Es la misma degradación graciosa que ya contemplaba el diseño: ante la duda, «sin dato», nunca un dato equivocado ni un agente caído.
• Ninguna clave de recuperación —ni ningún material que permita descifrar— sale del equipo. Se mantiene intacta esa garantía.
• Sin dependencias nuevas ni tráfico nuevo.
• Linux y macOS no cambian en esta versión.

Lo que se verificó antes de publicar

Notas de actualización

• La actualización es automática y no cambia ninguna configuración existente.
• El detalle de protectores volverá en una versión posterior, con la lectura rehecha de forma segura.

Agente multiplataforma de Observer RMM (Windows, Linux, macOS). Binarios adjuntos abajo y publicados también en el CDN agents.observer.cl.

Corrección del detalle de protectores de BitLocker en Windows. Desde la 2.15.30 el agente informa el estado de cifrado de cada volumen, pero el detalle —cuántos protectores tiene y de qué tipo, y el porcentaje de avance— llegaba vacío en equipos reales, aun con el disco efectivamente cifrado. Esta versión lo corrige: esos datos ahora sí viajan. No cambia nada más, y Linux y macOS no cambian.

Cambios en esta versión

• El detalle de protectores de BitLocker vuelve a informarse (sólo Windows). En un volumen cifrado, el agente ahora informa correctamente cuántos protectores tiene, de qué tipo, y el porcentaje de avance del cifrado. Antes esos tres datos llegaban vacíos aunque el sistema los tuviera.
• La causa era interna: al abrir la sesión de consulta y pedir cada volumen, el agente liberaba el objeto de Windows un instante antes de usarlo, y la lectura fallaba en silencio dejando el dato vacío. Se corrigió el manejo de esos objetos; el estado de cifrado —que ya funcionaba— no se toca.
• Ninguna clave de recuperación —ni ningún material que permita descifrar— sale del equipo. Se mantiene intacta la garantía: sólo viajan cantidades y códigos de tipo.
• Sin dependencias nuevas ni tráfico nuevo.
• Linux y macOS no cambian en esta versión.

Lo que se verificó antes de publicar

La confirmación de que el detalle de protectores ya llega correctamente se hace sobre un equipo con un volumen cifrado real al desplegar esta versión.

Notas de actualización

• La actualización es automática y no cambia ninguna configuración existente.
• No hay nada que configurar ni que conceder en los equipos.

Agente multiplataforma de Observer RMM (Windows, Linux, macOS). Binarios adjuntos abajo y publicados también en el CDN agents.observer.cl.

Versión de diagnóstico para la lectura de protectores de BitLocker en Windows. En la 2.15.30 el agente empezó a informar el estado de cifrado de cada volumen, pero el detalle de protectores (cuántos y de qué tipo) y el porcentaje de avance no aparecían en equipos reales, aun con el disco efectivamente cifrado. Esta versión agrega una traza interna que identifica en qué paso falla esa lectura, para poder corregirla. No cambia ningún comportamiento visible, y Linux y macOS no cambian.

Cambios en esta versión

• Traza de diagnóstico para la lectura de protectores de BitLocker (sólo Windows). Cuando el agente no logra leer el detalle de protectores de un volumen, ahora registra internamente el paso donde se detuvo, en vez de dejar el dato simplemente vacío. Es un paso intermedio para corregir un problema detectado en equipos reales.
• Ningún material de clave sale del equipo, tampoco en la traza. La traza contiene únicamente nombres de paso, códigos de error y cantidades — jamás identificadores de protector ni nada que permita descifrar un disco. Se mantiene la garantía de la versión anterior.
• Sin dependencias nuevas ni tráfico nuevo: la traza viaja dentro del mensaje de inventario que ya existía.
• Linux y macOS no cambian en esta versión.

Lo que se verificó antes de publicar

Notas de actualización

• La actualización es automática y no cambia ninguna configuración existente.
• Es una versión de diagnóstico: la corrección definitiva del detalle de protectores llega en la versión siguiente.

Agente multiplataforma de Observer RMM (Windows, Linux, macOS). Binarios adjuntos abajo y publicados también en el CDN agents.observer.cl.

Segundo paso del estado de cifrado de disco: sobre lo que la versión anterior ya informaba (si cada disco está cifrado con BitLocker), el agente de Windows agrega ahora cuántos protectores tiene cada volumen y de qué tipo, y cuánto lleva avanzado un cifrado en curso. Todavía no se ve en la consola — esta versión sólo enriquece el dato que ya viajaba; la vista de cumplimiento llega en una entrega posterior. No cambia ningún comportamiento actual, y Linux y macOS no cambian.

Cambios en esta versión

• El agente de Windows informa, por cada volumen, la cantidad y el tipo de protectores de BitLocker. Es lo que permite distinguir un disco cifrado sólo con el chip del equipo (TPM) de uno que además exige clave, o que tiene guardada una clave de recuperación. Sobre el estado que ya se enviaba —protegido / cifrado por completo / en curso—, ahora se sabe también con qué está protegido.
• Un cifrado en curso informa su porcentaje de avance. Un disco que se está cifrando en este momento deja de ser un sí/no y pasa a decir cuánto le falta.
• Ninguna clave de recuperación —ni ningún material que permita descifrar— sale del equipo. El agente informa cuántos protectores hay y de qué clase, jamás su contenido. Esta versión agrega guardianes automáticos dedicados a esa regla: uno que verifica los campos de hoy y otro que vigila que ninguna clave del mensaje llegue siquiera a nombrar material de clave, contra una lista de 14 términos.
• Un fallo al leer los protectores no degrada el estado de cifrado. La lectura de protectores está aislada en su propio camino: si algo falla, ese volumen informa «protectores: sin dato» y el resto —el estado de cifrado que ya entregaba la versión anterior— llega intacto. Un problema nuevo no puede romper lo que ya funcionaba.
• Sin dependencias nuevas ni tráfico nuevo: el dato viaja dentro del mensaje de inventario que ya existía, con el mismo ritmo de siempre.
• Linux y macOS no cambian en esta versión.

Lo que se verificó antes de publicar

El aviso honesto: la lógica de protectores está cubierta por las comprobaciones automáticas, pero todavía no se midió leyendo protectores en un equipo Windows real — en particular el caso del volumen sin protectores explícitos. Si en algún equipo fallara la lectura de protectores, ese volumen informaría «protectores: sin dato», nunca un dato equivocado, y el estado de cifrado seguiría siendo el correcto.

Notas de actualización

• La actualización es automática y no cambia ninguna configuración existente.
• No hay nada que configurar ni que conceder en los equipos: el estado se lee del propio sistema, sin permisos nuevos.

Agente multiplataforma de Observer RMM (Windows, Linux, macOS). Binarios adjuntos abajo y publicados también en el CDN agents.observer.cl.

Primer paso del estado de cifrado de disco: el agente de Windows empieza a informar si los discos del equipo están cifrados con BitLocker. Todavía no se ve en la consola — esta versión sólo hace que el dato exista y viaje; la vista de cumplimiento llega en una entrega posterior. No cambia ningún comportamiento actual, y Linux y macOS no cambian.

Cambios en esta versión

• El agente de Windows informa el estado de cifrado de cada disco. Junto con el inventario que ya enviaba —memoria, discos, red, tarjetas— ahora viaja, por cada volumen: si está protegido, si el cifrado está completo o en curso, con qué algoritmo, y cuál de todos es el disco del sistema. Es el dato que permitirá responder «¿qué equipos de la flota están sin cifrar?» sin revisarlos uno por uno.
• Un equipo que no ofrece BitLocker no se cuenta como incumplimiento. Las ediciones de Windows que no incluyen la función se informan como «no soportado», que es una respuesta distinta de «sin cifrar».
• Una consulta que falla nunca se muestra como «sin cifrar». Si el equipo no deja leer el estado, el agente informa el motivo en vez de mandar una respuesta vacía. Es la diferencia entre «este equipo está desprotegido» y «de este equipo no sabemos», y confundirlas sería el peor error posible en una revisión de cumplimiento.
• Ninguna clave de recuperación sale del equipo. El agente informa el estado, jamás el material que permitiría descifrar un disco.
• Sin dependencias nuevas ni tráfico nuevo: el dato viaja dentro del mensaje de inventario que ya existía, con el mismo ritmo de siempre.
• Linux y macOS no cambian en esta versión.

Lo que se verificó antes de publicar

El aviso honesto: el caso «Windows sin la función de BitLocker» está cubierto por las comprobaciones automáticas, pero todavía no se midió en un equipo real de esa clase. Si en alguno fallara la clasificación, el agente informaría «no se pudo leer» en vez de «no soportado» — nunca «sin cifrar».

Notas de actualización

• La actualización es automática y no cambia ninguna configuración existente.
• No hay nada que configurar ni que conceder en los equipos: el estado de cifrado se lee del propio sistema, sin permisos nuevos.
• Hasta que llegue la vista de cumplimiento, el dato queda guardado junto al inventario del equipo y no aparece en pantalla.
• Linux y macOS: sin cambios; su comportamiento es el de la versión anterior.

Agente multiplataforma de Observer RMM (Windows, Linux, macOS). Binarios adjuntos abajo y publicados también en el CDN agents.observer.cl.

Cierra la captura de pantalla del modo perdido en Linux con Wayland. Hasta esta versión, en los escritorios modernos —GNOME y KDE sobre Wayland— un caso de modo perdido no lograba capturar la pantalla, aunque el equipo sí lo permitía. Conviene actualizar la flota Linux. Windows y macOS no cambian.

Cambios en esta versión

• En Wayland la captura ya funciona de verdad. El sistema de Wayland no deja que una aplicación lea la pantalla como en X11: hay que pedírselo al portal del escritorio, que contesta la captura por un camino aparte. El agente pedía por un lado y escuchaba la respuesta por otro, así que la captura se tomaba pero el agente la daba por perdida y reportaba una espera agotada. Ahora pide y escucha por el mismo canal, y la imagen llega.
• GNOME moderno: el permiso ya se puede conceder. En GNOME (versión 50 en adelante) la única vía de captura es ese portal, y el paso que pide el permiso —con alguien delante del equipo, al instalar o actualizar— no llegaba a ejecutarse nunca. Quedaba corregido pero inalcanzable. Ahora la solicitud de permiso corre cuando corresponde y el equipo queda habilitado.
• KDE sobre Wayland: se acabó la falsa pantalla en negro. La captura se iba por un camino de X11 que en Wayland devuelve una imagen negra, y esa imagen negra se leía como una avería del equipo. Ahora usa la vía nativa de KDE y la pantalla en negro vuelve a significar lo que debe: la pantalla apagada, no un fallo.
• La imagen se recupera aunque el escritorio la deje en un lugar reservado. La copia la hace ahora el propio usuario del escritorio, así que funciona también donde el servicio, por sí solo, no tendría permiso de leerla.
• Windows y macOS no cambian en esta versión.

Lo que se verificó antes de publicar

KDE sobre Wayland ya estaba medido en una versión anterior. Los compositores de la familia wlroots (sway, Hyprland) usan una vía más simple que no cambió, pero no se han medido en un equipo real de esa familia.

Notas de actualización

• La actualización es automática y no cambia ninguna configuración existente.
• En un equipo Linux con Wayland recién actualizado, es esperable que el sistema pida una vez el permiso de compartir pantalla si hay alguien con la sesión gráfica abierta. Concederlo ahí deja el equipo habilitado para el modo perdido; el permiso queda guardado y sobrevive a las siguientes actualizaciones.
• Si nadie concede ese permiso, el caso lo dice con un motivo claro (wayland_sin_autorizacion) en vez de fingir una captura: es un dato accionable, no una falla.
• Windows y macOS: sin cambios; su comportamiento es el de la versión anterior.

Agente multiplataforma de Observer RMM (Windows, Linux, macOS). Binarios adjuntos abajo y publicados también en el CDN agents.observer.cl.

Corrige un fallo de macOS que hacía que, cuando el permiso de Cámara tardaba en resolverse, el de Grabación de pantalla ni siquiera se intentara. Conviene actualizar todos los Mac. Windows y Linux no cambian.

Cambios en esta versión

• Corregido: el permiso de Grabación de pantalla no se pedía si el de Cámara se demoraba. El agente pide los dos permisos uno tras otro. El segundo pedido se lanzaba con lo que quedaba de un cronómetro que ya había gastado el primero, así que en cuanto había una persona contestando el diálogo de la cámara —o sea, en el caso normal— el de la pantalla se daba por vencido antes de empezar.
• El síntoma engañaba: en el registro quedaba un fallo del pedido de pantalla, que se lee como si el sistema lo hubiera rechazado. No lo rechazaba: nunca llegó a preguntar.
• Cada paso tiene ahora su propio tiempo, y ese tiempo se fijó por encima de lo que el propio macOS puede tardar en cerrar el proceso anterior. Antes estaba por debajo, así que una espera legítima se contaba como error.
• Dos comprobaciones automáticas nuevas, las dos probadas al revés: fallan contra el código anterior.
• Windows y Linux no cambian en esta versión.

Notas de actualización

• La actualización es automática y no cambia ninguna configuración existente.
• En equipos macOS con alguien conectado, es esperable que aparezcan los avisos de Cámara y Grabación de pantalla a nombre de ObserverCaptura. Conceder ambos ahí mismo es lo que corresponde: los permisos se pierden en cada actualización y el agente sirve justamente para poder volver a pedirlos.
• Acceso a disco completo: este permiso se concede a mano y también se pierde al actualizar. Se repone en Ajustes del Sistema › Privacidad y seguridad › Acceso a disco completo, añadiendo /opt/observeragent/observeragent. Afecta a la ubicación del equipo, no a la captura.
• La foto de cámara en macOS necesita que alguien tenga la sesión gráfica abierta; en Windows y Linux no.
• La foto de cámara sigue apagada de fábrica y sólo se activa a propósito desde la configuración de la plataforma.
• El LED de la cámara se enciende y no se oculta, igual que en versiones anteriores.

Agente multiplataforma de Observer RMM (Windows, Linux, macOS). Binarios adjuntos abajo y publicados también en el CDN agents.observer.cl.

Corrige la v2.15.25 en macOS y conviene actualizar todos los Mac. Es la que hace que la reparación del permiso de Grabación de pantalla funcione de verdad: las versiones anteriores la intentaban y el sistema la rechazaba por un motivo que no se veía. Windows y Linux no cambian.

Cambios en esta versión

• Corregido: la reparación del permiso de Grabación de pantalla nunca llegaba a ejecutarse. El agente le pedía al sistema que borrara la autorización vencida usando el nombre del permiso tal como aparece en pantalla —«Grabación de pantalla»— en vez del identificador interno que la herramienta del sistema espera. El sistema respondía con un error que parecía indicar otra cosa, así que el problema sobrevivió a tres versiones.
• Se nota sobre todo en equipos en español, que es donde el nombre visible y el identificador interno no coinciden. En un Mac configurado en inglés esto funcionaba por casualidad.
• Con esto, la secuencia completa funciona: el agente borra la autorización vencida, el sistema vuelve a preguntar, y la persona puede conceder el permiso en el momento — sin reinstalar nada.
• Windows y Linux no cambian en esta versión.
• Una comprobación automática nueva, probada al revés: si se vuelve a pasar el nombre visible, falla.

Notas de actualización

• La actualización es automática y no cambia ninguna configuración existente.
• En equipos macOS con alguien conectado, es esperable que aparezcan los avisos de Cámara y Grabación de pantalla a nombre de ObserverCaptura. Conceder ambos ahí mismo es lo que corresponde: los permisos se pierden en cada actualización y esta versión sirve justamente para poder volver a pedirlos.
• Acceso a disco completo: este permiso se concede a mano y también se pierde al actualizar. Se repone en Ajustes del Sistema › Privacidad y seguridad › Acceso a disco completo, añadiendo /opt/observeragent/observeragent. Afecta a la ubicación del equipo, no a la captura.
• La foto de cámara en macOS necesita que alguien tenga la sesión gráfica abierta; en Windows y Linux no.
• La foto de cámara sigue apagada de fábrica y sólo se activa a propósito desde la configuración de la plataforma.
• El LED de la cámara se enciende y no se oculta, igual que en versiones anteriores.

Agente multiplataforma de Observer RMM (Windows, Linux, macOS). Binarios adjuntos abajo y publicados también en el CDN agents.observer.cl.

Corrige la v2.15.24 en macOS y conviene actualizar todos los Mac. Aquella traía la reparación del permiso de Grabación de pantalla, y al medirla en un equipo real no llegó a funcionar: un defecto anterior, que sólo se ve en un equipo con el agente instalado y en uso, la anulaba. Windows y Linux no cambian.

Cambios en esta versión

• Corregido: la aplicación auxiliar se rehacía una y otra vez, muchas veces por minuto. Debía rehacerse sólo cuando el agente se actualiza; en la práctica se rehacía en cada consulta. El agente comprobaba si hacía falta mirando un archivo que él mismo modifica al firmarlo un instante después, así que la comprobación nunca volvía a dar que estaba al día.
• Eso era lo que impedía reparar el permiso de pantalla: la reparación se ejecutaba sobre una aplicación que se estaba reescribiendo en ese mismo momento, y el sistema la rechazaba. Con esto corregido, la reparación de la v2.15.24 puede hacer su trabajo.
• Efecto secundario que también desaparece: trabajo de disco y de firma repetido sin necesidad en cada equipo macOS.
• Windows y Linux no cambian en esta versión.
• Una comprobación automática nueva, probada al revés: si el testigo vuelve a ser el archivo que la firma reescribe, falla.

Notas de actualización

• La actualización es automática y no cambia ninguna configuración existente.
• En equipos macOS con alguien conectado, es esperable que aparezcan los avisos de Cámara y Grabación de pantalla a nombre de ObserverCaptura. Conceder ambos ahí mismo es lo que corresponde.
• Acceso a disco completo: este permiso se concede a mano y también se pierde al actualizar. Se repone en Ajustes del Sistema › Privacidad y seguridad › Acceso a disco completo, añadiendo /opt/observeragent/observeragent. Afecta a la ubicación del equipo, no a la captura.
• La foto de cámara en macOS necesita que alguien tenga la sesión gráfica abierta; en Windows y Linux no.
• La foto de cámara sigue apagada de fábrica y sólo se activa a propósito desde la configuración de la plataforma.
• El LED de la cámara se enciende y no se oculta, igual que en versiones anteriores.

Agente multiplataforma de Observer RMM (Windows, Linux, macOS). Binarios adjuntos abajo y publicados también en el CDN agents.observer.cl.

Completa la v2.15.23 en macOS y conviene actualizar todos los Mac. Aquella dejó dicho lo que no hacía: tras actualizar, Grabación de pantalla quedaba pendiente y el agente no la reparaba por sí mismo. Esta versión la repara. Windows y Linux no cambian.

Cambios en esta versión

• En macOS, el permiso de Grabación de pantalla vuelve a pedirse solo después de cada actualización. Hasta ahora quedaba en un estado sin salida: el sistema seguía teniendo anotada la autorización de la versión anterior, la mostraba encendida en Ajustes, y a la vez la denegaba — sin volver a preguntar nunca. El agente ahora borra esa anotación vencida y pide el permiso de nuevo, con lo que el sistema vuelve a preguntar y la persona puede concederlo en el momento.
• Por qué no se hacía ya: el agente descartaba esa reparación cuando le parecía que nunca se había preguntado — y una autorización vencida se ve exactamente igual que una que nunca existió. Descartaba, entonces, justo el caso para el que la reparación existe. Medido en un equipo real.
• La cámara no cambia: el sistema ya volvía a preguntar por ella solo, y la foto está medida funcionando.
• Windows y Linux no cambian en esta versión.
• Una comprobación automática nueva, probada también al revés: reintroduciendo la condición que anulaba la reparación, falla.

Lo que sigue necesitando a una persona

Conviene decirlo claro, porque cambia lo que hay que planificar:

Lo que esta versión cambia es que el sistema vuelve a preguntar. Antes, en la pantalla, dejaba de preguntar para siempre y la captura quedaba muerta hasta reinstalar.

Notas de actualización

• La actualización es automática y no cambia ninguna configuración existente.
• En equipos macOS con alguien conectado, es esperable que aparezcan los avisos de Cámara y Grabación de pantalla a nombre de ObserverCaptura. Conceder ambos ahí mismo es lo que corresponde.
• La foto de cámara en macOS necesita que alguien tenga la sesión gráfica abierta; en Windows y Linux no.
• La foto de cámara sigue apagada de fábrica y sólo se activa a propósito desde la configuración de la plataforma.
• El LED de la cámara se enciende y no se oculta, igual que en versiones anteriores.

Agente multiplataforma de Observer RMM (Windows, Linux, macOS). Binarios adjuntos abajo y publicados también en el CDN agents.observer.cl.

Corrige la v2.15.22 en macOS y conviene actualizar todos los Mac. Aquella estrenó la foto de cámara —que funciona— y el permiso reparable; al medirla en un equipo real aparecieron dos fallas alrededor: la captura de pantalla no llegaba a guardarse, y el agente avisaba de un permiso faltante que la persona sí había concedido. Windows y Linux no cambian.

Cambios en esta versión

• Corregido: en macOS la captura de pantalla no se guardaba. El agente pedía la imagen en la carpeta de trabajo reservada al servicio, y la herramienta del sistema necesita crear ahí un archivo temporal propio que esa carpeta no le permite. La captura moría sin dejar nada. Ahora la imagen se toma en el área temporal del usuario y se copia al archivo final, que sigue naciendo cerrado y legible sólo por quien tiene la sesión abierta.
• Y fallaba igual que si faltara el permiso, que es lo que más costó: la herramienta del sistema termina informando éxito en los dos casos, así que un problema de carpetas se leía como un permiso denegado. Esta versión distingue las dos cosas.
• Corregido: el aviso de «permiso pendiente» aparecía aunque la persona lo hubiera concedido. Al pedir Grabación de pantalla, macOS no espera la respuesta: abre el aviso, contesta «todavía no» y sigue. El agente tomaba esa respuesta como definitiva y mostraba la advertencia. Medido en un equipo real: se dio por vencido 18 segundos antes de que el permiso quedara concedido. Ahora espera a que la concesión aparezca —hasta tres minutos, que es lo que tarda ir a Ajustes del Sistema y volver— antes de decir nada.
• La cámara no cambia: su permiso sí se pregunta y se espera correctamente desde la versión anterior, y la foto está medida funcionando en un Mac real.
• Windows y Linux no cambian en esta versión.
• Dos comprobaciones automáticas nuevas, probadas también al revés: deshaciendo cada arreglo, fallan.

Notas de actualización

• La actualización es automática y no cambia ninguna configuración existente.
• ⚠️ Los permisos de macOS hay que volver a concederlos, como en cada actualización. La aplicación auxiliar se rehace junto con el agente, y macOS ata sus autorizaciones a la versión exacta del programa: al cambiar, las descarta. Medido en un equipo real con esta misma actualización.
• Cámara: el sistema vuelve a preguntar solo. Basta conceder cuando aparezca el aviso.
• Grabación de pantalla: el sistema no vuelve a preguntar, y en esta versión el agente todavía no lo repara por sí mismo. Queda pendiente hasta la próxima versión; mientras tanto, la captura de pantalla de un equipo macOS no está disponible tras actualizar.
• En macOS, la foto de cámara necesita que alguien tenga la sesión gráfica abierta; en Windows y Linux no.
• La foto de cámara sigue apagada de fábrica y sólo se activa a propósito desde la configuración de la plataforma.
• El LED de la cámara se enciende y no se oculta, igual que en versiones anteriores.

Agente multiplataforma de Observer RMM (Windows, Linux, macOS). Binarios adjuntos abajo y publicados también en el CDN agents.observer.cl.

Continúa la v2.15.21. Aquella sacó un intento de recuperación de permisos que no podía funcionar y dejó el problema declarado: en macOS, los permisos concedidos al agente no se podían reparar, y había que volver a concederlos a mano después de cada actualización, para siempre. Esta versión los hace reparables, y a la vez estrena la foto de cámara en macOS, que hasta ahora no salía en ningún Mac.

Cambios en esta versión

• La foto de cámara funciona en macOS. Hasta ahora el agente dependía de un programa de línea de comandos para tomarla, y macOS no trae ninguno: en un Mac recién instalado la foto simplemente no salía. Ahora la toma el propio agente con el componente de cámara del sistema, sin instalar nada.
• La captura de pantalla y la foto pasan por una aplicación auxiliar propia, ObserverCaptura. El agente la instala, la firma y la registra por sí solo junto al servicio, y la rehace en cada actualización. Es el cambio de fondo de esta versión y el que explica los dos puntos siguientes.
• Hay que conceder los permisos una vez más, y sólo una vez más. En Ajustes del Sistema aparecerá ObserverCaptura —no el agente— pidiendo Cámara y Grabación de pantalla. Como es una aplicación nueva para el sistema, el diálogo sí aparece, a diferencia de lo que ocurría con el agente.
• A cambio, los permisos dejan de perderse en cada actualización. Estando concedidos a una aplicación empaquetada, el agente puede volver a pedirlos por sí solo cuando el sistema los invalida. El aviso de permisos pendientes de la v2.15.20 pasa de sólo avisar a arreglar.
• En macOS, la foto de cámara necesita que alguien tenga la sesión gráfica abierta. Es una restricción del sistema operativo, no del agente: sin sesión, la cámara no entrega imagen. Cuando ocurre, el equipo lo informa con un motivo propio en vez de dar un error genérico. En Windows y Linux no aplica: ahí la foto sale con el equipo bloqueado.
• La foto se guarda cerrada desde que nace, legible sólo por el usuario de la sesión, sin pasar por carpetas temporales compartidas.
• Windows y Linux no cambian en esta versión.
• Comprobaciones automáticas nuevas sobre el armado, la firma y el registro de la aplicación auxiliar, y sobre la ronda de permisos. La comprobación que antes prohibía usar la herramienta de reparación del sistema ahora exige que se use, y sólo contra la aplicación auxiliar.

Lo que todavía no está medido en un equipo real

Se dice acá porque cambia la decisión de actualizar, no porque haya un problema conocido:

Notas de actualización

• La actualización es automática y no cambia ninguna configuración existente.
• En equipos macOS es esperable que aparezcan los diálogos de Cámara y Grabación de pantalla a nombre de ObserverCaptura. Conceder ambos ahí mismo es lo que corresponde, y es la última vez que hace falta hacerlo a mano.
• Los permisos que hoy tenga concedidos el agente no se traspasan a la aplicación auxiliar: son autorizaciones distintas a nombres distintos.
• La foto de cámara sigue apagada de fábrica y sólo se activa a propósito desde la configuración de la plataforma.
• El LED de la cámara se enciende y no se oculta, igual que en versiones anteriores.

Agente multiplataforma de Observer RMM (Windows, Linux, macOS). Binarios adjuntos abajo y publicados también en el CDN agents.observer.cl.

Continúa la v2.15.20. Aquella estrenó la ronda de permisos de macOS; ésta corrige lo que se midió al verla funcionar por primera vez en un equipo real: uno de sus pasos no podía funcionar en ningún Mac y, peor, informaba que había funcionado.

Cambios en esta versión

• Se elimina un paso de la recuperación de permisos en macOS que era imposible. Cuando el permiso de Cámara o Grabación de pantalla queda como denegado, el sistema deja de preguntar, y la única forma de que vuelva a preguntar es borrar esa autorización. El agente lo intentaba con la herramienta del sistema (tccutil), y está medido que no puede: esa herramienta sólo acepta aplicaciones empaquetadas, y el agente es un programa suelto. Fallaba en todas sus variantes, con el usuario administrador y con el de la sesión.
• Y el intento se declaraba exitoso. La comprobación miraba si el permiso había quedado «sin definir», pero no lo comparaba con cómo estaba antes: un permiso que ya estaba sin definir hacía que el paso se diera por bueno. En el registro del equipo aparecía como logrado algo que nunca ocurrió — el peor modo de falla para una función que existe para avisar de un problema.
• Qué queda en su lugar: el agente pide el permiso al sistema (dos veces, por dos vías distintas) y, si el sistema ya no pregunta, avisa a la persona con una ventana que dice qué dejó de funcionar. Ese aviso está verificado en un equipo real.
• Una comprobación automática nueva impide que el paso eliminado vuelva a aparecer sin que antes se vuelva a medir. Se probó al revés también: reintroduciendo la llamada, la comprobación falla.
• Windows y Linux no cambian en esta versión. En macOS tampoco cambia lo observable para quien usa el equipo: lo que se saca es un intento invisible que no hacía nada.

Lo que esto significa para los Mac de la flota

Conviene decirlo claro porque cambia lo que hay que planificar, no sólo lo que hace el programa:

Nada de esto afecta a la ubicación del equipo, al bloqueo, al mensaje en pantalla ni a la alarma, que no dependen de esos permisos.

Notas de actualización

• La actualización es automática y no cambia ninguna configuración existente.
• En equipos macOS con alguien conectado, es esperable que aparezca una vez la ventana de permisos pendientes después de actualizar: el programa cambió y el sistema descartó las autorizaciones anteriores. Conceder los permisos ahí mismo es lo que corresponde.
• La foto de cámara sigue apagada de fábrica y sólo se activa a propósito desde la configuración de la plataforma.

Agente multiplataforma de Observer RMM (Windows, Linux, macOS). Binarios adjuntos abajo y publicados también en el CDN agents.observer.cl.

Continúa la v2.15.19. Aquella corrigió la comprobación del permiso de cámara en macOS; ésta va un paso más allá en los dos equipos donde el sistema operativo se interpone entre el agente y la pantalla: macOS, donde ahora el agente pide sus propios permisos en el momento en que hay alguien delante, y Linux con Wayland, donde la captura de pantalla dejaba de intentarse.

Cambios en esta versión

• macOS: el agente pide sus propios permisos, y los vuelve a pedir cuando el sistema se los quita. En macOS, la Cámara y la Grabación de pantalla no se pueden conceder por administración remota —el perfil de Apple para eso sólo sabe negarlas—: la única vía es el diálogo del sistema, con una persona frente al equipo. Ahora el agente lo pide él mismo, al instalarse y después de cada actualización.
• El disparador no es «hubo una actualización», sino que el programa es otro. Es exactamente el evento que hace que macOS descarte los permisos vigentes, y se detecta sin depender de que la actualización avise. Así no quedan equipos con los permisos caídos en silencio, que era lo que pasaba hasta ahora.
• Nunca en medio de un caso de equipo perdido. Un diálogo de permisos en un equipo robado le avisa a quien se lo llevó que alguien está mirando. La ronda de permisos está prohibida mientras hay un caso activo, y también si no hay ninguna sesión abierta en el equipo: sin nadie que conteste, el sistema puede denegar sin preguntar, y esa negativa después cuesta más de revertir.
• El instalador no pide los permisos; los pide el servicio al arrancar. Si los pidiera el instalador, el permiso quedaría a nombre de la Terminal desde la que se instaló y no le serviría al agente. Con este cambio la autorización queda anclada al agente, que es lo que se necesita.
• Se molesta a la persona lo mínimo: como máximo dos rondas por versión del programa, con 24 horas entre ellas, y el aviso final —el que aparece cuando el diálogo ya no es posible— sale una sola vez y explica qué deja de funcionar, en vez de mandar a nadie a revisar interruptores que no reparan nada.
• Linux con Wayland: la captura de pantalla vuelve a existir. Hasta ahora, en una sesión Wayland el agente informaba «no soportado» sin intentar nada, porque las herramientas de X11 devuelven una imagen negra en vez de fallar. Ahora se prueba, en orden y según el escritorio, la vía nativa y silenciosa de cada uno —GNOME, KDE y los escritorios basados en wlroots (Sway, Hyprland, river)— y sólo si el equipo no tiene ninguna se recurre al mecanismo genérico del sistema, que exige una autorización previa.
• En GNOME la captura no muestra el destello de la pantalla al tomarla, que delataría el proceso en un equipo perdido.
• Dos motivos distintos donde antes había uno. wayland_no_soportado pasa a significar «este equipo no tiene ninguna vía» y se suma wayland_sin_autorizacion, que es un equipo reparable con una visita. Fundirlos hacía ver como limitación permanente algo que se arregla en dos minutos.
• La autorización de Wayland se pide con las mismas guardias que la de macOS: al arrancar el servicio, nunca con un caso activo, nunca si el escritorio ya tiene una vía silenciosa —no hay por qué molestar a nadie— y con el mismo tope de dos intentos.
• Windows no cambia en esta versión.
• Comprobaciones automáticas nuevas: 35 casos que fijan el orden de intentos por escritorio y el análisis de las respuestas, más la batería de la ronda de permisos de macOS. Corren en cada integración, también las de macOS, que se prueban en Linux a propósito para que no dependan de tener un Mac disponible.

Lo que todavía no está medido en un equipo real

Se dice acá porque cambia la decisión de actualizar, no porque haya un problema conocido:

Ninguna de las dos novedades toca el camino que hoy funciona: un equipo Windows, un Linux con X11 o un macOS se comportan igual que con la versión anterior.

Notas de actualización

• La actualización es automática y no cambia ninguna configuración existente.
• La foto de cámara sigue apagada de fábrica y sólo se activa a propósito desde la configuración de la plataforma.
• El LED de la cámara se enciende y no se oculta, igual que en versiones anteriores.
• En equipos macOS, después de esta actualización el agente pedirá los permisos por sí solo: conviene avisarle a quien usa el equipo que el diálogo es esperable y que corresponde concederlo.

Agente multiplataforma de Observer RMM (Windows, Linux, macOS). Binarios adjuntos abajo y publicados también en el CDN agents.observer.cl.

Continúa la v2.15.18. Aquella hizo que la foto de cámara funcionara en Linux sin depender de programas instalados; ésta corrige el equivalente en macOS, donde la función no llegaba a intentarse nunca — ni siquiera en un equipo que tuviera el permiso concedido.

Cambios en esta versión

• En macOS, la comprobación del permiso de cámara no podía funcionar. Antes de encender la cámara, el agente le pregunta al sistema si tiene autorización. Esa consulta estaba mal escrita y fallaba siempre, en todos los equipos, así que el agente concluía que no había permiso y no tomaba la foto aunque el permiso estuviera concedido. Corregido.
• Por qué no se había visto: el resultado que publicaba era permiso denegado, exactamente el mismo mensaje que aparece cuando el permiso realmente falta. Desde la consola los dos casos se veían idénticos, así que el error no tenía ningún síntoma propio. Se detectó midiendo en un MacBook real, no en pruebas.
• Lo observable no cambia en un equipo sin permiso: el agente sigue sin abrir la cámara y sin mostrar ningún aviso a quien tiene el equipo, que es el comportamiento buscado — pedir el permiso en ese momento le avisaría a quien se llevó el computador que alguien lo está mirando. Lo que cambia es que ahora, en un equipo con el permiso concedido, la foto se toma.
• Dos comprobaciones automáticas nuevas impiden que el error vuelva: una prohíbe la construcción exacta que lo causó y la otra impide que la consulta se vacíe para satisfacer a la primera. Ambas corren en cada integración.
• Windows y Linux no cambian en esta versión.

Importante para equipos macOS: los permisos se pierden al actualizar

Durante la medición se confirmó un comportamiento del propio sistema operativo que conviene conocer, porque no es evidente y no genera ningún aviso:

macOS asocia los permisos de Grabación de pantalla, Cámara, Micrófono y Acceso a disco completo a la versión exacta del programa autorizado. Cuando el agente se actualiza, el programa cambia y esos permisos dejan de aplicarse. En el equipo de prueba, Acceso a disco completo pasó a denegado por sí solo al actualizar, y Grabación de pantalla seguía apareciendo encendida en Ajustes del Sistema mientras el sistema la denegaba por detrás.

Esto afecta a cualquier programa distribuido de esta forma, no sólo a este agente, y no se puede resolver por administración remota: los permisos de cámara, micrófono y pantalla sólo los puede conceder una persona frente al equipo. Se está evaluando firmar el agente con una identidad estable de desarrollador, con lo que los permisos sobrevivirían a las actualizaciones.

Notas de actualización

• La actualización es automática y no cambia ninguna configuración existente.
• La foto de cámara sigue apagada de fábrica y sólo se activa a propósito desde la configuración de la plataforma.
• El LED de la cámara se enciende y no se oculta, igual que en versiones anteriores.
• En equipos macOS, revisar los permisos después de actualizar (ver el apartado anterior).

Agente multiplataforma de Observer RMM (Windows, Linux, macOS). Binarios adjuntos abajo y publicados también en el CDN agents.observer.cl.

Continúa la v2.15.17. Esa versión le puso cara al modo perdido; ésta se asegura de que la cara también se vea en los equipos de un cliente, donde no hay nada instalado y la red no deja instalar nada.

Cambios en esta versión

• En Linux, la foto de la cámara ya no depende de que el equipo tenga programas instalados. El agente la toma directamente del dispositivo, con lo que trae el propio sistema operativo. Hasta la versión anterior necesitaba fswebcam o ffmpeg, y si no estaban, el caso recibía el motivo no hay herramienta de captura en lugar de una foto.
• Por qué importa: en los dos equipos Linux reales donde se probó, ninguno traía esos programas y ninguno podía instalarlos — en uno la red del cliente bloquea los repositorios y en el otro un equipo de seguridad de la red interrumpe las conexiones cifradas. Es decir que la función fallaba justo en el escenario para el que existe: un equipo de cliente, en la red del cliente, recién sustraído.
• El instalador sigue sin tocar el gestor de paquetes del equipo. Se evaluó que el instalador instalara el programa que faltaba y se descartó: además de no funcionar en las redes donde hace falta, habría añadido 23 MB de dependencias a cada instalación por una función que viene apagada de fábrica, y habría cambiado lo que el instalador de un RMM puede hacer en un servidor con control de cambios.
• La foto sale más rápido y con mejor calidad. La cámara entrega la imagen ya comprimida y el agente la guarda tal cual, sin volver a procesarla: en un equipo real, 1280×720 en poco más de un segundo, incluida la espera para que el sensor ajuste la exposición.
• fswebcam y ffmpeg siguen sirviendo, ahora como respaldo. Si están instalados, se usan cuando la cámara entrega un formato que la vía directa no sabe leer. Ya no son un requisito.
• Se distingue mejor la cámara ocupada. Cuando otro programa tiene la cámara tomada —una videollamada, por ejemplo—, el caso recibe cámara ocupada, que es información del caso y no una avería. Antes eso dependía del texto que imprimiera el programa externo; ahora lo informa el propio sistema.
• En un equipo con varias entradas de video se elige la correcta por lo que declara cada una, no por su número. Una sola cámara publica dos entradas y sólo una entrega imágenes.
• Los equipos con cámaras que sólo entregan imagen sin comprimir también quedan cubiertos: el agente arma el JPEG él mismo.

Lo que se midió en un equipo real

Terreno del 13 de agosto de 2026, en un equipo Linux de un cliente (Ubuntu 24.04, cámara integrada, sin fswebcam ni ffmpeg y sin poder instalarlos):

Notas de actualización

• Nada que hacer: la actualización es automática y no cambia ninguna configuración existente.
• La foto de cámara sigue apagada de fábrica y sólo se activa a propósito desde la configuración de la plataforma.
• El LED de la cámara se enciende y no se oculta, igual que en la versión anterior.
• En Windows no hay cambios en esta área: ya tomaba la foto con los componentes del propio sistema. En macOS la función sigue a la espera del permiso de cámara, que no se puede conceder por administración remota.

Agente multiplataforma de Observer RMM (Windows, Linux, macOS). Binarios adjuntos abajo y publicados también en el CDN agents.observer.cl.

Acompaña a la v1.4.10 de la plataforma. Es la versión que le pone cara al modo perdido: hasta ahora un equipo marcado reportaba dónde estaba y qué había en su pantalla; desde esta, además puede sacar una foto de la cámara de quién lo tiene delante.

Cambios en esta versión

• Foto de la cámara mientras el equipo está marcado como perdido. Cada ciclo puede sumar, junto a la ubicación y la captura de pantalla, una foto de quién está frente al equipo. A diferencia de la pantalla, no depende de que alguien haya iniciado sesión: la cámara es un dispositivo del sistema, así que la foto sirve incluso en la pantalla de inicio —que suele ser justo donde está un equipo recién sustraído—.
• Disponible en Windows y Linux. En Windows la foto se toma con los componentes del propio sistema, sin ninguna herramienta extra. En Linux usa fswebcam o ffmpeg si están instalados, y si no lo están, el caso recibe el motivo no hay herramienta de captura en vez de una foto. En macOS la función queda a la espera del permiso de cámara, que no se puede conceder por administración remota.
• Nace apagada de fábrica. El interruptor de la foto de cámara es global y arranca en off: actualizar el agente no empieza a sacar fotos por su cuenta. Sólo se activa a propósito desde la configuración de la plataforma, y al apagarlo la captura se detiene en el acto, sin esperar a reiniciar el equipo.
• El LED de la cámara se enciende, y no se oculta. En la mayoría de los equipos el LED está cableado al sensor y ninguna aplicación puede apagarlo. La foto nunca es invisible; el agente no intenta ocultar el LED porque el hardware no lo permite y hacerlo sería lo indebido.
• Una foto en negro NUNCA se sube como si fuera evidencia. El sensor arranca con la exposición sin converger y da varios cuadros oscuros; el agente los descarta y mira la imagen final. Si sigue en negro —la tapa puesta, el cuarto a oscuras— manda el motivo en su lugar. Un caso lleno de fotos negras parece tener evidencia y no la tiene.
• Corregido: el interruptor global de la foto de cámara se lee en cada ciclo. Antes se leía una sola vez al arrancar el servicio, así que apagarlo durante un caso abierto no surtía efecto hasta el siguiente reinicio del agente.
• Corregido: en Linux, la foto se escribía en una ruta que no existía y el ciclo terminaba en fallo de captura con la cámara funcionando. Ahora se escribe donde corresponde.

Lo que se midió en un equipo real

Terreno del 13 de agosto de 2026:

⚠️ macOS sigue sin foto de cámara en esta versión: el permiso no se puede conceder por MDM, así que si nadie lo autorizó a mano en el equipo, el caso recibe el motivo correspondiente en vez de una imagen.

Plataformas

Los ocho binarios habituales: Windows x64 y 386 (moderno y legacy), Linux amd64 y 386, macOS amd64 y arm64.

Instalación

Se instala y se actualiza desde la consola, no bajando el binario de esta página. La flota se actualiza sola cuando la plataforma marca esta versión como la vigente.

Compatibilidad

• La foto de cámara requiere la plataforma en v1.4.10 o superior. Contra un servidor anterior el agente funciona igual que la v2.15.16: el modo perdido reporta ubicación y pantalla, sin foto.
• Sin cambios para las funciones existentes en las tres plataformas.

Agente multiplataforma de Observer RMM (Windows, Linux, macOS). Binarios adjuntos abajo y publicados también en el CDN agents.observer.cl.

Acompaña a la v1.4.8 de la plataforma. Es la versión que le da ojos al modo perdido: hasta ahora un equipo marcado reportaba dónde estaba; desde esta, además muestra qué se está haciendo con él.

Cambios en esta versión

• Captura de pantalla mientras el equipo está marcado como perdido. Cada ciclo junta la ubicación del momento y una imagen de la pantalla, y los sube como un lote que la consola muestra en la línea de tiempo del caso. La captura es silenciosa: no suena, no avisa y no deja ninguna ventana a la vista.
• La imagen sale de la sesión de la persona que tiene el equipo, no del servicio. Es la diferencia entre una captura útil y una pantalla negra: un servicio de Windows vive en una sesión sin escritorio, y capturar desde ahí devuelve negro sin dar ningún error.
• Una captura en negro NUNCA se sube como si fuera evidencia. El agente mira la imagen antes de mandarla y, si está vacía, manda el motivo en su lugar. Un caso lleno de imágenes negras parece tener evidencia y no la tiene.
• Cuando no se puede capturar, se dice por qué. El ciclo igual queda registrado con su motivo: nadie ha iniciado sesión, la pantalla del equipo está apagada, la sesión es Wayland (donde no existe captura silenciosa), macOS no tiene concedido el permiso de grabación de pantalla, o el equipo no tiene ninguna herramienta de captura instalada. La consola los muestra redactados, no en clave.
• La evidencia no se acumula en el equipo. La imagen se borra apenas se sube, y si el equipo está sin red el ciclo se pierde en vez de guardarse: dejar un depósito de capturas en el equipo que alguien se llevó sería peor que perder una imagen.
• La ubicación se mide una sola vez por ciclo y el mismo punto alimenta el mapa de siempre y la evidencia del caso. Con dos mediciones, los dos podían contar cosas distintas del mismo instante.

Lo que se midió en un equipo real

Terreno del 12 de agosto de 2026 contra un equipo Linux de laboratorio con escritorio XFCE:

⚠️ Windows y macOS siguen sin medición de terreno de esta función al momento de publicar esta versión. En macOS hay además una limitación conocida y ajena al producto: el permiso de grabación de pantalla no se puede conceder por MDM, así que si nadie lo autorizó a mano en el equipo, el caso recibirá el motivo correspondiente en vez de imágenes.

Compatibilidad

• Requiere la plataforma en v1.4.8 o superior para subir evidencia. Contra un servidor anterior el agente sigue funcionando igual que la v2.15.15: el modo perdido reporta ubicación y nada más.
• Sin cambios para las funciones existentes en las tres plataformas.

Agente multiplataforma de Observer RMM (Windows, Linux, macOS). Binarios adjuntos abajo y publicados también en el CDN agents.observer.cl.

Acompaña a la v1.4.7 de la plataforma. Un solo cambio de comportamiento, y es el que faltaba para que el modo perdido reaccione cuando se lo marca: hasta ahora el estado llegaba al instante pero la cadencia intensiva empezaba en el ciclo siguiente.

Cambios en esta versión

• Corregido: al marcar un equipo encendido, la ubicación intensiva empezaba hasta media hora después. El aviso del servidor fijaba el estado en el momento —el equipo ya sabía que estaba marcado— pero el temporizador de ubicación seguía con la cadencia normal hasta su siguiente turno. Medido en un equipo real: 3 minutos y 20 segundos en un ambiente con la cadencia normal acelerada, y 25 a 35 minutos con la cadencia por omisión del producto. Ahora el aviso re-arma el temporizador en el acto.
• Y toma el primer punto de inmediato, sin esperar el primer turno de la cadencia nueva. Con una cadencia de 60 minutos, esperarlo habría sido una hora sin un solo punto justo después de que alguien denunció el robo. El primer punto —dónde estaba el equipo cuando se lo marcó— es el más valioso del caso. Al recuperar no se captura nada: recuperar es dejar de mirar.
• Interno: la captura de ubicación quedó en una sola función con su guardia de concurrencia, en vez de repetida en cada disparador. Ahora hay dos —el turno del temporizador y el aviso del servidor— y duplicar la guardia invitaba a que uno de los dos se olvidara de tomarla.

Lo que se midió en un equipo real

Marcaje a las 00:12:57; el agente registró el cambio de cadencia y el primer punto en ese mismo segundo. La medición se hizo contra el mismo equipo Linux de laboratorio de la v2.15.14.

⚠️ Como en la versión anterior, todo lo medido fue en Linux de 64 bits. Windows y macOS no tienen medición de terreno de esta función.

Compatibilidad

• Requiere la plataforma en v1.4.6 o superior para operar el modo perdido. Contra un servidor anterior el agente funciona igual que la v2.15.14 y el estado nunca se enciende.
• Sin cambios para las funciones existentes en las tres plataformas.

Agente multiplataforma de Observer RMM (Windows, Linux, macOS). Binarios adjuntos abajo y publicados también en el CDN agents.observer.cl.

Esta versión acompaña a la v1.4.6 de la plataforma y trae el lado del agente de la primera etapa del modo perdido/robado: el estado que sobrevive al apagón y al reinicio, y la ubicación intensiva mientras el caso está abierto. No captura pantalla ni fotos — eso llega en la siguiente etapa.

Cambios en esta versión

• Estado de "equipo perdido" que sobrevive al proceso y al reinicio. El equipo guarda el estado en su propio disco y lo retoma al arrancar el servicio, sin esperar a hablar con el servidor. Un equipo robado se reinicia —lo apaga quien lo tiene, o se queda sin batería—, así que un estado que sólo viviera en memoria se perdería justo en el escenario para el que existe. Al recuperar el equipo, el archivo se borra en vez de quedar marcado como inactivo: no queda en el disco un rastro de que se lo estuvo siguiendo.
• Dos caminos para enterarse, y el segundo es el que importa. El aviso inmediato del servidor no sirve si el equipo estaba apagado cuando lo marcaron —que es el caso central—, así que el estado también viaja en la consulta de configuración que el agente hace por su cuenta. Ese camino es el garantizado: el equipo se entera al reconectarse.
• Ubicación intensiva mientras el caso está abierto. La frecuencia de reporte pasa a la del caso (entre 1 y 60 minutos) y vuelve sola a la normal al recuperar el equipo. El límite se aplica dos veces, en el servidor y otra vez en el agente: el valor llega por dos caminos distintos y un cero significaría captura continua, que mata la batería y delata al agente frente a quien tiene el equipo.
• El modo perdido pasa por encima del interruptor global de geolocalización, y también del sensor del sistema. Sin eso la función sería inútil en una instalación nueva, que viene con la geolocalización apagada. En Windows 11 24H2 y Server 2025 el rastreo por redes WiFi además exige la ubicación del sistema activada; el agente la activa mientras el caso está abierto, porque encender el interruptor sin encender el sensor sería un "listo" falso.
• La captura de ubicación salió del hilo principal. Con la frecuencia del caso, una captura lenta —en macOS puede costar hasta 40 segundos— retrasaba el latido que mantiene al equipo "en línea" en la consola, y podía hacerlo aparecer desconectado justo cuando más importa. Si una captura se pasa de largo, se salta el turno en vez de apilar dos.
• Corregido: al arrancar, el modo perdido tardaba hasta media hora en activarse. El dato ya venía en la primera consulta de configuración del arranque y no se aplicaba: había que esperar al primer turno de ubicación. Medido en un equipo real: 5 minutos y 2 segundos en un ambiente con la frecuencia de ubicación acelerada, y entre 25 y 35 minutos con la frecuencia por omisión del producto.
• Corregido: después de reiniciar, la ubicación volvía a la frecuencia normal por otra media hora. El estado se retomaba del disco al instante, pero el temporizador nacía con la frecuencia de siempre y sólo bajaba a la del caso en el turno siguiente — justo la ventana ciega que la persistencia venía a evitar. Medido tras matar el servicio a la fuerza: 5 minutos y 12 segundos; ahora el temporizador nace con la frecuencia del caso.
• La caída de red no apaga el modo perdido. Cuando el agente no logra hablar con el servidor usa una configuración de repliegue con todos los campos en cero, y ese cero se leía como "el servidor dice que ya no está perdido". Ahora el estado sólo se aplica cuando la configuración vino de verdad del servidor: perder la red es exactamente cuando no se sabe.
• Interno: el workflow de integración continua declaraba correr en todas las ramas y no lo hacía —el comodín no cruza barras—, así que ninguna rama de trabajo disparaba las pruebas y el vacío se leía como "todavía no arrancó".

Lo que se midió en un equipo real

Sobre un equipo Linux de laboratorio enrolado en el ambiente de pruebas, antes y después de los arreglos:

⚠️ Todo lo anterior se midió en Linux de 64 bits. Windows y macOS no tienen medición de terreno de esta función todavía.

Compatibilidad

• Requiere la plataforma en v1.4.6 o superior para operar el modo perdido; contra un servidor anterior el agente funciona igual que la v2.15.3 y el estado nunca se enciende.
• Sin cambios para las funciones existentes en las tres plataformas.

Agente multiplataforma de Observer RMM (Windows, Linux, macOS). Binarios adjuntos abajo y publicados también en el CDN agents.observer.cl.

✅ Versión estable. Sale del candidato v2.15.3-rc1 sin un solo cambio de código —mismo árbol— después de probarlo en un equipo Windows de verdad. Lo que cambia respecto de la candidata es lo que ahora está medido en vez de afirmado, y queda escrito más abajo.

Cambios en esta versión

• Corregido: en un equipo con Windows de 64 bits donde se instaló el agente de 32 bits, la actualización automática no surtía efecto nunca. El instalador dejaba los archivos en C:\Program Files\ObserverAgent y el agente los buscaba en C:\Program Files (x86)\ObserverAgent, así que el servicio seguía ejecutando el binario viejo: la versión reportada a la consola no cambiaba y el equipo volvía a descargar los mismos 7,9 MB cada hora, para siempre y en silencio. El agente ya no deduce dónde está instalado: lo resuelve del ejecutable que está corriendo y del registro. 🔑 Los equipos que ya quedaron en ese estado se sanan con la actualización normal, sin que nadie los toque.
• Corregido: en esos mismos equipos el inventario de software mostraba 97 programas de 424. El agente leía sólo la mitad de 32 bits del registro y quedaba ciego a todo el software de 64 bits instalado en el equipo. Ahora consulta las dos vistas, sin duplicar el listado en un Windows de 32 bits genuino.
• Corregido: en esos mismos equipos, «Desinstalar agente» desde la consola fallaba en silencio, y desinstalar a mano no cortaba el acceso remoto. Las dos cosas buscaban archivos en el directorio equivocado: el desinstalador de Inno Setup y el meshagent.exe del acceso remoto.
• El instalador de Windows ahora se niega a instalarse cuando la arquitectura no calza, en las dos direcciones. El de 32 bits sobre un Windows de 64 bits, y el de 64 bits sobre un Windows de 32 bits. Antes los dos casos terminaban «bien» y el problema aparecía después, lejos de su causa: el primero dejaba el equipo en el bucle de descarga de arriba, y el segundo dejaba los archivos, la entrada en «Agregar o quitar programas» y ningún agente corriendo. Ahora sale un mensaje diciendo qué instalador corresponde. ⚠️ La negativa no alcanza a las actualizaciones de un equipo que ya tiene el agente de 32 bits puesto: si las bloqueara, esos equipos nunca recibirían el arreglo que los repara.
• Corregido: si el enrolamiento fallaba, el equipo quedaba con el acceso remoto instalado y sin ficha en la consola. El instalador pone el acceso remoto antes de registrar el equipo; cuando ese registro fallaba, el proceso moría dejando un acceso remoto vivo que ninguna fila del RMM apunta. Ahora, si el registro falla, se deshace lo que esa misma corrida instaló. ⚠️ Deshacerlo cierra el acceso en el equipo, pero no borra el registro del lado del servidor: eso es local por diseño y lo levanta el censo diario. Cada intento fallido de enrolamiento deja un registro más para ese censo.
• La desinstalación ya no borra por su cuenta el directorio del acceso remoto. Quien se lleva ese directorio es la propia desinstalación del acceso remoto, en 4,3 s y con código 0. La línea que lo borraba no hacía nada en el camino sano y sólo llegaba a actuar cuando lo otro fallaba — justo el caso en que borrar es irreversible, porque se lleva el único ejecutable con el que se puede reintentar a mano.
• En Windows de 64 bits con el agente de 64 bits, y en Windows de 32 bits genuino, no cambia nada. Esa es la flota normal: ahí no había ninguna ruta divergida que corregir y el comportamiento es idéntico al de la v2.15.2. Linux y macOS tampoco cambian.

Lo que se midió en un equipo real

El recorrido completo —instalar la v2.15.2 de 32 bits en un Windows 10 de 64 bits, actualizar con este instalador y verificar el resultado— se ejecutó sobre un equipo de laboratorio. Cinco criterios verdes y uno rojo, y el rojo está explicado abajo:

Sobre el rojo — es residuo en disco, y se asume a conciencia. La migración deja el directorio viejo con 2.742 archivos / 81 MB de la instalación anterior. No afecta al servicio, ni al acceso remoto, ni a las actualizaciones siguientes: el agente ya no mira ahí. Limpiarlo desde el propio agente significaría que un proceso corriendo borre el árbol del que acaba de mudarse, y ese es exactamente el camino en que un borrado equivocado no tiene vuelta. Se limpia por fuera, con la plantilla agente-386-ruta-legacy.ps1 de la biblioteca de scripts de la consola, que primero censa y después borra.

⚠️ Dos cosas que siguen sin medirse, y conviene saberlo:

• El binario de compatibilidad (Windows 7/8) no quedó ejercitado. El instalador de 32 bits elige por versión de Windows, y en un Windows 10 entrega el moderno. El mecanismo corregido sí está probado —vive en archivos comunes a los dos—, el binario de compatibilidad no.
• La negativa del instalador de 64 bits sobre un Windows de 32 bits está afirmada sobre el código, no medida: no hay máquinas de 32 bits en la integración continua. Es el caso ruidoso, no el silencioso: un binario de 64 bits directamente no ejecuta en un sistema de 32 bits.

Notas de la consola que acompañan a esta versión

Estas dos no son del agente —son del servidor y de la consola web—, pero se publican acá porque es donde se van a leer, y también quedan en docs.observer.cl:

• 🔐 Los secretos de la Configuración global ya no se pueden volver a leer. La contraseña del SMTP, el token del asistente de IA y las credenciales de MeshCentral salen enmascarados de la consola y del registro de auditoría. Al editar, dejar el campo vacío significa «no lo toqué» y conserva el valor guardado; para escribir uno nuevo hay que reemplazarlo. Consecuencia práctica: anota la contraseña antes de guardarla, porque después no hay forma de recuperarla desde la consola. La integración con MeshCentral pasó además a sólo lectura — se configura desde el servidor, y editarla desde la consola no persistía.
• 🤖 La clave del asistente de IA que viene sembrada es de cortesía: reemplázala por la tuya. El producto trae una clave de OpenRouter para que la función se pueda probar sin configurar nada, pero es una sola clave compartida, así que el cupo diario es uno para toda la flota y se agota entre todos. Además, los modelos gratuitos de esa plataforma suelen condicionarse a que los textos enviados se usen para entrenamiento. Para uso real, pon tu propio token en Configuración global → Asistente de IA: sirve cualquier proveedor compatible con el formato de OpenAI, incluido uno alojado por ti.

Plataformas

darwin-amd64 · darwin-arm64 · linux-386 · linux-amd64 · linux-arm · linux-arm64 · windows-386 · windows-amd64

Instalación

El agente se instala desde la consola de Observer RMM (Agentes → Agregar), que genera el instalador con el token de enrolamiento del cliente/sitio. Los binarios de esta página son los que sirve el backend / CDN. La flota que ya tiene el agente instalado sube sola a esta versión en su ciclo siguiente.

---

Licencia: uso interno BrainCorp.

Agente multiplataforma de Observer RMM (Windows, Linux, macOS). Binarios adjuntos abajo y publicados también en el CDN agents.observer.cl.

⚠️ Versión candidata (-rc1): no es para la flota. Sale marcada como prerelease, sin marcar «Latest», y el backend sigue entregando la v2.15.2, así que ningún equipo la toma solo. Existe para producir el instalador nuevo de Windows y poder probarlo en un equipo de verdad: el instalador sólo se puede compilar en un release. Cuando esas pruebas pasen, sale la v2.15.3 definitiva.

Cambios en esta versión

• Corregido: en un equipo con Windows de 64 bits donde se instaló el agente de 32 bits, la actualización automática no surtía efecto nunca. El instalador dejaba los archivos en C:\Program Files\ObserverAgent y el agente los buscaba en C:\Program Files (x86)\ObserverAgent, así que el servicio seguía ejecutando el binario viejo: la versión reportada a la consola no cambiaba y el equipo volvía a descargar los mismos 7,9 MB cada hora, para siempre y en silencio. El agente ya no deduce dónde está instalado: lo resuelve del ejecutable que está corriendo y del registro. 🔑 Los equipos que ya quedaron en ese estado se sanan con la actualización normal, sin que nadie los toque.
• Corregido: en esos mismos equipos el inventario de software mostraba 97 programas de 424. El agente leía sólo la mitad de 32 bits del registro y quedaba ciego a todo el software de 64 bits instalado en el equipo. Ahora consulta las dos vistas, sin duplicar el listado en un Windows de 32 bits genuino.
• Corregido: en esos mismos equipos, «Desinstalar agente» desde la consola fallaba en silencio, y desinstalar a mano no cortaba el acceso remoto. Las dos cosas buscaban archivos en el directorio equivocado: el desinstalador de Inno Setup y el meshagent.exe del acceso remoto.
• El instalador de Windows ahora se niega a instalarse cuando la arquitectura no calza, en las dos direcciones. El de 32 bits sobre un Windows de 64 bits, y el de 64 bits sobre un Windows de 32 bits. Antes los dos casos terminaban «bien» y el problema aparecía después, lejos de su causa: el primero dejaba el equipo en el bucle de descarga de arriba, y el segundo dejaba los archivos, la entrada en «Agregar o quitar programas» y ningún agente corriendo. Ahora sale un mensaje diciendo qué instalador corresponde. ⚠️ La negativa no alcanza a las actualizaciones de un equipo que ya tiene el agente de 32 bits puesto: si las bloqueara, esos equipos nunca recibirían el arreglo que los repara.
• Corregido: si el enrolamiento fallaba, el equipo quedaba con el acceso remoto instalado y sin ficha en la consola. El instalador pone el acceso remoto antes de registrar el equipo; cuando ese registro fallaba, el proceso moría dejando un acceso remoto vivo que ninguna fila del RMM apunta — el perfil de los 4 nodos huérfanos del 2026-07-29. Ahora, si el registro falla, se deshace lo que esa misma corrida instaló. ⚠️ Deshacerlo cierra el acceso en el equipo, pero no borra el registro del lado del servidor: eso es local por diseño y lo levanta el censo diario. Cada intento fallido de enrolamiento deja un registro más para ese censo.
• La desinstalación ya no borra por su cuenta el directorio del acceso remoto. Medido el 2026-08-09 en un Windows 10 x64: quien se lleva ese directorio es la propia desinstalación del acceso remoto, en 4,3 s y con código 0. La línea que lo borraba no hacía nada en el camino sano y sólo llegaba a actuar cuando lo otro fallaba — justo el caso en que borrar es irreversible, porque se lleva el único ejecutable con el que se puede reintentar a mano.
• En Windows de 64 bits con el agente de 64 bits, y en Windows de 32 bits genuino, no cambia nada. Esa es la flota normal: ahí no había ninguna ruta divergida que corregir y el comportamiento es idéntico al de la v2.15.2. Linux y macOS tampoco cambian.
• Limitación conocida y aceptada: al desinstalar el agente de 32 bits de un equipo de 64 bits queda C:\Program Files (x86)\ObserverAgent con archivos adentro. Es basura en disco, sin efecto sobre el servicio ni sobre el acceso remoto, y sólo en un escenario que no debería existir — es una instalación equivocada, no una configuración soportada.

Qué falta probar en esta candidata

• El recorrido completo en un equipo de verdad con el agente de 32 bits sobre Windows de 64 bits: instalar la v2.15.2, actualizar con este instalador y comprobar que el servicio queda reapuntado, que la versión sube y que el inventario pasa de ~97 a ~424 programas.
• ⚠️ En Windows 10 ese banco no ejercita el binario de compatibilidad (el de Windows 7/8): el instalador de 32 bits elige por versión de Windows y en un Windows 10 entrega el moderno. El mecanismo corregido sí queda probado — vive en archivos comunes a los dos —, el binario de compatibilidad no.
• La negativa del instalador de 64 bits sobre un Windows de 32 bits está afirmada sobre el código y no medida: no hay máquinas de 32 bits en la integración continua.

Plataformas

darwin-amd64 · darwin-arm64 · linux-386 · linux-amd64 · linux-arm · linux-arm64 · windows-386 · windows-amd64

Instalación

El agente se instala desde la consola de Observer RMM (Agentes → Agregar), que genera el instalador con el token de enrolamiento del cliente/sitio. Los binarios de esta página son los que sirve el backend / CDN. Al ser una versión candidata, la consola no la entrega: para probarla hay que tomar el instalador de esta página y correrlo a mano en el equipo de prueba.

---

Licencia: uso interno BrainCorp.

Agente multiplataforma de Observer RMM (Windows, Linux, macOS). Binarios adjuntos abajo y publicados también en el CDN agents.observer.cl.

Versión de mantenimiento, sin cambios de comportamiento respecto de la v2.15.1. El agente hace exactamente lo mismo que la versión anterior en las tres plataformas. No hay urgencia en actualizar: quien esté en v2.15.1 no gana nada funcional con esta versión, y quien esté por debajo debería actualizar por lo que trae la v2.15.1, no por ésta.

Cambios en esta versión

• Nada cambia para quien usa el producto. Es deliberado: esta versión se publica para ejercitar la actualización automática de punta a punta sobre un equipo Windows 7 de 32 bits, la única combinación de la flota que nunca había recorrido ese camino con un cambio real de versión. Un binario funcionalmente idéntico al anterior es justamente lo que hace que la prueba sea segura — si algo sale mal, el problema está en el mecanismo de actualización y no en el agente.
• Corregido: una atribución de procedencia en el código apuntaba a un repositorio inexistente. Los tipos de datos que el agente comparte con el servidor llevan escrita, en un comentario, la referencia al proyecto de origen del que se tomaron. Un reemplazo automático de marca durante el rebranding alcanzó por error al nombre de ese repositorio ajeno, dejando una cita que no llevaba a ninguna parte. El nombre de un repositorio de terceros es una atribución, no una marca propia: renombrarlo no limpiaba nada y fabricaba una referencia falsa. No afecta al binario ni a su comportamiento.

Plataformas

darwin-amd64 · darwin-arm64 · linux-386 · linux-amd64 · linux-arm · linux-arm64 · windows-386 · windows-amd64

Instalación

El agente se instala desde la consola de Observer RMM (Agentes → Agregar), que genera el instalador con el token de enrolamiento del cliente/sitio. Los binarios de esta página son los que sirve el backend / CDN.

Los equipos que ya tienen el agente instalado toman esta versión solos por la actualización automática, sin reinstalar nada. La arquitectura se conserva: un equipo con el agente de 32 bits recibe el instalador de 32 bits.

---

Licencia: uso interno BrainCorp.

Agente multiplataforma de Observer RMM (Windows, Linux, macOS). Binarios adjuntos abajo y publicados también en el CDN agents.observer.cl.

Ésta es una corrección sobre la v2.15.0, y toca sólo a los equipos con Windows. Conviene actualizar la flota Windows: hasta esta versión, todo texto con acentos que un script imprimiera en un equipo Windows llegaba a la consola mutilado, y nada avisaba de que eso estaba pasando. En Linux y macOS no cambia nada.

Cambios en esta versión

• Corregido: los acentos desaparecían de la salida de los scripts en Windows. Un script que imprimía «Unión a dominio», «Interpretación» o «caché» llegaba a la consola como «Unin a dominio», «Interpretacin» y «cach»: las letras acentuadas, la eñe y la diéresis simplemente no estaban. No era texto mal codificado que se ve raro —eso salta a la vista—, sino letras faltantes en medio de palabras por lo demás correctas, que es mucho más fácil de leer por encima sin notarlo. El agente ahora interpreta la salida del equipo con la codificación que ese equipo realmente usa, en vez de descartar lo que no entiende.
• Alcanza a los scripts propios, no sólo a los del producto. Los scripts que vienen con Observer RMM traían desde antes un remedio escrito adentro de cada uno; los que escribe cada operador en la consola, no. Cualquier script con acentos que hayas escrito venía perdiéndolos en silencio en los equipos Windows. Con esta versión llegan completos, sin tener que agregarle nada al script.
• Corregido: un script escrito en la consola podía romperse por dentro antes de ejecutarse. En Windows, un script con acentos dentro del propio código —un mensaje entre comillas, un nombre de carpeta con eñe— podía llegar al equipo ya alterado, porque Windows lo leía suponiendo una codificación distinta de la que la consola había usado para guardarlo. El resultado era un script que fallaba o se comportaba raro sin motivo aparente. El agente ahora le indica al equipo, de forma explícita, cómo leer el archivo.
• La salida en Linux y macOS queda exactamente igual que antes. El agente respeta sin tocar el texto que ya viene bien formado, así que este cambio no puede alterar lo que hoy funciona: sólo interviene cuando encuentra texto que la versión anterior habría descartado.

Plataformas

darwin-amd64 · darwin-arm64 · linux-386 · linux-amd64 · linux-arm · linux-arm64 · windows-386 · windows-amd64

Instalación

El agente se instala desde la consola de Observer RMM (Agentes → Agregar), que genera el instalador con el token de enrolamiento del cliente/sitio. Los binarios de esta página son los que sirve el backend / CDN.

Los equipos que ya tienen el agente instalado toman esta versión solos por la actualización automática, sin reinstalar nada.

---

Licencia: uso interno BrainCorp.

Agente multiplataforma de Observer RMM (Windows, Linux, macOS). Binarios adjuntos abajo y publicados también en el CDN agents.observer.cl.

Ésta es la versión definitiva de la serie 2.15: reemplaza a la candidata v2.15.0-rc1, que salió marcada como prerelease para poder producir y probar el instalador nuevo de Windows. Todo lo que traía la candidata está acá, más el aviso de desinstalación que se describe abajo.

Cambios en esta versión

• Desinstalar el agente en el equipo ya no lo deja fantasma en la consola. Hasta ahora, correr el desinstalador en la máquina —el uninstall en Linux y macOS, o «Desinstalar un programa» en Windows— sólo limpiaba el equipo: la consola no se enteraba de nada y el equipo se quedaba ahí para siempre, en Offline, como un agente que ya no existe. Ahora el equipo avisa al servidor antes de destruirse, y el servidor levanta una alerta, la manda por correo y borra el registro del agente y su nodo de control remoto, igual que si lo hubieran borrado desde la web.
• La alerta dice quién, dónde y cuándo. Llega al correo y a la campanita de la consola con el nombre del equipo, el cliente y el sitio, la IP de la red local, la hora, y quién ejecutó la desinstalación: en Linux y macOS, la persona detrás del sudo (no «root»); en Windows, la cuenta que ejecutó el desinstalador y, si es distinta, la que está usando el equipo en ese momento. La alerta sobrevive al borrado del equipo, que es justamente el momento en que hace falta.
• El borrado espera diez minutos antes de concretarse, y se cancela solo si el equipo vuelve a reportar. Reinstalar el agente sobre un equipo existente ejecuta el mismo desinstalador, así que sin esa espera una reinstalación se habría llevado el registro por delante. El aviso y la alerta salen al instante; lo que espera es el borrado.
• Corregido: al desinstalar podía quedar vivo el equipo en el control remoto. El desinstalador invocaba al agente de control remoto de una forma que, en ciertos binarios, dispara un instalador escondido en vez de la desinstalación — puede abrir un cuadro de diálogo en el escritorio de la persona y quedarse esperando un clic que nadie va a dar. Estaba corregido en el flujo de Linux y ahora se cierra también en macOS, en Windows y en la auto-reparación del control remoto, que era el caso más expuesto porque ahí el binario siempre es el que trae el instalador adentro.
• Windows: un solo instalador por arquitectura, y es él el que decide qué agente dejar en el equipo. El instalador lleva los dos agentes adentro y copia el que corresponde a la versión de Windows: el moderno en Windows 10/11 y Server 2016 o superior, el de compatibilidad en Windows 7/8/8.1 y Server 2008 R2/2012 R2. En disco queda siempre observeragent.exe, así que la consola no cambia y las actualizaciones automáticas siguen decidiendo solas en cada equipo. No hay que elegir nada ni saber qué Windows tiene el equipo antes de instalar.
• Los equipos con Windows 10/11 y Server 2016+ pasan a un agente compilado con Go 1.26.5. El agente venía compilándose con una versión del compilador de 2023 y eso arrastraba vulnerabilidades conocidas de la biblioteca estándar, que llegan por el compilador y no por el código del agente. En este binario quedan cerradas.
• Windows 7, 8, 8.1, Server 2008 R2 y Server 2012 R2 siguen soportados, con el agente de compatibilidad (Go 1.20.14, el último que arranca en esos sistemas). ⚠️ Ese binario no recibe los parches de seguridad del compilador: existe por compatibilidad, no por seguridad. Si un equipo puede pasar a Windows 10 o superior, conviene que pase.
• Linux y macOS también van con el compilador moderno, así que cierran las mismas vulnerabilidades de biblioteca estándar. En Linux, además, se sacó del camino una dependencia de manejo de texto que ya no hacía falta.
• El agente informa qué tipo de sesión gráfica tiene el equipo Linux, que es lo que permite anticipar cuándo «Tomar control» va a mostrar pantalla negra en vez de fallar sin explicación.
• Corregido: la IP pública quedaba en blanco donde el tráfico HTTPS está interceptado. Ahora, si la consulta por HTTPS no llega, el agente resuelve la IP pública por DNS.
• El instalador de Windows pesa cerca de 9 MB en vez de 4,8 MB, porque viaja con los dos agentes. Lo que queda instalado en el equipo pesa lo mismo que antes: se copia uno solo.

Plataformas

darwin-amd64 · darwin-arm64 · linux-386 · linux-amd64 · linux-arm · linux-arm64 · windows-386 · windows-amd64

Instalación

El agente se instala desde la consola de Observer RMM (Agentes → Agregar), que genera el instalador con el token de enrolamiento del cliente/sitio. Los binarios de esta página son los que sirve el backend / CDN.

El aviso de desinstalación necesita un servidor con la versión de backend que lo acompaña. Con un servidor anterior el agente funciona igual; simplemente el aviso no tiene a quién avisarle y la desinstalación se comporta como antes.

---

Licencia: uso interno BrainCorp.

Agente multiplataforma de Observer RMM (Windows, Linux, macOS). Binarios adjuntos abajo y publicados también en el CDN agents.observer.cl.

⚠️ Versión candidata (-rc1): no es para la flota. Sale marcada como prerelease y el backend sigue entregando la versión que tiene configurada, así que ningún equipo la toma solo. Existe para producir el instalador nuevo de Windows y poder probarlo en máquinas de verdad — un Windows 10/11 y un Windows 7 —, porque el instalador sólo se puede compilar en un release. Cuando esas pruebas pasen, sale la v2.15.0 definitiva.

Cambios en esta versión

• Windows: un solo instalador por arquitectura, y ahora es él el que decide qué agente dejar en el equipo. El instalador lleva los dos agentes adentro y en la instalación copia el que corresponde a la versión de Windows del equipo: el moderno en Windows 10/11 y Server 2016 o superior, el de compatibilidad en Windows 7/8/8.1 y Server 2008 R2/2012 R2. En disco queda siempre observeragent.exe, así que la consola no cambia, la descarga sigue siendo 32 o 64 bits, y las actualizaciones automáticas vuelven a decidir solas en cada equipo. No hay que elegir nada ni saber qué Windows tiene el equipo antes de instalar.
• Los equipos con Windows 10/11 y Server 2016+ pasan a un agente compilado con Go 1.26.5. El agente venía compilándose con una versión del compilador de 2023 (Go 1.20.13) y eso arrastraba 39 vulnerabilidades conocidas de la biblioteca estándar que llegan por el compilador, no por el código del agente. En este binario quedan cerradas.
• Windows 7, 8, 8.1, Server 2008 R2 y Server 2012 R2 siguen soportados, con el agente de compatibilidad (Go 1.20.14, el último que arranca en esos sistemas). ⚠️ Ese binario no recibe los parches de seguridad del compilador: existe por compatibilidad, no por seguridad. Si un equipo puede pasar a Windows 10 o superior, conviene que pase.
• Linux pasa al mismo compilador moderno. Los binarios de Linux se compilaban con la versión vieja sin necesidad — no hay flota Linux antigua que lo exija —, así que también cierran las 39. macOS ya iba con el compilador moderno.
• El instalador de Windows pesa cerca de 9 MB en vez de 4,8 MB, porque viaja con los dos agentes. Lo que queda instalado en el equipo pesa lo mismo que antes: se copia uno solo.
• El comportamiento del agente no cambia en nada. No se tocó una sola línea de lógica: los cambios son el empaquetado, el compilador y rutas internas del proyecto. Un equipo que hoy funciona bien se comporta igual.

Plataformas

darwin-amd64 · darwin-arm64 · linux-386 · linux-amd64 · linux-arm · linux-arm64 · windows-386 · windows-amd64

Instalación

El agente se instala desde la consola de Observer RMM (Agentes → Agregar), que genera el instalador con el token de enrolamiento del cliente/sitio. Los binarios de esta página son los que sirve el backend / CDN. Al ser una versión candidata, la consola no la entrega: para probarla hay que tomar el instalador de esta página y correrlo a mano en el equipo de prueba.

---

Licencia: uso interno BrainCorp.

Agente multiplataforma de Observer RMM (Windows, Linux, macOS). Binarios adjuntos abajo y publicados también en el CDN agents.observer.cl.

Corrección sobre v2.14.7 con un solo cambio, esta vez en Windows. La v2.14.7 cerró en Linux y macOS un problema que dejaba equipos sin «Tomar control» sin avisar, y decía —con razón— que Windows no estaba afectado. Sigue sin estarlo: se revisó equipo por equipo. Lo que hace esta versión es cerrar la misma puerta en Windows antes de que alguien la empuje, y de paso corregir un fallo que estaba oculto y sí era real. Actualización recomendada para la flota Windows; no hay urgencia porque no corrige ningún síntoma visible hoy.

Cambios en esta versión

• Windows: el agente pide su identificador de escritorio remoto de la forma segura. El componente que MeshCentral entrega para instalar puede traer un instalador anexado que se dispara ante cualquier pregunta y responde con el texto de una reinstalación en lugar del identificador — eso fue exactamente lo que rompió equipos Linux y macOS antes de la v2.14.7. En Windows la pregunta se hacía sin la protección que ya usaban los otros sistemas. Ahora la usa. Se midió en los tres equipos Windows de la flota antes de cambiar nada: con y sin la protección el identificador es idéntico, así que el cambio no altera en nada los equipos donde hoy funciona.
• Corregido: un fallo que quedaba oculto y podía borrar el identificador en la consola. Cuando la consulta del identificador fallaba, el agente no registraba el fallo: seguía adelante y le enviaba al servidor un identificador vacío. Hoy eso no llega a romper nada porque el servidor descarta los valores vacíos, pero el agente estaba confiando en esa red de contención en vez de detenerse. Ahora se detiene y reintenta en el ciclo siguiente.
• El agente descarta cualquier respuesta que no tenga forma de identificador, igual que Linux y macOS desde la v2.14.7. No basta con que la respuesta parezca hexadecimal: el valor que rompió el primer equipo lo era —una dirección MAC son doce dígitos hexadecimales perfectamente válidos—, así que se exige además el largo correcto. Si no consigue un identificador legítimo, se queda sin él en vez de inventarlo: uno ausente se completa en la siguiente revisión, uno falso se ve correcto y no funciona.
• Nada que hacer en los equipos. No hace falta reinstalar ni tocar la consola; los equipos con auto-actualización toman esta versión solos.

Plataformas

darwin-amd64 · darwin-arm64 · linux-386 · linux-amd64 · linux-arm · linux-arm64 · windows-386 · windows-amd64

Instalación

El agente se instala desde la consola de Observer RMM (Agentes → Agregar), que genera el instalador con el token de enrolamiento del cliente/sitio. Los binarios de esta página son los que sirve el backend / CDN.

---

Agente multiplataforma de Observer RMM (Windows, Linux, macOS). Binarios adjuntos abajo y publicados también en el CDN agents.observer.cl.

Corrección sobre v2.14.6 con un solo cambio, salido de una instalación real que falló en terreno: al instalar el agente en Linux o macOS, el equipo podía quedar sin «Tomar control» y sin que nada lo avisara. Actualización recomendada para toda la flota, y conviene aplicarla antes de instalar equipos nuevos de esos sistemas.

Cambios en esta versión

• Corregido (Linux y macOS): un equipo recién instalado podía quedar sin «Tomar control», mientras se veía online y normal. Durante la instalación, el agente le pregunta su identificador al componente de escritorio remoto. Ese componente, tal como lo entrega el servidor, trae un instalador incrustado que se dispara ante cualquier pregunta: en vez de responder el identificador, se reinstalaba a sí mismo y devolvía el texto de esa instalación. El instalador guardaba ese texto como si fuera el identificador. El resultado era un equipo online, respondiendo comandos y reportando inventario con normalidad, pero con «Tomar control» inutilizable y ningún mensaje que lo dijera. En un equipo real quedó registrada una dirección MAC en lugar del identificador.
• Corregido: el instalador de Linux terminaba mostrando errores y dejaba archivos sueltos. Después de decir Installation was successful! aparecían varios command not found y un syntax error, y en la carpeta desde donde se corrió quedaban archivos vacíos con nombres como Checking, Stopping o Uninstalling. Era el mismo problema visto por fuera: el texto de la instalación se ejecutaba como si fueran órdenes.
• Nuevo: el agente descarta cualquier respuesta que no tenga forma de identificador. Es una segunda línea de defensa, deliberadamente estricta: no basta con que la respuesta parezca hexadecimal, porque el valor que rompió el equipo real lo era (una MAC son doce dígitos hexadecimales perfectamente válidos). Si el agente no consigue un identificador legítimo, sigue sin él en vez de guardar un valor inventado — un identificador ausente se puede completar después, uno falso se ve correcto y no funciona.
• Los equipos ya afectados se reparan solos al actualizar. El agente revisa su identificador de forma periódica; con esta versión, la primera revisión posterior a la actualización lo corrige en la consola sin intervención. No hace falta reinstalar.
• Windows no estaba afectado. Su componente de escritorio remoto responde el identificador directamente, y se verificó equipo por equipo que toda la flota tiene el identificador correcto.

Plataformas

darwin-amd64 · darwin-arm64 · linux-386 · linux-amd64 · linux-arm · linux-arm64 · windows-386 · windows-amd64

Instalación

El agente se instala desde la consola de Observer RMM (Agentes → Agregar), que genera el instalador con el token de enrolamiento del cliente/sitio. Los binarios de esta página son los que sirve el backend / CDN.

---

Agente multiplataforma de Observer RMM (Windows, Linux, macOS). Binarios adjuntos abajo y publicados también en el CDN agents.observer.cl.

Corrección sobre v2.14.5 con dos cambios, los dos salidos de probar la versión anterior en equipos reales: el texto de los mensajes en pantalla en Linux, que llegaba alterado en escritorios KDE/LXQt, y la alarma, que ahora suena por los parlantes del equipo y no por los audífonos que tenga puestos la persona. Actualización recomendada para toda la flota.

Cambios en esta versión

• Corregido (Linux): el mensaje en pantalla llegaba alterado en escritorios KDE y LXQt. Un mensaje que nombrara una ruta de Windows (C:\temp\nueva) aparecía partido en dos líneas y con parte del texto perdido, y uno que usara < , > o & mostraba códigos crudos en pantalla (<urgente> en lugar de <urgente>). El operador escribía una cosa y la persona leía otra. Ahora el texto llega tal cual se escribió, incluidas las rutas, los símbolos y los mensajes de varias líneas. Los escritorios GNOME no estaban afectados por esto.
• Nuevo: la alarma suena por los parlantes del equipo, aunque haya audífonos conectados. Antes la alarma salía por donde estuviera saliendo el audio: si la persona tenía audífonos o parlantes Bluetooth conectados, el sonido iba a sus oídos en vez de a la sala. Para una función que existe para encontrar un equipo eso no servía, y con la opción de volumen máximo además era desagradable para quien los llevara puestos. Ahora el agente cambia la salida a los parlantes internos antes de sonar y la devuelve a donde estaba al detener la alarma, incluso si el equipo se reinició mientras sonaba. Se ignoran las salidas que en realidad son otro aparato: HDMI, DisplayPort, digital óptica, USB y Bluetooth.
• Disponible en macOS y Linux. En Windows no está disponible: cambiar la salida de audio por omisión exige una interfaz del sistema que Microsoft no documenta y que no se pudo verificar en ningún equipo, así que se prefirió no incluirla antes que incluirla sin probar. En Windows la alarma sigue sonando por la salida que tenga el equipo, exactamente como hasta ahora.
• Si la salida no se puede cambiar, la alarma suena igual. Un equipo que se está buscando tiene que sonar aunque el sistema de audio no coopere; el intento fallido queda registrado.

Plataformas

darwin-amd64 · darwin-arm64 · linux-386 · linux-amd64 · linux-arm · linux-arm64 · windows-386 · windows-amd64

Instalación

El agente se instala desde la consola de Observer RMM (Agentes → Agregar), que genera el instalador con el token de enrolamiento del cliente/sitio. Los binarios de esta página son los que sirve el backend / CDN.

---

Agente multiplataforma de Observer RMM (Windows, Linux, macOS). Binarios adjuntos abajo y publicados también en el CDN agents.observer.cl.

Versión con funciones nuevas para la alarma antirrobo —sonido máximo y alarma sin límite de tiempo— y cuatro correcciones de la misma familia: casos donde la consola informaba éxito y en el equipo no pasaba lo que decía. Actualización recomendada para toda la flota si usa la alarma o los mensajes en pantalla.

Cambios en esta versión

• Nuevo: la alarma puede sonar al volumen máximo del equipo. Al lanzar la alarma se puede pedir que el equipo suba el volumen al 100 % y se desilencie, que es lo que hace falta cuando el equipo está perdido y hay que encontrarlo de oído. El volumen previo se guarda y se devuelve al detener la alarma, incluso si el equipo estaba silenciado de partida. Disponible tanto en la acción sobre un equipo como en la acción masiva.
• Nuevo: la alarma puede sonar sin límite de tiempo. Hasta ahora el máximo eran 300 segundos. La alarma "eterna" suena hasta que alguien la detenga desde la consola, y sobrevive al reinicio del equipo: un equipo robado que se apaga y se vuelve a encender sigue sonando. El único interruptor es "detener alarma" desde la consola, así que exige que el equipo pueda conectarse.
• Nuevo: la alarma suena como una alarma. Antes terminaba usando sonidos de notificación del sistema —un "ding" corto— que sirven para avisar pero no para encontrar un equipo. Ahora el agente genera su propia sirena de dos tonos y la usa en las tres plataformas.
• Corregido (Windows): un equipo podía quedarse al volumen máximo de forma permanente. En cualquier equipo que no estuviera silenciado —o sea la mayoría—, el agente subía el volumen al 100 % pero interpretaba mal la respuesta del sistema y daba la operación por fallida. Como creía que había fallado, no guardaba el volumen anterior, y al detener la alarma no lo devolvía: el equipo quedaba al máximo para siempre. Ahora el volumen vuelve siempre a donde estaba.
• Corregido (todas las plataformas): si alguien mataba el sonido, la alarma quedaba muda pero "encendida". Bastaba cerrar un proceso desde el administrador de tareas para que el equipo quedara en silencio con el volumen clavado al máximo, mientras la consola seguía mostrando la alarma activa — y, en la modalidad eterna, volvía a "sonar" muda después del reinicio. Ahora el agente vigila su propio reproductor y lo vuelve a levantar si se cae.
• Corregido (Linux): los mensajes en pantalla podían llegar cambiados o vacíos. Un mensaje que nombrara una ruta de Windows (C:\temp\...) perdía parte del texto, y uno que usara < , > o & —por ejemplo "Ventas & Cobranzas"— podía mostrar el diálogo completamente vacío. El texto que escribe el operador ahora llega tal cual a la pantalla.
• Corregido (Windows): "bloquear" y "alarma" fallaban en equipos con alguien conectado por escritorio remoto. Si la pantalla física estaba en el inicio de sesión y la persona trabajaba por RDP, el mensaje en pantalla sí llegaba pero bloquear y hacer sonar la alarma respondían "no hay sesión de usuario" con una persona dentro del equipo. Ahora las tres acciones eligen la misma sesión.

Plataformas

darwin-amd64 · darwin-arm64 · linux-386 · linux-amd64 · linux-arm · linux-arm64 · windows-386 · windows-amd64

Instalación

El agente se instala desde la consola de Observer RMM (Agentes → Agregar), que genera el instalador con el token de enrolamiento del cliente/sitio. Los binarios de esta página son los que sirve el backend / CDN.

---

Agente multiplataforma de Observer RMM (Windows, Linux, macOS). Binarios adjuntos abajo y publicados también en el CDN agents.observer.cl.

Corrección sobre v2.14.3, con dos arreglos independientes: uno de la alarma antirrobo que afecta sólo a macOS, y uno de la geolocalización que afecta a las tres plataformas. Actualización recomendada para toda la flota por el segundo: hasta esta versión, apagar la geolocalización desde la consola no surtía efecto hasta que el agente se reiniciara.

Cambios en esta versión

• Corregido (macOS): la alarma no se podía detener y sonaba para siempre. Al apretar "detener", la consola informaba la acción como exitosa, el agente registraba la alarma como detenida antes de tiempo, y el sonido seguía sin parar hasta que alguien apagaba el equipo o lo intervenía a mano. En una función antirrobo que se dispara sobre el equipo de una persona, eso convertía una prueba en un problema. Ahora el sonido se corta al recibir la orden y no vuelve a nacer.
• Corregido (macOS): la alarma se pasaba de la duración pedida. Una alarma de 10 segundos sonaba cerca de 12, porque el sonido que estaba a medio reproducir terminaba igual. Ahora se corta también ése, así que la duración se respeta.
• Windows y Linux nunca estuvieron afectados por lo anterior, y esta vez está medido, no supuesto. Se probó la detención en un Windows 11 y en un Ubuntu 24.04 reales, por la cadena completa de la consola: en los dos la alarma se detiene de inmediato y sin dejar residuos. Si su flota no tiene Mac, estos dos primeros puntos no le cambian nada.
• Corregido (todas las plataformas): un equipo que arrancaba sin red quedaba sin geolocalización hasta el siguiente reinicio. Si el agente partía antes de que hubiera DNS —un portátil recién encendido, o antes de que suba la VPN— la geolocalización quedaba desactivada durante toda la vida del proceso, sin ningún aviso. En la consola se veía igual que si la función no existiera: un equipo que nunca reporta su ubicación, con el seguimiento activado en el servidor todo el tiempo. Medido en un caso real: dos horas y media sin un solo punto.
• Corregido (todas las plataformas): apagar la geolocalización desde la consola ahora surte efecto sin reiniciar el agente. Es el mismo defecto mirado del lado que más importa: el interruptor se leía una sola vez al arrancar, así que desactivar el seguimiento tampoco se aplicaba hasta el siguiente reinicio. Para un interruptor de privacidad, ése era el lado grave. Ahora el agente re-consulta el interruptor en cada captura, en las dos direcciones.
• La configuración de geolocalización se re-lee periódicamente en vez de una sola vez. Como efecto secundario, un cambio de intervalo hecho en la consola se toma solo, y un equipo que arrancó sin red se corrige en minutos en lugar de quedar esperando un reinicio. Cuando una captura se salta, ahora queda registrado el motivo: el silencio sin explicación era la parte que hacía difícil darse cuenta.
• Sin cambios en alert (mensaje en pantalla) ni en el bloqueo remoto (lock) en ninguna plataforma.

Plataformas

darwin-amd64 · darwin-arm64 · linux-386 · linux-amd64 · linux-arm · linux-arm64 · windows-386 · windows-amd64

Instalación

El agente se instala desde la consola de Observer RMM (Agentes → Agregar), que genera el instalador con el token de enrolamiento del cliente/sitio. Los binarios de esta página son los que sirve el backend / CDN.

---

Licencia: uso interno BrainCorp.

Agente multiplataforma de Observer RMM (Windows, Linux, macOS). Binarios adjuntos abajo y publicados también en el CDN agents.observer.cl.

Corrección sobre v2.14.2, equivalente en macOS a la que esa versión trajo para Linux. Actualización recomendada con prioridad para la flota Mac: sin este arreglo, el bloqueo remoto podía reportarse como exitoso dejando la pantalla desbloqueada.

Cambios en esta versión

• Corregido (macOS): el bloqueo remoto podía informar éxito sin haber bloqueado la pantalla. En las versiones actuales de macOS, el método de bloqueo que Apple ofrecía históricamente ya no está disponible, así que el agente recurre a dormir la pantalla. Eso bloquea el equipo sólo si está configurado para pedir la contraseña al despertar; si esa opción está desactivada o con retardo, la pantalla quedaba accesible y la consola igual mostraba la acción como exitosa. En una función pensada para responder a un robo, ese falso positivo es el peor error posible.
• Ahora el bloqueo sólo se informa como exitoso cuando el propio sistema confirma que la pantalla quedó bloqueada. Si no lo confirma, el agente devuelve el error correspondiente y el operador sabe que el equipo no quedó protegido, en vez de recibir un visto bueno falso.
• La confirmación se consulta durante unos segundos, porque el bloqueo no es instantáneo (medido: menos de medio segundo en un equipo real). El plazo total de la acción se ajustó para que un fallo se informe como "no se pudo bloquear" y nunca como un problema de conectividad con el equipo.
• Sin cambios en alert (mensaje en pantalla) ni en alarm (alarma sonora), ni en Windows ni en Linux.

Plataformas

darwin-amd64 · darwin-arm64 · linux-386 · linux-amd64 · linux-arm · linux-arm64 · windows-386 · windows-amd64

Instalación

El agente se instala desde la consola de Observer RMM (Agentes → Agregar), que genera el instalador con el token de enrolamiento del cliente/sitio. Los binarios de esta página son los que sirve el backend / CDN.

---

Licencia: uso interno BrainCorp.

Agente multiplataforma de Observer RMM (Windows, Linux, macOS). Binarios adjuntos abajo y publicados también en el CDN agents.observer.cl.

Corrección sobre v2.14.1. Actualización recomendada con prioridad: sin este arreglo, el bloqueo remoto podía reportarse como exitoso dejando la pantalla desbloqueada.

Cambios en esta versión

• Corregido (Linux): el bloqueo remoto podía informar éxito sin haber bloqueado la pantalla. El agente pedía el bloqueo al gestor de sesión del sistema y daba la orden por cumplida al entregarla; pero en escritorios cuyo bloqueador no atiende esa vía —por ejemplo LXQt con xscreensaver— no pasaba nada y la consola igual mostraba la acción como exitosa. En una función pensada para responder a un robo, ese falso positivo es el peor error posible.
• Ahora el bloqueo por esa vía sólo se informa como exitoso cuando el sistema confirma que la sesión quedó bloqueada; si no lo confirma, el agente sigue probando los bloqueadores del escritorio en vez de detenerse.
• Se amplió la lista de bloqueadores soportados (xscreensaver, light-locker, xflock4, además de los que ya estaban), de modo que la acción funcione en más escritorios sin configuración previa.

Plataformas

darwin-amd64 · darwin-arm64 · linux-386 · linux-amd64 · linux-arm · linux-arm64 · windows-386 · windows-amd64

Instalación

El agente se instala desde la consola de Observer RMM (Agentes → Agregar), que genera el instalador con el token de enrolamiento del cliente/sitio. Los binarios de esta página son los que sirve el backend / CDN.

---

Licencia: uso interno BrainCorp.

Agente multiplataforma de Observer RMM (Windows, Linux, macOS). Binarios adjuntos abajo y publicados también en el CDN agents.observer.cl.

Corrección sobre v2.14.0. Se recomienda actualizar: sin este arreglo, un mensaje en pantalla podía reportarse como entregado sin que nadie lo hubiera visto.

Cambios en esta versión

• Corregido (Linux): un equipo detenido en la pantalla de login se trataba como si tuviera un usuario adentro. El mensaje en pantalla se dibujaba sobre la propia pantalla de login —donde no hay nadie— y la consola informaba la acción como exitosa. Ahora el agente distingue la sesión del gestor de inicio de sesión de la de una persona, y responde "nadie tiene una sesión abierta", que es lo que realmente pasa.
• Por la misma razón se dejaron de considerar las cuentas de servicio al buscar el escritorio del usuario, respetando el umbral de cuentas de usuario que declara el propio sistema (para que también valga en distribuciones antiguas).

Plataformas

darwin-amd64 · darwin-arm64 · linux-386 · linux-amd64 · linux-arm · linux-arm64 · windows-386 · windows-amd64

Instalación

El agente se instala desde la consola de Observer RMM (Agentes → Agregar), que genera el instalador con el token de enrolamiento del cliente/sitio. Los binarios de esta página son los que sirve el backend / CDN.

---

Licencia: uso interno BrainCorp.

Agente multiplataforma de Observer RMM (Windows, Linux, macOS). Binarios adjuntos abajo y publicados también en el CDN agents.observer.cl.

Cambios en esta versión

• Respuesta rápida en el equipo: tres acciones nuevas que el operador dispara desde la consola, sobre un equipo o de forma masiva.
• Bloqueo remoto de pantalla: bloqueo nativo del sistema operativo (el equivalente a Win+L), no un candado propio. Sirve como respuesta inmediata ante pérdida o robo.
• Mensaje en pantalla: muestra un aviso al usuario del equipo. Útil para anunciar una mantención o pedir que guarde su trabajo.
• Alarma sonora: suena en bucle con los sonidos propios del sistema, con un tope de 5 minutos, y se puede cortar en cualquier momento.
• Las tres acciones se ejecutan en la sesión del usuario aunque el agente corra como servicio del sistema, que es lo que permite que el mensaje se vea y la alarma se oiga.
• Cada acción tiene su propio permiso por rol y queda registrada en el log de auditoría, tanto si se ejecuta como si falla.
• Cuando una acción no se puede completar, el agente informa por qué: nadie con sesión abierta, sin herramienta de diálogo, sin reproductor de audio, o sin método de bloqueo disponible. La consola traduce esos motivos al idioma del operador.

Plataformas

darwin-amd64 · darwin-arm64 · linux-386 · linux-amd64 · linux-arm · linux-arm64 · windows-386 · windows-amd64

Instalación

El agente se instala desde la consola de Observer RMM (Agentes → Agregar), que genera el instalador con el token de enrolamiento del cliente/sitio. Los binarios de esta página son los que sirve el backend / CDN.

---

Licencia: uso interno BrainCorp.

Agente multiplataforma de Observer RMM (Windows, Linux, macOS). Binarios adjuntos abajo y publicados también en el CDN agents.observer.cl.

Cambios en esta versión

• Auto-reparación del control remoto: si el agente Mesh se detecta ausente o roto, se reinstala automáticamente, restaurando "Tomar control" sin intervención manual.
• Jitter en la ejecución de tareas y mayor robustez en la sincronización con Mesh, para suavizar picos de carga en flotas grandes.
• Limpieza del Python gestionado al cambiar de versión, evitando residuos entre actualizaciones.
• RunScript como usuario en Windows usa CREATE_NO_WINDOW: los scripts corren sin abrir una ventana de consola visible al usuario final.
• Publicación al CDN agents.observer.cl en cada release (HTTP/1.1 + reintentos, para subidas confiables de binarios grandes).

Plataformas

darwin-amd64 · darwin-arm64 · linux-386 · linux-amd64 · linux-arm · linux-arm64 · windows-386 · windows-amd64

Instalación

El agente se instala desde la consola de Observer RMM (Agentes → Agregar), que genera el instalador con el token de enrolamiento del cliente/sitio. Los binarios de esta página son los que sirve el backend / CDN.

---

Licencia: uso interno BrainCorp.

Mirror del release v2.10.5 del repo canónico observer-agent (binarios byte-idénticos). Fuente de distribución a la que apunta observer-rmm (get_agent_url).