Cabecera PRINCIPAL

Claves: técnico, redes, networks, microsoft, open source, gnu, programador, software, hardware, desarrolladores

Juan Enrique Gómez Péérez

miércoles, 28 de noviembre de 2007

ISA Server 2004 en un SBS R2 2003

Bueno, hace algun tiempo que no alimentamos este blog con una bonita anecdota.
El cliente esta vez tiene un marido informático el cual además trabaja en la parte de seguridad dentro del mundo de la informática con lo que la paranoia en seguridad y firewalls es importante. Durante la fase de diseño hemos presentado diversas configuraciones con firewalls por software por hardware, etc. pero al final se optó por la más versatil, y aparentemente eficiente que fue ISA Server que la incluye Windows 2003 Server for Small Business Premium edition.

Bien, en nuestro diseño de implementación nos la prometiamos felices ya que bueno, SBS sus asistentes, sus instalaciones automatizadas, la integración blah, blah, todo genial.

Bien pues el escenario de instalación más o menos como sigue, un servidor 2000 Server en producción con un Active directory funcionando y protegido de internet por un Firewall Linksys básico. Instalamos el CD1 de SBS, hasta que es un 2003 Funcional y antes de convertirlo en un SBS full-equip continuando la instalación lo unimos al dominio, lo convertimos en controlador, y le asignamos los roles y lo convertimos en catalogo global.

Pues nada, dale manolo, instalamos el resto, exchange, administración, sharepoint, etc... todo de maravilla. Venga vamos a por el isa y nos ponemos a configurar equipos con exchange...
Vale instalamos ISA, y arrancamos con un error, evento en ISA 14147, que las rutas que figuran en un adaptador no corresponden con la ip. Revisamos las configuraciones, cada tarjeta con sus ips correctas, la de internet con su puerta de enlace, la interna sin puerta de enlace y con sus dns. Configuramos las politicas reiniciamos un millon de veces, probamos mil configuraciones, y nada, el firewall arranca, pero en el estado en la consola de ISA nos muestra una cruz roja con 4 interrogaciones.

Instalamos SP3, desinstalamos, ejecutamos el Asistente de configuración de internet se autoconfigura todo de maravilla, pero nada pelotita roja, e interrogaciones. Cambiamos los rangos de ips, y nada, modificamos las rutas a mano, nada. Configuramos RRAS para ver interfaces e intentar controlar las cosas pero nada.

Bueno, conseguimos una pista y es que los usuarios de sistema "Network Service" y "Local Service" deben figurar en la política local de "Generar auditoría", bien, vamos. Editas la politica local (donde deben figurar) y misteriosamente (o no tanto) no nos permite añadir usuarios (evidente, es un controlador de dominio no podemos usar politicas locales). Lo intentamos de todas las formas conocidas y no hay forma.

Mi compi sigue indagando por los grupos de google y da con un articulo, el cual se deriva del párrafo anterior. La verdad es que el párrafo de añadir los usuarios de las politicas locales era el que más sonaba, lo que indica que tenemos un problema de permisos, y efectivamente resulta que el problema radica en que el servicio "Microsoft Firewall" (el alma de ISA) se está ejecutando con las credenciales de "Network Service" y al cambiar para que se ejecute con el usuario "Local Service" reincias, y voila!, todo funciona de maravilla....aparentemente...

Vega, dale, vamos a ponernos como locos a configurar outlooks (esta historia nos ha llevado casi 24 horas resolverla), pues claro, en nuestra felicidad inmensa por reparar el problema de ISA añadimos el outlook a Exchange y se acaba la felicidad... pero al instante.... Nada, nada esto es un problema de reglas y listo.......5 horas más tarde (y no es mi primer ISA server) no hay forma de con reglas, sin reglas, cambiado todo, permitiendo nada, imposible....venga tio vamos por la calle de enmedio, desinstala.........10 minutos.... reinstala (sin SPx).....intenta ahora el outlook.... plafff... a funcionar... joder y por que ahora funciona..... no preguntes y tira pa lante...

