The Sysadmin´s Block

Usualmente estabamos acostumbrados a instalar un servidor en la version 2012 o 2012 R2, instalar las aplicaciones, hacer el tunning de los sistemas y luego de estabilizar remover la capa gráfica y dejarlo en modo core.

En Windows 2016 no puedes efectuar este cambio. 

Note

“Unlike some previous releases of Windows Server, you cannot convert between Server Core and Server with Desktop Experience after installation. For example, if you install Server Core and later decide to user Server with Desktop Experience, you should do a fresh installation (and vice versa).”

Cuando deseas realizar la acción deberá aparecer un error 

Active Directory Certificate Services (AD CS) proporciona servicios para la emisión y administración de certificados.  Si por motivos de actualización de hardware necesitamos mover nuestro CA a otro servidor podemos hacer lo siguiente:

Nota:  Este no es un procedimiento para cambiar el CA a otro servidor con un nombre diferente al que ya tenia, tampoco es un procedimiento de actualización de un CA 2003 a 2008 R2 (de estos escenarios escribiremos en un post más adelante).

1.  Debemos de tener nuestro servidor destino sin ingresarlo a dominio, pues mas adelante cambiaremos el nombre al que tenia nuestro CA anterior y lo ingresaremos al dominio.

2. Hacemos respaldo de la base de datos y del certificado con la Private key, y asignamos una clave al certificado la cual usaremos mas adelante para importarlo:

3.  Detenemos el servicio del CA para que este ya no genere mas certificados en el proceso de moverlo.

4. Hacemos respaldo de la llave de registro que contiene los datos de la CA

5.  Removemos el rol de CA del servidor (estas pantallas han sido tomadas de una CA instalada en un server core)

6. Desunimos el servidor del dominio

7.  Borramos todo rastro del servidor en el AD y en el DNS

8. Ingresamos nuestro servidor destino al dominio con el nombre del servidor anterior

9. Iniciamos una MMC (en ejecutar solo escribimos MMC) y agregamos el snapin de certificados de "Computer Account" para importar el nuestro

10. Bajamos al contenedor PERSONAL y seleccionamos la opción IMPORT

11. Importamos nuestro certificado

12. Colocamos el password con el que lo guardamos y marcamos la opcion "Include all extended properties"

13. Nos aseguramos que el contenedor sea personal

14.  Nos aseguramos que el proceso finalice exitosamente

15.  Luego abrimos el certificado y copiamos los datos de la propiedad "serial number"

16. Abrimos una linea de comandos y ejectuamos

17.  Instalamos el rol de Active Directory Certificate Services

18.  Seleccionamos ENTERPRISE y ROOT en las siguiente dos pantallas respectivamente

19. Seleccionamos "Use existing private key"

20. Nos aseguramos que este el certificado de nuestra private key

21.  Damos la ubicación de la base de datos y los logs

22.  Finalizamos la instalación

23.  Iniciamos la consola de la CA.  Haciendo click derecho vamos a la opcion "Import", nos mostrará un mensaje que el servicio se detendrá y damos OK

24. Seleccionamos la opción "Certificate Database and Certificate database Logs" y le damos la ruta de nuestro respaldo

25.  Esperamos que la restauración este completa y se iniciará el servicio

26.  Detenemos el servicio de la CA e importamos la clave de registro que tenemos del servidor anterior desde una linea de comandos

27.  Revisamos las siguientes claves de registro

en especial las llaves:

DBDirectory

DBLogDirectory

DBSystemDirectory

DBTempDirectory

para ver que correspondan con nuestro servidor

28.  Revise que el valor de la clave de registro en DBSessionCount sea 64

29.  Iniciamos el servicio del CA nuevamente

Luego hacemos las pruebas respectivas para ver si esta generando certificados.

1.  Complete the Base Configuration. The Base Configuration is the core of all Test Lab Guide scenarios. The first step is to complete the Base Configuration.

2.  Configure CM1. After installing the operating system, CM1 must be configured and joined to the corporate domain.

3.  Complete Installing SQL Server 2008 R2 Enterprise and Service Pack 2. System Center 2012 Configuration Manager requires SQL Server 2008 or 2008 R2 with the latest service 

pack.

4.  (optional) Complete the TMG Core Configuration. The TMG Core Configuration provides internet access to the Test Lab.

5.  Configure DC1. Several steps must be performed on the domain controller in preparation for System Center 2012 Configuration Manager.

6.  Install System Center 2012 Configuration Manager Prerequisites. Prior to installing System Center 2012 Configuration Manager , there are some prerequisites that must be met.

7.  Install System Center 2012 Configuration Manager. Install the System Center 2012 Configuration Manager binaries on CM1.

8.  Configure System Center 2012 Configuration Manager. Configure the roles of System Center 2012 Configuration Manager.

9.  Deploy the System Center 2012 Configuration Manager Client. Deploy the Configuration Manager Client to CLIENT1.

La guia completa lleva los paso a paso sobre la configuración sobre este escenario, una buena opción para hacer sus laboratorios de pruebas con Configuration Manager 2012.  Encontraran también los enlaces necesarios para descargar los productos para hacer el lab.

Siempre se ha recomendado para aumentar la tolerancia a fallos en el servicio de DHCP el que se pueda dividir el ámbito en dos servidores.  Hasta Windows 2003 server esta tarea era un poco tediosa.  Con Windows 2008 R2, este tipo de configuraciones se simplifica enormemente.  Veamos el caso.

Supongamos que tenemos dos servidores uno con un ámbito ya configurado y el otro solo con el servicio de DHCP instalado.  El ámbito que dividiremos será para esta prueba es del rango 10.10.0.100 a la 10.10.0.150.

Lo que hacemos es seleccionar el ámbito de nuestro servidor DHCP actual.  Hacemos click derecho y vamos a la opcion Advanced y luego a Split-Scope

Después de dar siguiente en la primera pantalla de bienvenida del asistente, tendremos una pantalla para seleccionar nuestro servidor DHCP adicional con el que dividiremos el ámbito.

Luego tan fácil como seleccionar nuestra estrategia de tolerancia a fallos con respecto al otro servidor, para que este pueda dividir el ámbito

En la siguiente pantalla se nos pedirá configura el tiempo de espera que tendrán entre servidor para enviar un paquete DHCP OFFER.  En el caso podemos poner 1000 al segundo servidor que indicara que se esperara 1 segundo, pues los valores están dados en milisegundos.

Por ultimo la pantalla con un resumen de la configuración y ya tendremos configurado nuestro ámbito divido con un aumento en la tolerancia a fallos.

Si desean tener mas información sobre la estrategia de 80/20 pueden visitar el siguiente enlace

El borrado accidental o incluso sin serlo de objetos dentro del Directorio Activo suele ser un problema dentro de los departamentos de IT.  Para ello el habilitar "Recycle Bin" para nuestro AD es indispensable.

Uno de los factores a tomar en cuenta dentro de esto es la configuración que tengamos del tombstoneLifetime.  Por defecto 2003 y 2008 traen 180 dias antes que los objetos sean borrados, sin embargo este es un parámetro que bien se pudiera modificar de acuerdo a las normas de cada compañía, y para hacerlo deberá modificar el atributo msDS-deletedObjectLifetime.

Lo otro también a tomar en cuenta es el nivel de funcionabilidad de nuestro bosque, este debe estar en 2008R2:

Y por último, al habilitar Recycle Bin, no hay marcha atrás este se habilita y no puede ser deshabilitado.

Teniendo en cuenta lo anterior procederemos a la habilitación de la bandeja de reciclaje, aunque existen dos formas de hacerlo, una vía ldp.exe y la otra vía cmdlet de powershell, siempre me inclino por la segunda, asi que lo haremos de esa forma:

1.  Revise en que servidor están ubicados los roles FSMO y de hagalo sobre este.

2.  Ejecute como Administrator el Active Directory Module for Windows PowerShell y escriba el siguiente cmdlet sustituyendo obviamente las opciones de su dominio:

Enable-ADOptionalFeature –Identity ‘CN=Recycle Bin Feature,CN=Optional Features,CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration, DC=midominio,DC=com’ –Scope ForestOrConfigurationSet –Target ‘midominio.com’ 

Presione  "Y" a la pregunta de desea la habilitación de "Recycle Bin".

Eso es todo.. ahora a hacer la prueba restaurando un usuario que hayamos borrado, en mi caso lo probare con un usuario: "Juana Castillo".

Para el proceso de restauración puede hacer lo siguiente:

Get-ADObject -Filter {displayName -eq "Juana Castillo"} -IncludeDeletedObjects | Restore-ADObject

Para mayor información de Get-ADObject: http://technet.microsoft.com/en-us/library/ee617198.aspx

Ahora podemos ver nuevamente al usuario dentro de la OU a la que pertenecía.

Si desea ver los datos del usuario antes de hacer el proceso de restauración puede ejecutar el cmdlet sin la opción de restaurar:

Get-ADObject -Filter {displayName -eq "Juana Castillo"} -IncludeDeletedObjects

Una de las políticas de grupo mas configuradas es la de estandarizar el fondo de escritorio.  Sin embargo usualmente vemos configurada esta política de forma inadecuada sobre cargando las infraestructuras.

