SCOM Me this, PowerShell Me that! (Dynamics AX 2012)

So, trying to have an inventive title, the "SCOM Me this, PowerShell Me that! (Dynamics AX 2012)" is in reference to some of the key technologies that are being used from the rest of the Microsoft Stack, to help make lives easier, in terms of Manageability and Microsoft Dynamics AX 2012.

One of the first area's of improvements is around the SCOM Pack for Microsoft Dynamics AX 2012. This is, System Center Operation Manager Pack. This exists with Microsoft Dynamics AX 2009, but in a *very* limited basis.



So much so, that not a lot of people actually are moved to make use of the SCOM Pack for Microsoft Dynamics AX 2009. Well welcome to Dynamics AX 2012!

The amount of detail and effort that has went into the SCOM Pack for Microsoft Dynamics AX 2012 is amazing!

• Diagram view of an instance, and all parts that make said instance up


• Ability to remotely restart services. (Thanks PowerShell!)


• Drain users, check online users, all from SCOM console


• Most all Admin task, from within the SCOM console. Less having to be done directly through Dynamics AX itself


• Total visibility through the entire enterprise, and the many instances, like Dev, Test and Prod - for a company


• Much more!

This means, that for anyone that has more than instance, and more than a single AOS, with anything beyond the core area of AX, needs to invest in SCOM and make use of this great tool.

Something I also mentioned above, is PowerShell. How much have we been talking about PowerShell? I believe in PowerShell!



With Microsoft Dynamics AX 2012, so much around Manageability improvements exists around the use of PowerShell, and delivered Microsoft Developed, PS CmdLet assemblies!

I went to the Reports Deployment session, and the entire session was focused around PowerShell, and a set of PowerShell scripts and Cmdlets that are used by said scripts to deploy and manage the deployment of Report Elements and Artifacts.

PowerShell is also a key piece to the SCOM management pack, as well as other area's like automating the deployment of .axmodel files from one instance to another.

What using the ISE (Integrated Scripting Editor) of PowerShell, and PowerShell framework itself brings to Microsoft Dynamics AX 2012 is greater flexibility, while promoting reuse, and lowering the manual administrative task associated with the many different aspects that exists for a Microsoft Dynamics AX 2012 deployment.

With these two key area's, it's important for a Dynamics AX Architect, Technical Engineer and Admin to learn now the syntax, usage, and ins and outs of. To see how this can help save time, promote reuse, and help lower the TCO of having Microsoft Dynamics AX 2012 as the ERP of choice for a company.

As more and more session content become ready in the CTP release coming soon, a lot of references, example PowerShell scripts, and usage highlights will be seen right here just on these topics! (Among others!)

That's all for now, and I hope you enjoy the second installment of Post #DAXCONF 11 coverage. This should be used as a build up to Convergence 2011, being held in Atlanta again this year! I am planning to be there myself.

Check back soon, as more to come!

"Visit the Dynamics AX Community Page today!"

I believe in PowerShell!

Microsoft PowerShell is a very powerful tool. With it, all sort of administrative task can be taking care of. It can connect and work with all Microsoft porducts, and is very open for creating your own connections and integrating with third party applications.

It is a true scripting language that offers those invested into Dynamics AX a valuable TCO lowering option. First off you can download PowerShell for free, and there are so many great resources on the web now that can point you in the right direction for it's use.

But what about Dynamics AX? How can a scripting language help a Dynamics AX investment? Well with Dynamics AX, there is typically integrations, WCF services, need to promote code, to check the "health" of the application, database with SQL Server, etc. etc.

So there are processes with the administration of Dynamics AX, and all the things that connect and extend Dynamics AX, that can have the administrative task associated with them, automated.

Before we get into some of the ideas, let first review some resources, that are must have bookmarks, when diving into Microsoft's PowerShell.

• Windows PowerShell Getting Started Guide


• The PowerShell Guy


• Dynamics AX 2009: Integrating AX with Powershell


• Axaptapedia - Powershell Entry

I have placed these in order of which I think you should review them. The first is MSDN home for PowerShell, and it's the getting started guide. This is a must to have, as it can get you going with PowerShell, syntax, and starting about about uses.

Next we have 'The PowerShell Guy', which is a blog all about PowerShell. Great articles, and good place to check from time to time. Finally we have two examples of PowerShell working with AX. The first shows off some cool stuff with working with records within AX, making use of the .Net BC.

The last entry, is from the Axaptapedia site, and it talks about PowerShell, and have some decent examples of starting uses for PowerShell. Take the last part, for example.:

# load the .dll (similar to the c# "Using" statement)
[reflection.Assembly]::Loadfile("C:\Program Files\Microsoft Dynamics AX\50\Client\Bin\Microsoft.Dynamics.BusinessConnectorNet.dll")
# or [Reflection.Assembly]::LoadWithPartialName("Microsoft.Dynamics.BusinessConnectorNet")
# or [Reflection.Assembly]::Load("Microsoft.Dynamics.BusinessConnectorNet, Version=6.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35")
$ax = new-object Microsoft.Dynamics.BusinessConnectorNet.Axapta

# Look at the properties
# More info at: http://msdn.microsoft.com/en-us/library/aa626373.aspx
# $ax | get-member

$ax.logon("","","","")
$o = $ax.CallStaticClassMethod("SysLabel","labelId2String2","@SYS21669" )
$o # Should be "ABC"

# Look at some session info
$xSession = $ax.CreateAxaptaObject("XSession")
$xSession.call("AOSName")
$xApplication = $ax.CreateAxaptaObject("XApplication")
$xApplication.call("buildNo")
$ax.CallStaticClassMethod("Session", "isBusinessConnector")
$ax.CallStaticClassMethod("Session", "getAOSInstance")
$ax.CallStaticClassMethod("Session", "getAOSPort")
$ax.logoff()


I think the above example is most handy, as it can quickly get you into connecting with AX, through the application layer, via the .Net BC.

Now that you have the above, you would also need a download for PowerShell. A great KB article has this, plus more, which can be found here: Windows Management Framework (Windows PowerShell 2.0, WinRM 2.0, and BITS 4.0)

It's the full Windows Management Framework, including the latest PowerShell 2.0.

With all of this, and examples, think about now what manual processes you do? Have any WCF services? Not using Windows AppFabric yet? Well then you can use Powershell to automate deployment, cycling, etc of the WCF services that AX might consume. What about automating your promotion process?

You can create a Table / Form that manages what objects, projects, etc. gets promoted, when, and the from and to instances. Then Powershell can read from this information, and actually execute this for you.

Creating something of this fashion not only allows you to then document what is being promoted, but also is the control panel for such promotions.

There is a lot that PowerShell can offer to help lower the TCO of an AX investment, and you could even use PowerShell to create testing scripts to have some forms of automated testing or even stress testing.

That's all for now, check back soon, and feel free to leave a comment on how you use PowerShell to help manage your Dynamics AX investment!



Visit Hillstar Business Intelligence (www.HillstarBI.com) in order to truly unlock your data trapped in your Microsoft Dynamics investment. With our value driven business intelligence strategy Hillstar help you transform into a data informed company.


"Visit the Dynamics AX Community Page today!"