Hola a todos,

A menudo me encuentro en mis clientes, y en los foros de Microsoft con bastantes consultas relacionadas con las distintas versiones de la familia Windows Server 2012 R2, casi siempre terminamos recurriendo a hacer búsquedas para encontrar esa información, e incluso otras veces desconocemos que la versión de nuestro Sistema Operativo no nos permite instalar un Rol específico, como es el caso de esta consulta del foro: https://social.technet.microsoft.com/Forums/es-ES/8b21b4fd-9343-4331-9574-5165c9d18c67/configuracin-dominioactive-directory-windows-storage-server-2012-r2?forum=wsides

En esta ocasión el problema está que la versión Windows Server 2012 R2 Storage Server tiene entre sus limitaciones que no puede instalarse ninguno de los Roles relacionados con Active Directory, por lo que podéis ver esto puede presentar un serio problema si no hacemos una compra acertada de nuestro SO.

Queda claro que la compra del hardware, y del SO debe ir en base a un análisis previo de que Rol/es va a desempeñar ese servidor en nuestra infraestructura, hay que evaluar los límites de hardware del SO elegido, así como que funcionalidades puede tener, obviamente el precio de la licencia varía en torno a las versiones, pero así evitaremos sorpresas.

Aquí os dejo la Matriz de 2012 R2 Products and Editions de Microsoft, donde podéis consultar tanto los límites de SO, como que Roles y Features admite cada uno de ellos.

2015-04-01_12-02-58

Windows Server 2012 R2 Products and Editions Comparison

 

Salu2!

Daniel Graciá

Hola a todos,

En la entrada de hoy no es que vaya a reinventar la rueda ni mucho menos, pero desde hace años veo cierta confusión a la hora de identificar los distintos grupos de AD, sus funcionalidades, y su alcance.

image

 

Existen muchas referencias en la Web, y en el sitio de Microsoft, sobre los grupos, pero casi nunca queda muy claro, además hay que leer bastante para tener perfectamente clara la manera de trabajar con los grupos de seguridad, las buenas prácticas a la hora de anidarlos, y sobre todo como utilizarlos en entornos de múltiples dominios, y o con relaciones de confianza.

Hoy me quiero centrar sobre todo en la parte relativa a los entornos con relación de confianza, en distintos dominios o Forests.

Casi todas las semanas recibo alguna consulta ya sea a través del Blog, Twitter, o de algún compañero o amigo, relacionada con que tipo de grupos usar para dar acceso a Dominio A en Dominio B, o en periodos de Coexistencia en migraciones de usuarios complejas, donde queremos que un usuario acceda a los recursos de un dominio distinto.

La información que podemos encontrar por la web se resume en este cuadro:

 Groups

Lo más importante es entender la funcionalidad de los grupos, en la tabla de arriba que la he sacado de Microsoft, y es la típica tabla donde nos explican que es, que hace, y los posibles miembros de cada grupo, no queda muy claro en muchas ocasiones si un grupo admite miembros de otro Forest, o solo de otros usuarios de Dominios distintos al suyo, pero dentro de su mismo Forest. A parte de los nombres que con el nombre de los grupos casi nadie sabe su finalidad.

Domain Local: La finalidad de este grupo es acceder a recursos de su propio Dominio, por eso es Dominio Local. Por lo tanto ya tenemos claro que un grupo de dominio local solo puede dar acceso a objetos de su propio dominio.

Global Group: Por el contrario los grupos de dominio Global se conciben para dar acceso a recursos dentro de cualquier dominio de su Forest, o incluso en dominios o forest con relación de confianza.

Universal Groups: Para dar acceso a cualquier recurso dentro del mismo Forest, o Forest de confianza.

Una vez aclarada la finalidad, ahora hay que entender cuales son los posibles miembros … porque claro, ojala todo fuera tan sencillo como entender la finalidad de cada grupo, además debemos conocer que usuarios, y grupos admite cada uno de ellos.

Entornos de Coexistencia, relaciones de confianza, y acceso entre forests, y Bosques de recursos.

Centrándome ya en el origen de esta entrada, me gustaría analizar detalladamente las situaciones que vivimos, y las necesidades que se nos presentan en entornos con relación de confianza, periodos de Coexistencia mientras vivimos una migración de AD entre entornos, o simplemente cuando instalamos un Forest de recursos, y debemos implementar un modelo de delegación, o de acceso a los recursos.

Voy a dar por hecho que ya hemos llegado a esta situación, que ya hemos establecido conectividad entre los distintos Dominios, relación de confianza, etc., y que por necesidades del proyecto, del servicio, o porque se ha definido así en la arquitectura o diseño del entorno, debemos dar acceso a recursos de nuestro dominio, a identidades (usuarios) de dominios externos.

Pongamos que tenemos como dominio destino donde residen los recursos a acceder contoso.com, y como dominios de origen bank.com y datum.es. Desde los dominios origen nos solicitan tener acceso a una granja de servidores llamada SW1.

Este tipo de situaciones se suelen solventar de dos posibles vías, la primera a mi modo de entender no es correcta, y la segunda si:

  • Dando acceso directamente en el recurso de contoso.com a usuario origen, Grupo Universal, o Grupo Global origen. Desgraciadamente en muchas ocasiones, y motivado por las prisas se da acceso directamente a los objetos de origen en SW1, sin crear en contoso ningún tipo de grupo que controle esta delegación de permisos. Esto a la larga es un gran error, ya que no controlamos quien tiene acceso, y con el tiempo se olvida que alguien dio acceso de manera local a SW1.

grupodn

  • Creando en contoso.com un grupo Domain Local, con los permisos necesarios sobre la granja SW1 (la forma de dar los permisos, o accesos es indiferente), el grupo podría llamarse DL_SW1_DATUM. Ahora faltaría hacer miembros de ese grupo domain local a los usuarios o grupos de datum. En teoría habrá cierta comunicación entre datum y contoso, y se habrá definido que se genere un grupo nuevo en Datum con los usuarios que deben tener acceso a SW1, ese grupo puede ser Global o Universal. Este es el método correcto ya que nosotros controlamos a través de grupos de seguridad los accesos a nuestra granja SW1, además la nomenclatura lo deja claro haciendo mención al dominio de origen, luego se podría incluir en la nomenclatura alguna mención al tipo de acceso, pero eso ya entra en la forma de trabajar, y en los modelos de administración de cada organización, a mi me gusta crear grupos en base a roles, y tipos de permisos.

GroupsD

Resumiendo un poco, los únicos grupos que admiten miembros de otros Forests (bosques) son los Domain Local Groups. En esta imagen he intentado resumir que el único grupo que admite miembros de otros bosques es Domain local, y los que se pueden usar para anidar en Domain Local de otros forests son Universales y Globales.

Groups_Mem

Un saludo

Daniel Graciá

Hola a todos,

Recientemente he recibido varias consultas relacionadas con un problema a la hora de configurar un fondo de escritorio mediante GPO a máquinas Windows 8, y Windows 8.1.

En los foros de Microsoft TechNet también he contestado últimamente a consultas relacionadas con este problema.

https://social.technet.microsoft.com/Forums/es-ES/8ef62cfb-2922-42f0-a5de-4e38db72daa4/gpo-wallpaper-windows-8-y-81?forum=wsgpes

 

PROBLEMA:

Cuando desplegamos por medio de GPO un fondo de escritorio para equipos Windows 8, y WIndows 8.1, los equipos cliente procesan dicha GPO, pero aparece un fondo de pantalla negro, que no es el que hemos definido en la configuración de la GPO. Es muy frustrante pues es un comportamiento totalmente anómalo, los pasos siempre son los mismos, revisión de la GPO, que se aplique sobre la OU que debe, que el fondo de pantalla, en su ruta de red esté accesible para los usuarios que deben tenerlo, que se procese la GPO, en resumen se de administradores que han intentado durante días encontrar el fallo… Pero … ¿está el fallo en la GPO?

 

 

CAUSA:

Bien, en este punto no está muy clara la causa, pero sí que se sabe que hay un tipo de problema con sistemas Windows 7, 8, y 8.1 con esta configuración por GPO, no es algo que suceda en el 100% de los casos, pero en organizaciones con cientos de equipos basados en estos sistemas operativos es frustrante ver como no somos capaces de configurar algo tan básico, y sencillo como un fondo de escritorio corporativo.

Buscando información por la Technet, y otras fuentes, hay un sin fin de entradas relacionadas con este problema, y podemos encontrar muchas soluciones, demasiadas.

El problema está relacionado con una entrada del registry en los equipos cliente, dicha entrada es la siguiente HKEY_CURRENT_USER\Control Panel\Desktop\ Debe existir un registro del tipo REG_SZ llamado WallPaper que apunta a la ruta del wallpaper.

En los equipos afectados por el problema del fondo de pantalla en negro pueden suceder varias cosas:

  • No existe dicha entrada.
  • Existe pero hace mención a un fichero de fondo de pantalla que no es el que hemos definido, y la GPO no puede actualizar dicha información.

 

 

SOLUCION:

La solución que he encontrado, y ha funcionado en todos los casos es la siguiente:

1. Creamos la GPO que aplica el Wallpaper que deseamos sea el fondo de pantalla de los equipos. La configuración de la GPO en mi caso es básica solo quiero que una imagen que tengo en una unidad de red accesible en modo lectura por los usuarios que deben tener acceso, se configure como fondo de pantalla, para ello llamamos a la GPO Wallpaper_Corporativo, la editamos y vamos hasta la ruta donde se encuentra la configuración del Wallpaper, la ruta es la siguiente User Configuration > Policies > Administrative Templates > Desktop > Desktop

2015-02-18_10-15-30

Antes de aplicar la GPO sobre el usuario en cuestión vemos que fondo de escritorio tiene su PC sin la GPO.

2015-02-18_10-10-56

2. Una vez creada la GPO, la vinculamos a la OU donde se encuentra el usuario sobre el que queremos que se aplique. En mi caso utilizo una OU donde se encuentra el usuario sobre el que quiero se aplique el fondo de pantalla.

2015-02-18_10-49-15

3. Ahora accedemos a un PC con dicho usuario que es TEST1, si el fondo de pantalla aparece negro hay que seguir estos pasos:

  1. Crear una GPO para crear una clave de registry, a la que daremos la ruta del fondo de pantalla.

2015-02-18_10-59-19

  1. Vincularla también sobre la OU donde se encuentran los usuarios que queremos tengan ese fondo.
  2. Reiniciamos el PC, y en el siguiente reinicio aparecerá el fondo que hemos definido.

2015-02-18_11-01-51

En ocasiones tampoco funciona creando la clave del registry, por lo que primero debemos definir que se elimine la clave del registry que hace mención al Wallpaper, y luego crearla de nuevo con la GPO.

Como he dicho no sucede en todos los equipos, pero cuando ocurre genera muchos problemas.

Salu2!

Daniel Graciá

MCSSE

Hola a todos,

Os traigo algo de información para aquellos que estéis preparando, o pensando en preparar la certificación MCSE Desktop Infrastructure, y es que Microsoft siguiendo con su serie de Webcasts relacionados con certificaciones ha elaborado este Webcast, en el que tratan por completo esta certificación.

Es aproximadamente de una hora de duración, y se cubre toda la certificación, desde una visión global, la preparación del examen, objetivos, trucos para el examen, etc.

2015-02-02_20-47-45

 

Os lo recomiendo 100%, además ahora está de promoción el Second Shot para los exámenes antes del 31 de Mayo. http://www.campusmvp.es/microsoft-second-shot.htm

 

Aquí tenéis el link Exam Prep: 70-415 and 70-416 – MCSE: Desktop Infrastructure

 

Saludos,

DGM

Hola a todos,

En la entrada de hoy en el Blog vamos a hablar de como desfragmentar (compactar) nuestra base de datos de AD DS de manera offline, sin necesidad de reiniciar el Controlador de dominio, aunque yo diría que más que centrarnos en como hacer la defragmentation, vamos a incidir más en algo que que está muy poco documentado, y es en CUANDO hacerlo, lo interesante sería tener constancia previa de cuanto espacio ganaríamos compactando nuestra base de datos, ¿verdad?, pues hay un procedimiento para que el sistema nos informe de cuanto ocupa nuestra base de datos de AD, y cuanto espacio está libre en realidad de todo lo ocupado, que sería la parte que se liberaría.

Esta tarea entraría en las denominadas “Tareas de mantenimiento de nuestro Directorio Activo” aunque sinceramente hay entornos en los cuales no es necesario llevarlo a cabo, y otros en los que si.

