lunes, 30 de agosto de 2021

Agregar el servicio COM+ en Windows Server 2016

Lo primero de todo: ¿qué es COM+?

COM+ (Component Object Model: modelo de objeto componente) es una tecnología de Microsoft cuya finalidad es posibilitar la interconexión de procesos entre si y ofrecer un entorno de desarrollo de objetos (aplicaciones). COM+ no es más que una extensión de COM y este servicio es el que se encarga de gestionar los procesos y aplicaciones basados en esta tecnología. Aunque el servicio sigue presente tanto en Windows Vista como en posteriores, parte de las funciones de COM están siendo sustituidas por Microsoft .NET y por Windows Communication Fundation. Viene bien explicado en este LINK.

Entonces, ¿para qué lo queremos instalado en el servidor? Por lo de siempre en el entorno Microsoft, no hay obsolescencia, las aplicaciones duran décadas. Aunque las aplicaciones ya no hagan uso de esta extensión, al estar incluidas en otros elementos como .NET, las aplicaciones antiguas siguen requiriéndolo. Y hasta Windows Server 2012 es fácil instalarla, solo tenemos que seguir los siguientes pasos:

Desde instalación de Roles y Características, agregamos el rol de Servidor de aplicaciones,

Y posteriormente en los servicios del rol, Acceso a red COM+

Como decía, hasta W2K12 R2, es facil. El problema viene a partir de Windows Server 2016. El servicio ya está obsoleto, y Microsoft no lo incorpora en sus nuevas versiones de Windows. Entonces, ¿Cómo instalarlo?

Podemos instalarlo en dos pasos:

1º Habilitamos el "acceso a red COM+" en el firewall de Windows. Para ello, le damos acceso en la ventana de "apps permitidas" en el firewall:

2º Modificamos el registro. Para ello, vamos a la siguiente subclave: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\COM3. Allí, hacemos doble click en la clave RemoteAccessEnabled y cambiamos su valor a 1.

Con esto, ya tenemos el servicio funcionando en las nuevas versiones de Windows.

Si te ha gustado el articulo, puedes invitarme a un café  ;)

domingo, 29 de agosto de 2021

Repite conmigo: los snapshots no son backups

Estamos en 2021, hace 11 años apareció ESXi 4.0. Entonces ya hacia snapshots, y por aquella época, se consideraban una forma de backup. Esto cambio en torno a 2014, con ESXi 5.0. Entonces los snapshots eran un medio de tomar una foto al equipo en un momento dado, para revertir pequeños cambios, pero de ninguna manera podían considerarse ya como copias de seguridad.
¿Y por qué este mini salto en el tiempo en referencia a los snapshots de VMware? 



En una charla sobre limpieza de snapshots todavía a estas alturas me indicaban que un snapshot es un backup. Que es lo que hacen las compañías de backup, un snapshot, que copian a su sistema. Y si, eso es lo que hacen, pero...¿y si se corrompe el vmdk original? Solo por poner solo un ejemplo. La respuesta es que el archivo delta del snapshot no te sirve de nada. Se pierde la VM.
Pero la mejor forma de demostrar estas afirmaciones es con hechos y documentación, y a ello vamos:

VMware

Para ello os dejo el siguiente LINK, de las best practices de VMware. Primer punto de las best practices: Do not use VMware snapshots as backups. Se puede decir mas alto, no mas claro. Ya de paso, es bueno seguir el resto de recomendaciones. Si bien originalmente los snapshots se vieron como backups, al ser algo revolucionario en sus origenes, con el tiempo, se consideran solo como solución de seguridad para una marcha atrás rápida. Por ejemplo, un parcheo fallido.

Veeam

En el siguiente articulo de Veeam explican muy bien las razones por las cuales un snapshot no es un backup. Aquí el LINK, y a continuación un breve spoiler: no es un backup principalmente por la razón indicada al comienzo: Sin una copia de todos los archivos originales que componen la VM, una corrupción o perdida de uno de estos hacen que el snapshot sea inútil. La propia Veeam reconoce que hacen uso del sistema de snapshots para sus copias, pero que se trata la copia completa de la VM como una Full, y posibilidad total de restores, mientras que los snapshots se consideran copias incrementales. Adicionalmente, dejan muy claro que cada snapshot es un SPOF en si mismo. Y por supuesto, la frase: It is important to note that the snapshot by itself is not a backup

Veritas

Esta compañía tiene solera en el tema del software de backup. Cuando empresas como Vembu, Veeam o Nakivo ni siquiera existian, ellos ya eran los "Windows" del sector de backups. Al grano, LINK, y paseo al punto 6 de los backups en vSphere. De nuevo, Snapshots are not backups. Luego agregan que, y traduzco, "las instantáneas de máquinas virtuales, si bien son útiles, nunca deben usarse como su medio principal de respaldo. Las instantáneas están bien para copias de seguridad a corto plazo de máquinas virtuales, pero tenga en cuenta que incurrirá en sanciones cada vez que las utilice". Con sanciones entra en una serie de problemas que indica vmware en sus best practices relacionadas con el rendimiento.

Vembu

Ya que les he mencionado, les agrego. LINK. Aunque no dicen explícitamente que los snapshots no son backups, sí dicen que no son una solución completa, sino que son un complemento, y que una copia incemental la consideran un snapshot, no un backup. De hecho, hay una parte de su documento muy correcta: While performing a backup you want your backup to be independent of your Virtual Machine that you are safeguarding.

Como se puede ver, todas las soluciones toman el snapshot como una especie de copia incremental que debe desaparecer en el tiempo, y ninguna lo toma como una solución válida ni segura. Y todas inciden en la copia completa de los archivos de la maquina, a otra ubicación no dependiente del sistema que la sostiene. Lo que viene a ser un backup de toda la vida de los archivos, vaya.

Si te ha gustado el articulo, puedes invitarme a un café  ;)

viernes, 27 de agosto de 2021

Mover múltiples usuarios a una OU

 Aquí dejo un script para poder mover un listado de usuarios, ubicados en cualquier OU, a la OU que se indique. Muy cómodo si tienes usuarios desperdigados por todo el directorio activo con alguna característica identificable, como por ejemplo que estén deshabilitados, o creados en una fecha determinada. 

Se puede hacer una búsqueda previa, y generar un listado con ellos. Posteriormente, con este script movemos dichos usuarios. 

Ahí va:

Y con esto tenemos el movimiento hecho, de todos los usuarios dentro del archivo users.txt.

Peculiaridades:

  • En el archivo de texto  debe ir un UserDN por linea (el ID con el que hacen login).
  • El "Write-Host "Moviendo cuenta... ." $userDN" es un "punto de control" que muestra el usuario que va procesando el script, por pantalla. De esta manera, se puede eliminar, pero asi tienes idea por pantalla de por donde va, sobre todo si el listado lo has organizado por orden alfabetico.
  • Igualmente el  "Write-Host "Movimiento de usuarios completado"" es por dejar el script finalizado mostrando algun tipo de aviso en pantalla. Saber que ha finalizado despues de ejecutar el bucle.

Si te ha resultado útil el articulo, puedes invitarme a un café  ;)