Friday, June 28, 2013

R2 Hotfix for Compile Time needs Schema Update

Just a quick note on the hotfix that was released quite a while ago to improve compile times on R2. Many blogs including the official Microsoft one linked directly to the hotfix, and many people have installed it immediately with no result. What many people don't seem to know (and honestly in my own haste to try it out I did the same thing at first) is that you need to update your model store schema to benefit from the improvements which included new indexes in the model store.
So, if you have installed the hotfix (KB2844240), make sure to run "axutil schema" on the model store to actually make the changes take effect!

Thursday, June 20, 2013

Dynamics AX Admin Tools - CodeCrib.AX.Config

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:


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.
import-module ((Get-Location).Path + "\CodeCrib.AX.Config.PowerShell.dll")

$config = Get-ServerConfiguration -aosname $instancename -active
$config | Save-ServerConfiguration -aosname $instancename
Set-ServerConfiguration -aosname $instancename -config $config.Configuration

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.
$config = Get-ClientConfiguration -active

$config | Save-ClientConfiguration -filename ($configfolder + "\" + $instancename + "_usr.axc")

$config | Save-ClientConfiguration -filename ($configfolder + "\" + $instancename + "_var.axc")

$config | Save-ClientConfiguration -filename ($configfolder + "\" + $instancename + "_cus.axc")

$config.KernelStartupCommand = "-Development"

$config | Save-ClientConfiguration -filename ($configfolder + "\" + $instancename + "_usr_Development.axc")

$config | Save-ClientConfiguration -filename ($configfolder + "\" + $instancename + "_var_Development.axc")

$config | Save-ClientConfiguration -filename ($configfolder + "\" + $instancename + "_cus_Development.axc")

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:
$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"

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!

Wednesday, June 19, 2013

Dynamics AX Admin Tools - CodeCrib.AX.Setup

Long overdue for release, I'm glad to announce the first beta of my admin tools. These tools are still a work in progress, but you can start taking advantage of these right away. As you probably know, we have open sourced our TFS build scripts for Dynamics AX, and ever since these were released I've received quite a few emails and messages from people asking how to automate deployment etc outside of TFS. Obviously we do some of that already inside the build scripts, and there's some code sharing that can be done. Additionally, we've been exploring SCVMM (System Center Virtual Machine Manager) for which we would like to automate a lot of things (such as installing AX, deploying code, etc). So, in an effort to refactor and support TFS builds as well as automated scripts or even your own tools (UI?), I embarked on a mission to create a set of admin tools. This first beta release features less than half of the final product, but it's a good start and it's what we've been using for SCVMM so far (more on that in another post).

So, today's release includes a code library (which you can use to create your own tools) and a wrapper PowerShell cmdlet library to automate installs of AX and maintain client and server configurations for AX. The downloads are:


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

Dynamics AX has always allowed silent installs using parameter files which you can pass to the setup executable of AX. For our VMM setup I wanted to make this even more generic and needed some good tools to support parameterized, automated installs. Additionally, a log file generated after an install of AX actually leaves you with most of the parameters you actually used (the exceptions are passwords are not stored in the log file).
All of this is captured in the library CodeCrib.AX.Setup and the PowerShell CmdLets CodeCrib.AX.Setup.PowerShell . The download also contains a sample UI which lets you load a log file and write it out as a parameter file, or load a parameter file and manipulate it. Note that the UI is just an example of how to use the class library in your own projects, I'm not planning on maintaining that much but will instead focus on the library and PowerShell cmdlets instead. The following is an example of the PowerShell script we currently have in use for installing an AOS:
import-module ((Get-Location).Path + "\CodeCrib.AX.Setup.PowerShell.dll")

$env:instance = $instancename

$setupparams = get-parameters -filename ((Get-Location).Path + "\AX2012 Server.txt")
$setupparams | set-parameter -environmentvariables

$setupparams | set-parameter -parameter "DbSqlServer" -value $databaseserver
$setupparams | set-parameter -parameter "AosAccount" -value $aosaccount
$setupparams | set-parameter -parameter "AosAccountPassword" -value $aosaccountpw

$setupparams | start-axsetup -setuppath $setuppath

Basically, the PowerShell script accepts some basic information such as the path to the setup executable, the SQL server name, a name for a new AOS server (and it will reuse that as the name of the database assuming you follow convention and what to keep those the same), account and password to use for the AOS service. Obviously this is abbreviated and it's specific to just installing an AOS. I will post more examples in future posts.
But basically, this loads the PowerShell cmdlets, loads the parameter file (AX2012 Server.txt) and then 1) replaces the %instance% environment variable, and sets the db / aos / password in the parameter object and starts the AX setup.

Tomorrow I will show you an example PowerShell script for the CodeCrib.AX.Config.PowerShell library, to create some standard configuration files to get into layers, development workspace, etc. Enjoy!