Un poco de historia respecto a la base de datos NTDS.DIT

Dentro del funcionamiento normal de la propia base de datos, se ejecuta de forma automática, y transparente para el usuario una desfragmentación cada 12 horas, la cual denominamos Online defragmentation y se lleva a cabo un par de veces al día. Pero claro la online defragmentation no es tan “potente” por así decirlo que la offline, en la Online se libera el espacio de los objetos eliminados de manera rápida, para ser reutilizados por nuevos objetos de AD DS, y en la medida de lo posible que no crezca la propia base de datos, pero no sirve para cuando se eliminan gran cantidad de objetos, en esos casos digamos que la desfragmentación Online no es tan efectiva.

image

image

¿Que hacemos al llevar a cabo la Defragmentation?

Con la denominada desfragmentación de la base de datos de AD DS, lo que hacemos es compactar de nuevo la base de datos, liberar espacio que se ha ido ocupando de más, y chequear la integridad de la base de datos.

Como he dicho al principio de la entrada, en la mayor parte de los escenarios no es necesario llevar a cabo está acción, pero hay otros entornos por ejemplo los que vienen de hacer un upgrade de los Controladores de dominio a una versión reciente de Windows Server, entornos muy grandes que han sufrido grandes variaciones donde si puede ser interesante desfragmentar la base de datos, también un tamaño desproporcionado del fichero ntds.dit es síntoma inequívoco de que hace falta compactar, aunque deberemos tener en cuenta que los Controladores de dominio que son además Catálogo Global tienen mayor tamaño de base de datos que el resto de DCs que no lo son, por lo que en ese caso la diferencia de tamaño de unos DCs respecto a otros está justificada.

¿Cuando debo realizar este procedimiento?

