Jun 20, 2013
Filed under: #daxmusings #bizapps

Yesterday I released code libraries and a wrapper PowerShell cmdlet libraries to automate installs of AX and maintain client and server configurations for AX. I also blogged an example of an installer script to have an automated install of an AX 2012 AOS. The download links for both libraries are:

CodeCrib.AX.Setup CodeCrib.AX.Config

Today I will give you an example of the Config library and how we’re using it. You can find reference documentation of the commands for the Config library here.

The point of the config library is to create and maintain configuration files. For example, when we auto-deploy an AOS for development, we can run a script that will change the AOS to have debugging and hot-swapping enabled. For the client side, we can generate client configuration files to log into the development workspace and in the correct layer. Both server and client config objects expose all the properties that you see on the configuration utilities. Before anyone comments, the big missing piece here is the “Refresh configuration” that exists on the client configuration utility. I’m working on finding out how to get that configuration easily.

So this one script takes care of both AOS and client configs. The first part of this script gets parameters in for the PowerShell script and loads the library. Next, it gets the active configuration (after initial install this is the “original” configuration). It changes the configuration name to equal the AOS name (I like this as a convention on our VMs), sets breakpoints on server, sets hotswapping, and save the configuration back (by piping the config object into the Save-ServerConfiguration cmdlet). Next, it uses Set-ServerConfiguration to set that new configuration as the active one for our AOS instance. <pre>Param( [parameter(mandatory=$true)][string]$instancename, [parameter(mandatory=$true)][string]$VARcde, [parameter(mandatory=$true)][string]$CUScode, [parameter(mandatory=$true)][string]$configfolder ) import-module ((Get-Location).Path + "\CodeCrib.AX.Config.PowerShell.dll")

$config = Get-ServerConfiguration -aosname $instancename -active $config.Configuration=$instancename $config.BreakpointsOnServer=1 $config.HotSwapping=1 $config | Save-ServerConfiguration -aosname $instancename Set-ServerConfiguration -aosname $instancename -config $config.Configuration</pre></code>

Next, we move on to the client configuration. Just like the server configuration, initially you are stuck with the “original” configuration. We just retrieve that one (it’s the active one), set user and global breakpoints, and save out the config three times (for three layers: USR, VAR, CUS). After that we repeat the process but we add the -Development startup command and create config files for each layer to log into the development workspace. <pre>$config = Get-ClientConfiguration -active $config.UserBreakPoints=1 $config.GlobalBreakPoints=1

$config.Layer=”usr” $config.LayerCode=”” $config | Save-ClientConfiguration -filename ($configfolder + “" + $instancename + “_usr.axc”)

$config.Layer=”var” $config.LayerCode=$VARcode $config | Save-ClientConfiguration -filename ($configfolder + “" + $instancename + “_var.axc”)

$config.Layer=”cus” $config.LayerCode=$CUScode $config | Save-ClientConfiguration -filename ($configfolder + “" + $instancename + “_cus.axc”)

$config.KernelStartupCommand = “-Development”

$config.Layer=”usr” $config.LayerCode=”” $config | Save-ClientConfiguration -filename ($configfolder + “" + $instancename + “_usr_Development.axc”)

$config.Layer=”var” $config.LayerCode=$VARcode $config | Save-ClientConfiguration -filename ($configfolder + “" + $instancename + “_var_Development.axc”)

$config.Layer=”cus” $config.LayerCode=$CUScode $config | Save-ClientConfiguration -filename ($configfolder + “" + $instancename + “_cus_Development.axc”)</pre></code>

We can probably shorten this into a loop of sorts, but this is easy to read and understand at this point.

Bonus round:

You could ask, how about actually creating a shortcut to start AX and pass the config file? I haven’t worked out that code yet (I’ll leave it as “an exercise for the reader” :-) but basically you can use WScript.Shell for that. I haven’t gotten past one issue with this (just haven’t had the time) where the target path validates the path’s existence. If you add the configuration file as a parameter in there, it basically fails to validate that whole string (including config file) as a valid target path. Either way, you can play with this but the following PowerShell script is where I left it last time I considered it: <pre>$shell = New-Object -COM WScript.Shell $shortcut = $shell.CreateShortcut("C:\Users\Public\Desktop\Powershell Link.lnk") #$shortcut.TargetPath=('"c:\Program Files (x86)\Microsoft Dynamics AX\60\Client\Bin\Ax32.exe" "' + $configfolder + "\" + $instancename + '_cus_Development.axc"') $shortcut.TargetPath="c:\Program Files (x86)\Microsoft Dynamics AX\60\Client\Bin\Ax32.exe" $shortcut.WorkingDirectory="c:\Program Files (x86)\Microsoft Dynamics AX\60\Client\Bin\" $shortcut.Description="AX link with config file" $shortcut.Save()</pre> Note how the commented line causes the error. So this will now create a shortcut to AX without the config file. I’ll let you know when I figure this out :-)

For now, that’s it on the admin tools. I’m actively working on this code base, so expect more updates in the next weeks!

 

There is no comment section here, but I would love to hear your thoughts! Get in touch!