Archivo de la categoría: Powershell

Instalar Azure Powershell.


Hoy algo sencillo y cada vez mas usual, que nos va a servir para posteriores trabajos, tareas  y posts.

¿Qué es Azure PowerShell?

Básicamente, Azure PowerShell es un conjunto de módulos que ofrece cmdlets para administrar Azure con Windows PowerShell.  Podemos utilizar dichos los cmdlets para crear, probar, implementar, administrar soluciones y servicios ofrecidos a través de la plataforma de Cloud Computing de Microsoft, Azure, asi como para tareas y procesos de Automatización.

En la mayoría de los casos, se pueden usar los cmdlet para las mismas tareas que el Portal de Azure, como la creación y configuración de servicios, máquinas virtuales, redes virtuales, aplicaciones web, etc., pero, como imaginais hay muchas tareas que solo puedes configurarlas a través de Powershell ;-), de ahí su importancia.

Tenemos diversas maneras de instalar Azure Powershell, os describo alguna de ellas:

1 Desde Web Platform installer.-

En mi opinión, es la más habitual, por eso la he puesto en el primer lugar:

  • Normalmente nos aparecerá como primera opción, seleccionamos agregar y …. siguiente, siguiente siguiente.

  • Aceptamos los términos de licencia y empezará primero a descargarse y luego a instalarse Azure Powershell

  • Una vez terminado, mostrará el siguiente mensaje:

2 Desde powershell.-

Esta es otra forma habitual de hacerlo. Desde una consola de powershell, solo añadimos el módulo de Azure, ASM o ARM:

  • ASM ==> Install-Module Azure
  • ARM ==> Install-Module AzureRM

Pues ya lo tenemos instalado y …. funcionando.

Antes se podía desde el portal de descargas de azure, pero ahora no funciona. Os lo dejo por si lo vuelven a activar:

  • Nos descargamos e instalamos el ejecutable spilauncher.exe, que justamente es Web Platform Installer y …. volvemos al punto 1.

Seguro que hay alguna mas que espero me conteis.

Besos y abrazos.

Links imprescindibles:

Listar cuentas de servicio en nuestros servidores con Powershell.


Hola a todos,

Me he encontrado este post que tenía guardado desde hace …. un año o_O  . Otra píldora sobre Powershell, ese gran y desconocido amigo que nos hace las tareas administrativas mucho más fáciles.

“Hace poco (ahora hace un año!!!), me pidieron chequear con qué usuario se estaban ejecutando cada servicio en todos los servidores y me dije, esto con Powershell seguro que lo hacemos sin ningún problema”

Estube buscando como enfocarlo y pensé que si tenía la lista de todos los servidores podía volcarla  a un fichero de texto y, despues, chequear y obtener las cuentas que ejecutan los servicios. Eso es!!! 😀

Primero necesitamos un fichero txt con un listado de los servidores, en este caso no eran mas de 10 y lo denominaremos “Server_list.txt“, super ocurrentes los nombre que pongo 😉

Y también, había visto cómo obtener los servicios de un servidor, utilizando Get-WmiObject Win32_service para recuperar la información sobre un objeto de un servicio.

Hice un par de pruebas y me quedé con este script:

$server_names = Get-Content "C:Servers_list.txt"
Foreach ($server in $server_names){
Get-WmiObject Win32_service | Where-Object {$_.state -eq "Running"} | Group-Object -Property StartName | Format-Table $server,Name, Count -auto >> c:ServiceAccounts.txt
}

El resultado es un listado del número de servicios que cada usuario ejecuta en cada servidor. Et voilá!!!

De esta primera prueba se pueden hacer variaciones con permutaciones y obtener fantásticos resultados, detalle que os recomiendo encarecidamente y me los hagais llegar.

Que tengais muy buena semana….

Windows Management Framework (WMF) 5.0 RMT disponible via Catálogo de Microsoft Update.


Buenos y felices dias,

