Hola todos, Mark de vuelta con un nuevo tema del cual no hemos hablado realmente mucho en el blog, IPv6. Cuando voy a sitio donde los clientes, tiendo a tener dos discusiones una y otra vez. Primero, los puertos RPC y los firewalls. Ned Pyle se ha ocupado de cada uno de ellos aquí y aquí. La segunda, IPv6. El punto de este post no es como funciona todo en profundidad técnicamente, el punto es entrar en una discusión similar a las discusiones en sitio que he tenido una que otra semana y que está orientada al administrador de Windows/Sistema. Ray Zabillia y yo tenemos planeadas más publicaciones acerca de conceptos básicos y como funciona todo en las próximas semanas. Si este es un tema de interés, podemos empezar desde ahí y profundizar realmente en algunas de las tecnologías de transición e incluso en cómo generar su propio laboratorio. ¡Por favor, háganoslo saber en los comentarios! Ahora demos un vistazo a las discusiones en sitio.

“A quien le interesa IPv6, tenemos IPv4 trabajando y funciona muy bien.”

Apuesto a que sí. Este es un argumento lógico similar a, “a quien le interesa equipos en 64-bit, tenemos 32-bit”. ¿Quieren hacer esa afirmación así? En febrero 3 de 2011, la Corporación de Internet para Nombres y Números Asignados (ICANN por siglas en inglés) se unió a la Organización de Recursos Numéricos (NRO por sus siglas en ingles), la Junta de Arquitectura de Internet (IAB por sus siglas en ingles) y la Sociedad de Internet (Internet Society) para anunciar que el conjunto de direcciones públicas del Protocolo de Internet versión 4 (IPv4) había sido completamente asignado.

En septiembre 14 de 2012, el RIPE NCC comenzó a asignar espacio de direcciones IPv4 desde el ultimo /8 del espacio de direcciones IPv4 que contiene. Actualmente el espacio de direcciones IPv4 se asigna de acuerdo a la sección 5.6 de las Políticas para la asignación de direcciones IPv4 del servicio de RIPE NCC para la región. Los paquetes de direcciones IPv4 del RIR (Regional Internet Registry) están próximos a agotarse RIPE NCC IPv4 Paquetes de direcciones disponibles. Poco tiempo después, los proveedores de internet (ISPs) agotarán sus paquetes de direcciones. Es en este punto donde los clientes se verán afectados por el agotamiento, porque no existirán mas direcciones IPv4 disponibles para entregarles. Todas habrán desaparecido.

También hay varias limitaciones de IPv4. No estoy diciendo que necesita implementar IPv6 mañana, pero no hagamos cosas hoy que harán difícil en el futuro realizar la transición hacia IPv6.

“¿Limitaciones de IPv4?, ¿como cuáles?”

Bueno, para empezar estamos escasos de direcciones como se ha dicho anteriormente. Lo más probable es que usted está consiguiendo MÁS dispositivos conectados a Internet, no menos. Pero vamos a suponer que usted tiene la suerte de tener una clase completa de direcciones A o B para sí mismo y no necesita más direcciones en el futuro previsible. ¿Necesita seguridad a nivel IP o necesitará de ella en el futuro? Supongo que sí. IPSec es opcional en IPv4, pero se ha convertido en un estándar en IPv6 desde el primer día, lo cual hace que las implementaciones de IPSEC sean consistentes a través de las implementaciones de los proveedores. ¿Qué pasa con la calidad de servicio (QoS)? IPv4 puede hacerlo utilizando el campo Tipo de Servicio (TOS), pero no funciona cuando se cifra el paquete. Así que espero que usted no quiera tener LA SEGURIDAD y LA CALIDAD DEL SERVICIO al mismo tiempo. Se está haciendo más y más difícil forzar IPv4 a hacer lo que se logra fácilmente en IPv6.

“Tenemos NAT funcionando en este momento, entonces está bien”

Esa es otra bola de cera. Por no hablar de la complejidad que se añade a la red que puede hacer que la solución de problemas sea aún más difícil de tratar, pero no todas las aplicaciones funcionan con NAT debido al hecho de no tener una dirección IP "real" en el cliente. Hacer que IPSec funcione con NAT también es un reto. NAT puede resolver algún problema, pero también puede introducir algunos otros. Probablemente no es sostenible en el largo plazo.

“Hmmm todo esto suena como que usted debería hablar con el equipo de redes acerca de esto, ellos están al fondo del pasillo. Este no es mi problema”

Está bien, hemos llegado al núcleo de este argumento. Es ABSOLUTAMENTE su problema. Si nunca ha tenido que solucionar problemas de un servidor que no es capaz de conectarse a otro servidor, éste debe ser su primer día en el trabajo. Saber solucionar problemas de conectividad es una herramienta crítica dentro de la bolsa de herramientas para la solución de problemas. Si no es así, añádala de inmediato, de nada. Ser capaz de comprender una dirección IPv6 y todo lo que significa será útil y en realidad, una necesidad en el futuro. He tenido clientes donde el equipo de red está “probando” IPv6 y el cliente empieza a recibir esta "dirección misteriosa". ¿Eso es normal?, ¿Está funcionando como se supone?, ¿Estoy en la red correcta?, todas estas preguntas pueden responderse hoy con una dirección IPv4, ¿por qué NO responder a ellas solo porque la dirección se ve diferente? La idea de no tener conocimiento básico de IPv4 hoy es impensable, tener habilidades de IPv6 no sólo le pondrá por delante de la curva hoy y le preparará para el futuro. Un ejemplo de la vida real, aquí en breve.

“Si, pero aun así, escucho que IPv6 daña las cosas, esa es la razón de por qué yo lo tengo que deshabilitar”

Por supuesto que usted tiene. En primer lugar, todavía tengo que escuchar que IPv6 "mete la pata". En segundo lugar, esto no es deshabilitar IPv6, esto es desligarlo del adaptador de red. Si su objetivo es deshabilitar IPv6 en el sistema, usted no lo ha hecho. Todavía se está ejecutando en el sistema. Si tiene que volver a marcar esa casilla NO HAY UNA MANERA PROGRAMATICAMENTE de hacerlo. Así que si se ha adelantado e incorporado la casilla desmarcada de la imagen y necesita IPv6 en ese adaptador de red, usted necesitará iniciar sesión EN CADA MAQUINA Y VOLVERLA A MARCAR. ¡Oh, qué divertido que será! Si usted tiene que desactivarlo siga el KB 929852 utilizando la llave de registro de Componentes deshabilitados. Recomiendo no deshabilitarlo, pero si para usted es absolutamente necesario, utilice una GPO para que pueda deshacer fácilmente esto en el futuro. Como se indica en el KB, si usted hace uso de la clave de registro de Componentes deshabilitados la casilla indicada permanecerá marcada. Ese es el comportamiento esperado.

“Todo eso está muy bien en teoría, pero ¿esto realmente sucede en el mundo real?"

Aquí en AskPFELatamPlat tenemos una perspectiva única por pasar tanto tiempo frente a tantos clientes, logramos ver lo que sucede en el mundo real. Recientemente Ray estaba ayudando a uno de nuestros grandes clientes empresariales en su migración de Directorio Activo de Windows Server 2003 a Windows Server 2008 R2. Ellos sólo habían instalado unos pocos controladores de dominio en 2008 R2 y poco tiempo después Ray recibió una llamada de uno de los arquitectos de AD de la empresa pidiendo que le explicara por qué él estaba obteniendo direcciones IPv6 en respuesta a su "ping" en los controladores de dominio 2008 R2. Además, ¿por qué había dos direcciones IPv6 asignadas? ¿Y por qué una de las direcciones siempre comenzaba con FEC0 y la otra con 2002? ¿Qué direcciones están siendo registradas en el DNS?

Ahora en este cliente en particular la mayor parte del soporte y administración de TI, incluyendo la de Directorio Activo había sido subcontratada con un proveedor de terceros. Así que Ray tuvo una reunión con el personal de AD propio del cliente y varios miembros del personal de AD de parte del subcontratista. Uno de los miembros del personal de soporte del tercero para AD dijo que esto tenía una solución fácil, que simplemente sólo sería desmarcar la casilla protocolo IPv6 en la configuración del adaptador de red para desactivar IPv6 y los problemas serían resueltos.

¿Ve el problema de la vida real? Si un proveedor le está diciendo que deshabilite IPv6 para "arreglar un problema" o que "observa que este causa problemas" retroceda un poco y pregúntele qué es lo que realmente está arreglando o los problemas que este está causando. Haga que sea específico. Es hora de no permitir que IPv6 sea este gran misterio del universo.

"Bien, hablando de todo un poco, cual es la posición de Microsoft sobre IPv6?"

Voy a dejar que la documentación oficial haga la charla en este caso. Respuesta corta, déjelo encendido. Originalmente lo puede encontrar en IPv6 para Microsoft Windows: Preguntas frecuentes (artículo en Ingles).

Es lamentable que algunas organizaciones deshabilitan IPv6 en sus computadores que funcionan con Windows 7, Windows Vista, Windows Server 2008 R2 o Windows Server 2008, donde está instalado y habilitado por defecto. Muchos deshabilitan IPv6 basados en el supuesto de que no están ejecutando aplicaciones o servicios que lo utilicen. Otros podrían deshabilitarlo debido a una percepción errónea de que tener tanto IPv4 como IPv6 habilitado efectivamente duplica su tráfico Web y de DNS. Esto no es cierto.

Desde la perspectiva de Microsoft, IPv6 es una parte obligatoria del sistema operativo Windows y está habilitado y se incluye en las pruebas de servicio y aplicación estándar de Windows durante el proceso de desarrollo del sistema operativo. Debido a que Windows se ha diseñado específicamente con IPv6 actualidad, Microsoft no realiza ninguna prueba para determinar los efectos de deshabilitar IPv6. Si IPv6 es desactivado en Windows 7, Windows Vista, Windows Server 2008 R2 o Windows Server 2008 o versiones posteriores, algunos componentes no funcionarán. Es más, podrían ser aplicaciones que usted puede pensar que no están utilizando IPv6, tales como Asistencia remota, Grupo Hogar, DirectAccess y Windows Mail.

Por lo tanto, Microsoft recomienda que deje IPv6 habilitado, incluso si usted no tiene una red habilitada para IPv6, ya sea nativo o tunelizado. Al dejar IPv6 habilitado, usted no deshabilita aplicaciones y servicios que solo usen IPv6 (por ejemplo, Grupo Hogar en Windows 7 y DirectAccess en Windows 7 y Windows Server 2008 R2 utilizan sólo IPv6) y sus anfitriones pueden tomar ventaja de una conectividad IPv6 mejorada.

“¿Que productos de Microsoft soportan IPv6?”

Obtenga la lista oficial aquí. Son bastantes.

“¿Algo más que yo deba saber?”

Una cita textual del prefacio de “Understanding IPV6 – Third Edition” lo resume muy bien.

“"En los últimos 24 meses, hemos hecho grandes progresos hacia el objetivo de mejorar la Internet. IPv6 ya no es el protocolo de Internet de la próxima generación, sino que se ha convertido en el protocolo de Internet de la generación actual.

El lanzamiento mundial de IPv6 en junio de 2012 marcó un punto de inflexión clave en esta transición. Cuando lea este libro, algunos de los servicios web más importantes del mundo, no sólo de Microsoft, sino de toda la comunidad de la tecnología, están en funcionamiento en la Internet IPv6. Millones de usuarios con equipos listos para IPv6 están utilizando IPv6 para interactuar con estos servicios y con algunos otros. Las aplicaciones, los sistemas operativos, la infraestructura de enrutamiento, los proveedores de Internet, y los servicios no solamente están listos, están activados”.

-Chris Palmer

IPv6 Program Manger

Microsoft

Bien, espero que en este punto dentro del post, usted haya girado en torno a IPv6 completamente y esté listo para profundizar en el. El punto de esto es que IPv6 no está llegando, está aquí ahora. IPv4 es, de hecho, la tecnología antigua o heredada. En nuestra próxima publicación vamos a entrar en más detalle y dar sentido a todo. No se preocupe, no es tan aterrador.

-Mark “IPv6 Ready” Morowczyski y Ray “IPv6 Ready” Zabilla

Hola a todo, una vez más Mark. En nuestro último tema hablamos acerca del ¿por qué usted debe preocuparse acerca de IPv6?. En este nuevo blog Ray Zabilla y yo vamos a desmitificar el enigma de las direcciones IPv6 y le dará una mejor comprensión del espacio de direcciones IPv6 y la sintaxis. Compararemos también diferentes conceptos que abordan entre IPv4 e IPv6.

Comencemos con un ejemplo común que estamos acostumbrados a ver.

Ahí está, una dirección IPv6. No temas no asusta.

Vamos a desglosar esta información y compararla con algo que sí sabemos bastante bien IPv4. La dirección IPv6 es de 128 bits de largo y IPv4 son 32 bits de longitud. Por eso IPv6 permite mucha más direcciones. Si usted desea ser más específico, IPv6 le permite 340.282.366.920.938.463.463.374.607.431.768.211.456 direcciones. Dile adios al bebé NAT!

El desglose de la direcciön IPv6

La dirección IPv4 se dividen en 8 bits, escrito en decimal y separados por un ".". Desde la pantalla tenemos la dirección 10.0.1.114.Dirección IPv6 se divide en 16 bits, escrito en hexadecimal y están separados por un ":". Desde la pantalla tenemos la FE80 :: D9E : bed6 : 4917 : C7DF%12

Otra de las diferencias significativas con las direcciones IPv6 y las direcciones IPv4 es que las direcciones IPv6 se expresan como números hexadecimales en lugar de números decimales. Dependiendo de su fondo esto puede hacer que sea más fácil o más difícil de entender, pero no te despegues permítenos explicar las reglas de la dirección IPv6. Si usted no tiene mucha experiencia trabajando con los números hexadecimales aquí hay un par de enlaces que proporcionan un poco más de detalle, si usted desea tener una mejor comprensión.

http://www.codemastershawn.com/library/tutorial/hex.bin.numbers.php

http://en.wikipedia.org/wiki/Hexadecima

Las calculadoras integradas también pueden convertir a hexadecimal para usted. Sólo tienes que cambiar a " programador"

De buelta al tema direcciones IPv6. Lo que realmente me ayudó a entender cómo leerlos fue reconocer los límites que contiene 4 caracteres hexadecimales y debe haber 8 conjuntos de ellos. Por ejemplo, sería algo como "abcd : abcd : abcd : abcd : abcd : abcd : abcd : abcd" Cada caracter en este grupo puede estar formado por 4 bits también conocidos como 'nibbles'. Así que vamos a hacer algunos cálculos aquí. Cada personaje es de 4 bits , hay 4 personajes por juego para un total de 16 bits. Tenemos 8 juegos, 8 x 16 = 128 bits. Todo concuerda.

Ahora nuestra dirección IPv6 reflejada en la captura de pantalla no cumple con el número total de caracteres y faltan algunos grupos. Vamos a escribirlo en la forma larga y dar consejos poder acortar la dirección mediante la compresión de ceros.

FE80:0000:0000:0000:0d9e:bed6:4917:C7DF%12

En primer lugar un grupo de 0s puede ser representado por dos puntos dobles " : " . Sólo se puede utilizar una vez por cada dirección. Así que nuestra nueva dirección con 0s comprimidos se puede escribir como FE80::0d9e:bed6:4917:C7DF%12. Mi otro truco mental es el siguiente. Sé que debería tener un conjunto de 8, así que tomo el número del conjunto que tengo de solo 0 y los substraigo del conjunto total de 8. Bien de nuevo a nuestra dirección.

Si se compara nuestra dirección en la salida de FE80::d9e:bed6:4917:C7DF%12 a nuestros nuevas direcciones con 0s comprimidos FE80::0d9e:bed6:4917:C7DF%12 tenemos un extra 0. Sin embargo También puede comprimir los principales 0s en la dirección . Así tenemos , FE80::d9e:bed6:4917:C7DF%12. Vamos a hacer algunos otros ejemplos y para poder aclarar los ejemplos.

Ejemplos

Vamos a empezar con la dirección IPv6 original desde arriba.

Esto se conoce como puntos hexadecimal

FE80:0000:0000:0000:0d9e:bed6:4917:C7DF%12

Forma binaria

1111111010000000000000000000000000000000000000000000000000000000

0000110110011110101111101101011001001001000101111100011111011111

Dividido en 16 bits

1111111010000000 0000000000000000 0000000000000000 0000000000000000

0000110110011110 1011111011010110 0100100100010111 1100011111011111

Supresión de ceros

FE80:0:0:0:d9E:bed6:4917:C7DF

Supresión de ceros con la supresión de " dos puntos dobles " Una secuencia única contigua de bloques de 16 bits se pone en 0 puede ser comprimido por "::" ( doble punto) Un doble de punto puede utilizarse solamente una vez cuando se comprime una dirección .

FE80::d9E: bed6:4917:C7DF

No se puede utilizar la compresión de cero para incluir parte de un bloque de 16 bits

FF02:30:0:0:0:0:0:5 no se puede hacer FF02:3::5, pero si FF02:30::5

Más ejemplos de compresión cero

2003:00ef:67ea:0000:ffdc:1268:0002:0044

2003:ef:67ea::ffdc:1268:2:44

3ffe:0039:ebc0:5600:cda0:0098:bca2:0096

3ffe:39:ebc0:5600:cda0:98:bca2:96

2109:de00:b00d:0087:0000:0000:0000:0027

2109:de00:b00d:87::27

300f:0000:0000:0096:0000:0000:0054:fdec

300f::96:0:0:54:fdec

Nótese que usamos el ":: " una vez , aunque tuvimos varios bloques de 0.

2999:0000:dead:beef:cafe:0000:0000:0001

2999::dead:beef:cafe:0:0:1

En general, el resumen de la espacio de direcciones IPv6 puede ser visto como sigue .

· Espacio de direcciones de 128 bits

· 2¹²⁸ posibles direcciones

· 340,282,366,920,938,463,463,374,607,431,768,211,456 direcciones (3.4 x 10³⁸ o 340 undecillones) (undecilion ni siquiera estaba en el corrector ortográfico de MS Word !)

· 6.65 x 10²³ direcciones por cada metro cuadrado de la superficie de la Tierra

· 128 bits para permitir una flexibilidad de erutación de un multinivel, jerárquico

Ahora que hemos definido el formato de una dirección IPv6 vamos a pasar a algunas de las otras características y funciones de IPv6.

Tipos de direcciones IPv6

IPv6 tiene tres tipos de direcciones , que se pueden clasificar según el tipo y alcance.

Unicast - Una dirección unicast identifica una única interfaz dentro del alcance del tipo de dirección de unicast. Con la topología de enrutamiento apropiada, los paquetes dirigidos a una dirección unicast se entregan a una sola interfaz.

Lo que esto significa, por ejemplo, es una dirección unicast global, que es similar a una dirección pública IPv4 y único a través de Internet, se entrega un paquete de interfaz única a otra interfaz única. Una dirección unicast local es similar a una dirección APIPA que es único a la subred local, de modo que el paquete sólo puede ser enviado a un dispositivo dentro del alcance. Hablaremos más acerca de Dirección IPv6 en el próximo enlace.

Los siguientes ejemplos son direcciones IPv6 unicast:

· Direcciones unicast globales agregables (IPv4 pública )

· Direcciones locales de vínculo (IPv4 APIPA 169.254.xx )

· Unique Local (IPv4 direcciones privadas )

· Direcciones locales del sitio están en cesando formalmente en el RFC 3879

· Direcciones especiales

· Direcciones de compatibilidad

· Direcciones de Transición

Mulitcast - Dirección de un conjunto de interfaces entregado a todas las interfaces del conjunto (paquete se entrega a múltiples interfaces)

Anycast – Dirección de un conjunto de interfaces, pero la entrega es sólo a una única interfaz en el conjunto. Se envía un paquete a la más cercana de múltiples interfaces (en términos de distancia de enrutamiento) .Éste puede ser un poco difícil de entender, pero creo que uno de los mejores ejemplos que se nos ocurrió fue algo así como un servidor proxy, donde usted puede tener varios servidores ubicados en la red, pero sólo desea reenviar paquetes a la más cercanos.

No más broadcast

Nota: ( Técnicamente IPv6 no tiene una dirección de broadcast, pero prácticamente la dirección IPv6 Multicast especial enviará un paquete a todos los nodos en donde obtenemos el mismo resultado , por ejemplo FF02::1)

Eso es todo, esos son los tipos de direcciones IPv6. Ahora vamos a pasar al alcance de ellos .

Alcance de direcciones IPv6

Global Address - El alcance de dirección en su totalidad de IPv6 en el Internet

Una dirección de unicast global es equivalente a una dirección pública IPv4. El alcance es todo IPv6 en el Internet, por lo tanto son globalmente enrutable y pueden utilzarse en la Internet IPv6. La dirección de Internet IPv6 ha sido diseñado desde su creación para mantener el intercambio eficiente, jerárquico de direccionamiento y enrutamiento direcciones de modo de unicast están diseñados para ser agregados o resumidos para facilitar la creación de una infraestructura de enrutamiento eficaz.

· Prefijo de Enrutamiento Global ( parte de la topología de enrutamiento público - junto con 001 prefijo )

· ID de subred ( la topología del sitio )

· Id. de interfaz

Direccion de enlace Local – El alcance de la dirección es un solo enlace

Una direccion IPv6 Unicast son similares a las direcciones IPv4 APIPA utilizados por los equipos que ejecutan Microsoft Windows. Los anfitriones en el mismo enlace (la misma subred) utilizan estas direcciones configuradas automáticamente a comunicarse entre sí. Se requiere una dirección de enlace-local para algunos procesos como "Neighbour Discovery" Descubrimiento de Vecinos y siempre se configura de forma automática, incluso en ausencia de todas las demás direcciones unicast.

· Equivalente a IPv4 dirección APIPA

· FE80 :: / 64 prefijo

· Única subred , configuración sin enrutadores

· Proceso de descubrimiento de vecinos

· Direcciones locales de vínculo son ambiguas por el ID de zona se utiliza

·para identificar la interfaz específica

· IDs de zona sólo se utilizan para las direcciones locales de vínculo desde

· Direcciones enrutables no son ambiguas. Ex. fe80::2b0:d0ff:fee9:4.143%3

· Windows Vista y por encima muestran el identificador de la zona de IPv6

·las direcciones locales en la salida del comando ipconfig.

Local Unico /Sitio de direcciones locales – Alternativa direccionamiento privado globales para el tráfico de la internet

