Coffee break in the Cloud with Windows PowerShell


In this post we will run Windows PowerShell in the cloud. The ability to connect your Windows PowerShell with your Microsoft Azure instances can double the value of Microsoft Dynamics NAV and PowerShell, since you now have tools for both on-premises and cloud deployments. And having the choice of hosted deployments is also one of the first prerequisites for moving to Cloud-first as described in the Are you putting the cloud first? article.

Coffee Break 3: PowerShell Remoting with Microsoft Dynamics NAV

Prerequisites:

Customer Story:

  • Cloud first
  • Running PowerShell remotely will be handy for customers who migrate or automate their system / part of their system or their development environment in / to the cloud.

Connect

Open your Windows PowerShell ISE. In order to connect to Azure you must have two things:

  1. Azure Publishsettings file which will have all the details of your subscription.
  2. Your Azure account credentials.

 

#Connect to Azure

import-module azure #see pre-requisites from above.

#Check if we are logged on to our Azure subscriuption – expect this to fail for now:

Get-AzureVM

#Log in to your Azure subscription

Add-AzureAccount

Get-AzurePublishSettingsFile #After saving your file once, just skip this point and remember where you save it, you don’t need to save it every time. But keep the file safe as it contains connection details.

Import-AzurePublishSettingsFile “C:\Temp\Windows Azure MSDN – Visual Studio Ultimate-5-14-2013-credentials.publishsettings”

#Check again – this time it should work:

Get-AzureVM 

 

You should now be able to run generic Azure commands, like Get-AzureVM and Start-AzureVM and more to access your Virtual Machines, and get some of the same information you get via the Azure management portal. Next, we will connect to a running machine and start running PowerShell remotely.

For the next steps you need to have at least one Virtual Machine (VM) running in your Azure subscription. You can create a VM easily from your Azure management portal. You will be able to pick a ready-built image with Microsoft Dynamics NAV 2015 from the Azure marketplace under Microsoft -> Dynamics. You can also create your own VM, and you can still continue with the scripts below. 

Note: When you create a new VM, you need to specify both Machine Name and Service Name. Some of the scripts below assume that these two names are the same. So just to avoid any confusion, keep Service Name and Machine Name the same. 

To connect to a remote machine we can use the cmdlet New-PSSession. This works nice and easy on your domain. However if the remote machine is in the cloud, connecting becomes a little bit more challenging. Luckily we have helper-scripts, right on the NAV product DVD – for more information, see Deploying and Managing Microsoft Dynamics NAV on Microsoft Azure. In this example, the DVD is in D:\NAVDVD\, and we will import the NAVRemoteAdministration module from the Cloud subfolder.

#Load NAV remote admin from the product DVD
Import-Module “C:\NAVDVD\WindowsPowerShellScripts\Cloud\NAVRemoteAdministration\NAVRemoteAdministration.psm1”

Before continuing lets just stop and check what the NAVRemoteAdministration module contains:

get-commandmodule NAVRemoteAdministration

What we will use first, is New-NAVAdminSession but also notice functions like Copy-FileToRemoteMachine, Get-NAVServerUserRemotely, New-NAVServerInstanceRemotely and Start-ServiceRemotely. We’re sure you can imagine how useful these can be. But first we need to create a session object that we can use to connect: Make sure that the VM you refer to exists and is running, and that service and machine names are the same:


$PsSession = New-NAVAdminSession `
  -RemoteMachineAddress MyTestDynnav2015.cloudapp.net `
  –AzureServiceName MyTestDynnav2015 `
  -VMAdminUserName VMAdmin `
  –VMAdminPassword 1MyPassword2

 

The 4 parameters in this function all are from when you created your VM.

You now have a session variable ($PSSession) that you can use to connect to your cloud VM. This is a persistent session but we will come back to session types in more details another time. You can start either an interactive session or just run scripts to this session.

#Enter an interactive session
Enter-PSSession $PsSession

get-navserverinstance #will show you any NAV instances on this VM

get-service

dir

and once you are done checking what you want, return to your own PC:

EXIT

 

Run a script remotely. It is a little bit of a problem to list something, since the result may just stay on the remote machine. So for example Get-NAVServerInstance would run, but not necessarily show you something. So instead we run a cmdlet to run an action – let’s stop the Microsoft Dynamics NAV Server service remotely:

Invoke-Command -Session $PssessionScriptBlock{Set-NavServerInstance NAV -stop}

Or run a script from a file, this time adding some parameters:

Invoke-Command -Session $psSessionFilePath .\MySCriptps1 -ArgumentList Arg1,Arg2

 

And finally let’s run one of the functions we looked at earlier, and again using the $PSSession variable to do the connection

 Copy-FileToRemoteMachineSession $PssessionSourceFile c:\Tmp\MyDB.bak -DestinationFile c:\NAV\DB.BAK

 

As you can imagine, the topic of PowerShell Remoting is much bigger than what can fit in a coffee break, but hopefully this has given some good insights at least.

 

Jasminka Thunes, Escalation Engineer Dynamics NAV EMEA

Lars Lohndorf-Larsen, Escalation Engineer Dynamics NAV EMEA

Comments (1)

  1. Pallea says:

    A few more tips 😉

    If you want to run powershell-scripts (like at backup) from your own local mashine, remotely on another in your own network, and do not want to do a login you can do the following:

    First you have to enable povershell remote execution on your server:

    Run CMD.EXE as administrator and type:

    Enable-PSRemoting –Force

    If your "client" and "server" are in a trusted network, then they need to be "handshaked" So run cmd.exe on both the client and the server.

    Set-Item wsman:localhostclienttrustedhosts *

    * = on the client the ip-address/ or servername

    on the server:

    * = the client ip-address/client computername, that should be allowed to execute a PS-script.

    Often you need to reboot the server. If thats not possible then restart WSMAN

    (Again run CMD as administrator) and type

    Restart-Service WinRM

    You can test from your client whether you have access a ps-script file on the server with:

    Test-WsMan servername/ip-address

    I hope that it made sense…Sorry for the typos.

    Thanks

    Palle