Como ya he comentado al comienzo de la entrada, la defragmentation online se lleva a cabo cada 12 horas, pero no cubre una acción en profundidad, es algo muy superficial, no siempre libera espacio. Durante los años de trabajo en un entorno con Directorio Activo la base de datos ntds.dit va aumentando de tamaño, cualquier objeto suma, aunque luego se eliminen van generando o consumiendo espacio, que la base de datos no es capaz de liberar por si sola en numerosas ocasiones, como en el borrado de objetos pasado el tombstone lifetime (tiempo en el que realmente se eliminan los objetos y ya no pueden ser recuperados.

Windows Server 2000 – 60 days
Windows Server 2003 – 60 days
Windows Server 2003 SP1 – 180 days
Windows Server 2003 R2 – 60 days
Windows Server 2003 R2 SP2 – 180 days
Windows Server 2008 – 180 days
Windows Server 2008 R2 – 180 days
Windows Server 2012 – 180 days
Windows Server 2012 R2 – 180 days

Para saber realmente cuando, o mejor dicho que espacio puedo liberar del fichero ntds.dit llevando a cabo la defragmentation hemos de modificar una clave del registry que nos mostrará de manera anticipada que ganancia obtenemos, y si realmente nos merece la pena hacer las defragmentation.

Para ello nos conectamos al DC sobre el que queremos ver el espacio a liberar, y modificamos la siguiente entrada del registro:

HKEY_LOCAL_MACHINE \ System \ CurrentControlSet \ Services \ NTDS \ Diagnostics

Como siempre ejecutamos regedit, y navegamos hasta la ruta

2015-01-27_11-56-14

Como podemos observar, el valor por defecto de la entrada 6 Garbage Collection es 0, nosotros debemos modificarlo a 1. Con esta simple acción incrementaremos el Logging del proceso Garbage Collection el cual se ejecuta junto con la defragmentation online. Ahora deberíamos esperar a que la proxima defragmetation online se lleve a cabo (ya hemos comentado que sucede un par de veces al día cada 12 horas), y entonces podremos estudiar el log Active Directory Domain Services.

Dentro del log buscaremos el event id 1646, por normal general aparece junto a los event ids 700 and 701.

SNAGHTML129584ae

Como se puede ver en el log en mi ejemplo (es un dominio recién instalado para pruebas) de los 18MB que ocupa la base de datos, si la compactásemos ahora mismo ganaríamos o liberaríamos 4MB, con lo que se quedaría en 14MB.

En entornos reales de producción, podréis observar como se puede ahorrar bastante espacio en la BBDD, y además mejorar el rendimiento de una manera muy leve.

El procedimiento como tal para hacer la compactación es sencillo, y se puede seguir en el siguiente enlace de Microsoft: https://technet.microsoft.com/en-us/library/cc794920%28v=ws.10%29.aspx

Saludos

DGM

Hola a todos,

Creo bastante oportuno hablar un poco acerca de esta propiedad de las que podemos dotar a nuestros Controladores de dominio.

Algunas abreviaturas para seguir este artículo, y disculpar por las definiciones en Inglés pero me parece más correcto así:

AD DS: Active Directory Domain Services

DC: Domain Controller

GC: Global Catalog

DNS: Domain Name System

UPNs: User Principal Names (daniel@contoso,com)

FSMO: Flexible Single Master Operations

 

La importancia de un buen diseño de AD DS es fundamental para el correcto funcionamiento de nuestro entorno, hay que tener en cuenta muchas variables, requerimientos, seguridad, topología geográfica, y un sin fin de variables que pueden hacer que nuestro diseño sea de una manera determinada, y apropiada para nuestra organización, o clientes.  Lo cierto es que a día de hoy parece que AD DS es de los productos más sencillos de desplegar, todos conocemos la errónea creencia del Siguiente, siguiente y siguiente y ya tienes un Dominio … y nada más lejos de la realidad los que nos dedicamos de verdad a esto sabemos que un mal diseño de AD DS puede afectar al negocio de tu cliente, y generar una auténtica catástrofe en entornos grandes que son Productivos.

En la arquitectura de AD DS hay bastantes factores a tener en cuenta, el núcleo por así decir sobre el que se sustenta nuestro AD DS es el servicio DNS, del que ya he escrito algunas entradas, y seguiré profundizando en sucesivas entradas, y otro factor muy importante es la topología de nuestro entorno, y por esa razón creo conveniente la entrada de hoy. En los foros de Microsoft en los cuales colaboro siempre que puedo, veo muchas consultas relacionadas con Global Catalog, y Universal Group Member Caching, pues bien veamos en profundidad que es cada una, que aportan, cuando usarlos y cuando no. 

Global Catalog

La definición sobre que es un GC sería algo así como un DC que almacena una copia completa de todos los objetos de su AD (aquí se refiere a los objetos de su propio dominio …del que forma parte el DC), y una copia parcial de todos los objetos de otros dominios en el bosque. Por lo tanto tiene replicas parciales de todas las particiones de dominios del bosque, estás réplicas parciales son distribuidas mediante replicación Multimaster (al igual que AD DS).

Por lo tanto podríamos decir que GC nos ofrece una funcionalidad crítica, y que pasa desapercibida en numerosas ocasiones.

Pero … ¿que hace exactamente un GC, o mejor dicho como aplica en el día a día su propia definición?

Tiene tres principales usos que serían:

Logon: Otra función es la de poder resolver los UPNs a la hora de hacer logon por ejemplo, como sabéis a la hora de validarnos en AD DS podemos hacerlo de varias maneras, las más común es hacerlo mediante domain_name\username, y otra es hacerlo mediante el UPN, el UPN usa formato de dirección de correo electrónico tipo daniel@contoso.com. El GC en este caso es el encargado de resolver o traducir el UPN a username.

Membresía de Grupos Universales : los grupos universales son un grupo de seguridad, y para refrescar un poco la memoria sobre ellos los grupos universales nos permiten aplicar permisos sobre cualquier recurso de nuestro dominio, y pueden contener objetos de cualquier dominio con el que tengamos relación de confianza. La membresía de los grupos Universales es almacenada en los GC, y replicada a través del forest.

image Os estaréis preguntando que tiene de especial esta funcionalidad del GC … los grupos universales están en AD DS… Si hacemos un poco de memoria en AD DS, cuando se introdujeron los grupos universales en AD DS en la versión Windows Server 2000 modo de funcionalidad Windows 2000 Nativo, resultaba que que si nuestro AD DS contaba con muchos grupos Universales, esto podía afectar al tráfico de red que generaban, ya que la información era replicada cada vez que se modificaba alguna propiedad de un objeto. En Windows 2003 se introdujo una mejora que fue la replicación de la membresía de grupos universales reduciendo drásticamente la carga de replicación.

Cuando un usuario se autentica, el DC debe poder ver los miembros de los grupos universales para determinar si permite autenticar a ese usuario en el dominio o no, por consiguiente debe existir al menos un GC en el AD DS, y por esa razón siempre el primer DC que se instala es GC. Si un GC está disponible localmente por ejemplo en el mismo site que el DC que intenta localizarlo contactará con el, si hubiera un GC en una ubicación remota el DC contactará con el GC remoto seguramente a través de una red WAN, y eso afectará al rendimiento, y al tiempo que se tarda en autenticar al usuario, por esa razón es muy importante tener un GC al menos en cada site.

Búsquedas en AD DS: El GC se encarga de procesar las peticiones de búsquedas sobre nuestro AD DS, esto que quiere decir, en definitiva quiere decir que cuando hacemos una búsqueda en AD DS el encargado de recibir dicha petición, y procesarla es el GC. Pongamos como ejemplo que abro una consola de Active directory users and computers, y haga una búsqueda cualquiera, la petición de búsqueda será enviada a un GC a través del puerto TCP 3268 (puerto específico para GC), y el GC procesará la petición.  ¿Cómo sabe a que GC enviar la consulta? Como ya hemos comentado al principio,el servicio DNS es fundamental en nuestra infraestructura de AD DS, y se basa en el para poder funcionar, y localizar los distintos servicios dentro de AD DS, los GC tienen un registro SRV denominado _gc que les identifica como GC, por lo tanto el servidor DNS identifica un GC, y se le envía la petición TCP por el puerto 3268.

image

Recomendaciones:

  • Tener al menos 2 GC por motivos de alta disponibilidad.
  • A día de hoy es altamente recomendado que todos los DCs sean GC en entornos denominados single-domain forest, ya que todos los DCs tienen la única partición de dominio en el forest. También lo es en entornos multi-domain.
  • Infrastructure Operation Master FSMO… no hacer GC a un DC que tiene el rol FSMO Infrastructure Master, a menos que todos los DCs sean GC, o el bosque tenga un único dominio.
  • ¿Existe alguna aplicación que requiera de un GC? Por ejemplo Exchange requiere el uso de GC, en esos casos hay que tener en cuenta el uso de GCs.

image Esto es solo una pequeña introducción a los GC, podemos investigar tanto como queramos, y en base a la estructura de la empresa el diseño será de una manera u otra, lo que está claro es que hay que toma tiempo para estudiar cada caso, los requerimientos, la topología, y el mejor diseño adaptado.

Algo de bibliografía

¿Qué es un GC? http://technet.microsoft.com/en-us/library/cc728188(v=ws.10).aspx

Scope de grupos en AD DS http://technet.microsoft.com/en-us/library/cc755692%28v=ws.10%29.aspx

Ubicación de GC http://technet.microsoft.com/en-us/library/cc732877%28v=ws.10%29.aspx

 

Lo dejamos aquí en esta entrada, profundizaremos más en sucesivas.

Un saludo,

DGM

Esta semana tuvo lugar la semana IaaS con una serie de videos en los que Mark Russinovich comparte su visión sobre que es Azure a día de hoy, y que será o cuales serán los pasos siguientes en el futuro cercano.

También intervienen grandes profesionales muy capacitados en Azure.

image

Como sabéis Mark fue nombrado CTO for Azure, y resulta muy interesante escuchar todo lo que tiene que contar, espero que lo disfrutéis ya que Mark nos cuenta cosas muy interesantes:

Por cierto, esta serie de videos son muy interesantes si estáis planteándoos certificaros como Microsoft Azure Specialist Exam 70-533 https://www.microsoft.com/learning/en-us/exam-70-533.aspx

 

Ah otra cosa … hoy he comenzado a leer un libro llamado Architecting the Cloud (Michael J. Kavis) el cual me está resultando de los más interesante, no es el típico tocho en el que nos meten 500 páginas de pantallazos, a parte de la visión técnica tiene su puntito histórico – divulgativo, donde el autor nos pone al día en cuanto a la historia del Cloud.

 

Detalles del producto

DGM

Hola a tod@s!

Navegando me he encontrado con una pequeña joya, la guía de supervivencia de Hyper-V!!

Está publicada en la wiki, y tras echarle un ojo me ha encantado todo el trabajo que hay recogiendo información, fuentes, enlaces … para aquellos que buscan un punto en concreto, los que tenéis unas horas libres y os apetece refrescar conocimientos, o porque queréis empezar en el mundillo de la virtualización con Hyper-V es perfecto.

 

Aquí tenéis el enlace: Hyper-V Survival Guide

microsoft-hyper-v-logo

 

Espero que la disfrutéis … eso si con calma, que la cantidad de información recabada es inmensa.

 

DGM

Datace

Hola a todos, en los próximos días el equipo de TechNet y Zerkana, realizarán una serie de webcast sobre Windows 2012 R2.

No os los perdáis, los imparten grandes profesionales.

http://blogs.technet.com/b/estechnet/archive/2014/05/05/webcast-de-la-comunidad-windows-server-2012-r2.aspx

 

Martes 13 de Mayo a las 18:00

Webcast TechNet: Integración y administración de Office 365 con WS012R2 con rol Essentials en pyme

https://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032586665&Culture=es-ES&community=0

-Subscripción a servicios en línea (office 365) desde consola Essentials

-Creación y asignación de roles de usuario Office 365.

-Sincronización de usuarios locales con Office 365

-administración de la subscripción a office 365 desde panel essentials.

Francisco L. Verdú – Consultor de Zerkana

Martes 20 de Mayo a las 18:00

Webcast TechNet: Remote desktop services para pymes (servidor todo en uno)

https://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032586671&Culture=es-ES

Paulo Días – Consultor de Zerkana

Martes 27 de Mayo a las 18:00

Webcast TechNet:WS2012R2 para pymes: aporte de rol essentials y ejemplos de configuración en un servidor

https://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032586673&Culture=es-ES

Durante este Webcast, Miguel Hernández ex Microsoft MVP en Small Business Server, expondrá las ventajas de contar con los productos pensados para una pyme y que forman parte de la familia Windows server 2012 R2 y como estos ayudan a la gestión de entornos pequeños donde es habitual encontrar un polivalente servicio IT interno o externo.

Miguel Hernández – Consultor de Zerkana

DGM

Primera entrada del 2014!

Como sabemos los Sufijos de User Principal Name (UPN) son la parte del UPN que comienza por símbolo @.

De tal manera que por ejemplo en el UPN DaniGracia@contoso.com, el sufijo UPN es el nombre de dominio contoso.com.

Los UPN hacen posible que los usuarios se autentiquen en el dominio usando una cuenta que incluya el nombre de sus dominios, sería algo parecido a una dirección de correo, tal y como hemos visto en el ejemplo anterior, y es algo fácil de recordar, aunque resulta muy útil en entornos complejos o bosques con múltiples dominios, donde los usuarios pueden autenticarse en diferentes dominios, y no deben usar diferentes credenciales, o estar pendientes sobre que dominio de la organización deben hacer la autenticación.

Veamos un ejemplo supongamos que el usuario Dani Gracia tiene una cuenta de usuario en el dominio sistemas.contoso.com, pero quiere iniciar sesión en un equipo que pertenece al dominio portatiles.contoso.com, lo más sencillo sería iniciar sesión usando el UPN de Dani Gracia que en este caso sería danigracia@contoso.com, estoy seguro que muchos dirían en la pantalla de inicio de sesión seleccionamos el dominio sistemas.contoso.com, o también escribiriamos Sistemas\DaniGracia … pero lo cierto es que lo más rápido y funcional en estos casos es escribir el UPN del usuario.

Alguno se preguntará … pero por qué en el UPN no he puesto DaniGracia@sistemas.contoso.com ?  Es sencillo, por defecto todos los usuarios tienen como sufijo UPN el nombre del dominio raíz, y el de su propio dominio, incluso si sus cuentas pertenecen a dominios hijo.

Hay una manera fácil de configurar los sufijos UPN alternativos que pueden utilizar los usuarios del dominio o bosque. Desde la consola de Directorio Activo de Relaciones de Confianza, tenemos la posibilidad de añadir o eliminar los sufijos UPN alternativos.

image

Estos sufijos alternativos aparecerán en las propiedades de directorio activo de usuario.

Otras utilidades de los Sufijos Alternativos:

Más info sobre los UPN

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

 

DGM