Direcciones locales de sitio proporcionan una alternativa frente a un direccionamiento privado globales para el tráfico de la intranet. Sin embargo debido a que el prefijo de la dirección local de sitio puede ser reutilizado para hacer frente a múltiples sitios dentro de una organización, un prefijo de la dirección local de sitio puede ser duplicado. La ambigüedad de las direcciones locales del sitio en una organización aumenta la complejidad y dificultad para aplicaciones, enrutadores y administradores de red.

En consecuencia, la dirección local de sitio han dejado de utilizarse y las direcciones locales únicas han superado este reto. El objetivo es reemplazar todas las direcciones locales del sitio con un nuevo tipo de direcciones que sería privada a una organización pero a la vez único a través de todos los sitios de la organización. En otras palabras, las direcciones locales únicas tienen un alcance global a la organización, pero su accesibilidad está limitada por las políticas de la topología de enrutamiento y políticas de filtrado en los limitadores de Internet. Las Organizaciones no anunciar sus prefijos de direcciones locales únicas fuera de su organización o crear entradas de DNS para estos por internet.

El ID Global (vea el diagrama a continuacion) identifica un sitio específico dentro de una organización y se establece en un valor aleatorio de 40 bits. Mediante la derivación de un valor aleatorio para el ID Global, una organización puede tener los prefijos de 48 bits estadísticamente únicos asignados a sus sitios. Además, el pensar que dos organizaciones que utilicen direccionamiento local único que pueda ser capaz de entrelazarse tiene una baja probabilidad de duplicar el prefijo de la dirección local única de 48 bits, lo que minimiza la remuneración sitio. A diferencia de los prefijos Global de Enrutamiento utilizados en direcciones globales, los identificadores globales en las direcciones locales no están diseñados para ser resumidos.

Mientras ULAs no tenían el propósito de ser registrado de ninguna forma, aún podría ocurrir que varias organizaciones generen o utilizan el mismo prefijo y, como tal, todavía exista una posibilidad de colisiones. Como resultado, un sitio de registro voluntario ULA se ha establecido en http://www.sixxs.net/tools/grh/ula/ para ayudar a minimizar las colisiones ULA. Claro está esto si todo el mundo utilizara este registro, la posibilidad de colisiones debería estar cerca de cero.

· RFC 4193 define esta dirección local única

· Equivalente a la dirección IPv4 privada

· FD00 :: / 8 prefijo

· Reemplazo para las direcciones locales de sitio

· Alcance global , sin identificación zona requerida

Las direcniones IPv6 especiles

· Sin especificar Dirección

· 0:0:0:0:0:0:0:0 o ::

· Dirección en bucle

· 0:0:0:0:0:0:0:1 o :: 1

Compatibilidad o transición de direcciones

Se utiliza para IPv4 a IPv6. Vamos a tener un próximo blog dedicado a las tecnologías de transición.

· Dirección compatible con IPv4

0:0:0:0:0:0:w.x.y.z or ::w.x.y.z

El w.x.y.z es la representación decimal con puntos de una dirección IPv4 pública), es utilizado por los nodos IPv6 / IPv4 que se están comunicando con IPv6 sobre una infraestructura IPv4 que utiliza direcciones IPv4 públicas, como por ejemplo en el Internet. Direcciones compatibles con IPv4 están en desuso en el RFC 4291 y no son compatibles con IPv6 para Windows Server 2012, Windows Server 2008 R2, Windows Server 2008, Windows 8, Windows 7 y Windows Vista.

· Direcciones asignadas de IPv4

0:0:0:0:0:FFFF:w.x.y.z or ::FFFF:w.x.y.z

La dirección asignada de IPv4 se utiliza para representar una dirección IPv4 como una dirección IPv6 de 128 bits

· Direcciones 6to4

2002:WWXX:YYZZ,

Una dirección IPv6 6to4 tiene el formato en que WWXX : YYZZ es la representación hexadecimal con dos puntos de w.x.y.z (una dirección IPv4 pública )2002:WWXX:YYZZ::WWXX:YYZZ

· Direcciones ISATAP

Prefijo de 64 bits:0:5EFE:w.x.y.z o prefijo de 64 bits:200:5EFE:w.x.y.z

Una dirección ISATAP de un prefijo de 64 bits: 0:5 EFE : w.x.y.z , donde w.x.y.z es una dirección IPv4 privada y se asigna a un nodo para el Sitio -Intra el direccionamiento automático de túne Protocolo ( ISATAP ) tecnología de transición IPv6..

· Dirección Teredo

Prefijo 2001::/32

Una dirección global que utiliza el prefijo 2001::/32. Teredo está diseñado para funcionar incluso en la presencia de traductores de direcciones de red (NAT).

Mete un Homerun!

Sé que esto ha sido mucho para procesar , pero vamos a volver a la captura de pantalla original y resumen la dirección FE80::d9e:bed6:4917:C7DF%12.

Ahora sabemos cuánto tiempo es (128 bits) y donde de todo el cero fuimos. Sabemos también los diferentes tipos y alcances de las direcciones de IPv6. Traer de vuelta a la pantalla el prefijo FE80 significa que es sólo una dirección de enlace local, que es el equivalente a IPv4 APIPA. La próxima vez que alguien dice esta dirección IPv6 FE80 está causando problemas de enrutamiento sólo tiene que decir , que no es más que una dirección IPv6 APIPA y sorprende a todos con su conocimiento de IPv6. En nuestro próximo post vamos a cubrir algunos temas más avanzados en las direcciones IPv6.

Mark “FE80:Chicago” Morowczynski y Ray “FE80:Minneapolis” Zabilla

Hola, mi nombre es Pierre RICCA, soy un Ingeniero de Campo de Premier (PFE) especializado en Active Directory y scripting de PowerShell. Inicié como PFE en Microsoft Francia en noviembre de 2010. Una parte importante de mi trabajo consiste en realizar revisiones de salud, análisis de riesgos y transferir conocimiento sobre tecnologías Microsoft para nuestros clientes en Francia.

Introducción

En el trabajo de campo, los clientes constantemente solicitan consejos y practicas recomendadas sobre cómo optimizar la resolución de nombres de DNS y, aun cuando la topología de DNS de cada cliente es única, existen algunas recomendaciones generales.

Probablemente sepan que es posible almacenar las zonas de DNS en una instancia de Active Directory si instalan el servidor de DNS en un Controlador de Dominio. Almacenar las zonas de DNS en Active Directory tiene múltiples beneficios: puede tomarse ventaja de la replicación de Active Directory y también permite tener múltiples servidores DNS “maestros” (SOA) para la misma zona de DNS.

Con algunos clientes he visto ambientes en los cuales una sola zona de DNS almacena todos los registros de DNS del forest. El ambiente del cliente está compuesto por un dominio raíz llamado “contoso.com” y algunos dominios hijo llamados “child1.contoso.com”, “child2.contoso.com”, “child3.contoso.com” y “child4.contoso.com”.

Esta imagen muestra como se ve este ambiente en la consola de administración de DNS:

Como pueden ver en el ejemplo, solo existe una zona “forward lookup” (contoso.com), en la cual, cada dominio hijo tiene su sub espacio de nombres para esa zona. Este tipo de configuración típicamente aparecerá si no se instala el rol de “DNS server” antes de ejecutar el DCPROMO para la creación de un nuevo dominio hijo. Notarán que el sub espacio de nombres “_MSDCS” también está almacenado en la zona de DNS padre.

Esta configuración tiene una desventaja principal: Si se instala un DNS server en un dominio hijo, no es posible seleccionar que se almacenen solo los registros específicos para ese dominio hijo, solo será posible almacenar la zona “contoso.com” completa, afectando el desempeño de la replicación de Directorio Activo así como el tamaño de la base de datos.

Para este tipo de ambientes, la mayoría de las veces recomendamos dividir los registros de DNS para cada dominio hijo en zonas de DNS separadas y usar una delegación en la zona de DNS del dominio raíz para cada una de las zonas hijo. La siguiente imagen muestra un ejemplo de la configuración recomendada.

Este artículo presentará una solución para dividir la gran zona del dominio “contoso.com” un sub zonas de DNS específicas para cada dominio hijo.

Historia de la división de zonas de DNS

A partir de Windows Server 2003, cuando se inicia la instalación de un nuevo bosque de Directorio Activo, DCPROMO creara dos zonas de DNS separadas, una llamada "_MSDCS.tudominio.com" y otra llamada "tudominio.com". Aquí hay un ejemplo de mi dominio “dom2k3.com”:

Este comportamiento permite tener diferentes ámbitos de replicación para las diferentes zonas de DNS. Por default, la zona “_MSDCS” del dominio raíz debe ser replicada a “All DNS servers in the Active Directory forest”, mientras que la zona de DNS del dominio debe ser replicada solo a “All DNS servers in the Active Directory domain”. Se pueden revisar y modificar estas opciones en el tab “General” de las propiedades de la zona:

Cuando el bosque se crea en Windows 2000 Server, DCPROMO no separa la zona “_MSDCS” de la zona del dominio raíz y esta zona se almacena directamente en la zona del dominio raíz. Para separar la zona “_MSDCS” y emular el comportamiento por default de “Windows Server 2003”, se debe realizar la división de las zonas de forma manual. El proceso de separación se detalla en el artículo técnico: “How to reconfigure a _MSDCS subdomain to a forest-wide DNS application directory partition when you upgrade from Windows 2000 to Windows Server 2003” http://support.microsoft.com/kb/817470/en-us.

La migración de los registros de DNS del dominio hijo

El artículo técnico mencionado anteriormente (KB 817470) sugiere dividir la zona “_MSDCS” mediante la creación de una nueva zona de DNS “_MSDCS” vacía, después de lo cual se debe forzar a cada controlador de dominio a registrarse en DNS dentro de la nueva zona.

Desafortunadamente, dicho procedimiento no puede ser utilizado en el escenario que hemos planteado, debido a que necesitamos migrar todos los registros existentes de los dominios hijo (incluyendo los registros estáticos), a una nueva zona de DNS dedicada al dominio hijo. En nuestro escenario, cada dominio hijo ha estado corriendo en producción por unos cuantos años y cuenta con unos cuantos miles de registros de DNS para cada dominio hijo. Una recreación manual de estos registros de DNS sería muy complicada y se llevaría mucho tiempo. La única solución que nos queda es utilizar un script!

He aquí el método que utilizamos.

Por favor tomen en cuenta que los scripts presentados en este artículo se proveen como ejemplo y no tienen soporte de parte de Microsoft. Antes de aplicar esta solución, asegúrense de respaldar sus zonas de DNS y estar preparados para hacer una recuperación de las zonas en caso de que suceda algo inesperado. En mi experiencia, esta solución puede tomar unas cuantas horas de principio a fin. Recomiendo encarecidamente aplicar esta solución fuera de horario de trabajo. El proceso automático de registros en DNS no estará disponible durante el tiempo que tome la migración de zonas.

Paso 1: Exportar la zona de DNS.

En primer lugar, necesitamos exportar la zona de DNS actual hacia un archivo. Afortunadamente, el comando “DNSCMD” permite realizar esta tarea. A continuación hay un ejemplo de cómo hacerlo:

Dnscmd /zoneexport contoso.com export.dns

Este commando va a crear un archive llamado “export.dns” debajo de la ruta “%SYSTEMROOT%\DNS\” (por ejemplo: “C:\Windows\system32\dns\export.dns”).

Paso 2: Crear un archivo de DNS específico para cada dominio hijo.

Ahora necesitamos dividir nuestro archivo plano “export.dns” en archivos específicos para cada dominio hijo, también es necesario exportar los registros de DNS de los dominios hijo hacia el archivo correspondiente.

Aquí hay un ejemplo del contenido del archivo “export.dns”:

…

MyComputer1234.child1 [AGE:3606209] 1200 A 172.2.3.4

MyComputer5678 [AGE:1782367] 1200 A 172.5.6.7

MyComputer90AB.child2 [AGE:2457912] 1200 A 172.9.0.1

MyComputerCDEF.child2 [AGE:1982627] 1200 A 172.10.11.12

…

Debemos analizar el archivo “export.dns” a fin de filtrar los registros de DNS correspondientes a los dominios hijo y crear un nuevo archivo de DNS específico para cada dominio hijo.

En el ejemplo anterior, deberíamos extraer la siguiente información para el dominio “child1.dns”:

…

MyComputer1234 [AGE:3606209] 1200 A 172.2.3.4

…

Deberíamos extraer la siguiente información para el dominio “child2.dns”:

…

MyComputer90AB [AGE:2457912] 1200 A 172.9.0.1

MyComputerCDEF [AGE:1982627] 1200 A 172.10.11.12

…

Noten que el registro “MyComputer1234.child1” del archivo “export.dns” debe ser convertido a “MyComputer” (sin “.child1”) cuando sea copiado hacia el archivo “child1.dns” (y lo mismo se debe tener en cuenta para los registros en child2). Noten también que el registro “MyComputer5678” del archivo “export.dns” es un registro presente directamente en el dominio raíz “contoso.com” y no debe ser copiado hacia ningún archivo de DNS de los dominios hijo.

He creado un script de ejemplo que puede extraer y convertir automáticamente dichos registros de DNS y exportar el resultado en los archivos “child.dns”. Por favor tomen en cuenta que este script es provisto como ejemplo y no tiene soporte de parte de Microsoft. Aquí hay un ejemplo de cómo usarlo:

.\Extract-DNSZone.PS1 -inputFile “C:\Scripts\export.dns” -outputFile “C:\Scripts\child1.contoso.com.ns” -extractZoneName "child1"

Pueden repetir esta operación para cada dominio hijo.

Paso 3: Importar las zonas de DNS de los dominios hijo

Ahora deberíamos tener un archivo de DNS específico para cada zona de cada dominio hijo (generada en el paso previo).

Es necesario importar estos archivos de los dominios “hijo” al servidor DNS. Primero hay que copiar dichos archivos al folder “%SYSTEMROOT%\DNS\” (por ejemplo: “C:\Windows\system32\dns\”).

Entonces hay que abrir la consola de administración de DNS. Dar clic derecho en “Forward Lookup Zones” y seleccionar “New Zone…”.

Dar clic en “Next”, después seleccionar “Primary zone” y asegurarse de que la opción “Store the zone in Active Directory” no este seleccionada (porque queremos cargar la zona desde un archivo) y dar clic en “Next”.

Introducir el nombre de la zona correspondiente al dominio hijo que vamos a importar (por ejemplo: child1.contoso.com) y dar clic en “Next”.

Seleccionar la opción “Use this existing file” y verificar que el nombre corresponda al nombre del archive de DNS del dominio hijo que vamos a importar, después de lo cual, dar clic en “Next”.

Seleccionar “Do not allow dynamic updates” (no queremos permitir las actualizaciones dinámicas mientras nuestro proceso de migración no haya terminado) después dar clic en “Next” y luego dar clic en “Finish”. Las actualizaciones dinámicas pueden habilitarse al final del proceso de migración de nuestras zonas de DNS.

Es necesario repetir esta operación para cada uno de los dominios hijo. Ahora, desde la consola de administración de DNS, deberían verse el dominio raíz y los dominios hijo con zonas de DNS independientes.

Paso 4: Replicar las zonas de DNS de los dominios hijo hacia todos los servidores de DNS en el bosque

En este paso, vamos a habilitar la replicación de las zonas de DNS de los dominios hijo hacia todos los servidores de DNS en el bosque. El alcance de replicación de cada zona se puede cambiar a “domain wide” al final del proceso de migración de nuestras zonas de DNS.

Desde la consola de administración de DNS, dar clic derecho en una de las zonas de DNS de un dominio hijo y abrir las propiedades de la zona.

Dar clic en el botón “Change” que esta junto al texto “Type: Primary”. Habilitar la opción “Store the zone in Active Directory” y dar clic en “OK”. Dar clic en “Yes” cuando solicite confirmación para integrar la zona a Directorio Activo.

A continuación, dar clic en el botón “Change” que aparece junto al texto “Replication: All DNS servers in this domain”. Seleccionar la opción “To all DNS servers running on domain controllers in the forest” y dar clic en “OK”.

He aquí un resumen de la configuración que deberían tener:

Dar clic en “OK” y repetir este mismo procedimiento para cada una de las zonas de los dominios hijo.

Paso 5: Restaurar las ACL (listas de control de acceso) de los registros de DNS

Ahora necesitamos restablecer los permisos (ACL) de los registros de DNS. Esto es especialmente importante si quieren configurar las actualizaciones dinámicas de DNS de forma segura. Cuando las actualizaciones dinámicas de DNS son configuradas como “seguras”, el servidor de DNS revisará las ACL de los registros de DNS para verificar si el servidor miembro del dominio tiene los permisos para modificar un registro de DNS en particular.

Desafortunadamente, el comando “DNSCMD /zoneexport” no exporta la información de las ACLs. Por eso es necesario que copiemos las ACLs de los registros desde la “vieja” zona del dominio raíz hacia el registro DNS correspondiente en la nueva zona de DNS del dominio hijo. Una vez más, he creado un script de ejemplo para realizar esto. Este script require del modulo de PowerShell para Directorio Activo, el cual puede ser instalado como una característica opcional de Windows Server (Optional Features) o puede ser instalado en un cliente Windows como parte de las herramientas de administración remota (Remote Server Administration Tools). Por favor tomen en cuenta que este script es provisto como ejemplo y no tiene soporte de parte de Microsoft. Aquí hay un ejemplo de cómo utilizarlo:

.\Copy-DNSACL.ps1 -SourceZoneDN "DC=contoso.com,CN=MicrosoftDNS,DC=ForestDnsZones,DC=contoso,DC=com" -TargetZoneDN "DC=child1.contoso.com,CN=MicrosoftDNS,DC=ForestDnsZones,DC=contoso,DC=com" -TargetDNSZoneShortName "child1"

Aquí hay un ejemplo del resultado del script:

Hay que repetir este paso para cada una de las zonas de los dominios hijo. Ahora, si observan en el tab de “Security” de las propiedades de un registro de DNS, podrán ver que el servidor miembro del dominio tiene control total (full control) sobre sus registros.

Paso 6: Habilitar nuevamente las actualizaciones dinámicas

Su el ambiente en que están trabajando utiliza actualizaciones dinámicas es momento de volver a habilitarlas. Para lo anterior hay que ir al tab “General” de las propiedades de la zona de DNS del dominio hijo y seleccionar “Secure only” o “Nonsecure and secure” del combo que esta junto al texto “Dynamic Updates” (si no estan seguros, pueden usar la misma configuración que tiene la zona de DNS raíz).

Paso 7: Limpiar los registros de DNS “viejos” y delegar las zonas de DNS de los dominios hijo

Antes de limpiar los registros de DNS viejos, deben asegurarse de:

- Tener un respaldo de la “vieja” zona de DNS y ser capaces de recuperarla.

- Que la resolución de DNS este trabajando apropiadamente tanto para los registros de la zona raíz, como para los registros de las zonas de DNS de los dominios hijo.

- Que las actualizaciones dinámicas esten trabajando adecuadamente.

- Que no se haya identificado ningún problema hasta ahora.

Para limpiar los registros viejos, hay que abrir la consola de administración de DNS y expandir la “vieja” zona de DNS del dominio raíz. (¡Asegúrense de que no vayan a borrar la nueva zona de DNS del dominio hijo!) Dar clic derecho en la sub zona “child1” bajo la zona raíz y seleccionar “Delete”.

Ahora la sub zona “Child1” ha desaparecido de las “sub zonas” debajo de “contoso.com”, pero la nueva zona “child1.contoso.com” aún está presente como una zona de DNS independiente.

Para que los servidores de DNS que hospedan la zona “contoso.com” pero que no hospedan la zona “child1.contoso.com” sean capaces de resolver esta última, es necesario crear una delegación para la zona “child1” desde la zona “contoso.com”. Para lo anterior, dar clic derecho sobre la zona “contoso.com” y seleccionar “New delegation…”.

Dar clic en “next” y digitar el nombre del dominio hijo (por ejemplo: child1) y dar clic en “Next”.

De la lista que aparece en la pantalla “Name Servers”, agregar todos los servidores que están hospedando la zona “child1.contoso.com” (esta podría ser una lista larga, dependiendo del tamaño del ambiente en el que estén trabajando), después dar clic en “Next” y dar clic en “Finish”.

Ahora se puede ver “child1 como una delegación de “contoso.com” en la consola de administración de DNS.

Es necesario repetir esta operación para cada uno de los dominios hijo. Al final, en la consola de administración de DNS se debe ver algo como esto:

¡Buen trabajo! ¡el proceso de migración ha finalizado! Ahora ya se puede cambiar el alcance de replicación para las zonas de los dominios hijo si lo desean. Como ultima tarea deben revisar que la lista de los registros NS sea coherente para todas las zonas de DNS. También pueden considerar volver a habilitar las opciones de “Aging” y “Scavenging” para estas nuevas zonas si así lo desean.

12-6-13- Puedes encontrar los scripts en el repositorio de TechNet. 

http://gallery.technet.microsoft.com/scriptcenter/Copy-ACL-of-DNS-records-97837128

http://gallery.technet.microsoft.com/scriptcenter/Extract-a-specific-DNS-dc633d77

-Pierre Ricca

Unos meses atrás, escribí un post sobre cómo reducir el tamaño del directorio WinSxS y liberar espacio en disco en Windows Server 2012.

A manera de recapitulación, el directorio WinSxS es un gran consumidor de espacio en disco tanto en  servidores como clientes Windows. Junto a las actividades de actualización y con el pasar del tiempo, el directorio WinSxS constantemente aumenta de tamaño.

¿Por qué es esto?

Una de las causas de esto es las actualizaciones de Windows. Para permitir la posibilidad de desinstalar una actualización, todas las versiones previamente instaladas de las actualizaciones de Windows son mantenidas en directorio WinSxS incluso cuando estas son reemplazadas por una versión nueva de la actualización. Esto explica por qué las actualizaciones de Windows consumen mucho espacio y que este aumente continuamente al ser instaladas más y más actualizaciones.

¿Cómo podemos limpiar el directorio WinSxS? Con cada Service Pack lanzado, también damos la opción de realizar una limpieza que elimina todas las versiones anteriores de los archivos actualizados por el Service Pack. Sin embargo, Service Pack 1 fue liberado hace más de 2 años, y no ha habido otro desde entonces. ¿Entonces, piensa en todos esos archivos actualizados por las actualizaciones de seguridad y las revisiones? Hasta hoy, no hemos tenido la capacidad de limpieza de estos archivos.

Pero todo cambia hoy.

Nueva e importante actualización que añade Windows Update Cleanup

Esta mañana, fue lanzada una nueva actualización recomendada. Se puede encontrar aquí.