La teoría es que el cambio de usuario de Network Service por Local Service cambio los permisos en algún punto y reconfiguro alguna entrada probablemente en el Registry de manera que esta última reinstalación se ha hecho de manera correcta y no como ha ocurrido en todas las ocasiones anteriores....

Que triste es la vida del informático...... bueno espero haberte ahorrado unos minutos de lucha...

P.D.: Gracias a mi compi que se lo curro .... y bien..

lunes, 17 de septiembre de 2007

Replicación de SYSVOL y NETLOGON o como migrar un servidor

Bien, situemonos, martes por la mañana en la oficina, se te acerca el comercial y te plantea la cuestión, oye Juanen tenemos un servidor de un cliente que es un pobre Pentium IV con 1Gb de memoria que corre W2003 SBS con Sharepoint 2 y 3, SQL Server, Exchange, Antigen, NOD32 y varios hosts IIS con aplicaciones ASP.NET.

Y tu le dices, si, si claro, que lo recuerdo, lo montamos hace un mes, compramos varias barras de acero y calzadores para conseguir meter todo... y ale con un par, to pa dentro...
Pues nada que me comenta el cliente que es que le va un poco lento que se está planteando ampliar el Hardware 8-\....

Bien para que os hagais una idea es un cliente que se gasto una fortuna en W2003SBS con sus 15 licencias, sus licencias de Antigen, Office, Project (menos mal que le convencimos de no montar project server), SharePoint, etc.... hablamos de varias decenas de miles de euros, y no fue capaz de invertir un centimo en hard....

Bueno, pues nada presupuestamos, se estima la migración en na, una mañana total pa que :=)...
Pues los buenos de los chicos del departamento discutimos un par de posibilidades que pasan por la reinstalación total, que no nos apetece demasiado ya que tiene muchisimas politicas de grupo, usuarios, seguridad, etc... Por lo que optamos por el metodo "Swing It!" de Jeff Middleton, el cual tiene unos resultados excelentes, facilita la tarea, y para los lerdos como un servidor (más adelante veréis por que) es maravilloso ya que la guia es paso a paso, comando a comando, y movimiento a movimiento, lo que te permite que si no tienes ni idea, saber como migrar un sbs en producción a otro hardware nuevo con el mínimo tiempo de caida. Si tienes algo de idea, pues si tienes un problema te sirve para seguir los pasos uno a uno y ver donde la has cagado.

Bien, nos ponemos a ello, y decidimos hacerlo mediante una Máquina Virtual, total para que narices vamos a usar una máquina intermedia, no hay que instalar hard, nos bajamos un vhd de Microsoft de Win2003 y ni instalamos...

La teoría del sistema "Swing It!" es sencilla, creamos un controlador de dominio temporal que replicará todos los elementos del directorio activo, lo convertiremos en catalogo global, asumirá todos los roles, replicará y en ese momento lo separamos de la red, lo conectamos al nuevo hardware repetimos los pasos y tenemos una replica identica del SBS original, con todas nuestras cositas conservadas, joer... dos horas de curro y listo.... dale niño....

