|
Entre todas las migraciones de servicios que podemos realizar en entornos Windows, una de las que normalmente me resultan más fáciles ha sido el DHCP
Aún en redes que muchos scopes, reservations y leases, siempre salió en mi ayuda el nunca bien ponderando netsh
Introduccion
En una red muy pequeña podemos darnos el lujo de no migrar un servicio sino simplemente rehacerlo, pero en redes medianas o complejas esto queda fuera de la tabla de discusión.
Ahora bien, migrar un servicio DHCP cuando se migra entre diferentes servidores pero con igual sistema operativo puede resultar relativamente sencillo, pues se trata solamente del reemplazo de la base de datos del DHCP en el servidor nuevo por la base que se encuentra en el servidor viejo.
Pero... esto rara vez sucede, normalmente se tratará de migrar un DHCP de una versión x del sistema operativo a la versión X+1 o X+2.
Operatoria
Para aquellos que venimos de la época de las cavernas de sistemas, operar con línea de comandos nos resulta ameno y deseable, es por ello que para la migración del servicio DHCP normalmente uso la linea de comandos via NETSH
NETSH, es un comando que puede ser utilizado como interfaz o como comando de ejecución directa, si iniciamos la linea de comandos con privilegios de administradores y ejecutamos NETSH, y luego ponemos ? ENTER para recibir ayuda, veremos una imagen como la siguiente.
Ahora bien, veamos un poco, los pasos del procedimiento primero...
- Exportar la información del DHCP a Migrar
- Poner el DHCP a migrar en start up manual
- Parar el servicio DHCP a migrar
- Importar la información del DHCP migrado al nuevo server
- Autorizar el nuevo DHCP en Active Directory
- Reiniciar el servicio del nuevo DHCP
- Verificar que el servicio del nuevo DHCP esté en startup automático
La mayoría de estos pasos no presentarán inconvenientes, por lo que veremos la Exportación e Importación directas via NETSH
En el server a migrar, iremos a la línea de comandos y ejecutaremos NETSH DHCP SERVER EXPORT C:\TEMP\DHCPINFO.TXT ALL, con esto,
generamos un arhicvo en c:\temp con la información completa del DHCP que vamos a migrar. Dependiendo de la cantidad de scopes, leases, reservations, etc. esto puede demorar algunos segundos o minutos.
Este comando dará como resultado un archivo no legible por un humano pero desablemente legible por un server DHCP. Como contrapartida en el server destino se ejecutará el siguiente comando para realizar la importación de la información b>NETSH DHCP SERVER IMPORT C:\TEMP\DHCPINFO.TXT, hay pocas diferencias entre ambos comandos, al exportar utilizarmos el verbo EXPORT y la opción ALL al final del comando para indicarle que exporte TODA la información del DHCP, en cambio al importar se cambia el verbo por IMPORT y no hace falta indicar si se importa todo porque el comando siempre importará todo lo que ve en el archivo.
Previo a la importación, el server DHCP se mostraría como el siguiente
Observese que no hay scopes y que el server no está autorizado por AD. Ahora bien, al ejecutar el comando, no pueden darse errores, ya que la ejecución es binaria, es decir, o se completa totalmente o falla por completo.
El caso más normal de fallas se dará por un conflicto de opciones, esto es porque el asistente de instalación del DHCP nos guía inicialemnte para poner opciones de dominio y de DNS que puede entrar en conflicto con las importadas dando por ej. la siguiente situación
Si este es el caso, es facilmente solucionable, lo único que deberemos hacer es borrar las opciones 006 y 015 a nivel de "Server Options" en el server destino de importación y volver a ejecutar el comando..
Borradas las opciones, el comando ejecutará correctamente, y luego podremos refrescar la MMC del DHCP con F5 para ver los datos importados.
Si este fuera el caso, todos felices, autorizamos el nuevo DHCP en AD, paramos el viejo, etc. etc. café de por medio y goog job.. peeeerrrooooo.. no simpre el resultado es feliz
TLS supported but not configured
Vimos como problemas de conflicto podían resolverse elimnando configuraciones preexistentes en el server destino de importación, pero, que pasa si surge un error de este tipo "TLS supported but not configured"?
Después de dar unas cuantas vueltas en vano con NETSH, que siempre me había sido fiel, tuve que recurrir al mismo procedimiento pero via PowerShell,
a persar que no me gusta, y como estoy operando un server 2012 (sirve de alli en adelante, y lo recalco porque las opciones de exportación e importación se incorporaron a powershell en 2012, en 2008 R2 no existían),
debí recurrir a powershell para sortear este problema.
Dado que el archivo de transferencia de netsh no es editable por un humano, no puedo ver exactamente que no le gustó al server destino, .. seee ya se... el problema es que no está configurado TLS... pero donde? porque? en fin... no siempre la herramienta necesaria es un martillo..
Los pasos para el procedimiento son similares, sino idénticos, pero via powershell, consecuentemente los comandos son diferentes.
Otra ventaja de powershell sobre netsh es que los comandos pueden ejecutarse en forma remota, por lo que podríamos hacer un script de powershell para todo el proceso, incluyendo el manejo del servicio DHCP en cuanto al inicio manual o automático y el estado corriendo o detenido, pero escapa al alcance del presente.
Similar a netsh, en powershell el comando para exportar data sería Export-DhcpServer -File C:\temp\dhcpexport.xml –leases o bien Export-DhcpServer -File C:\temp\dhcpexport.xml -ComputerName NombreServerOrigen –leases si lo ejecutamos en forma remota
Como primera observación, debemos notar aqui que el archivo de salida está en formato XML y que le hemos pedido a powershell que incluya los leases en la exportación. El que el archivo esté en formato XML será de gran ayuda.. creanme..
La ejecución como en netsh demorará de acuerdo a la cantidad de scopes, leases y reservation que tengamos.
Nota:La opción -Force sobreescribre el archivo destino si existe.
Finalizada la exportación, podremos importar el archivo en el server destino con el comando Import-DhcpServer -File C:\temp\dhcpexport.xml -leases, nuevamente aqui podremos hacerlo en forma remota, para lo cual el comando sería Import-DhcpServer -ComputerName NombreServerDestino -File C:\temp\dhcpexport.xml -leases
Si todo sale bien, la importación es un éxito, nos quedarán las tareas de parar el server DHCP viejo, autorizar el nuevo, iniciarlo, configurar el inicio manual para DHCP viejo y el automático para el nuevo y good job...
Pero, como decía el filósofo Argentino TuSam... puede fallar..
Incorrect Version, Version not supported
Como dijimos al principio, si se trata de versiones idénticas del mismo sistema operativo, o bien pasamos de una versión vieja a una nueva, todo debería salir con fritas, pero.. y sino..
Si intentamos pasar por ej. de 2012 R2 a 2012, que sucedería? .. Bueno, la exportación funconaría perfecto, pero la importación fallaría... y daría un mensaje por ej. File Version 6.1 not supported.
Y aqui es donde nos acordamos del padre, la madre y todos los parientes de MSFT, netsh y powershell... pero.. no hay que desesperar... recordamos que el archivo que se generó en la epxortación es XML, y por lo tanto entendible por un humano, pero las ventajas
no terminan alli, porque al ser XML podemos manipularlo un poco y ver si con eso solucionamos el problema.
Sería extenso mostrar aqui todo el proceso, pero para cotejar archivos, en el nuevo DHCP generamos una estructura básica, scope, reservation, etc. y exportamos.., con ello tenemos un archivo para comparar con el ya generado dhcpexport.xml
Una vez explorada la estructura veremos que no hay casi diferencias y que solo sería necesario ajustar la versión para que la importación funcionara, por lo tanto editamos lo siguiente
Tomamos el cabezal del archivo, (en este caso corresponde a Windows Server 2012 R2) y cambiamos la versión o revisión por la que necesitemos (en el ejemplo, pasamos a un 2012, por lo que debemos bajar el dígito en 1, para que nos quede la versión 6.2 en lugar de 6.3) y luego podremos importar sin problemas.
Conclusiones
En fin... el caso es que hasta el servicio más simple puede compilcarse, y no debemos encasillarnos en las herramientas que nos gustan, sino que debemos optar por la mejor para el trabajo, y aun así la situración puede fallar.. pero si la herramienta es la indicada podremos tomar atajos, algunos más arriesgados que otros para solucionar el problema.
En Powershell un script para realizar estas tareas se vería más o menos como el siguiente
La potencia que otrora ofrecía VBA para la adminitración de servidores, fue pasando a herramientas de linea de comandos como netsh,
para ir paulatinamente avanzando hacia powershell, tal vez hoy no sea la panacea utilizar powershell en todos los casos,
pero cierto es que MSFT a apuntado sus cañones hacia alli y no ha retrocedido, por lo que tarde o temprano los administradores más viejos,
deberemos ir pasando nuestro bagage de herramientas VBA a powershell, nos guste o no... Muerto el rey... Viva el Rey !!
|