Pero por cuestiones laborales tuve en suerte el tener la primera homologación de Windows 10 para un entorno corporativo, y con esta tarea, comenzaron las sorpresas. Como consecuencia de un proyecto de este estilo, me siento comprometido a compartir algunas de las impresiones que me llevaron a pensar en este nuevo sistema operativo de M$ como algo más orientado a un celular o un tablet, y ni en chiste al mundo corporativo, considerando inclusive elementos importantes, como ser la integración de entornos, o la interfaz común entre ellos.
El proceso de homologación comienza como siempre con los pasos necesarios para realizar la instalación, y la validación sobre la compatibilidad de las máquinas existentes en casa de un cliente para albergar el SO, incluyendo detalles sobre disponibilidad, estabilidad y mantenibilidad de drivers, y los programas circundantes.
Aquí la primer sorpresa. No todas, ni tampoco la mayoría, pero sí varias de las máquinas existentes, que soportaban Windows 7, tienen problemas con sus drivers para Windows 10. Y cuando digo problemas me refiero no a que no existan, sino a que luego de implementados requieren de verificaciones varias por haber problemas que llevan a que la máquina se rebootee.
Literalmente un desastre, porque uno prefiere saber que algo no está soportado, a encontrarse con la sorpresa de que se le cae la máquina por un bug que sólo se descubre cuando una falla aparece. Al comunicarnos con el soporte Gold de M$ encontramos que la respuesta es "es cierto, no funciona con tal o cual pieza de hardware, el driver no está aún estable". En particular, hemos juntado varias preguntas para ser volcadas al soporte en cuestión, siempre hablando del Gold.
Una vez analizados esos inconvenientes, y acotada la cantidad total de máquinas que pueden recibir este nuevo SO, nos encontramos con varios problemas de seguridad bastante fuertes, que no sólo que no están resueltos, sino que ni en el soporte oficial ni en algún foro perdido pudieron ser superados.
Por ejemplo, M$ Edge es considerado inseguro, y por ello si alguien genera un usuario local en una máquina, y decide ingresar con él y abrir dicho programa, recibe un mensaje interesante, mencionando que no se puede con esa cuenta. Sí, el usuario no es guest, ni nada de ese estilo.
Al hablar con el soporte (remarco, Gold), nos mencionaron que ese problema está reportado, y que no se va a solucionar porque M$ Edge es considerado inseguro.
Y lo mismo pasa con otros elementos que sorprenden por ser de los usados normalmente por un usuario local, como ser el cambio de hora en el reloj, o los gadgets que aparecen al abrir el menú que sería de "Inicio".
Todo esto ocurre con el equipo recién instalado, y sin incorporarlo a dominio alguno.
Entonces comenzaron las pruebas insertándolo a un dominio prexistente, tanto AD como Samba-NT, ya que se debe homologar para ambos casos.
Para el caso de AD, uno de los primeros problemas encontrados consistió en que un equipo agregado al AD, luego de ingresar con un usuario de dominio, comienza a pedir la clave de dicho usuario y lockear la pantalla, aún cuando el tiempo de lock no se haya alcanzado. Algunas veces la deslockea, y otras veces no, por lo que si hay alguna política de lock de claves por reintentos fallidos (como las hay en la mayor parte de las empresas), el usuario termina lockeando invountariamente su cuenta, aún cuando haya ingresado bien su contraseña. En este caso es necesario acceder al servidor de dominios y deslockear dicha cuenta para que se pueda seguir trabajando. La respuesta de soporte Gold? "Ya está reportado, y no hay una solución inmediata al tema". No es terrible, pero implica que un usuario genere un ticket, y que el sysadmin lo resuelva reactivando la cuenta. Supongamos una hora de trabajo, y una o dos horas sin poder trabajar por parte del usuario final. Y eso si el usuario no está de viaje por alguna región exótica del mundo, donde una llamada signifique una diferencia de ocho horas, por ejemplo.
Otro issue encontrado es que aún cuando el servidor de dominios sea Windows 2012, pueden aparecer problemas al mapear unidades de red compartidas cuando se intentan montar automáticamente por medio de logon scripts. Para resolverlo hay que tocar algunas claves de registry, y sale funcionando. Nuevamente, un par de horas de máquina sin producir, y alguna hora de sysadmin. Eso por cada máquina.
Si todo lo anterior parece sacado de un libro de fantasías, lo mejor viene cuando se quiere ingresar a un viejo dominio Samba-NT (Samba 4 en modo NT, no AD), momento en el cual hay que cargarle varias claves de registry para que no nos reporte que no hay servidor de dominios, otro tanto para que soporte los nuevos roaming profiles, y otros tantos rebooteos y cambios para que realmente funcione de manera medianamente estable.
Calculé el tiempo de implementación en una hora, para el SO básico, media hora por los patches iniciales, media hora para cambiar claves de registry para su ingreso en el dominio, otra media hora para las siguientes modificaciones de registry, y como me levanté con el corazón dulce, dejo en sólo una hora el marcador para todo lo demás. Y ojo, no estoy considerando implementación de Office, y demás herramientas.Eso implica unas tres horas y media por puesto.
Claramente, mi informe final trató de plasmar todo esto, y llegamos a lo siguiente:
- Implementar M$ Win 10 significa, en casos de AD, unas dos horas de implementación, y unas dos a tres horas de soporte mensuales al menos hasta que aparezcan patches para todo lo que nos fuera reportado como "ya lo sabemos, y no hay solución".
- Implementar M$ Win 10 significa, en casos de NT-Domains, unas tres horas y media por puesto.
Entonces, pensándolo para una empresa de unos cien puestos (100 PCs), que no es una gran cantidad, ni nada que se le parezca, caeríamos en un overhead de unas doscientas horas de implementación, y unas trescientas horas de soporte, para que quede algo estable. Para el caso de NT-Domains, tenemos unas trescientos cincuenta horas de implementación.
De lo anterior llegamos a que un proyecto de despliegue de este nuevo SO significaría, entonces, contratar por lo menos tres personas extra en el equipo de IT. Al menos por el tiempo que se esté desplegando el SO.
Luego tenemos otros temas, como ser las configuraciones de actualizaciones automáticas, seguridad, cada paquete de oficina, y demás, de lo que cual no tiene mucho sentido hablar aquí, ya que es lo mismo que venimos haciendo hace años.
Agradezco a M$ los intentos por aumentar la ocupación en nuestro rubro de IT, pero no es ésta la forma...termina en un costo extra para empresarios que no conocen mucho del tema, y deciden adquirir las nuevas licencias casi a la fuerza, y con la promesa de que "si no te gusta, te vestís y te vas"...
Por estos elementos, y por la increible desprolijidad en la entrega de un SO que pareciera haber salido del horno un tiempo antes de estar cocido, creo que está aún bastante lejos del mundo corporativo, y no lo veo evolucionar tampoco demasiado en el mundo móvil. Veremos qué nos depara el destino en este sentido, y recordemos que siempre tendremos a nuestros amigos, los pingüinos, los diablillos, o los soles, que se implementan en pocos minutos, se mantienen estables en el tiempo, no requieren antivirus, y su licencia puede ser GPL. Y en una de esas, hasta logramos que nuestro sysadmin amigo sonría...
[Agregado] Hoy me encontré con la belleza de que ya varios son los sitios que no soportan Windows 10. El que más me preocupó, al menos por ahora, es el de Webex, que al accederlo nos muestra esto:
Por lo tanto, si tu usuario pide Windows 10 y quiere mantener reuniones con Webex, estamos en problemas...
No hay comentarios:
Publicar un comentario