Esta actualización trae de vuelta algunas de las mismas funcionalidades ya incorporadas en Windows 8 y versiones posteriores. Nos da la posibilidad de purgar las versiones anteriores de los archivos reemplazados por las actualizaciones de Windows.

Nota: Esto se clasifica como una actualización "importante". ¿Qué significa esto para usted? Esto significa que no es una actualización de seguridad crítica, que no debería ser automáticamente instalado o enviada a los clientes esto dependiendo de la configuración de Windows Update, configuración de WSUS u otros programas de administración/gestión de software  producidos por terceros.

Proceso de limpieza de Windows Update

Así que ¿Cómo es este proceso?

Después de instalar la actualización, haga clic en el botón de Start, Search y escriba Disk CleanUp, luego de un clic derecho sobre este y seleccione la opción de ejecutar como Administrador.

En primer lugar, se le pedirá que seleccione la unidad que desea limpiar. Esto sólo es válido para la unidad del sistema operativo. Entonces seleccione C:\.

El utilitario de limpieza de disco analizara y calculara cuánto espacio podrás liberar en ese disco:

Si usted no ejecuta Disk Cleanup como Administrador, en este punto, tendrás que tomar un par de pasos adicionales. Usted necesitará hacer clic en el botón de “Limpieza de los archivos de sistema”.

En ese momento, Disk Cleanup será re ejecutado ahora como Administrador y usted tendrá que repetir los dos primeros pasos. Entonces ahórrate unos clics adicionales y ejecuta el utilitario como administrador desde el inicio.

Si te desplazas a través de la lista de archivos para borrar, verás la nueva opción añadida por esta actualización junto con la cantidad de espacio que puede liberarse con la ejecución. Se llama Windows Update Cleanup. Nótese que se activa de forma predeterminada.

Nota: Si no se encuentra nada que Windows Update Cleanup pueda procesar, esto no se mostrará como una opción.

Nota importante: Después de realizar esta limpieza, puede que usted no pueda desinstalar ninguna de  las actualizaciones actualmente instaladas. Sin embargo, si necesita revertir a una versión anterior, aún lo podrá hacer manualmente.

Si usted se posiciona sobre Windows Update Cleanup, se le presentaran los siguientes datos:

"Windows mantiene copias de las actualizaciones instaladas desde Windows Update, incluso después de instalar la versión más reciente de estas. La limpieza de Windows Update elimina las versiones anteriores de las actualizaciones que ya no son necesarias y están tomando espacio. (Muy probablemente necesitará reiniciar el ordenador)."

Cuando de clic en ok, Disk Cleanup se ejecutara y limpiara los archivos innecesarios en su máquina. En la siguiente imagen se puede ver el Windows Update Cleanup ejecutandose:

Al terminar el Disk Clean Up se cerrara.

En mi experiencia realizando pruebas con esta actualización, no le pedirá que reinicie. Sin embargo, cuando en el siguiente reinicio, observara la pantalla de configuración de las actualizaciones tanto al apagado como al inicio de Windows.

La limpieza toma unos minutos, no se alarme si se no muestra progreso por uno o dos minutos. Cuanto mayor sea la limpieza, más tiempo tomará. Pero incluso en mi máquina con 1,78 GB de archivos para limpiar, esto funcionó en menos de 5 minutos.

La cantidad de espacio que usted ahorrará variará por la máquina, pero aquí hay una captura de pantalla de otro ejemplo:

 ¿Cómo automatizar el proceso de limpieza de las actualizaciones?

Sé que ejecutar el Disk Cleanup en 10.000 clientes no es la idea de un buen momento. ¿Cómo automatizamos esto?

Bueno, lograr esto al principio es un poco incómodo, pero no está mal. Hace falta un poco de trabajo inicial. Se requiere la exportación de unas llaves de Registro y la importación de estas en los clientes. Podemos usar cleanmgr.exe (la versión de línea de comandos del Disk Cleanup) para automatizar la limpieza de Windows Update.

Unos cuantos detalles previos. Bajo la siguiente clave del Registro de Windows, tenemos una lista de todos los plugins o componentes de limpieza de disco relacionados al Disk Cleanup:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\VolumeCaches

Aquí está un ejemplo de lo que parece esta clave del registro en mi cliente de Windows 7 SP1:

Dentro de cada uno de estos componentes, hay un valor llamado StateFlags. Tradicionalmente se establece en un valor de 0 ó 1 en estos. Si es 1, esto causa que dicho componente de Disk Cleanup aparezca seleccionado para su ejecución. Acá les muestro como aparece el plugin de Update Cleanup en mi máquina cliente con Windows 7 SP1:

Con el fin de automatizar el Disk Cleanup usando cleanmgr.exe, tenemos que publicar  un nuevo valor de registro para el ítem StateFlags esto para los componentes queremos automatizar. Entonces, ¿cómo lo hacemos?

Abra la consola de comandos con derechos de administrador y ejecute el siguiente comando:

cleanmgr.exe /sageset:11

11 puede ser cualquier número aleatorio que elegir entre 0 y 65535.

Parecerá que se está ejecutando el Disk Cleanup. Se le preguntara el disco y se presentarán las opciones tal como lo hicimos antes. Cuando el proceso complete, si usted regresa y mira estos complementos en el registro, notará los hubiera que aquellos que configuro tienen ahora un nuevo valor de StateFlags, el cual corresponde a lo que especificó con sageset. Como ejemplo aquí está ese mismo complemento  ahora:

Es importante señalar que ejecutar sageset no realiza la limpieza en sí. Simplemente actualiza la configuración de ese complemento. La limpieza no es realizada hasta que se ejecute el comando que mostraremos más adelante en este artículo.

Ahora que tienes la configuración, usted puede exportar esta clave del registro StateFlags para cada uno de los plugins que desee automatizar e importarlo en sus otros clientes Windows 7 SP1. Sólo asegúrate de exportar la clave de registro StateFlags que recientemente fue añadida por el comando sageset. Este será el que tenga el número que elegiste anexado al final. En la imagen anterior, eso sería StateFlags0011.

Una vez que tienes esta clave exportada, puedes publicar estas entradas mediante una Directiva de Grupo (GPO), archivo tipo BAT u otros medios. La elección es suya.

Después de la importación, entonces puedes iniciar el cleanmgr.exe /sagerun:11 que se ejecutará el mismo proceso de limpieza a través de todos sus clientes.

¡Y voila! ¡Presto! ¡Más espacio libre!

Al igual que las llaves del registro, usted puede publicar una tarea programada que luego ejecute el comando anterior en sus clientes quizás una vez al mes. Sin embargo, no querrá ser tan agresivo y sugiero tener cuidado con la frecuencia de ejecución. Recuerde, después de llevar a cabo esta limpieza, no pueden quitar las actualizaciones de Windows que se hayan aplicado previamente. Claro, aun puede desinstalar las actualizaciones más recientes que se han aplicado después de la limpieza, pero esto podría tomarle todo el camino de regreso al nivel inicial de Service Pack 1. Tampoco deseas que esta tarea programada se ejecute después de aplicar las actualizaciones. Dependiendo de tu horario de parcheo, quizá quieras programar la ejecución de la limpieza uno día o dos antes de aplicación de las nuevas actualizaciones programadas. De forma predeterminada, la opción de ejecutar una tarea programada tan pronto como sea posible después de un reinicio programado no está seleccionado. Esto pues no quieres correr esto inmediatamente después de aplicar nuevas actualizaciones, te aconsejo no marcar esta casilla. Si la configuración anterior se omitiese se lo pierde, deja que la limpieza se ejecute la próxima vez.

Feliz día del Windows Update Cleanup!

Charity “El invierno es la nueva temporada de limpieza de primavera” Shelbourne.

Que tal, Mark y Tom con una serie de artículos que creemos les va a gustar. Siento que la mitad de nuestros posts están construyendo algún tipo de laboratorio. En PFE nos encantan los laboratorios.. Así es como la mayoría de nosotros aprendemos. Configura un  laboratorio, juega un poco con la tecnología y configúrala. Es diversión para todos, cierto?! Estamos empezando a tener más y más peticiones de clientes acerca de cómo empezar con ADFS. Pensamos que podemos iniciar a todos encaminándolos a través del proceso de cómo crear tu propio laboratorio con ADFS.

Configuración Inicial

Primero necesitas tener un Bosque de AD. Si no tienes uno, checa el artículo de Doug Gabbard. http://blogs.technet.com/b/askpfeplat/archive/2013/01/30/no-excuses-you-need-a-lab-for-active-directory-2012.aspx

Antes de comenzar, asumimos que tienes la siguiente configuración:

• Active Directory Forest
• Servidor para ADFS con Windows Server 2012
  • Unido al dominio.
  • Configuración de red valida.

Creando una cuenta de Servicio

ADFS funciona con una cuenta de servicio. Esta necesita ser creada antes de ejecutar la instalación.

Algunas advertencias sobre la cuenta de servicio:

#1: No le muevas a los Service Principal Names (SPN) de ninguna cuenta relacionada con ADFS. El asistente de configuración de ADFS configure automáticamente los Service Principal Names (SPN) correctos en esta cuenta de servicio así que no te preocupes por configurar el SPN.

#2: Asegúrate que el nombre de la computadora física de la granja de ADFS sea igual al nombre del servicio ADFS. Si piensas llamar a tu servicio de ADFS sts.markmorow.com, asegúrate que ninguno de los servidores en la granja tengan este mismo nombre. Si lo haces, inmediatamente tendrás un caso de un SPN duplicad, lo cual prevendrá la autenticación por medio de Kerberos hacia esta granja de ADFS. Aquí hay más información en SPNs duplicados:

http://blogs.technet.com/b/askpfeplat/archive/2012/03/29/the-411-on-the-kdc-11-events.aspx

Para mi ambiente de prueba he creado una cuenta llamada ADFS_SVC y mi servidor se llama ADFS01Corp.

Obteniendo los Certificados

Como lo explico Jasmin en http://blogs.technet.com/b/askpfeplat/archive/2013/07/22/faq-on-adfs-part-1.aspx necesitamos tres certificados para ADFS. Pero en realidad, solo se necesita uno para la instalación. Se necesita un certificado para comunicaciones de servidor (SSL). Tenemos tres opciones: [DG1] [MM2] [MM3] 

1.)    Puedes obtener un certificado firmado públicamente. Como este ambiente es de pruebas tal vez no quieras pagar por uno.

2.)    Puedes generar un certificado auto-firmado (self-signed). Aquí hay una Buena guía en como hacerlo. http://www.sslshopper.com/article-how-to-create-a-self-signed-certificate-in-iis-7.html

3.)    Puedes requerir un certificado desde tu PKI interna. Tienes PKI interno verdad??? http://social.technet.microsoft.com/wiki/contents/articles/4797.ad-cs-and-pki-step-by-steps-labs-walkthroughs-howto-and-examples.aspx

Yo escogí el #3. Solo utilice un par de horas y pude configurar PKI en mi laboratorio. Las guías son muy fáciles de seguir. No tengas miedo.

 Primero necesitamos solicitar un certificado. Hacemos eso desde la consola MMC y agregamos certificados para la cuenta de computadora, Equipo local, clic derecho – Personal, Todas las tareas, solicitar Nuevo certificado.

 Seleccionamos Active Directory Enrollment Policy Y hacemos clic en siguiente.

Si no aparece Web Server, asegúrate que tu plantilla de Web Server este publicad y tengas permisos. Como se puede ver necesitamos configuración adicional. Haz clic en el texto azul.