Despues de estas fiestas y una cantidad ingente de torrijas os comparto esta noticia: “Windows Management Framework (WMF) 5.0 RMT disponible via Catálogo de Microsoft Update”

El equipo de Powershell anunció el pasado día 21 la disponibilidad de WMF 5.0 RTM via Microsoft Update Catalog, , con lo que ya no tenemos escusa para desplegar a gran escala la última versión de Powershell. Podemos realizarlo a través de WSUS o System Center Configuration Manager (SCCM) para instalar WMF 5.0 en todos nuestros sistemas.

Podemos descargarnos los paquetes de WMF 5.0 usando los siguientes KBs:

  • KB3134758 para Windows Server 2012 R2 y Windows 8.1
  • KB3134759 para Windows Server 2012
  • KB3134760 para Windows Server 2008 R2 SP1 y Windows 7 SP1

Nota Importante:  Antes de instalar los paquetes de WMF 5.0, tenemos que asegurarnos de los siguientes puntos:

Buena semana a todos,

Powershell – Modificar atributos de un objeto de directorio activo. Ruta de acceso al perfil de usuario..


Buenos días,.

Hoy nos toca píldora de Powershell y Directorio Activo (AD). Hace tiempo me solicitaron modificar la ruta de acceso al perfil de usuarios, concretamente dejar este atributo vacio para todo los usuarios ya que se iba a dejar de utilizar perfiles móviles.

Podemos consultar el valor de este campo si editamos cualquier usuario de AD desde la consola de Usuarios y Equipos, por ejemplo, en la pestaña de “Perfil” o “Profile”

Lo vamos a enfocar en dos partes, la primera encontrar todos los usuarios que tengan  el campo “Profilepath” con contenido. Y el segundo borrar el contenido de dicho campo, todo ello en un mismo cmdlet entubado …..

  • Parte 1: Nos lista todos aquellos usuarios en los cuales tenemos establecidos valores en el campo perfil.
    • get-aduser -filter “profilepath -like ‘*'” -Properties profilepath | ft name,profilepath

En este caso, podeis ver tanto el nombre de usuario como la carpeta compartida donde se encuentra ubicado su perfil (he obviado la información que no nos interesa ;-))

PSAD000006

Otro ejemplo, si a mi cuenta de AD le pongo que la ruta del perfil sea “aaaaaa”, o “bbbbbb”, y lo consulto con el cmdlet:

PSAD000002 PSAD000001

  • Parte 2: Nos establece el campo perfil (profilepath) como nulo:
    • Set-Aduser Filtro de usuario –profilepath $null

 Nos quedaría de la siguiente manera:

  • get-aduser -filter “profilepath -like ‘*'” -Properties profilepath | Set-Aduser  –profilepath $null

PSAD000003

Nada de nada, correcto. Hemos dejado en blanco todas las rutas de perfiles de usuarios.

Espero que os sea útil y os animeis a utilizar Powershell, ese amigo desconocido.

Besos y abrazos,

Algunos cmdlets interesantes de Directorio Activo … gracias a un “Rap as a Service”.


Hace muy poco nos hicieron un “Rap”, o lo que antes conocíamos como un ADRAP (Risk And Helath Assessment Program for Active Directory), o sea un análisis de un Directorio Activo por parte de Microsoft para ver su situación en cuanto a Salud, riesgos, etc., Ahora se realiza desde la nube y se denomina “RAP as a Service for Active Directory”

RAPasAservices00002

Bueno no me enrollo mas. Recibida la visita del Ingeniero de AD y PKI de Microsoft nos dejó estas perlias para nuestro y vuestro conocimiento:

Equipos del dominio que no han cambiado su password en los últimos 30 días:

$d = [DateTime]::Today.AddDays(-30)
Get-ADComputer -Filter ‘PasswordLastSet -lt $d’ -Properties PasswordLastSet | FT Name,PasswordLastSet

Name                                                        PasswordLastSet
—-                                                        —————
SORM04                                                    24/01/2011 16:50:05
BGTZA                                                     05/03/2011 9:57:30
ADRAPZ                                                   07/07/2008 19:25:03
EAVZA                                                     08/10/2012 9:55:36
EMDZA                                                     01/11/2012 1:20:41
EPCPA                                                     29/03/2007 16:28:29
EPCPB                                                     10/04/2007 12:06:24
ECODA                                                     02/05/2010 15:16:29
PASIFAE-1                                                   26/04/2006 9:57:50
PASIFAE-2                                                   24/04/2006 11:02:48
RPEDA                                                     09/03/2013 22:06:11
RBEFA                                                     16/10/2013 3:33:03
RBEDA                                                     13/11/2013 0:37:29
RBEPA                                                     17/11/2013 10:58:14
ECRDB                                                     20/11/2013 18:55:23
ECRFA                                                     16/12/2013 20:10:19
EWEZB                                                     06/03/2014 21:22:39
EWEZA                                                     12/04/2014 23:01:42
EFTZZ                                                     27/05/2014 7:15:22
ERGFA                                                     30/03/2014 6:14:31

Demasiados sin reportar ….

Usuarios del dominio que no han cambiado su password en los últimos 180 días:

$d = [DateTime]::Today.AddDays(-180)
Get-ADUser -Filter ‘PasswordLastSet -lt $d’ -Properties PasswordLastSet | FT Name,PasswordLastSet

El resultado lo he volcado a un fichero LastPassword.xls del cual no os puedo extraer información. Sorry. Pero podeis ver una mala práctica y ejemplo del administrador….

RAPasAservices00004

Usuarios con Password no requerida:

Get-ADUser -Filter ‘useraccountcontrol -band 32’ -Properties useraccountcontrol | FT Name

Name
——————–
Administrador
IUSR_CAZA
IUSR_CAZAM
IWAM_CAZA
IWAM_CAZAM

En este caso solo nos sale cuentas de servidores antiguas y una de “Administrador”, jejejejeje.

Usuarios que tienen configurado que su Password nunca expira:

Get-ADUser -Filter ‘useraccountcontrol -band 65536’ -Properties useraccountcontrol | FT Name |  Out-File c:useraccountcontrol.txt

Os podeis imagar el número de usuarios que me salian… he preferido dejaros solo el cmdlet.

Y este es el resultado final. No está mal para ser una DMZ:

RAPasAservices00001

 

 

Siento no estar últimamente “on fire” pero …. se aproximan grandes cambios en mi vida, sobre todo laboralmente hablando y …. apenas me queda tiempo para compartir con todos vosotros.

Que tengais una muy buena semana.

Errores de NETLOGON “NO_CLIENT_SITE” Parsear con Powershell.


Buenos dias,

