I’ve been playing with PowerShell more and more lately, and I thought it’s a good idea to bring on a mini-series of posts on this topic. I’ll be stepping through a few topics, from the most basic actions like extracting a solution and deploying it to a target environment, then move into more DevOps focused actions.
But let’s get started. This first post will focus on the setup of the environment.
Oftentimes you find these fabulous posts with loads of useful information, but for a beginner it’s missing something as simple as the core setup.
Right off the bat, we’re looking at the Microsoft.Xrm.Data.PowerShell library. It’s available from GitHub at the following URL:
https://github.com/seanmcne/Microsoft.Xrm.Data.PowerShell
Big thumbs up to the authors:
Sean McNellis & Kenichiro Nakamura
Now, you can follow the instructions on the landing page. Seems simple enough, just run:
Install-Module Microsoft.Xrm.Data.PowerShell –Scope CurrentUser
That works well if you’re going to run each command line individually. If you build a script for distribution, you want be a little more fancy than that (and that’s a technical term). You want to put this installation into a function that checks to see if this module is already installed, and if not, perform the installation.
Funny enough, let’s call this function InstallModule. The lines starting with “#” are comment lines.
# Script using Microsoft.Xrm.Data.Powershell
function InstallModule{
Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass -Force
$moduleName = “Microsoft.Xrm.Data.Powershell”
$moduleVersion = “2.7.2”
if (!(Get-Module -ListAvailable -Name $moduleName)) {
Write-Host “Module $moduleName NOT found, installing now…”
Install-Module -Name $moduleName -MinimumVersion $moduleVersion -Scope CurrentUser -Force
Write-Host “Module $moduleName installed!”
}
else {
Write-Host “Module FOUND!”
}
}
Let’s take each command separately and look at it. Start with the Set-ExecutionPolicy command.
The detailed description is available at https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.security/set-executionpolicy?view=powershell-6
You can simply type in PowerShell the following command:
Get-Help Set-ExecutionPolicy
The Execution Policy is the setting that determines which type of scripts can run on your system. The default setting is Restricted, which mean you can’t run scripts. We start by setting the scope to the current process only. Other options include:
- MachinePolicy
- UserPolicy
- Process
- CurrentUser
- LocalMachine
Next you set the ExecutionPolicy. You can get the Execution Policy default value by running Get-ExecutionPolicy. You will probably get Undefined unless it’s modified on your machine. We want to set this to Bypass to allow our script to execute even if the script is unsigned.
And finally, the –Force switch simply means “execute no matter what”, or maybe “stop bugging me with confirmations and just do it” if you like.
Next two lines define string values for the variables holding the module name and minimum version.
Finally, in an If statement, we determine if the module is already installed by checking in the list of available module if the module with our name exists.
Get-Module -ListAvailable -Name $moduleName
The Write-Host lines simply output status messages to the console, so we know what’s going on and where we are in the script execution.
Now, if we determined that our module is not installed, we can finally run the Install-Module command.
The Else branch simply outputs a message that the module is installed.
We call this function in our script by simply running InstallModule at the beginning of our script execution block.
NOTE:
If you encounter a SecurityError with UnauthorizedAccess you must run PowerShell as Admin and execute the following command:
set-executionpolicy remotesigned
This is because the script is not digitally signed and Windows blocks execution of non-digitally signed PowerShell Scripts.
Next post we’re looking at connecting to a D365CE environment. Baby steps!
Cheers!