El nombre de nuestro certificado será STS.tudominio.com. Obviamente configure el nombre de acuerdo tus necesidades. Haz clic en OK y finaliza el proceso de certificados.

Instalación de ADFS

OK ahora que tenemos todos nuestros pre-requisitos vamos a hacer la instalación de ADFS.

Empecemos por agregar el rol de ADFS desde Server Manager.  Clic en Siguiente.

 Esto agregara muchos otros roles y característica adicionales que son necesarios. Haz Clic en siguiente en esta pantalla hasta que llegues a los servicios de ADFS.

Después de dar siguiente en algunas pantallas llegaras a esta ventana. Después hablaremos del proxy ADFS, pero por ahora solo dejaremos el “Federation Service” seleccionado. Continua dando clic en siguiente hasta llegar a Finalizar y después permite que la instalación termine.

 Veras un signo de exclamación Amarillo  en la parte superior derecha que te avisara que hay configuraciones adicionales que hacer. Haz clic en “Run the AD FS Management snap-in”

Esto abrirá la consola de ADFS para terminar la configuración. Haz clic en “ADFS Federation Server Configuration Wizard”

Dado que este es nuestro primer servidor de ADFS vamos a  seleccionar “Create New Federation Service”  y después hacer clic en Siguiente.

Estaremos creando una granja de un solo servidor. Clic en siguiente.

ADFS debería de tomar el certificado del servidor automáticamente. Hacemos clic en siguiente.

Escribe la cuenta de servicio que creamos previamente y haz clic en siguiente. La instalación debería de iniciar.

Todo listo. Ahora vamos a configurar la base de datos WID. Si quieres usar una base de datos SQL tienes que hacer la instalación desde la línea de comandos. En la segunda parte de esta serie hablaremos de como configurar un “relaying party” y una aplicación web para ver los claims.

Mark “Next, Next” Morowczynski, Tom “Finish” Moser 