Bien comenzamos la tarea, montamos Virtual Server R2 en la máquina con hardware nuevo, un VHD de microsoft con Windows 2003 Standard de evaluación (si, si, aqui está: http://www.microsoft.com/vhd/), lo configuramos, lo unimos al dominio, le promocionamos como controlador, nos replica el dns, joer, esto va de locura.... vamos, vamos... esto en hora y media... (tardamos más en descargar que en montarlo... si esto es España). Lo desconectamos de la red del SBS original y decimos vamos a cerciorarnos que va todo bien, vale, nos bajamos un Vista de Evaluación, ale para el Virtual Server, lo arrancamos, lo intentamos unir al dominio y ups... no hay forma....

Algo ha pasado...revisamos, miramos, re-revisamos....y descubrimos que el servicio NTFRS no está replicando los directorios SYSVOL Y NETLOGON con lo que Houston tenemos un problema, bien una semana de curro, dandole vueltas, tirando el controlador, uniendolo desuniendolo, mirando, leyendo KB de MS, nada de nada...

En este momento la desesperación es bastante grande la verdad, así que no podemos perder más tiempo (ya hemos perdido bastante pasta con una semana y un fin de semana continuo migrando historias). Y a alguien se le ocurre borrar la base de datos del NTFrs (si reiniciarlo tampoco funciona), paramos el servicio, la borramos, lo iniciamos...y voila!, no replica pero si nos da el evento 10516 que dice que sysvol y netlogon ya están disponibles..... así que como medida drastica decidimos no perder más tiempo seguir desde ese punto y ya algun machaca se recreará todas las GPO a manita... les imprimimos las configs, y ale para adelante...

La verda es que el resto del camino tuvo algun que otro problema (configuraciones de DNS olvidadas, etc. el sistema de Jeff incluye unas herramientas que evitan ese tipo de problemas) pero conseguimos tener el directorio activo en el nuevo hardware sin problemas, pero también sin GPO.

Al echar un ojo a las politicas que habían llegado, las politicas estaban pero los archivos que deberían conteniendolas no estaban, sysvol estaba vacio, podíamos crearlas, pero no editar o aplicar las existentes, así que teníamos un visor de sucesos petado de errores. La solución....

Sencillo, exportarlas, se abre la consola de GPO, botón derecho en cada una de ellas y se exportan, ojito con esto, no lo hagáis sobre un HDD USB ya que tuvimos problemas con los nombres de algunas de ellas por los caracteres y las longitudes, exportarlas en vuestro disco duro NTFS y luego las comprimis con un WINRAR para moverlas al nuevo hardware... En el nuevo hardware las importais, y voila!, servidor en producción como un campeon....

Realmente la historia es bastante más compleja, lo único que pretendo es comentaros que si os encontrais en este caso y NTFrs no monta sysvol y netlogon, borrarle la base de datos, y al final simplemente le copias (exportais e importais) las politicas y los scripts que podáis tener y listo...

Un saludo.

domingo, 29 de julio de 2007

Desarrollo para Microsoft CRM 3.0

Hace tiempo ley una frase que decía "Los README son para cobardes, ¡ejecuta!", y la verdad es que creo que es una máxima de los informáticos, pero todos somos conscientes que tras 3 días de darnos cabezazos contra algo que no conseguimos que funcione, perdemos dos horas en leer un par de docs, y lo sacamos en 5 minutos... pues eso mismo es aplicable a este pequeño articulo.

El tema de hoy se basa en desarrollar "Callouts" o "Workflows" para Microsoft CRM 3.0 en Visual Studio 2005. Bien, MS te da soporte para VS 2003, y su CRM SDK solo es para 2003. Y claro, vacaciones, portatil, conexión UMTS, busca VS2003, bajatelo, lleva instalado dos entornos de desarrollo, los SDKs, que hay configurado, que no, vamos una locura... Así que alguien debió pensar lo mismo y se ha currado un template para crear callouts en C# en Visual Studio 2005, y ¡es autoinstalable!.

Bien, el autor es Arash Ghanaie-Sichanie (uno de los desarrolladores de MS), tienes hasta un MSI para instalar el template, lo primero que te llama la atención al instalarlo es que la ruta por defecto es "C:\Program Files\" sin más, y dices bueno, si este chico lo ha hecho así el sabra... Bien, instalas, y evidentemente no funciona. Lo quitas, y dices pues hay algo mal, lo reinstalas, pero ahora le fuerzas la ruta a la del VS2005, y tres cuartos de lo mismo. No hay forma, hasta que te da por leer un poco más abajo en su blog (los comentarios), y descubres que donde se deben instalar los templates es en "Documents and Settings (ó Users en Vista)\Documentos\Visual Studio 2005\Templates\ProjectTemplates\", pues nada, desinstalamos, reinstalamos, y efectivamente, ahi están los templates. ¡Genial! vamos a programar algo.....

Meeec, error, no encuentra algo en C:\Program Files\DynamicsCRM\, esto te hace pensar, oyes pues quizas la primera opción era correcta, pero esta vez tiras por la calle de enmedio, copias el directorio DynamicsCRM que te ha instalado en tu carpeta de templates en C:\Program Files\ y ale funcionando perfectamente...

Espero que al menos encuentres este post antes de que te vuelvas loco intentando hacer funcionar todo esto ;-)

P.D.: Los gurus de Visual Studio ya saben todo esto, es que este post no es para ti...

Enlace al template: http://blogs.msdn.com/arash/attachment/719626.ashx
Enlace al Articulo original: http://blogs.msdn.com/arash/archive/2006/08/25/719626.aspx

Saludos.

sábado, 28 de julio de 2007

Licenciamiento en Terminal Server 2003

El licenciamiento en los productos de Microsoft es una de las partes a mi modo de ver peor soportadas. No se si es algún tipo de interés oculto dentro de MS para tener la libertad de cambiarlo cuando les plazca, o que realmente no quieren que se conozca o entienda de manera eficiente. Tengo amig@s que son MCP en licenciamiento de Microsoft en sus 3 categorías, y ni siquiera ellos pueden explicartelo. Tengo acceso a partners de MS que tienen competencia de Licenciamiento y ni por esas, por ello tras la experiencia que vamos cogiendo día a día, aqui avanzamos algunas de las cosas que descubrimos de licenciamiento sobre todo desde el punto de vista de los desgraciaitos técnicos.

El licenciamiento de Terminal Servern en Windows 2003, tiene dos modos diferentes de ser contemplado, podemos otorgar licencias por dispositivo o por usuario.

Licencias por dispositivo: Estas licencias se otorgan a un cacharro único (entiendase por cacharro, cualquier cosa que sea utilizable con un cliente de terminal server, un PC, una PDA, un Tablet, etc.), en este caso no importa cuanta gente utilice un cacharro, es el propio cacharro el que tiene la licencia asignada y pueden acceder tantas personas como queramos desde el mismo. Un ejemplo sería una empresa de telemarketing, en que tenémos 20 puestos de operadoras, con 3 turnos (si un poco esclavizados pero bueno), esto hace que 60 personas diferentes usen los sistemas, pero como elegiríamos el sistema por dispositivo, solo necesitamos 20 licencias, una para cada cacharro o PC.

Licencias por usuario: Estas licencias en vez de utilizarse por cacharro van asignadas a un único nombre de usuario. Esto es, 1 licencia para "Fulanito de Tal", este fulanito podrá acceder desde todos los cacharros del mundo que desee a su servidor de Terminal en modo licencia por usuario. Este escenario está pensado por ejemplo para los que tenemos o utilizamos habitualmente más de un cacharro, el PC de la oficina, el de casa, la PDA, el del Cyber, si fueramos por dispositivo necesitaríamos una licencia para cada uno, al ser por usuario se asigna la licencia al usuario "Fulanito de Tal" y listo.

El sistema de licenciamiento funciona por servidor, esto quiere decir que si el servidor está en modo licencia por dispositivo, no podemos instalar licencias por usuario y viceversa. Lo que hay que tener en cuenta, en un único servidor de licencias no pueden convivir los dos modos. Sin embargo en una misma red si podemos tener dos servidores de licencias sin problemas, en modos diferentes, peeeeeeeeeero ojito, por que cada servidor de Terminal server se agarra a un único servidor de licencias, por lo que si el sevidor de TS número 1 está agarrado al servidor de licencias (puede ser el mismo o no) que sirve licencias por dispositivo, solo podrá conectarse gente con licencias por dispositivo.

Tras esta introducción siguen dos articulos más sobre la gestión de licencias, y sobre la asignación de las mismas... estar atentos por que la parte de licenciamiento por usuario es muy, muy interesante.....