Veamos los pasos necesarios para hacer la política de la forma conveniente.

1. El primer consejo es evitar usar una ruta UNC para configurar la política de fondo de escritorio.  Teniendo esto en cuenta, para lo único que usaremos la ruta UNC es para hacer la copia del archivo a las computadoras que el usuario hará inicio de sesión.

2.  Creamos una carpeta compartida con la imagen a copiar y dado que usaremos una preferencia solo necesitan permisos el grupo "COMPUTADORAS DEL DOMINIO" tener permisos:

al igual en los permisos NTFS.

2.  Usamos las preferencias de W2008 para copiar el archivo:

 3.  Recuerde solo aplicarlo una vez, esto quiere decir que configure la pestaña "common":

4.  Configure ahora la política dando la ubicación local del archivo que hemos puesto en la preferencia:

Ahora solo configuramos la opción de habilitar fondo de pantalla "Enable Active Desktop":

Suficiente para configurar nuestro fondo de pantalla institucional.  Si entre nuestros equipos existen Windows XP, hay que recordar que debemos de tener las Client Side Extension instaladas (a estas alturas es casi obligatorio haberlo desplegado) para ello tiene dos opciones la primera es mediante su WSUS/Windows Update, y sino por un script.

Descargas manuales del CSE: http://blogs.technet.com/b/grouppolicy/archive/2009/03/27/group-policy-preferences-not-applying-on-some-clients-client-side-extension-xmllite.aspx

Aplicación por medio de script:

Comenzaré diciendo que el contenido de este post no es recomendable hacerlo en ambientes de producción seguros y que deberá ser implementado solo en casos especiales en los cuales el departamento de IT tenga un buen control sobre los equipos a los que se aplica esta política y que sea de extrema necesidad.

Veamos como ocupamos las preferencias de las políticas de grupo para hacer el logon automatico:

1. Al crear la politica vamos a la seccion: Computer Configuration - Preferences - Windows Settings - Registry

2.  Creamos 3 registros: AutoAdminLogon, DefaultPassword, DefaultUsername.  Para ello hacemos click en Action - New - Registry Item y configuramos las opciones tal como aparecen en las siguientes imágenes:

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon

3.  Los registros quedaran de la siguiente manera:

4.  Luego de aplicar la política los registros del equipo cliente quedaran de la siguiente manera:

Hace poco en un tranning me preguntaron si podíamos cambiar la imagen de fondo en la pantalla de logueo del usuario desde una GPO, luego de hacer una pequeña y rápida encuesta muy pocos tienen implementado algo asi y a todos les gustaría.  Así que prometí poner el post y aquí les dejo los pasos:

1.  Creamos la politica de grupo nos apoyaremos de las preferencias que Windows 2008 R2 nos proporciona para configurar los equipos, y comenzamos creado la ubicación en la que pondremos la imagen.

En la sección de preferencias, en la sección de "FOLDERS"

La ubicación debe ser: %WindowsDir%\System32\oobe\info\backgrounds

2.  Ahora copiamos el archivo de la ubicacion de origen a la carpeta destino siempre apoyados con las preferencias.  Es importante hacer mención que debes de poner el nombre del archivo destino como "BackgroundDefault.jpg" y que los permisos en la carpeta origen debe de tener por lo menos al gruipo "Computadoras del dominio" para que pueda leer y copiar el archivo.

Ahora la preferencia a utilizar es la de "FILES"

3.  Ahora nos vamos a la sección de "POLITICAS" y vamos a: Administrative templates / System / Logon / Always use custom logon background y lo habilitamos.

Listo, ahora aplicamos la política a una OU o al dominio y esperamos que las políticas se actualicen por sí mismas o damos un gpupdate /force para probarla en un equipo.

El resultado:

Cuando trata de unir un equipo al dominio aparece el siguiente mensaje de error:

La solución en mi caso particular fue bastante simple.  Al comparar la hora del equipo a unir y la hora del controlador, el desfase de tiempo era superior a los 15 minutos.  Por lo tanto al sincronizar la hora del cliente con el servidor el equipo pudo unirse al dominio sin ningún problema.

Todo esto por el timestamp... recuerdan?? :) 

Un error de acceso denegado aparece al intentar hacer la des promoción de un controlador de dominio:

Para solucionarlo simplemente nos vamos al NTDS Settings del servidor dentro de la consola de Site and Services y quitamos la marca de "Protect object from accidental deletion":

De forma predeterminada en SharePoint Server 2010, los propietarios de los sitios y los diseñadores no tienen acceso a editar la master page de estos. En el momento que uno quiere editar la pagina con Sharepoint Designer 2010 se muestra el siguiente mensaje de alerta

