Archivo de la categoría: Powershell

Actualizar Azure Powershell.


Buenas y fresquitas tardes. Creo que este es mi primer post en Domingo!!!

Hace poco vimos cómo instalar Azure Powershell, sencillo y, a partir de ahora, veremos que muy util. Pues bien hoy en esta píldora os explicaré cómo tener actualizado nuestro Azure Powershell, instalar versiones en paralelo y tener los distintos módulos de Azure a la última versión.

Antes de continuar, me gustaría comentar rápidamente que Azure Powershell utiliza un control de versiones semántico. pero …..  ¿y que carajo signfica esto?

Bien, significa que si la versión de Powershell A es mayor que la versión B, A > B, la versión A tiene las API más actualizadas, obviamente. Microsoft declara una API pública, con una nomenclatura X.Y.Z, donde X es la versión “major”, Y es la versión “minor” y Z es el “patch” de la versión. Para más información sobre los procedimientos de Versionamiento Semántico en Azure PowerShell, consulte su especificación en: http://semver.org , se trata de evitar los terribles problemas del “infierno de las dependencias” al ir actualizando versiones.

Las formas que habiamos visto para instalar powershell eran:

  • A traves de Web Platform Installer, herramienta que nos permite instalar automáticamente componentes, mucho contenido web (IIS) asi como paquetes individuales como herramientas de administración de Azure a través de PowerShell, Windows Azure Pack, etc.
  • O desde la Galería de PowerShell, usando PowerShell Get. De esta manera instalamos Azure Powershell a través de la consola de Powershell.

Si continuamos con el ejemplo del post que he comentado al principio, donde habiamos instalado Azure Powershell. Si ejecutamos el siguiente cmdlet:

Get-Module PowerShellGet -list | Select-Object Name, Version, Path

Nos muestra el nombre, versión y ruta del módulo de Powershell. Y si ejecutamos:

Get-Module AzureRM -list | Select-Object Name,Version, Path

Tanto para Azure como para AzureRM obtendremos los mismos resultados …. o no:

Esto nos indica que si hemos instalado Azure Powershell pero para ASM, no el módulo para ARM 😉 Bien, pues procedemos a instalar modulo de Azure Resorce Management

Hay que tener en cuenta que los módulos de Azure y AzureRM tienen dependencias en común, por lo que si actualizamos uno, automáticamente se actualiza el otro.

Procedemos a Instalar el módulo de powershell de AzureRM

install-module -name AzureRM

Nos aparece el mensaje anterior indicándonos que PowerShellGet requiere la versión del proveedor NuGet 2.8.5.201 o superior, para interactuar con cualquier repositorio basado en NuGet. Bien pues aceptamos la instalación e importación de dicho paquete. Se descarga y nos informa que estamos instalando los módulos de AzureRM desde un repositorio que no es de confianza ¿que hacemos? …. continuamos, pues

Observamos el proceso de instalación y

Tachan … comprobamos si ahora están instalados ambos módulos

Otro detalle interesante, es la posibilidad de instalación de versiones de módulos en paralelo. Concretamente, a partir de la versión 2.1.0, y la 1.2.6 para AzureStack, ya que fueron diseñados para poder usarse en paralelo. Esto nos ocurriría, por ejemplo, si tenemos scripts escritos con una versión anterior de Azure PowerShell y no tenemos ni recursos ni tiempo para actualizarla.

Como se puede ver, podemos instalar diversas versiones del módulo de AzureRM de Powershell:

Install-Module -Name AzureRM -RequiredVersion 3.7.0
Install-Module -Name AzureRM -RequiredVersion 1.2.9

pero, solo una de ellas se puede cargar por sesión de PowerShell. Tendremos que abrir una nueva ventana de PowerShell y realizar una tarea de importación de la versión específica que necesitemos de los cmdlets de AzureRM:

Import-Module AzureRM -RequiredVersion 1.2.9