Os dejo con otra píldora formativa de Directorio Activo (AD9. Es relativamente habitual encontrar en nuestros controladores de dominio el siguiente evento de error tipo:

Log Name:      System
Source:        NETLOGON
Date:          04/09/2014 12:50:53
Event ID:      5807
Task Category: None
Level:         Warning
Keywords:      Classic
User:          N/A
Computer:      ROBDCA.zalo.com
Description:
During the past 4.25 hours there have been 517 connections to this Domain Controller from client machines whose IP addresses don’t map to any of the existing sites in the enterprise. Those clients, therefore, have undefined sites and may connect to any Domain Controller including those that are in far distant locations from the clients. A client’s site is determined by the mapping of its subnet to one of the existing sites. To move the above clients to one of the sites, please consider creating subnet object(s) covering the above IP addresses with mapping to one of the existing sites.  The names and IP addresses of the clients in question have been logged on this computer in the following log file ‘%SystemRoot%debugnetlogon.log’ and, potentially, in the log file ‘%SystemRoot%debugnetlogon.bak’ created if the former log becomes full. The log(s) may contain additional unrelated debugging information. To filter out the needed information, please search for lines which contain text ‘NO_CLIENT_SITE:’. The first word after this string is the client name and the second word is the client IP address. The maximum size of the log(s) is controlled by the following registry DWORD value ‘HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNetlogonParametersLogFileMaxSize’; the default is 20000000 bytes.  The current maximum size is 20000000 bytes.  To set a different maximum size, create the above registry value and set the desired maximum size in bytes.

Básicamente, esto quiere decir que hay equipos que tienen asignada una subred que no está dada de alta en Directorio Activo, concretamente en Active Directory Sites and Services (ADS&S). Esto puede dar lugar a problemas a la hora de hacer Logon o conectarse al dominio por parte de dichos equipos. Y ¿cómo lo solucionamoes? pues revisándonos el fichero NETLOGON.log de cada Controlador de Dominio y buscando aquellos errores de NO_CLIENT_SITE, o clientes sin Site definido.

Pues como ha caido en mis manos un post del Blog de Simon Wahlin de cómo utilizar PowerShell (PS) para analizar el fichero NETLOGON.log pues vamos al lio utilizando el siguiente script Get-MissingSubnets.ps1 que lo podemos descargar desde aqui.

SINTAXIS

La sintaxis de Get-MissingSubnets.ps1 es la siguiente:

.Get-MissingSubnets.ps1 [[-NumLines] <Int32>] [[-DomainControllers] <String[]>] [-IncludeTimestamp] [<CommonParameters>]

Donde podemos seleccionar los siguentes parámetros:

  • Get-MissingSubnets.ps1  sin ningún parámetro, nos mostrará el parseo de todas las subredes de todos los Controladores de Dominio.
  • Get-MissingSubnets.ps1 -NumLines <int32> donde analizará las últimas líneas que le hayamos especificado. Por defecto son las 100 últimas.
  • Get-MissingSubnets.ps1 -DomainControllers <String> donde analizará únicamente el Controlador de Dominio que le indiquemos.
  • Get-MissingSubnets.ps1 -IncludeTimestamp <CommonParameters> podemos especificar si el timestamp puede ser leido o o no del fichero netlogon. Si el timestamp está deshabilitado en cada Controlador de Dominio seleccionaremos la opción $false.

EJEMPLO

Os dejo un ejemplo sencillo como real.

Ejecuto el script sin parámetro alguno, asi que va a consultar las 100 últimas líneas del fichero NETLOGON.log en cada Controlador de Dominio (DC), con el siguiente resultado:

NetlogonParsePS000005

Por lo tanto tenemos equipos que acceden desde una subred 10.13.120.0/24 o una subred 10.13.32.0/24 a nuestros DCs y no está definida dicha Subnet, como podemos comprobar:

NetlogonParsePS000003

Añadimos dicha subred a AD Sites & Services y solucionado.

Recordar que para ejecutar este script …. tenemos que tener una Política de Ejecución de Scripts adecuada, como para este ejemplo:

NetlogonParsePS000004

Que tengais una buena semana.

Lecturas recomendadas:

Blog de Simon Wahlin.

Blog de Jorge’s Quest For Knowledge!

Migrar roles FSMO mediante Powershell.


Buenos dias,

Hoy os dejo otra píldora formativa de PowerShell y Directorio Activo (AD). ¿Como migrar los roles Flexible Single Master Operations (FSMO) de AD a través de Powershell? En Castellano son los Controladores de Dominio (DC) Maestros de Operaciones.

Cmdlet

El cmdlet a utilizar es Move-ADDirectoryServerOperationMasterRole donde podremos especificar los siguients parámetros, entre otros:

  • Identity .- El DC destino/target.
  • Server.- Especificaremos la Instancia de AD a conectarnos y su puerto.
  • Force.- Si queremos forzar el traspaso de los Roles FSMO. Este lo utilizaremos normalmente cuando el DC origen está inaccesible, offline o desaparecido en combate.
  • Confirm.- Nos preguntará para confirmar la ejecución del cmdlet antes de su ejecución ($true | $false)
  • OperationMasterRole.- Aqui podemos especificar directamente el rol FSMO o su número. Os dejo la tabla de conversión:

FSMO_PS_000003

  • Whatif.- Que os puedo decir, que conviene utilizarlo antes, para asegurar.

Sencillo a la par que muy potente. No lo olvideis.

Ejemplos:

Queremos mover el rol PDC Emulator desde el DC A al DC B.

Para empezar comprobamos qué DC tienes los roles FSMO: un simple Netdom /query FSMO. Todos están en el A.

FSMO_PS_000001

Ejecutamos  nuestro cmdlet y comprobamos si se ha transferido el rol PDC Emulator. Como soy un valiente en la primera ejecución he utilizado el parámetro -WhatIf 😉

FSMO_PS_000004bis

Role transferido al B. Correcto.

Queremos mover todos los roles FSMO al DC B.- Mas de lo mismo, compruebo que todo está en el DC A, muevo los roles y compruebo que todo está en el DC B:

FSMO_PS_000005bis

No he comentado nada pero supogno que sabreis que antes de realizar cualquiera de estas operaciones hay que cargar el módulo de PS de Directorio Activo:

FSMO_PS_000002

Que tengais buena semana.

Depromocionar un Controlador de Dominio que también es una Entidad Certificadora. Un poco mas dificil .. o no!


Hoy es dejo esta perlita informativa sobre cómo quitar un controlador de dominio  que, además es la Entidad Certificadora, todo ello sin que haya pérdida del servicio, y vuelva a la normalidad, vamos, sin que pase nada, sobre un Windows Server 2003.

Los siguientes gráficos nos muestran cómo es la situación inicial y cómo queremos que sea la final, el camino ….. se hace al andar.

Antes

Antes

Despues

Despues

Nuestro objetivo es empezar a eliminar servicios publicados en Windows Server 2003 y elevar la funcionalidad de nuestro dominio DMZ.com a Windows Server 2008 R2 o superior.

Lo normal en estos casos es buscar un poco de información en Internet, como apoyo, ver HowTo, documentos, experiencias de otros Administradores. Si haces una búsqueda en Google sobre “Migrar entidad certificadora” aparecen los siguientes items:

Migrate00001

Es un honor para mi compartir links de resultados con dos gurus de la tecnologia, maese Josep Ros (@josepros),  y el Gran Bujarra 3.0, (Hector Herrero (@nheobug). Apuntaros sus twitters y sus blogs ya que son dos referentes del panorama IT en castellano.

Los pasos a seguir serán los siguientes:

  • Copia de seguridad de nuestra CA.
  • Eliminar el Rol de CA.
  • Realizar un DCPromo.
  • Volver a instalar el rol de CA.
  • Verificar el entramado

0 Realizar Copia de Seguridad de la Entidad Certificadora.

Este es el punto inicial para la gran mayoria de actuaciones, tener o realizar una copia de seguridad. Este punto ya lo hemos visto en un post del mes pasado “Migración de una Entidad Certificadora de Servidor. Parte I – Exportación“.

Migrate00007

Poco o nada puedo aportar. Hago un breve resumen:

  • Realizar Backup de la CA.
  • Exportar la configduración del registro de nuestra CA.

1 Eliminar Rol de Entidad Certificadora (CA).

Como es un Windows Server 2003 desde Panel de Control, agregar o quitar programas, procedemos a eliminar el rol de Certificate services:

DesinstallCAwithDCPromo00001

También se reconfigurarán los servicios de IIS

DesinstallCAwithDCPromo00002

Y finalizará exitosamente:

DesinstallCAwithDCPromo00003

Como veis, muy sencillo este paso.

2 Depromocionar el rol de Controlador de Dominio.

Lanzamos a nuestro gran amigo “DCPromo”, ya desaparecido en Windows Server 2012 y 2012 R2, apareciéndonos el asistente de “depromoción” de Controlador de Dominio de Directorio Activo (AD):

DesinstallCAwithDCPromo00004

En nuestro caso no es el último controlador del Dominio, asi que dejaremos en blanco esta selección:

DesinstallCAwithDCPromo00006

Pondremos password a la cuenta de Administrador local del servidor, ahora que va a dejar de ser Controlador de Dominio:

DesinstallCAwithDCPromo00007

Un pequeño detalle, puede aparecer que este Controlador de Dominio tambén sea Catálogo Global (GC), por lo que tendremos que quitar éste rol antes de proceder a realizar el Depromocionado. Continuamos y, nos informa que va a proceder a eliminar el rol de Controlador de Dominio del dominio DMZ.com:

DesinstallCAwithDCPromo00008

Procederá a parar servicios como NETLOGON:

DesinstallCAwithDCPromo00009

El servicio RPCLOCATOR:

DesinstallCAwithDCPromo00012

Y eliminando LDAP así como RPC:

DesinstallCAwithDCPromo00013

Nos informará, nuevamente, de que ha sido eliminado el rol de DC:

DesinstallCAwithDCPromo00014

No hay que olvidarse que este proceso, obligatoriamente, requiere un reinicio:

DesinstallCAwithDCPromo00015

O sea, este servidor ya no es ni Controlador de Dominio del dominio DMZ.com, ni Entidad Certificadora de dicho dominio, ya no es nadie, jejejeje.

3 Instalación del Rol Entidad Certificadora.

Llegamos al ecuador de nuestro post del dia. Ahora llega lo mas dificil. Ya hemos visto como montar un Entidad Certificadora en un post del mes pasado “Migración de una Entidad Certificadora de Servidor. Parte II – Importación“, concretamente en el primer punto de post veiamos como montar una CA sobre Windows Server 2008 R2, pero, en este caso es una CA en Windows Server 2003. Es muy parecido, por no decir que igual.

Desde Panel de Control, Agregar o quitar programas:

DesinstallCAwithDCPromo00017

Seleccionaremos el rol de Certificate Services. Posteriormente nos aparecerá el tipo de Entidad Certificadora queremos instalar, en nuestro caso Enterprise root CA:

DesinstallCAwithDCPromo00019b

Continú la instalación y nos pregunta sobre la Clave Pública y la Clave Privada. Como hemos hecho una copia de seguridad en el paso Cero, lo podemos restaurar ahora, o cuando se termine de instalar el rol. Si restauraremos ahora la clave pública:

DesinstallCAwithDCPromo00020

Nos informa de si queremos sobreescribir, ya que los ficheros existen del paso 1:

DesinstallCAwithDCPromo00021

También podremos seleccionaremos nuestro CSP y el algoritmo Hash:

DesinstallCAwithDCPromo00022

Nos informará sobre la identificación de nuestra Entidad Certificadora, Common name, Distinguished name y la validez de la misma:

DesinstallCAwithDCPromo00023

Seleccionaremos las rutas de la base de datos y los logs. En la captura vienen las rutas por defecto:

DesinstallCAwithDCPromo00024

Nos avisará que los servicios de IIS se pararán durante la instalación…

DesinstallCAwithDCPromo00025

Reinstalación de los servicios de IIS:

DesinstallCAwithDCPromo00026

Y ya está instalado el rol.

Como he comentado antes, podíamos realizar una instalación con todos los parámetros por defecto y posteriormente restaurar el backup y la clave del registro con toda la configuración que funcionará perfectamente, esta opción también la hemos comentado el mes pasado en el siguiente post “Migración de una Entidad Certificadora de Servidor. Parte II – Importación“. Aunque … Lo dejo a vuestra elección.

4 Chequeo de funcionamiento.

Nos faltaría realizar las comprobaciones pertinentes, os dejo los chequeos principales, que ya hemos visto en el Chequeo de la Entidad Certificadora:

  • Podemos acceder al certificado de la CA y comprobar todas sus características.
  • Que todos los certificados emitidos por la CA siguen funcionando correctamente.
  • Que podemos emitir nuevos certificados que sirven a su función.
  • Que vemos todas las plantillas que se publican en Directorio Activo.
  • Podemos ver todos los certificados revocados,
  • Podemos visualizar los certificados emitidos por la anterior CA.
  • Podemos acceder a la lista de revocación de certificados (CRL).
  • Comprobar todas las Extensiones tanto del Punto de distribución de la CRL como del Acceso a la Información de la Autoridad (AIA), etc.,

 

Y también nos faltaría realizar las comprobaciones pertinentes en los Controladores de Dominio:

  • Verificar el estado lanzando la herramienta DCDIAG.
  • Echar un vistazo a los visores de eventos tratando de encontrar algún error.
  • Verificar la replicación entre los Controladores de Dominio existentes, por ejemplo con repadmin o con “AD Replication Status Tool
  • etc.

Pues ya estaría.

Si quería dejaros un pequeño listado de errores que me han aparecido en este proceso:

  • El Controlador de Dominio Windows Server 2003 también es Catálogo Global.- Tenemos que quitar el rol de Catálogo Global antes de realizar el DCPromo.

DesinstallCAwithDCPromo00005

  • En el proceso de Depromocionar nuestro Controlador de Dominio nos ha dado un error de  “time out” a la hora de reiniciar el servicio NETLOGON.- Esto es algo, relativamente normal. Así que vuelves a lanzar el proceso de DCPromo y solucionado.

DesinstallCAwithDCPromo00010

  • Error a la hora de importar Backup de la Entidad Certificadora.- Suele pasar al tratar de restaurar un backup de la base de datos de la CA sobre un directorio que ya contiene datos. Tiene que estar en blanco.

DesinstallCAwithDCPromo00033

  • Error de Caché en el Pool de Aplicación que utiliza la Entidad Certificadora.- Esto pasa porque el usuario con el que se ejecuta el Pool de Aplicación no tiene permiso en una serie de directorios de C:. Se dan los permisos y funcionando.

DesinstallCAwithDCPromo00035

Todos ellos fáciles de solucionar. Para que luego digan que todo sale a la primera, o a la segunda. Normalmente hay que ir solucionando algún que otro error.

Espero que os haya gustado y, sobre todo, que os sea util. Buena semana a todos.

Referencias:

Blog de Josep Ros.

Blog del Bujarra 3.0.

Elevar el nivel funcional de un dominio con PowerShell.


Buenas tardes,RDFFL000004

¿Qué es el “Nivel funcional de un Bosque” o de un Dominio? El nivel funcional determina las capacidades y bondades que están disponibles de nuestro Bosque o Dominio de Directorio Activo (AD). Hay que tener en cuenta que este nivel funcional también determina que sistemas operativos Windows Server puedan ser Controladores de Dominio. Los sistemas operativos clientes quedan exentos.

Otro punto muy importante es que el Nivel funcional del Bosque determina el nivel funcional mínimo de todo dominio incluido en el mismo, o sea, que ningún dominio incluido en nuestro bosque puede tener un nivel funcional inferior al nivel funcional del bosque. Si pueden tener un nivel funcional superior. En resumen:

Nivel funcional del Bosque <= Nivel funcional del Dominio

En nuestro post trataremos de elevar el nivel funcional de un Bosque y Dominio Windows Server 2003 a Windows Server 2008 R2 utilizando Powershell. Empezamos.

Primero, como paso necesario, importamos el módulo de PowerShell para Directorio Activo:

Import-Module Active Directory

RDFFL000005

Para despues consultar la funcionalidad tanto del dominio como del bosque actual:

Get-ADForest

RDFFL000006Get-ADDomain

RDFFL000007

Una vez comprobado procedemos, primero con el Dominio y luego con el Bosque:

Dominio

Set-ADDomainMode -Identity “Dominio” -domainMode Windows2008R2Domain -confirm:$false

RDFFL000008

Comprobamos de una manerá gráfica que el dominio tiene una funcionalidad distinta del bosque:

RDFFL000009

Bosque

set-adforestmode –identity “netbiosname” windows2008R2Forest –confirm:$false

RDFFL000010

En este caso he ejecutado el cmdlet sin el parámetero -confirm, para que se vea claramente que nos pide confirmación. Al igual que en el caso anterior, comprobaremos gráficamente la situación final:

RDFFL000011

Lo habitual es que este proceso se realice a través de las consolas de gestión de Directorio Activo. Os dejo unos videos que nos muestra cómo hacerlo, hay muchos por internet. No tienen pérdida:

Este primero en ingles:

Este segundo en castellano:

Downgrade.

Ya para terminar, Una de las bondades incluidas a partir de Windows Server 2008 R2 es la siguiente. Si tenemos nivel funcional de Bosque o Dominio Windows Server 2008 R2 o superior si podemos realizar el paso inverso al que acabamos de hacer, en vez de elevar sería degradar. Obligatoriamente se tiene que realizar por PowerShell.

He visto que se pueden hacer las siguientes degradaciones: de Windows Server 2008 R2 a Windows Server 2008 y de Windows Server 2012 a Windows Server 2008 R2. El resto tendré que investigarlo.

Lecturas recomendadas:

Todo esto es extrapolable cuando queremos elevar el nivel funcional del Bosque o Dominio para Windows Server 2012 y Windows Server 2012 R2.

Buen fin de semana a todos.

¿Elimino las direcciones X.400 de mi infraestructura de correo Exchange?


Buenas tardes,

Hoy vamos a hablar sobre un tipo de direcciones de correo que habitan el universo Exchange. Las direcciones, x.400,  Éstas, eran requeridas por servidores de correo Microsoft Exchange Server 2003 y anteriores, y que ahora nos aparecerán en el caso de que hayamos ido migrando de infraestructura en infraestructura, ya que van unidas a la Default Recipient Policy. En aquellos entornos de correo con versiones superiores a Exchange 2000 o Exchange 2003 se pueden eliminar ya que carecen de funcionalidad alguna.

powershell_2

¿Cómo lo hacemos de una manera sencilla, rápida y transparente? pues con qué va a ser, con PowerShell.

En el MsExchange Blog Spot Telnet25 nos facilitaban hace unos meses un script de Powershell que nos hacía todo el trabajo

 foreach ($mbx in (get-mailbox -resultsize unlimited ))

{$addrs = $mbx.emailaddresses |? {$_.prefixstring -ne “x400”}

set-mailbox $mbx -emailaddresses $addrs -whatif

}

Pero ¿quién ejecuta un Script ajeno en Producción a Puerta gayola? Yo no. Primero vamos a chequear si mi usuario tiene dirección X.400, ejecutamos los siguientes cmdlets:

x400_00001

Efectivamente, mi infraestructura se ha ido migrando de versión de Exchange en Exchange, desde la 2000, así que tengo dirección X400.

Una vez comprobado y entendido qué hace el script, procedo a su ejecución ….. con mucho miedo, o sea, primero en mi entorno de pruebas y con la opción -Whatif  y si todo va bien, en producción (como podeis ver):

x400_00002

Y una vez ejecutado en producción, este es el resultado:

x400_00003

En el caso de que tengais también las direcciones X400 en los Grupos de Distribución, pues probad con el siguiente script de PowerShell:

 foreach ($mbx in (Get-DistributionGroup -resultsize unlimited)){
$addrs = $mbx.emailaddresses |? {$_.prefixstring -ne “x400”}
Set-DistributionGroup $mbx -emailaddresses $addrs -whatif
}

Espero que os sea util. Que tengais buena semana.

Lecturas Recomendadas:

MsExchange Blog Spot Telenet25.

Exchange Forum.

masrobeznoquenunca

Comparto lo que hago y lo que veo.

El camino de un ITPro

El camino de un ITPro

adumont

Just another WordPress.com weblog

Marco Antonio's space

Una mirada dentro de mis ratos libres...

Marcelo Ruiz

Network and SocialMedia

A Digital Frontier...

Blog personal de Robert Garrandés Simancas ("Versión Beta")

enero11

Literatura para romper el tiempo.

A %d blogueros les gusta esto: