PowerShell y los comandos de inicio en Dynamics AX 2012 (PS-III)

En los primeros artículos de esta serie, aprendimos las bases de PowerShell en general, y cómo utilizar librerías de cmdlets extra, incluyendo las que vienen con Microsoft Dynamics AX 2012 y permiten muchas acciones que facilitan la administración y el mantenimiento. PowerShell - jaestevan.com

Pero para poder utilizar PowerShell en nuestros sistemas DevOps reales, debemos unirlo todo y utilizar tanto cmdlets específicos, como la potencia de PowerShell para poder ejecutar todos los pasos necesarios en un despliegue típico de AX, y en muchas otras tareas de mantenimiento.

Empecemos con PowerShell estándar

Por ejemplo podemos utilizar los comandos base de PowerShell para buscar si en el sistema existe un AOS con un determinado nombre, e iniciarlo si no lo está, de esta forma (probablemente no es la mejor forma, pero resulta ilustrativa para este caso):

powershell-aos-service

$AxAOSName = "MicrosoftDynamicsAX"

$svcAOS = Get-Service AOS60* | Where { $_.DisplayName.EndsWith($AxAOSName) } -ErrorAction SilentlyContinue
if (-not ($svcAOS.Length -gt 0))
{
    throw "AOS service " + $AxAOSName + " can not be found."
}

Write-Host "AOS:" $svcAOS.DisplayName

if ($svcAOS.Status -ne 'Running')
{
    Start-Service $svcAOS -PassThru
}

Continue Reading…

PowerShell para la administración automática de Dynamics AX 2012 (PS-II)

En la primera entrega de esta serie sobre PowerShell y DevOps para Microsoft Dynamics AX 2012  hablábamos sobre los principios más básicos de PowerShell y su sintaxis. También vimos en post anteriores como PowerShell se puede usar de formas bastante creativas.

Keyboard

Esta vez vamos a ver los comandlets específicos para la administración de Microsoft Dynamics AX 2012, que podemos separar en varias familias:

Gestión de Modelos y la Model Store

Estos comandlets son muy importantes y van a ser la base de nuestra estrategia DevOps, combinada con los procesos builds automáticos que tendremos configurados en nuestro TFS, si es que los utilizamos.

La combinación de estos componentes va a permitirnos diseñar procesos que actualicen automáticamente nuestros entornos, orientando nuestros procesos hacia la integración o el despliegue continuo de nuestros entornos, especialmente entornos de desarrollo y/o pruebas. Hablaremos sobre esto en los siguientes posts de esta serie.

Estos son los que normalmente utilizamos para estas tareas, aunque vale la pena echar un vistazo a la referencia completa porque todos pueden ser útiles para tareas concretas o para scripts que automaticen tareas más completas:

Modelos

Comando Descripción
New-AXModel  Crea un nuevo modelo en la Model Store
Uninstall-AXModel  Elimina un modelo de la Model Store
Install-AXModel  Importa un modelo (desde un fichero) en la Model Store
Export-AXModel  Exporta un model de la Model Store a un fichero .axmodel
Move-AXModel  Mueve los objetos de un modelo a otro modelo, combinando todos los objetos en este último.

Continue Reading…

Introducción a PowerShell para desarrolladores Dynamics AX 2012 (PS-I)

PowerShell (lo abreviaremos PS en lo sucesivo) es una herramienta impresionante, entre otras cosas, para la administración de nuestros servidores y aplicaciones, y eso incluye, por supuesto, nuestro Microsoft Dynamics AX 2012. Con esta versión se incluye un módulo propio de PS al que llama “Microsoft Dynamics AX 2012 Management Shell” con algunos comandos que veremos en sucesivas entregas. Estos comandos son muy útiles, pero podemos sacar provecho también de la funcionalidad estándar de PowerShell para muchas tareas.

Todo esto lo veremos en las siguientes entregas de este artículo, de momento es necesario empezar con lo más básico de PS, que nos permitirá comprender y sacar provecho a los siguientes artículos.

Cómo obtener ayuda

Como, a estas alturas, todos debemos saber, PowerShell es una herramienta de administración de Windows a modo de consola de comandos. Una versión mejorada de la antigua consola msdos disponible en versiones anteriores que, como aquella, nos permite crear y reutilizar scripts de comandos.

Dependiendo de la versión de Windows que utilicemos, PowerShell viene instalada por defecto (en las últimas versiones), o habrá que instalarla manualmente. Se puede descargar de manera gratuita de la web oficial de Microsoft. También se puede descargar un editor gratuito (que también viene por defecto en algunas versiones de Windows) que nos permite editar, depurar y ejecutar scripts de PS fácilmente, llamado Windows PowerShell ISE.

Los primeros comandos (en PS llamados: Cmdlets) que debemos aprender son los relativos a la ayuda. Sin duda, nos van a hacer falta. Podemos utilizar el comando Get-Help para obtener ayuda sobre cualquier comando, o para obtener una lista de los comandos disponibles. Para comprobar las posibilidades del sistema de ayuda podemos probar los comandos siguientes y analizar su resultado:

# Ayuda
Get-Help
Get-Help Get-Help -Full

# Ayuda sobre un Cmdlet
Get-Help process
Get-Help Get-Process –Examples
Get-Help Get-Process –Online

# Actualizar ayuda desde internet
Update-Help

Mediante estos comandos vemos cómo obtener una lista de comandos buscando por una palabra clave, cómo buscar información sobre un comando concreto, cómo ir directamente a la página web de Microsoft que nos muestra la ayuda de un comando, y cómo actualizar desde internet la base de datos de ayuda de nuestro sistema local.

001-GetHelp

La curva de aprendizaje de PowerShell es dura, así que seguro que utilizaremos estos comandos a menudo, sobre todo al principio.

Introducción, Pipes y Aliases

A pesar de que se dice de PS que es la nueva versión de la antigua consola msdos, lo cierto es que su utilización no tiene nada que ver, salvo en el simple hecho de que ambas son consolas de comandos, y ambas permiten almacenar y reutilizar scripts.

El resultado de los comandos de PS es siempre un objeto (como los de programación orientada a objetos), no simple texto como en otras consolas. Por tanto, cuando encadenamos la salida de un comando hacia el siguiente, lo que recibe el segundo comando es un objeto o una lista de objetos de los que puede hacer uso de manera completa (no sólo de lo que se muestra por la consola), incluyendo sus propiedades y sus métodos.

Continue Reading…

[HOWTO] Tomar el control de un backup de AX 2012 mediante PowerShell

Hace unos días hacía un comentario en twitter acerca de las posibilidades de PowerShell que me trajo mucho feedback.

Supongo que hay mucho interés en conocer más sobre las bondades de PowerShell aplicadas a Microsoft Dynamics AX, y estoy preparando un artículo largo (probablemente una serie de varios artículos) sobre el tema que estarán terminados en las próximas semanas. PowerShell es una herramienta extremadamente potente y a la vez extraña. Los programadores habitualmente la consideran una herramienta de administración (es una consola) mientras que los sysadmin suelen verla como algo para programadores (es código). Curioso, ¿verdad?

Mientras termino el artículo, y para ir abriendo boca, un problema común en todas las versiones de AX es que, tras restaurar una copia de seguridad de AX de un entorno a otro, hay varias situaciones en las que no podremos acceder al sistema porque nuestro usuario no está dado de alta en esa aplicación. Casos típicos es que la copia es de un cliente lo restauramos en una máquina propia en otro dominio, o que nuestro usuario de desarrollo no está dado de alta en la aplicación de producción.

Sin importar mucho el por qué, la solución siempre ha sido ir a la base de datos manualmente, buscar en la tabla de usuarios y actualizar el SID del usuario administrador por el nuestro; o bien crear manualmente un nuevo usuario en la tabla. Esta es, de hecho, la única solución. Pero no siempre es fácil conocer nuestro SID y esta es una tarea que, por definición, podemos automatizar.

Para eso podemos utilizar un script PowerShell que podrá ser ejecutado cada vez que restauramos un backup, y nos permitirá tomar el control del usuario admin de ese entorno automáticamente (todo este código puede pegarse en un nuevo fichero con extensión .ps1 y utilizarse como un cmdlet):

[CmdletBinding()]
Param
(
[Parameter()]
[string] $dbInstance = "localhost",

[Parameter(Mandatory=$True)]
[string] $dbName,

[Parameter()]
[string] $adDomain = [Environment]::UserDomainName,

[Parameter()]
[string] $adUser = [Environment]::UserName
)

Import-Module sqlps -DisableNameChecking

$ntAccount = New-Object System.Security.Principal.NTAccount($adDomain, $adUser)
$adSID = $ntAccount.Translate([System.Security.Principal.SecurityIdentifier])

$params = "adDomain = $adDomain",
"adUser = $adUser",
"adSID = $adSID"

Invoke-Sqlcmd -Query "
SELECT ID, NAME, SID, NETWORKDOMAIN, NETWORKALIAS
FROM [dbo].[USERINFO]
WHERE ID = 'admin';
"
-ServerInstance "$dbInstance" –Database "$dbName" | Format-Table

Invoke-Sqlcmd -Query "
UPDATE [dbo].[USERINFO]
SET NAME = 'Admin',
SID = '`$(adSID)',
NETWORKDOMAIN = '`$(adDomain)',
NETWORKALIAS = '`$(adUser)'
WHERE ID = 'admin';
"
-ServerInstance "$dbInstance" –Database "$dbName" -Variable $params

Invoke-Sqlcmd -Query "
SELECT ID, NAME, SID, NETWORKDOMAIN, NETWORKALIAS
FROM [dbo].[USERINFO]
WHERE ID = 'admin';
"
-ServerInstance "$dbInstance" –Database "$dbName" | Format-Table

El usuario nos permite pasar por parámetros los datos de nuestro usuario y la base de datos, y también asume valores por defecto. Si se utilizan los valores por defecto, el script utilizará el usuario actual. Después se utiliza el módulo PowerShell de SQL Server para lanzar el update necesario a la tabla, y nos mostrará por consola los datos antes y después de su ejecución para asegurarnos, o por si queremos guardarlo en un fichero de texto, por si acaso 😉

Este es el resultado:

Restore-AXAdminUser

Después de ejecutar el script ya puedo entrar en la aplicación correspondiente porque desde este momento mi usuario esta enlazado al usuario admin de esa aplicación.

Más sobre PowerShell en los próximos días! 🙂