Para terminar, ¿cómo podemos tener actualizados los modulos de Powershell? a la ultimísima …. con el cmdlet Update-Module. Vemos un ejemplo. Ejecutamos el cmdlet con el swithc -whatif

Vemos que si que hay una actualización en el módulo AzureRM.Profile …. pues actualizamos

Que tengais una buena semana, ya llegan las vacaciones!!!

Azure Cloud Shell ahora supervitaminada con Powershell!!!


La pasada semana hablábamos de Azure Cloud Shell, que ya estaba entre nosotros, y bla, bla, bla, bla, bla, También comentaba que podiamos ver que estaba previsto también una shell de Powershell …

Pues, lo dicho, ya está aqui, entre comillas. Esta shell nos proporciona todos los beneficios que ya comentamos en el post anterior y, adicionalmente nos provee de:

  • Azure namespace capability.- nos permite descubrir y navegar facilmente entre todos los recursos de Azure

  • Interaction with VMs.-  nos permitirá una gestión totalmente transparente en nuestras guest VMs.

  • Extensible model.- Nos permitirá importar cmdlets adicionales asi como poder correr cualquier ejecutable.

Puedes participar en una preview limitada para utilizar esta impresionante característica:  Sign-up today

Rellena este formulario y ….. a darle caña!!! Para mas información: Sneak Peek – Powershell in Azure Cloud Shell.

Buen fin de semana, que con la llegada de mi pequeño se me había pasado publicar este post. Abrazos

Azure Cloud Shell ya está aqui!


La pasada semana apareció la funcionalidad de Azure Cloud Shell en disponibilidad general en la Microsoft’s Build Conference  …. y ¿que es?¿cómo funciona?¿qué puedo hacer con ella? Os dejo unas pinceladas de todo su potencial, el resto ….. hay que descubrirlo 😉

Azure Cloud Shell nos ofrece una experiencia de Shell preconfigurada, accesible desde el navegador, para gestionar los recursos de Azure sin la sobrecarga que nos supone la instalación, versionado y mantenimiento de un servidor dedicado para este fin, sin olvidarnos de una gran variedad de herramientas directamente desde nuestro navegador favorito a través del Portal de Azure.

Hay que tener en cuenta que Cloud Shell se autentica en cada sesión que abramos a través de Azure CLI 2.0

Otros puntos a tener en cuenta son:

  • Cloud Shell  se ejecuta en una máquina temporal que se proporciona por sesión y por usuario.
  • Cloud Shell se cerrará despues de tener 10 minutos de inactividad.
  • Cloud Shell solo puede ser accedida a través de un recurso compartido.
  • Los permisos se establecen como un usuario normal de Linux.

Ademas, estas son las Herramientas y características incluidas:

  • Interpretes de Shell de Linux.-
    • Bash
    • SH
  • Control de fuentes.-
    • Git
  • Containers.-
    • Docker
    • Kubectl
    • DC/OS CLI
  • Bases de datos
    • PostgreSql client
    • MySQL client
    • sqlcmd Utility
  • Herramientas de Azure.-
    • Azure CLI 2.0
    • Azure CLI 1.0
  • Editores de texto:
    • vim
    • nano
    • emacs

Y, lo que parece una primicia … Azure Powershell 3.0, la caña!!!

Como las máquinas que se utilizan para Cloud Shell son temporales se requieren que se instale un “Recurso Compartido” para ser montado de manera persistente el directorio $Home.

Cuando lo configuramos/abrimos por primera vez, Cloud Shell nos solicita la creación de un Grupo de Recursos, una cuenta de almacenamiento y un recurso compartido

Esta cuenta de almacenamiento es LRS, las tres réplicas locales de rigor. El Recurso Compartido es un Azure Files de 5GB.

Este paso solo ocurrirá la primera vez, luego ….. coser y cantar!!!

Y para terminar …

Listos para empezar.

Que tengais buena semana.

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.

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: