November 16, 2009

Server 2008 R2 / Exchange 2010 p2


Pues bien, la instalación de los mailbox servers a terminado sin problema alguno, solo un par de cosas por resaltar, los requisitos de instalación, para simplificarnos podemos cumplirlos corriendo estos comandos de PoS:
Import-Module ServerManager
Add-WindowsFeature NET-Framework,RSAT-ADDS,Web-Server,Web-Basic-Auth,Web-Windows-Auth, Web-Digest-Auth,Web-Metabase,Web-Net-Ext,Web-Lgcy-Mgmt-Console,WAS-Process-Model,RSAT-Web-Server,Web-ISAPI-Ext,Web-Dyn-Compression,NET-HTTP-Activation,RPC-Over-HTTP-Proxy -Restart
•Set-Service NetTcpPortSharing -StartupType Automatic

Algo que me a fascinado es que ya no se depende del bendito servicio de Windows Cluster, para los que lo sufrimos esto es una gloria, no más “cluadmin .” Ahora Exchange se encarga de hacer la magia del failover.
Otro aspecto es que, durante la instalación del primer CAS se establece el nombre de Internet de tu organización, esto te pre-configura los URLs externos, lo cual realmente era una tarea lenta y tediosa en 2007, en donde realmente era muy simple comerter algun error.
Por otro lado, e esta instruyéndome en el tema en una manera más formal, les comparto un poco de las consideraciones a tomar en una implementación de Exchange 2010.
Si se puede pasar de Exchange 2003 a Exchange 2010, lo único necesario es expandir el esquema, además el modo funcional del bosque deba de ser 2003 y al menos contar con un servidor 2003 SP2 que funcione como GC en cada sitio donde se va a implementar Exchange. El modo operacional de la organización debe de ser Nativo.
RODC/ROGC no son soportados por E14! Esto como sabemos solo está disponible a partir de Windows Server 2008.
Si se va a hacer un upgrade desde 2007 también se requiere extender el esquema, igual se necesita tener SP2 instalado.
El CAS de E14 se puede usar como front-end con 2003 y 2007! Genial esto…
En un caso de migración de 2007 se deben de mantener los Hub Transport Servers, esto pues el HUB 2010 no puede comunicarse con mailbox servers en 2007.
Existen dos métodos para moverse a E14, por migración el cual te permite mover datos desde otras organizaciones o bien desde aplicaciones de mensajería de terceros (sigamos matando a Domino…) o bien por transición, la cual se efectúa cuando movemos datos entre nuestra misma organización.
Así rápidamente les comento algunas de las múltiples mejoras en el área de almacenaje.
Coalesced I/O. En Exchange Server 2010, ESE combina múltiples operaciones de I/O para crea una única operación, lo cual al final son menos I/Os, disminuyendo así la frecuencia de operaciones al disco, lo cual alarga su vida y nos da un mayor rendimiento general. Ligado a esto tenemos también que estas operaciones ahora manejan una mayor cantidad de datos.
También el viejo proceso de Online Defragmentation ha cambiado ya que este afectaba negativamente el rendimiento del servidor y sus dispositivos de almacenaje. Ahora el ESE contiene un nuevo evento llamado Defragmentation Manager, el cual monitorea la base de datos e identifica cuales B-Tress (método de almacenaje del ESE) necesitan ser desfragmentados, una vez identificados el mantenimiento se lleva a cabo en el background cuando la actividad en el servidor es menor, eliminando así el impacto mencionado anteriormente.
Realmente cuando me metí en Exchange 2007 note un gran salto tecnológico y en mi humilde opinión también agregaron cosillas que ofrecía la competencia y lo mejor las mejoraron, pero ahora veo un salto aun mayor, un producto más maduro y amistoso con el administrador, esperare con ansias mi primer implementación real!
Tambien pueden referirse al Exchange Deployment Assistant, esta herramienta les ayudará con su implementación, por ahora solo disponible de 2003 a 2010.
~D~

November 14, 2009

Y dónde está???

Alguna vez les ha pasado que llegan a ver un ambiente y no encuentran algo… por ejemplo el grupo de Enterprise Admins?! Y lo mejor, cuando preguntan te ven como si tuvieras 3 ojos!!!
Desafortunadamente es muy común que los informáticos hagamos cosas y no las documentemos… o bien, algunos documentamos vía email y la gente simplemente no lee los correos… desgraciados…
Ok, mantengámonos en lo expuesto anteriormente ya que es algo muy común, ahora bien, a resolverlo.
Existe una categoría especial de entidades predefinidas controladas por el sistema interno de seguridad de Windows, estas existen en todos los equipos, aunque varían ligeramente según la versión del sistema operativo; no importa si es un equipo en un workgroup o en un dominio, siempre encontraremos algunos de los llamados Well Know Security Principals, como son por ejemplo el grupo Everyone, Creator Owner, Administrators.
Estos son simple y sencillamente necesarios para el funcionamiento de nuestro sistema, además no podemos crear nuestros propios Well Know Security Principals.
Ok y que hacen estas entidades, básicamente agregan un SID a nuestro token de acceso, lo cual nos dará ciertos derechos predeterminados. Esto del SID y token entonces me lleva a mencionar ciertos puntos, el SID o Security Identifier es como lo que los ticos conocemos como el numero de cedula o identificación, en este caso esa cedula es un conjunto de valores alfanumérico que nos identifica, ahora bien, el hecho de renombrar un objeto no significa que el SID cambien, así como cambiarnos de nombre no varía nuestro numero de cedula (por lo cual esta técnica no me sirve para evadir mis deudas :-[ que mal).
Entonces para hacer una historia larga corta pensemos que al iniciar sesión se crea un token, el cual contiene nuestro SID y los SIDs de los grupos a los que pertenecemos, con esto el sistema sabe quién es y a que grupos de seguridad pertenece esa entidad y así puede otorgar los permisos adecuados. Realmente eso es un tema mucho más complejo que esto, pero hoy Sábado no creo que mi esposa quiera que pase toda la noche en la computadora escribiendo, a si que luego ahondamos en todas esas maravillas de la seguridad.
Habiendo dicho esto entendemos que el SID del Well Know Security Principal se suma al nuestro y así se dan ciertos permisos, algo como “mi número de identificación + el número de identificación de los Domain Admins = daemonRoot es Domain Admin = peligro!”
Bien pero como mencione anteriormente algún sonajas renombro alguno de estos grupos y ahora no sabemos donde están entonces vamos a rastrearlos. Cómo?! Pero ya les di la clave, por el SID! Primero necesitamos saber el SID de nuestro dominio, esto por la forma en que un SID está compuesto, para esto vamos a usar la herramienta llamada ADFind http://joeware.net/freetools/tools/adfind/index.htm luego necesitaremos otra herramienta que nos de el displayName del objeto que buscamos, el SidToName http://joeware.net/freetools/tools/sidtoname/index.htm .
El primer paso es ejecutar este comando en al consola adfind –f “objectClass=domain” –samdc objectSID este nos va a dar el SID del domino, que es algo como S-1-5-21-3922922491-1485192142-2417811997.
Ahora bien para saber cómo están formado los SIDs de los Well Know Security Principals podemos consultar el KB 243330.
Entonces el siguiente paso es ejecutar este otro comando en la consola sidtoname S-1-5-21-3922922491-1485192142-2417811997-519 el cual nos va a dar el displayName del grupo llamado Enterprise Admins o talvez queramos probar con el -512 que pertenece a los Domain Admins <:0)
Si lo analizan un poco, esa tendencia que tenemos de renombrar la cuenta Administror “por seguridad” pues no lo es tanto, ya que el SID del Administrator siempre va a ser S-1-5-21-(SID del dominio)-500… lero-lero ^_^ !
Espero estas gotas de información les sea útil, si alguien gusta discutir más a fondo algún tema, pues bienvenido! Realmente trato de expresarme y explicar las cosas de una forma simple y sencilla pero di… cada cabeza es un mundo, hasta pronto!
~D~

November 12, 2009

Server 2008 R2 / Exchange 2010.


Como podrán imaginar e estado esperando con mucha emoción el lanzamiento de Exchange 2010... hace un par de días mi buzón de correo corporativo fue migrado al ambiente de pruebas y ahora pues lo mejor "hágalo usted mismo!"
El día de ayer inicie la tarde de actualizar un poco mi ambiente de pruebas... para lo cual instalare Windows Server 2008 R2 Enterprise con Exchange 2010 Enterprise.
Les describo un poco el ambiente... lo que tengo es una maquina con un AMD Phenom X3 2.3Ghz, 4GBs RAM 800Mhz y dos discos SATA de 500GB... Espero Colacho me traiga una con 2 procesadores y mas slots de memoria, acepto donaciones!
El host como les dije es un Server 2008 R2, DC/GC, DNS, WINS, CA, Exchange 2010 CAS y HT.
Este tiene dos maquinas virtuales, mismo sistema operativo y además DC/GC, DNS, WINS y próximamente Exchange 2010 MBX.
La instalación del sistema operativo no varia mucho, realmente si es mas rápido que la versión anterior, ningún controlador me dio problema alguno...
Realmente todo fue muy bien, hasta que intente agregar la segunda maquina al dominio.
Como sabemos el Windows Firewall utiliza perfiles y pues algún parámetro en el perfil de domino no me permitía una buena comunicación con equipos que no están en el domino, realmente podía desde el cliente en el workgroup hacer ping, nslookup, nltest y otros, mas no podía mapear unidades de red ni agregar la maquina al dominio.
Llegue a pensar en problemas de resolución de nombres, configuración de las redes virtuales... también culpe al pobre Symantec... y como vemos era sencillo, claro, encontrar esto no lo fue tanto.
En fin, habiliten todo tipo de conexiones en el perfil de domino del Windows Firewall, agreguen el o los equipos al dominio y luego vuelvan a la configuración recomendada.
Ok perfecto, ahora tenía 3 controladores hablando entre sí felizmente... ahora vamos con Exchange!
Acá tampoco cambio mucho el proceso de instalación, lo primero el Setup.com /PrepareAD /OrganizationName. En mi cabecita dije, para tener más recursos disponibles voy a detener las maquinas virtuales mientras hacia esto, luego las inicio y listo, de por si el Schema Master es la maquina física o sea que pipa soy... pues no, parte de los chequeos preliminares que el instalador hace son buscar problemas de replicación, de existir la instalación no procede.
El error dice algo así como "The server side error is: 0x21a2 The FSMO role ownership could not be verified because its directory partition has not replicated successfully with at least one replication partner".
Listo, maquinas virtuales arriba, NTDS reciclado*, repadmin /replsummary no muestra problema alguno.... después de unos minutos el proceso termina... ahora el Setup.com /PrepareSchema.
*Funny fact… algo que es una bendición en 2008 es que se puede reinicar el servicio de Active Directory ( net stop ntds o sc \\host stop ntds ) eso te va a quitar unas cuantas reiniciadas de sistema a lo largo de la vida… algo más curioso es que en 2000/2003 si navegan a HKLM\SYSTEM\CurrentControlSet\Services verán que el NTDS esta ahí solo que no podemos manipularlo; para mí que algún developer por estar chateando dejo eso a medias y no fue sino hasta 2008 que lo arreglaron... no sean hipocritas, también les a pasado!
Si son curiosos antes de correr esto podrían hacer lo siguiente, via ADSIEdit conéctense a la partición de Configuration... y naveguen al contenedor de llamado Services.
Acá encontraran aquellos servicios que se prestan en nuestro bosque, noten que digo bosque, pues otros como LCS/OCS se almacenan en la partición de dominio y no en la de configuración, esto pues la ultima es compartida por todos los DCs de nuestro bosque. También como parte del ejercicio podrían revisar el snap-in del Active Directory Schema ( el cual aparece al correr el comando regsvr32 schmmgmt.dll)... acá si revisan el contenedor de atributos, notaran que los atributos msExch* no están presentes...
Esto les da una breve idea de lo que los comandos anteriores hacen, ok ahora después de correr el Setup.com revisen de nuevo.
Bueno, manos a la obra a instalar Exchange!
Una de las cosas que más me gusta de 2007 es que los binarios son guardados en el disco local, por lo cual si pones tu disco de Exchange guindando en el retrovisor de tu carro y el sol lo daña, no hay problema!
Ok si van a instalar la función de Client Access van a necesitar esto http://go.microsoft.com/fwlink/?LinkId=123380 así que mejor ya y evitarse la regañada.
Por ahí también puede que les salga un error que habla del NetTcpPortSharing... Dios nunca había escuchado de eso... claro Daniel sea inteligente y corra un sc query findstr /I "net" eso le va a dar la respuesta, pues... no! Acá es cuando me voy con solo los 500 mil pesos en ¿Quien quiere ser millonario? :(
Para solucionar esto debemos correr este comando de PowerShell o PoS Set-Service NetTcpPortSharing -StartupType Automatic y listo!
El set up continuara sin problema alguno.
Ah como disfrute cuando salude a mi servidorcito...
220 nemesis.daemonroot.com Microsoft ESMTP MAIL Service ready at Thu,
12 Nov 2009 22:49:13 -0600
ehlo daemonroot.com
250-nemesis.daemonroot.com Hello [::1]
250-SIZE
250-PIPELINING
250-DSN
250-ENHANCEDSTATUSCODES
250-STARTTLS
250-X-ANONYMOUSTLS
250-AUTH NTLM
250-X-EXPS GSSAPI NTLM
250-8BITMIME
250-BINARYMIME
250-CHUNKING
250-XEXCH50
250-XRDST
250 XSHADOW
Ok a este punto ya tengo mis DCs... y un CAS/HUB... mañana espero seguir con la parte de los Mailbox servers, espero estas líneas les ayuden en algo... hasta pronto!

P.D si ustedes tienen un chip que decodifica IPv6, los envidio, yo no... asi que talvez esto les sea útil http://support.microsoft.com/default.aspx/kb/929852

virgen del blog...

Ok ok... aquí un fan más de la tecnología, amante de la consola...
Realmente me gusta escribir y por los últimos años e mantenido una pequeña lista de distribución de correo a la cual contantemente bombardeo con noticias, trucos y mis vivencias, razones por las cuales me decidido a crear un blog para poder así llegar a más personas y tal vez poder ser de ayuda con mis humildes aportes...
Aca voy!