Para permitir a los propietarios y diseñadores del sitio poder editar la master page debemos conceder permisos en el nivel correspondiente, para ello vamos a la sección de Acciones del sitio > Configuraciones del sitio > Administración de la colección de sitios > Configuración de Sharepoint Designer

El certificado auto-firmado que Exchange 2007 (sin SP2) crea y configura durante la instalación de los roles expira al año de su creación.

Para solucionarlo podemos hacer dos cosas: generar un nuevo certificado o clonar el existente.

Vamos por la primera opción.

Abrimos nuestra consola de comandos Powershell de Exchange Server:

Ejecutamos Get-ExchangeCertificate | List

Podemos ver que aparece el campo NotAfter con la fecha de caducidad del certificado, en el campo Services, todos aquellos servicios que ocupan el certificado y el Thumbprint que es único para cada certificado, este ultimo lo ocuparemos mas adelante.

Ahora generamos el nuevo certificado y bastara que ejecutemos el cmdlet

New-ExchangeCertificate

Nos pedira una confirmacion si queremos sobreescribir el certificado existente en el SMTP a lo cual daremos "Y". Esto genera un certificado con un thumbprint diferente y con vigencia de un año desde la fecha de creación.  Podemos ver los dos certificados nuevamente ejecutando Get-ExchangeCertificate | List

Si vemos bien en la seccion de Services, el nuevo certificado no esta asociado al servicio del IIS por lo que este todavia esta usando el certificado caducado.  Ahora procederemos a asociarlo

Enable-ExchangeCertificate -Thumbprint "THUMBPRINT DEL CERTIFICADO NUEVO"

Ahora si nos aparecerá el servicio IIS asociado con el nuevo certificado al dar ejecutar nuevamente Get-ExchangeCertificate | List

Procedemos a la ultima fase que es remover el certificado anterior

Remove-ExchangeCertificate -Thumbprint "THUMBPRINT DEL CERTIFICADO ANTERIOR"

Y podremos ver ahora con Get-ExchangeCertificate | List que solo exista el certificado nuevo con fecha de vencimiento en un año.

NOTA: LAS IMÁGENES FUERON TOMADAS DE UN LABORATORIO DE PRUEBAS USANDO EXCHANGE 2010.  POR ESO LA DURACIÓN DE LOS CERTIFICADOS ES DE 5 AÑOS.  EL PROCESO SIN EMBARGO ES EL MISMO EN EXCHANGE 2007.

La otra opción que tenemos es que en algunos casos (muchas veces la mayoría), es posible que tenga sentido clonar estos certificados

Get-ExchangeCertificate -Thumbprint "THUMBPRINT ACTUAL" | New-ExchangeCertificate

Si alguna vez tenemos la necesidad de generar el listado de usuarios de grupos anidados, tenemos varias opciones para hacerlo, sin embargo describiremos dos de ellas.

El escenario es el siguiente: tenemos un grupo llamado "asistenciaremota" y dentro de el tenemos a dos usuarios y un grupo.

La primera  las opciones es desde una consola de comandos:

dsquery group -name asistenciaremota | dsget group -members -expand

En esta forma encontraremos listado el nombre del grupo anidado pero también los miembros este.

La otra forma mas ordenada a mi forma de ver es con powershell:

Get-ADGroupMember "asistenciaremota" -recursive | Select-Object name

La transferencia de los roles de Mastros de Operaciones, conocidos como FSMO (Flexible Single Master Operations) podemos hacerlo tanto de forma gráfica como en línea de comandos.  Los roles FSMO a transferir son 5:

A nivel de Forest

Schema Master

Naming Master (Domain Naming Master)

A nivel de Dominio

Insfrastructure Master

RID Master

PDC (PDC Emulator)

En este caso haremos uso del comando ntdsutil para hacer la transferencia del servidor DC01 al DC02.

Para ello:

Abrimos una línea de comandos y escribimos "ntdsutil"

Luego escribimos "roles"

Ahora escribimos "connections"

Luego "connect to server DC02 (en su caso el server destino)

Digite quit (en su defecto q) y luego enter

Ahora comenzamos a transferir los roles:

Escriba "transfer schema master"

Aparecerá un mensaje de confirmación de la transferencia del rol (este mensaje aparecerá para cada uno de los roles a transferir)

Ahora digite "transfer naming master"

Luego "Transfer RID master"

Ahora "transfer PDC"

y finalizamos con "transfer infrastructure master"

Para salir de ntdsutil solo digite "quit" hasta salir al prompt del sistema.

Puede consultar ahora la ubicacion de los roles con "netdom query fsmo"