Hola a todos! Roger Osborne con una actualización a mi artículo Mejores Prácticas de Hyper-V (artículo original: Hyper-V Best Practices para Server 2012.

Han pasado cerca de 7 meses desde el articulo inicial, y puedo decir que la respuesta ha sido (y sigue siendo) SOR-PREN-DEN-TE!

En mi humilde opinión, el interés alrededor de mi artículo apunta directamente a negocios pequeños, medianos y grandes (Empresas) que utilizan Hyper-V como su solución de virtualización! Hyper-V no solamente ha probado ser una solución a nivel de empresas en datacenters alrededor del mundo, también ha sido probado ser una solución económica para reducir la marca de los servidores físicos en ambientes empresariales.

Tener un gran producto no quiere decir que puedes dormir en tus laureles (proverbio J), sin embargo como algunos de ustedes saben Microsoft libero Windows Server 2012 R2, esta versión incluye características IMPRAIONANTES especificas a Hyper-V!

He aquí algunas de mis favoritas:

• Live Migration, ha sido mejorado, lo cual reduce enormemente el tiempo para migrar VMs de un nodo a otro utilizando compresión.
• La habilidad de cambiar de tamaño un VHDX que está conectado a una VM en ejecución.
• Live Migration entre versiones, nos habilita para mover VMs fácilmente desde un host Hyper-V 2012 a otro Host Hyper-V con 2012 R2.
• Activación automática de VMs, que más puedes pedir además de activar automáticamente las VMs ejecutándose en la versión datacenter de Hyper-V!?
• Y por último, un nuevo Servicio de integración que nos  permite copiar archivos desde una VM R2/8.1 hacia el host R2 SIN NECESIDAD de una conexión de red! Esto es espectacular en el mundo de Roger, mis amigos!

Para una lista completa de actualizaciones y nuevas características, revisa el siguiente artículo: http://technet.microsoft.com/en-us/library/dn282278.aspx

Con todas las mejoras en R2 pensarías que habría algunas mejoras o cambios a mi artículo Windows Server 2012 Hyper-V Mejores prácticas (Best Practices) (En formato de lista), pero no es así; lo cual son buenas noticias para ti!! Si ya seguiste las recomendaciones provistas en mi blog, puedes simplemente llevar esas mismas prácticas hacia Hyper-V en Windows server 2012 R2!

La única adición que hice al artículo –relacionada a las características nuevas/mejoradas de R2 – son las siguientes:

⎕ (Nueva Característica) Disco Virtual compartido: No utilices un disco VHDx compartido para el sistema operativo. Los Servidores deben de tener un disco virtual VHDx único (para el SO) que solo ellos puedan acceder. Discos virtuales compartidos son mejor utilizados como discos de datos y como discos testigo en un clúster.

Para más información:

http://blogs.technet.com/b/meamcs/archive/2013/10/03/windows-server-2012-r2-preview-hyper-v-shared-vhdx-and-storage-qos.aspx

http://technet.microsoft.com/en-us/library/dn265980.aspx

Otros cambios y actualizaciones (no especificas para R2) han sido hechas al post durante los últimos meses, si puedes tomar unos minutos y revisa el articulo actualizado.  Tomate la libertad de dejar un comentario si tienes una pregunta o sugerencia.

http://blogs.technet.com/b/askpfeplat/archive/2013/03/10/windows-server-2012-hyper-v-best-practices-in-easy-checklist-form.aspx

Mientras tengo tu atención, has oído acerca de la aplicación en Windows 8.x llamada Posterpedia? Si no, te al recomiendo! La última versión incluye un poster genial para Hyper-V en Server 2012. Recomendado!

También, Microsoft está ofreciendo capacitación y certificaciones para Hyper-V GRATIS!! Revisa estos artículos para más información:

http://blogs.technet.com/b/in_the_cloud/archive/2013/10/29/microsoft-wants-to-help-vmware-experts-future-proof-their-career.aspx

http://www.virtualizationsquared.com/#section-intro

Así que dime: Cuál es tu característica favorita en R2? Me encantaría saber de ti, agrega tus comentarios más abajo!

Sinceramente espero que encuentres este articulo útil! Si es así, por favor envía el enlace a quien lo pueda necesitar!

Hasta la próxima,

Roger “best practicing” Osborne, Microsoft PFE

Como seguimiento al reciente artículo sobre la auditoria para eliminaciones DNS, aquí les tenemos un poquito sobre prevención.

Compañeros nuestros, nuestros pares en otras áreas y muchos otros han cubierto esto pero decidimos igual proporcionar nuestro propio aporte a forma de seguimiento lógico al artículo previamente mencionado sobre auditoría en DNS.

Aquí las ligas a algunos de otros valiosos artículos:

• De AskDS: http://blogs.technet.com/b/askds/archive/2013/06/04/two-lines-that-can-save-your-ad-from-a-crisis.aspx
• De Eric Jansen: http://cbfive.com/blog/post/Protecting-DNS-Zones-from-Accidental-Deletion.aspx  

Empecemos…  

Para zonas DNS en la partición de dominio:

Usted puede usar la consola de “Active Directory Users and Computers” para acceder a uno de los mejores “checkboxes” en la historia de AD… o, igual se puede usar powershell (¡¡¡obviamente!!! J):

Las zonas en las particiones de aplicación Domain-Wide y Forest-Wide son almacenadas en algún otro lugar dentro de AD:

Para proteger estas zonas hacemos uso de powershell para habilitar lo equivalente a la opción “Protect object from accidental deletion”, dado que esto no se puede acceder todavía desde ninguna interfaz gráfica (hey Grupo de Producto, ¿cachaste ésta petición? J)

Partición de aplicación Domain-wide

Para enumerar todas las zonas dns vulnerables en una “cajita” gráfica:

Get-ADObject -Filter 'ObjectClass -like "dnszone"' -SearchScope Subtree -SearchBase “DC=DomainDnsZones,DC=domain,DC=lab" -properties ProtectedFromAccidentalDeletion | where {$_.ProtectedFromAccidentalDeletion -eq $False} | Select name,protectedfromaccidentaldeletion | out-gridview

Para protegerlas:

Get-ADObject -Filter 'ObjectClass -like "dnszone"' -SearchScope Subtree -SearchBase “DC=DomainDnsZones,DC=domain,DC=lab" -properties ProtectedFromAccidentalDeletion | where {$_.ProtectedFromAccidentalDeletion -eq $False} | Set-ADObject –ProtectedFromAccidentalDeletion $true

Para checarlas:

Get-ADObject -Filter 'ObjectClass -like "dnszone"' -SearchScope Subtree -SearchBase “DC=ForestDnsZones,DC=domain,DC=lab" -properties ProtectedFromAccidentalDeletion | where {$_.ProtectedFromAccidentalDeletion -eq $True} | Select name,protectedfromaccidentaldeletion | out-gridview

Partición de aplicación Forest-wide

Para enumerar todas las zonas dns vulnerables en una “cajita” gráfica:

Get-ADObject -Filter 'ObjectClass -like "dnszone"' -SearchScope Subtree -SearchBase “DC=ForestDnsZones,DC=domain,DC=lab" -properties ProtectedFromAccidentalDeletion | where {$_.ProtectedFromAccidentalDeletion -eq $False} | Select name,protectedfromaccidentaldeletion | out-gridview

Para protegerlas:

Get-ADObject -Filter 'ObjectClass -like "dnszone"' -SearchScope Subtree -SearchBase “DC=ForestDnsZones,DC=domain,DC=lab" -properties ProtectedFromAccidentalDeletion | where {$_.ProtectedFromAccidentalDeletion -eq $False} | Set-ADObject –ProtectedFromAccidentalDeletion $true

Para checarlas:  

Get-ADObject -Filter 'ObjectClass -like "dnszone"' -SearchScope Subtree -SearchBase “DC=ForestDnsZones,DC=domain,DC=lab" -properties ProtectedFromAccidentalDeletion | where {$_.ProtectedFromAccidentalDeletion -eq $True} | Select name,protectedfromaccidentaldeletion | out-gridview

Partición de dominio (legacy)

Para enumerar todas las zonas dns vulnerables en una “cajita” gráfica:

Get-ADObject -Filter 'ObjectClass -like "dnszone"' -SearchScope Subtree -SearchBase “CN=MicrosoftDNS,CN=System,DC=domain,DC=lab" -properties ProtectedFromAccidentalDeletion | where {$_.ProtectedFromAccidentalDeletion -eq $False} | Select name,protectedfromaccidentaldeletion | out-gridview

Para protegerlas:

Get-ADObject -Filter 'ObjectClass -like "dnszone"' -SearchScope Subtree -SearchBase “CN=MicrosoftDNS,CN=System,DC=domain,DC=lab " -properties ProtectedFromAccidentalDeletion | where {$_.ProtectedFromAccidentalDeletion -eq $False} | Set-ADObject –ProtectedFromAccidentalDeletion $true

Para checarlas:

Get-ADObject -Filter 'ObjectClass -like "dnszone"' -SearchScope Subtree -SearchBase “CN=MicrosoftDNS,CN=System,DC=domain,DC=lab " -properties ProtectedFromAccidentalDeletion | where {$_.ProtectedFromAccidentalDeletion -eq $True} | Select name,protectedfromaccidentaldeletion | out-gridview

Nota:  Si se requiere eliminar alguna de estas zonas en el futuro lo único que habría de hacer es cambiar el atributo ‘ProtectedFromAccidentalDeletion’ a FALSE with PowerShell:

Set-ADObject “DC=DOMAIN_APP_PARTITION.COM,DC=DomainDnsZones,DC=domain,DC=lab" protectedFromAccidentalDeletion $False 

Bueno, ahora que ya tiene usted un poco más de recursos de ayuda… ¡¡¡es hora de ir y proteger su DNS!!!

Hola, soy Joao Botto y durante los últimos cuatro años he estado enfocado en el sistema operativo Windows para cliente. Trabajé en Europa durante el lanzamiento de Windows 7 y después me mudé a Estados Unidos para trabajar en Windows 8 y 8.1. Así que este es un día muy especial para mí –este es mi primer post en AskPFEplat y es de Windows 8.1 GA (http://windows.microsoft.com/en-us/windows/home).

Durante el último año, he soportado docenas de implementaciones de Windows 8 y he estado observando de primera mano cómo los cambios relacionados con el botón/menú de inicio en Windows 8 hacen sentir incomodos a algunos usuarios. Por supuesto, en IT, como en todo, el cambio es inevitable y como humanos, somos fácilmente adaptables :)

En Windows 8.1, el Botón de Inicio está de vuelta – pero no el clásico menú de Inicio. En este post, Mike Hildebrand y yo presentamos un par de soluciones que deberían ayudar a los usuarios tradicionales de mouse y de teclado (como nosotros) a sentirse más cómodos con la interfaz gráfica del sistema operativo Windows 8.1.

Primero, les mostraremos como ajustar la “experiencia” de inicio en dos  “sabores” diferentes y luego discutiremos como pueden desplegar/personalizar los parámetros de la pantalla de inicio a través de su ambiente.

Con estos trucos, les mostraremos como establecer una experiencia que es similar en funcionamiento al clásico botón/menú de inicio de Windows 7. Una vez que se acostumbre a los cambios, podemos predecir que se encontrará trabajando de manera más eficiente con la pantalla de inicio 8.1 visualmente más rica y más escalable.

Los usuarios típicamente instalan muchas, muchas aplicaciones durante el ciclo de vida de un PC. El resultado de esto era a menudo un Menú de Inicio que se expandía en múltiples filas o “carpetas”. La navegación en él, con el mouse cada vez se hacía más difícil para los usuarios a medida se instalaban más y más aplicaciones. También, el icono más común para las aplicaciones era una “carpeta” el cual lo hacía un poco estático visualmente y la personalización estaba limitada ya que debían estar todos alineados. La pantalla de inicio permite “Tiles” de variados colores, tamaños e iconos y nos permite organizarlos en el “espacio”.

Vista: Todas las Aplicaciones

La primera Vista que cubriremos es la que denominamos la Vista “Todas las Aplicaciones”.

El primer paso es cambiar de la Pantalla de Inicio por defecto a la Vista de Aplicaciones. Esto se realiza en “Propiedades de la barra de tareas y navegación”

• Clic derecho en la barra de tareas y seleccionar “Propiedades”, después seleccionar la pestaña “navegación”.
• Seleccionar “Mostrar la vista Aplicaciones automáticamente al ir a Inicio”

Ahora, en lugar de la pantalla de Inicio, vemos la siguiente pantalla que muestra todas las aplicaciones instaladas cuando iniciamos sesión:

También podemos elegir el orden de la clasificación de las aplicaciones…

Aquí seleccionamos mostrar los usados con mayor frecuencia primero – esto lo hará “sentir” más como Windows 7. 

Fondo de escritorio en Inicio

En Windows 8.0, cuando cambio a la pantalla de Inicio desde el escritorio, se produce un “switch” visualmente dramático a una pantalla completamente diferente.

En 8.1, tenemos más opciones. Podemos hacer que los iconos de la pantalla de inicio realicen una especie de “overlay” en el papel tapiz del escritorio en lugar de ser devuelto a una pantalla completamente separada.

Con esto habilitado, cuando cambiamos a la pantalla de Inicio, es mucho menos dramático el cambio/flash visual.

Para esto, seleccione: “Mostrar mi fondo de escritorio en Inicio”

Ahora, el escritorio hara la transision mas suavemente de esto…

…. A esto ( y de vuelta).

 Vista: Grupos de Aplicaciones

Para un diseño alternativo, donde agrupemos un set específico (o sets) de aplicaciones juntos, escogemos los siguientes parámetros…

Ahora, usted puede fijar lo que usted quiera en la pantalla de Inicio. Usted puede personalizar el orden, tamaño, agrupado y ubicación de sus iconos. Usted también puede hacer clic derecho en el fondo de la pantalla de Inicio, clic en “Personalizar” y definir nombres para sus grupos de aplicaciones…

• En la siguiente pantalla de Inicio, he fijado mis aplicaciones de trabajo primarias y algunas herramientas secundarias y aplicaciones que se encuentran comúnmente en el menú de Inicio de Windows 7 y personalice los iconos para ayudar a que mi trabajo sea más eficiente:
• Mis Documentos
• Varias Herramientas/Consolas administrativas (Hyper-V, RDP – hay una buena nueva aplicación moderna de RDP que pueden encontrar en la Tienda)
• Panel de Control
• Windows Update
• Dispositivos e Impresoras

Aquí nuevamente, cuando usted pasa del escritorio a la pantalla de inicio y vuelve de nuevo, hay una transición muy suave entre los dos…

Arranque en el Escritorio

En conjunto con nuestra elección de tema, si usted lo desea, puede escoger arrancar o iniciar sesión directamente en el escritorio en lugar de la pantalla de Inicio.

Algunos prefieren arrancar en la pantalla de inicio y comenzar con los iconos/Tiles, otros quieren ir directo al Escritorio. Podemos darnos el lujo de darles a los usuarios la flexibilidad de usar cualquier manera.

Configuración Centralizada

Ahora – cómo configurar centralizadamente esto?

Así como la mayoría de las configuraciones de Windows, podemos aprovechar las Políticas de Grupo y/o las Preferencias de las políticas de Grupo para controlar las configuraciones del Sistema Operativo. Windows 8/8.1 no es diferente.

Acá está la Politicapara mostrar la vista de Aplicaciones en lugar de la pantalla de Inicio (esta puede ser configurada localmente o vía GPOs de Dominio):

Sin embargo, tener la opcion de el fondo de pantalla en la pantalla de Inicio es una decisión “por usuario” y no puede ser expuesta via GPO.

Esta solo puede ser cambiada manualmente por el usuario a través de la siguiente llave de registro:

• Subkey: HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Accent
• Entrada: MotionAccentId_v1.00
• Tipo: REG_DWORD
• Values:
• Chequeado/mostrar mi fondo de escritorio en el Inicio: 219 (decimal)
• No chequeado/No mostrar mi fondo de escritorio en el Inicio: 221 (decimal)

 Afortunadamente, distribuir esta llave de registro se puede facilitar mediante el poder de las Preferencias de las Políticas de Grupo:

Detalles adicionales y PODER!

Para algunos detalles adicionales acerca de establecer una pantalla de Inicio personalizada “estándar” para los usuarios, consultar la siguiente sección de la librería de TechNet y los buenos post del blog de nuestros “Deployment Guys” usando MDT para despliegues empresariales:

• http://technet.microsoft.com/en-us/library/dn467928.aspx
• http://blogs.technet.com/b/deploymentguys/archive/2012/10/26/start-screen-customization-with-mdt.aspx  

Una nota más acerca del botón de Inicio,  la pantalla de Inicio y la experiencia del escritorio en 8.1 – Apagado y Reinicio.

Estos eran un poco los puntos sensibles en Windows 8.0 y muchas personas crearon sus propios accesos directos/Tiles para la pantalla de Inicio (Incluyéndome).

Sin embargo, en Windows 8.1, presionando la tecla de Windows + X se despliega un menú (o haciendo clic derecho en el botón de inicio) que provee estas opciones desde el escritorio. Yo ya no utilizo los Tiles Apagar/Reiniciar de mi pantalla de Inicio, así que los eliminé.

Dejenos saber via los comentaros como van con la personalizacion de su pantalla de Inicio 8.1 y los elementos asociados.

De Hilde y Joao, Feliz día Windows 8.1 GA y como dicen en Portugal – até ja!

Hola, este es otro post por Venkat Kalyanasundaram de IPv6 para todos.

Ya discutimos en el post anterior IPv6 para el Administración en Windows: ¿Cómo funciona la resolución de nombres en un escenario IPv4/IPv6? y se discutió sobre el comportamiento cuando se utiliza un rango de direcciones IP privadas. Hoy vamos a hablar de un escenario especial cuando se tiene rangos de direcciones IPv4 públicas en nuestra red interna. Vamos a empezar.

Repaso Rapido

Los siguientes tres bloques de direcciones IPv4 en el mundo son tratados como direcciones privadas. En resumen, estas direcciones no pueden ser utilizadas por enrutadores para tráfico de Internet y se pueden implementar dentro de la red corporativa para el tráfico de Intranet. Si usted tiene la paciencia y el tiempo para leer RFC, puede obtener más información sobre este tema en los siguientes enlaces.

http://www.faqs.org/rfcs/rfc1918.html.

10.0.0.0 - 10.255.255.255 (10/8 prefijo)

 172.16.0.0 - 172.31.255.255 (prefijo 172.16/12)

 192.168.0.0 - 192.168.255.255 (prefijo 192.168/16)

Si has implementado el rango de direccionamiento IPv4 que no sea uno de los tres bloques de direcciones anteriores, entonces probablemente se utilizó unas direcciones públicas. Si bien no es común para utilizar rango público de direcciones IPv4 en la red interna, la gente todavía puede hacerlo por varias razones. Técnicamente no hay nada que pueda impedir el utilizar  rango público de direcciones IPv4 en la red interna.

Si tu eres una de las personas que habían utilizado rango público de direcciones IPv4 en la red interna, esto te podrá parecer interesante y servir de ayuda.

Dual Stack Comportamiento predeterminado y las direcciones de túnel 6to4

Las máquinas de Windows (con dual stack habilitado para IPv4 e IPv6) que son configuradas con un rango publico de IPv4 (131.107.xy por ejemplo) en su red, tendrá un comportamiento por defecto para generar direcciones de túnel 6to4.

Si usted se está preguntando cuál es la dirección de un túnel 6to4, entonces usted necesita entender los conceptos tecnológicos de transición con IPv6. Discutido de forma rápida, esto quiere decir - Básicamente un paquete de túnel IPv6 dentro del marco de IPv4 en una red que solo soporte IPv4. Hay diferentes tipos de mecanismo disponibles para crear túneles (ISATAP, 6to4 y Teredo) dependiendo del tipo de redes IPv4 involucrados. Si usted está interesado en aprender más sobre las tecnologías de túnel de IPv6, puede obtener la información de este enlace.

Technet

http://technet.microsoft.com/en-us/library/bb726951.aspx

Veamos esto con un ejemplo. Una máquina de Windows se configura a partir de un rango de direcciones IPv4 públicas 131.107.23.20 como se muestra en el resultado del comando IPCONFIG arriba. Supongamos IPv6 también está habilitado y no hay una dirección IPv6 global configurado para esta máquina. El comportamiento predeterminado en Windows es, generar la dirección del túnel 6to4 y en este caso se configura en la sección del Adaptador.

La dirección de túnel 6to4 siempre comienza con un 2002. Los dígitos restantes 836b: 1714 se genera en función de la dirección IPv4 configurada en la máquina y también se repite en la parte del ID de interfaz. Se trata básicamente de la representación hexadecimal de los valores de direcciones IPv4. Si se convierte el dígito decimal 131 en un valor hexadecimal, es 83, 107 se convierte a 6B hexadecimal y así sucesivamente. Como mencioné anteriormente, si usted quiere saber más acerca de cómo las tecnologías de túneles trabajan, revisar el los enlaces en el  technet http://technet.microsoft.com/en-us/library/bb726951.aspx

Impacto en el mundo real y Active Directory

Con la generación automática de la dirección del túnel 6to4, veamos ahora el impacto que crea. Una dirección 6to4 es tratada como una dirección IPv6 normal y queda registrado en el DNS como registros AAAA con actualizaciones dinámicas habilitadas a nivel de DNS. Con ambos registros AAAA y A registrados entre dos equipos con Windows, el comportamiento predeterminado en Windows es tratar de comunicarse a través de IPv6. (De acuerdo con el comportamiento de resolución de nombres que hemos hablado en el blog anterior y se explica en el diagrama anterior). La red sigue funcionando por que la direccion 6to4 se envia a traves del tunel dentro de un paquete IPV4 y se transmite como trafico IPv4 por medio de la red inmediata como enrutadores, etc.

La mayoría de las personas no se dan cuenta que el comportamiento anterior está ocurriendo en su red cuando utilizan un rango público IPv4 en las máquinas de Windows. Ellos se sorprenden al ver los registros AAAA en DNS, como se muestra en la imagen de arriba muestra AAAA y registros A para la máquina con 6to4 habilitada. También tienden a olvidar como definir la asociación equivalente en la subred / site IPv6 en Active Directory (Consulte la imagen siguiente para la consola MMC Sites and Services)

 Por lo tanto el impacto real - aquí usted comienza a tener problemas de rendimiento a nivel de Active Directory porque los clientes Windows están tratando de comunicarse a través de IPv6 (dirección túnel 6to4) y no tienen ninguna subred / sitios definidos en Active Directory IPv6. Por lo que podría terminar en escenarios como - cliente Windows está tratando de autenticar con un controlador de dominio en el sitio remoto (aunque hay un DC disponible en el sitio local) o cualquiera de los servicios como DFS o aplicaciones que se basa en la configuración de costos en AD puede encontrar problemas de rendimiento.

La siguiente pregunta lógica es ¿cómo puedo deshabilitar la generación automática de la dirección del túnel 6to4 en el caso que discutimos anteriormente con un ejemplo?

Forma correcta para desactivación 6to4

Puede usar un GPO “política de grupo” de Windows para deshabilitar el adaptador túnel 6to4 como se muestra en la imagen siguiente. Al desactivar a través de la GPO “política del grupo”, IPv6 se mantiene habilitado pero no se generarán direcciones 6to4. Si desea utilizar la opción “”Disabledcomponents”  debe utilizar la clave del Registro como se menciona en el KB

http://support.microsoft.com/kb/929852

 Como último punto a tener en cuenta, usted no tiene que preocuparse de esto si despliega rangos privados de direcciones IPv4 en la red.

Venkat

Hola, soy Venkat Kalyanasundaram, Senior PFE del área metropolitana de Nueva York.

Como alguien que trabaja constantemente con IPv6, comúnmente veo surgir el mismo conjunto de preguntas una y otra vez. Quiero tomar un poco de tiempo para abordar algunas de las preguntas más comunes y tratar de quitar el misterio de IPv6 de una vez por todas. Este es el primer post de una serie, así que estén al pendiente de las siguientes entregas para conocer más bondades de IPv6.

La primera pregunta que quiero tratar es extremadamente común. ¿Cómo funciona el proceso de resolución de nombres en un escenario de dual stack con Windows? Siendo más específico, nos gustaría saber ¿Cuál es el impacto a nuestro entorno de red cuando se habilita IPv6 en Windows?

Bueno, resolvamos esto de una vez. Como hemos dicho antes, no es recomendable deshabilitar IPv6 en los equipos Windows (En el FAQ de IPv6 para Microsoft Windows pueden revisar la pregunta "¿Cuál es la recomendación de Microsoft sobre deshabilitar IPv6?" para más detalles.)

La clave aquí es tener un entendimiento básico sobre cómo funciona el proceso de resolución de nombres en Windows cuando se habilitan IPv4 e IPv6.

En el mundo de IPv4, estamos acostumbrados a manejar el proceso de resolución de nombres usando Microsoft WINS y DNS. En el mundo de IPv6, WINS ya no importa. En otras palabras, las direcciones IPv6 no se registran en WINS y deben ser manejadas totalmente vía DNS. Una dirección IPv6 es representada como un registro AAAA (cuádruple A) en DNS similar a como se representa una dirección IPv4 como un registro de Host A. El concepto de registro PTR (para resolución de nombres inversa - de dirección IP a nombre de host) también se aplica a las direcciones IPv6 en DNS.

Con IPv4, normalmente estamos acostumbrados a tener registrada en DNS una sola dirección IP para una máquina dada. Con IPv6, tenemos que lidiar con diferentes tipos de direcciones (Link Local, Global etc. como comentaron anteriormente Mark y Ray en su blog http://blogs.technet.com/b/askpfeplat/archive/2013/06/24/ipv6-for-the-windows-administrator-ipv6-fundamentals.aspx). Tengan en cuenta que no todos los tipos de direcciones IPv6 se registran en DNS. Por ejemplo, una dirección Link Local que inicia con FE80: (dirección no enrutable, activa solamente dentro de su subred local) no es registrada en DNS. Mientras que una dirección Global se registra en DNS con un registro AAAA (cuádruple A). Cuando se trabaja con tecnologías de transición, las direcciones de Teredo no se registran en DNS. El artículo de Microsoft Technet Comportamiento del cliente DNS explica este comportamiento a detalle.

Repasemos algunos escenarios de la vida real en donde la red corporativa existente está funcionando casi al 100% con IPv4 y ustedes están tratando de introducir máquinas Windows nuevas con dual stack habilitado (IPv4 e IPv6 activos). Intentaremos averiguar cómo se comunican estas máquinas nuevas con la red existente.

Escenario #1:

Como se puede ver en el diagrama de arriba, tenemos dos máquinas (digamos que son un cliente Windows 7 y un Appserver1 ejecutando Windows 2008/R2) ubicadas en dos subredes diferentes con IPv4 e IPv6 activado (dual stack). Cuando habilitamos IPv6, la dirección Link Local (que inicia con FE80: lo cual puede verificarse con la salida del comando IPCONFIG) se configurará automáticamente en Windows. No vamos a entrar al detalle de cómo es generada de forma automática la dirección Link Local. Ese es un tema que trataremos en una entrega posterior. Vamos a asumir que no hemos configurado ninguna dirección Global de IPv6 ni alguna dirección para tecnologías de transición de IPv6.

El servidor AppServer1 registra su IPv4 en DNS. Como la dirección Link Local de IPv6 no es enrutable y esta confinada a la subred local, no se registra en DNS. En otras palabras, en DNS tenemos un sólo registro Host A para el nombre AppServer1 que apunta a la dirección IPv4 10.1.0.2, aun cuando tenemos habilitado IPv6 en el servidor.

Digamos que el cliente Windows 7 necesita comunicarse con el servidor AppServer1, vamos a ver cómo funcionan las cosas en el background desde la perspectiva de la red y la resolución de nombres. Inicialmente el cliente envía una petición al servidor DNS para resolver el nombre "AppServer1.contoso.com". El servidor de DNS le responde con un registro A apuntando a  la dirección IPv4 10.1.0.2. Entonces el cliente se comunica con el AppServer1 enviándole una solicitud a la dirección IPv4 10.1.0.2. Como se puede ver, la comunicación se sigue estableciendo vía IPv4 aunque tengamos habilitado IPv4 e IPv6 tanto del lado del cliente, como del lado del servidor. No existe impacto al performance de la red. Aun cuando el cliente o el servidor estuvieran configurados solo con una dirección IPv4 (sin dirección IPv6), encontraríamos el mismo comportamiento que acabamos de explicar.

Escenario #2:

Extendamos un poco más el escenario #1. Esta vez, digamos que el cliente está configurado con dual stack (con una dirección IPv4 y una dirección IPv6 Link Local como en el escenario #1), pero esta vez el servidor está configurado con una dirección IPv4 y una dirección IPv6 Global.

En este escenario, el AppServer1 va a registrar en DNS su registro Host A (apuntando a la dirección IPv4 10.1.0.2) y su registro AAAA (para la dirección IPv6 Global). En este caso también se genera la dirección Link Local en el AppServer1, la cual no se registra en DNS.

¿Qué pasará cuando el cliente Windows 7 quiera comunicarse con el AppServer1 en este escenario? El cliente envía una petición al servidor DNS para resolver solo el registro Host A para el nombre AppServer1. El cliente nunca intentará consultar el registro AAAA (aun cuando el servidor DNS tenga el registro AAAA del AppServer1), lo anterior porque el cliente sabe que el solamente tiene configurada una dirección Link Local que no es enrutable. El servidor DNS responde con la dirección IPv4, después de lo cual, el cliente se comunica vía IPv4 similar a como sucedió en el escenario #1.

Escenario #3:

Vamos a asumir que para este escenario, hemos configurado direcciones IPv6 globales, tanto en el cliente como en el servidor. También vamos a asumir que el equipo de redes ha configurado los ruteadores para rutear correctamente las direcciones IPv6. Esto significa que hemos realizado acciones específicas para configurar direcciones IPv6 globales en nuestra red, ya sea manualmente o utilizando el servidor DHCP o incluso desde el ruteador. (Sí, es posible configurar las direcciones IPv6 directamente desde el ruteador... Este tópico se cubre brevemente aquí: http://blogs.technet.com/b/askpfeplat/archive/2013/07/08/ipv6-for-the-windows-administrator-more-ipv6-subnetting-zones-address-autoconfiguration-router-advertisements-and-ipv4-comparisons.aspx)

En este escenario tanto el cliente como el servidor registran en DNS su registro Host A (para su dirección IPv4) y su registro AAAA (para su dirección IPv6 Global). Cuando el cliente Windows 7 intenta comunicarse con el AppServer1 en este escenario, hace la consulta a DNS para resolver el nombre AppServer1. El servidor DNS le responde con el valor del registro A (apuntando a la dirección IPv4) y con el valor del registro AAAA (que apunta a la dirección IPv6 Global) del servidor AppServer1. En este caso, el cliente se comunica con el servidor mediante IPv6. Si ambos registros (A y AAAA) pueden ser resueltos, el comportamiento por default en Windows es tratar de comunicarse vía IPv6.

Recapitulando…

Como puede verse en los escenarios de arriba, el escenario #3 es el único en donde el cliente y el servidor se comunican vía IPv6. En este escenario, los administradores de Windows y de Redes han realizado tareas  específicas para configurar las direcciones IPv6 globales en los ruteadores y en los equipos Windows. Si no se han realizado dichas tareas específicas y se habilita IPv4 e IPv6 en los equipos Windows con la configuración predeterminada, el impacto a la red es mínimo, como se puede constatar en los escenarios #1 y #2.

Como han podido notar en los escenarios anteriores, hemos usado direcciones IPv4 en el rango de direcciones privadas. Si en su red están usando direcciones IPv4 públicas (rangos distintos al 10.x.y.z, 172.16.x.y o 192.168.x.y) hay unas cuantas cosas más que debemos tener en cuenta. En mi próximo post, abordaré estas cuestiones.

Venkat