• About

Day 2 Day Dynamics

~ Experiences of a working AX developer

Day 2 Day Dynamics

Tag Archives: Setup

Send-Email custom PowerShell function

13 Friday Mar 2015

Posted by John Hagler in Powershell

≈ 5 Comments

Tags

Automation, AX, AX 2012, AX Email, Build Scripts, Dynamics AX, PowerShell, Setup

When looking at automating my AX 2012 processes, the first thing I was interested in was the ability to send emails when steps were completed.  This would allow me to kick off my process and walk away, tracking it on my phone if necessary.

The function I created for this is Send-Email and can be found on Codeplex.  It takes 7 parameters:

  • SMTPServer (SMTP server that will send the email)
  • From (Who the email is from)
  • To (Who the email is to)
  • Subject (Email subject)
  • Body (Email body)
  • Priority (Email priority)
  • FileLocation (Allows you to attach a file if used.  I primarily use this to attach my log files)

This function uses the Net.Mail.MailMessage and Net.Mail.SmtpClient to send an email message.  I usually default some of these parameters in the scripts I use to call these functions but we’ll get into that when I walk through my build function.  You can view the code in this function using PowerShell ISE.

The way that I currently test and run these standalone PowerShell functions is to use my profile.  In my profile, I include a link to a PowerShell script that holds my function locations.  I do this so that when I add new functions, I can just include them in my D2D_PSFunctions.ps1 script and they will be automatically included by my profile the next time I open up PowerShell.  You can get more info on what I’m doing in an earlier post as well as Codeplex.

Please take a look at this function to get an idea of what is going on.  There may be optimizations or better ways to do things in PowerShell but I was teaching myself PowerShell while I wrote all of this.

DynamicsAXCommunity PowerShell module plus changes

04 Wednesday Mar 2015

Posted by John Hagler in Powershell

≈ 2 Comments

Tags

Automation, AX2012, Build Scripts, Dynamics AX, PowerShell, Setup

When I first started looking at creating an automated build process, I settled on PowerShell primarily because of 2 resources; the DynamicsAXCommunity PowerShell module and the Build and Deploy Scripts for Microsoft Dynamics AX 2012.  While I was ultimately unable to get the B&D Scripts running in my environment, I did learn a lot about PowerShell and the direction I needed to go to get a build process going.  I ended up using a lot of the ideas in my own processes.

The DynamicsAXCommunity Powershell module became the first brick in my process.  I started out using most of the functions available but eventually rewrote some of them to incorporate email functionality.  The three that I still use regularly are Get-AXConfig, Start-AXAOS and Stop-AXAOS.  I have also modified some of the code used in the Get-AXConfig method to return some values from the configurations that I needed.

My changes to the module are on the alpha version.  There appear to be 2 newer versions of this module, a beta and 0.3.4 but I have not integrated my changes into either of these.  You can find both the original alpha version and the version with my code changes in Codeplex based on the check-ins.  I plan to either integrate my changes in the newest version or add the three functions that I use from the DynamicsAXCommunity module into my functions at some point in the future.  For now, the alpha version has been used with my scripts for the last year and half and I feel comfortable that it works.

I have added three values that are returned from the Get-AXConfig function.

  • ServerBinDir
  • ServerLogDir
  • AosName

DynamicsAXCommuntiyChanges

The two directories are used to get executables and compile logs and the AOS name is used in some of the standard AX PowerShell functions installed with the Management Utilities.

This post and my last one have laid the groundwork for what is necessary to start using my functions.  In my next post, we will start looking at them.

Setting up your PowerShell environment

27 Friday Feb 2015

Posted by John Hagler in Powershell

≈ 2 Comments

Tags

Automation, AX2012, Dynamics AX, PowerShell, Setup

Since the majority of my upcoming posts will revolve around PowerShell, I’ve decided to post about setting up your environment.  All of the things I will discuss can be found elsewhere and I will link to some of the sources that I’ve used but I’m hoping to give enough information that anyone can repeat my steps using only this blog. Also, in case anyone has issues or is just interested to know, I am using PowerShell version 3.0.

The first thing that you will need to do is set the execution policy of your environment.  The default execution policy is Restricted, meaning you will be unable to run any PowerShell scripts.  The most restrictive setting that you can have that will still enable you to run my scripts is RemoteSigned.  You can find more information here.

  • Set-ExecutionPolicy RemoteSigned

PS_Set-ExecutionPolicy

The next step is to get a profile set up.  PowerShell is largely session dependent and most things that you want to use need to be loaded into your session before they are available.  Setting up a profile gives you the ability to load things into a session by default.  The PowerShell commands that I use to set up my profile are below and you can find more information here.

  • Test-Path $profile
  • New-Item -path $profile -type file -force
  • notepad $profile

PS_CreateProfile

Most, if not all of the things that I am going to be talking about in the future start with the AX 2012 Management Utilities.  This is something that can be installed using your AX 2012 installation media and is required to be installed on the server where you will be running these scripts.

Installing the AX 2012 Management Utilities gives you access to the Microsoft Dynamics AX 2012 Management Shell.  You can find more information here.  This is another PowerShell client with some things preloaded and some UI changes.  I prefer to use the standard PowerShell client so I preload the same things using my profile.

The script that is used by the AX 2012 Management Shell is saved by default to “C:\Program Files\Microsoft Dynamics AX\60\ManagementUtilities\Microsoft.Dynamics.ManagementUtilities.ps1”.  Adding this to your profile, prefixed with a period, will call this script and load the necessary modules into your PowerShell client session the next time it is started.  An example of my profile can be found here.  This example will also be updated with future posts so make sure you only grab what is necessary for you when downloading it.

PS_ManagementUtilities

This is as far as I plan to go today. I just wanted to walk you through the steps that are prerequisites for using the PowerShell functions that I will be talking about in later posts. Also, if you plan on using the PowerShell IDE client for examining these functions, be aware that the IDE client uses a separate profile so you will need to duplicate the profile steps for the IDE client as well.

Follow Day 2 Day Dynamics on WordPress.com

Day 2 Day Dynamics

  • RSS - Posts
  • RSS - Comments

Follow me on Twitter

My Tweets

Recent Posts

  • Minimizing Database Calls
  • Push-AXModel custom PowerShell function
  • Clean-AXModel custom PowerShell function
  • Get-AXTFSCombinedXpo custom PowerShell Function
  • Refresh-AXAifPort custom PowerShell function

Archives

  • February 2016
  • December 2015
  • November 2015
  • October 2015
  • September 2015
  • August 2015
  • July 2015
  • June 2015
  • May 2015
  • April 2015
  • March 2015
  • February 2015

John Hagler

John Hagler

John Hagler

I am the Dynamics AX Technical Architect at Dealer.com. I have been working with AX since Sep. 2006, starting with Axapta 3.0. I have worked as both a VAR and an AX customer.

View Full Profile →

Blog at WordPress.com.

  • Follow Following
    • Day 2 Day Dynamics
    • Already have a WordPress.com account? Log in now.
    • Day 2 Day Dynamics
    • Customize
    • Follow Following
    • Sign up
    • Log in
    • Report this content
    • View site in Reader
    • Manage subscriptions
    • Collapse this bar
 

Loading Comments...