This quick public cloud adoption can be explained by several factors such as the following:

The latest member of the Dynamics Family, Dynamics 365, is not hosted on Azure, since Azure does not provide SaaS.

The difference between on-premise and the different cloud services can be better understood by the following diagram. As you can see, in on-premise setup you have different levels of control whereas in the cloud services the controls and access are limited:

There are a number of relevant services that play an important role during the deployment process. They are as follows:

Use the link, https://manage.windowsazure.com/, in order to access the management portal of Windows Azure. It manages all Azure Services. Also, PowerShell is available for more options (this topic is covered in detail in a later part of this chapter).

Infrastructure as a Service helps companies to move their physical infrastructure to the cloud with a level of control similar to what they would have in a traditional on-premise data center. Core data center infrastructure components are storage, servers (computing units), the network itself, and management tools for infrastructure maintenance and monitoring. These are depicted in the following diagram:

Infrastructure as a Service taxonomy

Platform as a Service provides the user with a configurable application platform including a preinstalled software stack. PaaS can be understood as another abstraction layer above the hardware, OS, and virtualization stack:

Platform as a Service taxonomy

PaaS provides execution runtimes service without direct access to the OS (databases, development platforms, and application servers).

Software as a Service is a cloud services delivery model, which offers an on-demand online software subscription.

The latest SaaS release of Microsoft is Dynamics 365 (previously known as Project Madeira). The following diagram illustrates the SaaS taxonomy. Here you can clearly understand different services such as Sales force, NetSuite, and QuickBooks which are distributed as SaaS:

Software as a Service taxonomy

In an on-premise architecture, one needs to take care of all the services and layers of the software system starting from the network layer up to the application layer (client). Here, the cost of maintenance is high, and it is a redundant service.

In IaaS, Microsoft provides a virtual abstraction of the operating system, which can be used as any on-premise operating system, and hence it lowers the cost of maintaining low-level systems.

In PaaS, a specific platform is exposed to the user so as to make the service even more precise and the user is concerned only up to the platform he/she is using; all the layers below it are managed by Microsoft.

SaaS is the latest of all services, where specific software can be isolated from all those complex layers. The user just needs to worry about the software layer, and everything beyond that is handled by the cloud factory. It is the easiest and most efficient model in cloud technology.

There are almost 15 folders in this category. These are folders that contain agreement terms in different languages. They also contain the developers' help file, which is an extremely valuable asset for NAV Developers and consultants. Let us understand its components in brief.

ADCS stands for Automated Data Capture System. The pattern implemented by ADCS helps Microsoft Dynamics NAV to communicate with different handheld devices through web services.

For example, if we want to test any handheld device that transmits a radio frequency, then we can use a radio receiver to capture those radio frequencies, and then a VT100 plug-in can be used to test that connection. The plugin helps Microsoft Dynamics NAV to receive the data transmitted from the device. The data is fetched in the form of an XML file, and can be used for further processing.

This folder contains the tools used for the ClickOnce installation process. The details of the ClickOnce process is explained in a later part of this chapter.

This folder contains a zip folder called DynamicsNAVIntegrationSolution.ZIP, which contains customization settings, content type, solution code, and other web-related resource files. It also contains a JavaScript file, which contains functions such as ConnectToNavClient, which is used by the NAV system to connect to the CRM and vice versa. It can be used by developers to make changes in the connection.

It contains the .msi file, which can be used to install the outlook add-ins. This is a useful tool if you, by any chance, miss the installation of Outlook components during the Dynamics NAV installation process. It can also be used if the outlook component is corrupted.

This is a very important folder, which should be properly understood before we start the installation process. It gives the details of all the prerequisite components that are required for the installation process. It is extremely important that one must fulfil all the prerequisites in order to guarantee a successful installation process:

This folder contains the configuration file for Role Tailored Client (RTC). It also contains all other essential component files that help RTC to connect to the middle tier. This folder is required in the later part of this chapter, in the ClickOnce installation in particular.

This is another very important folder, which contains the license file along with the precious SQL Demo database backup file. In most of the cases when we accidentally corrupt our demo database, we can easily restore this .bak file. This comes in very handy if we want to play with the database and objects.

I personally believe this part to be the best part of Dynamics NAV 2016. It contains tools that can be used to test our customizations against regression issues. Most of us do not even know about this part, and I would like to go into detail over this in Chapter 4, Testing and Debugging. Some experts also call it the last missing piece to complete the big puzzle called Road to Repeatability.

This folder contains the tools that are key to the upgrade process. We will go into detail on the Upgrade toolkit in Chapter 9, Upgrade and Migration.

This folder contains most of the PowerShell Scripts, which can be used for various PowerShell operations related to multi-tenancy, database, company data, Azure installation, and many others. In fact, most of the manual operations can be customized using PowerShell Scripts, which is available in this folder. Since this is an extremely useful topic, I have explained it in detail in the Installation scenarios section of this chapter.

It is recommended to use Internet Protocol security (IPsec) for data encryption to maintain a secure channel between NAV and SQL System. IPSec uses cryptographic security services. For a better understanding of the concept, refer to the following diagram:

In Microsoft Dynamics NAV, we can also use the Azure SQL database, which is a cloud service. It provides data storage, and the best part is that it is inbuilt in the Azure services platform.

We can directly connect the Microsoft Dynamics NAV Server instance to Azure VM.

We can categorize the PowerShell commands into five major categories of use:

Here, in this section, I will break down the basic syntax of PowerShell Script, and explain how it functions:

Syntax: get-service -name "*net*" 

The preceding syntax can be broken down into four essential parts. The first part, that is, GET, is a function, which is generally used as a verb that signifies the main action of the code. The second part is generally a noun, which defines the operation. Part one and part two combine to form a command, leaving part three and four to be the name and argument, which combine to form a parameter. This is better explained as follows:

I have drawn the following simple figure just to explain the process for a better understanding of the PowerShell Script. Every PowerShell Script can be understood by this method, and it's even easy to memorize and manipulate it if you can understand the structure of the scripts:

The following is a list of prerequisites for this installation process:

The entire process can be understood in just a few steps, which are as follows:

The steps mentioned in the preceding section can be understood in detail as follows:

Or find the folder in the NAV Installation DVD in NAV.Installation.DVDClickOnceInstallerToolsProgram FilesMicrosoft Dynamics NAV90ClickOnce Installer ToolsTemplateFilesNAVClientInstallation.html.

Following is the list of prerequisites for this installation process:

The entire process can be briefly understood in just a few steps, which are as follows:

The steps mentioned in the preceding section can be understood in detail as follows:

The same process can be used to upgrade, using the setup file shared over the network of Windows machines:

And that's it! The installation process is simplified and distributed over the network. If the process implements an Internet protocol, then it's even easier to distribute the system.

Following is the list of prerequisites for this installation process:

The entire process can be understood briefly in just few steps, which are as follows:

The steps mentioned in the preceding section can be understood in detail with the following detailed steps. I have tried the Classic Portal. You can also try the new Portal; the steps will remain the same:

The second model uses two virtual machines, the NAV web server and service tier, and another VM for the NAV database. This is better for a system using huge databases:

Steps needed to prepare PowerShell commands

In these steps, I will explain how we can utilize the readymade command file, which is nothing but PowerShell Scripts prepared by Microsoft for administrative purposes:

1. Run PowerShell ISE as an administrator.
2. Change the CloudHowTo folder:
   • Set-PartnerSetting.ps1
3. Delete the #TODO (as explained in the following screenshot, highlighted in yellow):
   

   Tip

   Update the values with the name of your subscription; here, replace MyAzureSubription with your Azure subscription.

   Provide a value for the parameter as required, and save the file.

   Now we can proceed with two types of deployment, deployment on single Azure VM and deployment on two Azure VMs. I will only elaborate on the first, since both deployments have similar steps.

4. Get ready for deployment (a single Azure VM):
   • Use Example-1VM.ps1 using the PowerShell command present in WindowsPowerShellScriptsCloudHowTo
   • Example-2VM.ps1 is used to deploy the system on two VMs, whereas Example-1VM.ps1 is for a single VM

Note

Note that the cmdlets are to be run on a virtual machine, so copy the saved file onto your VM first.

The steps in this example file are explained as follows:

1. Create a new virtual network if it does not already exist.
2. Create a Azure VM, if it doesn't already exist, and wait until it is ready to use. Now create an SQL Server data disk.
3. Upload the following files to the VM:
   • The NAV DVD
   • The .bak file that should be used when creating instances
4. Install the SSL certificate that is used for HTTPS on the NAV Web Client as well as on the NAV server's OData and SOAP web services.
5. Install NAV on the VM.
6. Add a tenant (instance) on the VM.
7. Just select the code section, press F8 or right-click on the code, and click on Run Selection under Options.

Note

Since all the cmdlets are already present in the file, CM on two machines also can be done similarly. The best part of the example file is that it is well documented and clear to read.

Following is a list of prerequisites for this deployment process:

To deploy a Microsoft Dynamics NAV database to an Azure SQL Database, the database must be exported as a data-tier application (DAC) file, which is known as a .bacpac file. This can be done using SQL Server Manager.

Creating a new database in the Microsoft Azure online portal includes some easy steps, which are explained as follows:

Let's test the connection from our local Microsoft SQL Management Studio. Before we start the connection, let's note down the information that will be needed for the connection. Go to the DASHBOARD tab of the server (similar to the CONFIGURE tab in the last step), and note down the administrator login information; this is the user name. From the dashboard of the database, note down the server name. In this case, the server name is j498jdtrqf.database.windows.net. Now let's use this information for the connection of the database engine. Use the password that we used while creating the database:

After successful connection, you can see the Azure SQL database on your SQL Management Studio Object Explorer. Now we can treat this database as any local database. But if we want to add any database to this server, then we will have to follow the steps which will satisfy certain criteria set by Azure Server.

Now, let's see how to replicate a database to the Azure SQL database:

This will deploy a local database to SQL Azure and a connection is established between the local DB and the SQL Azure Database Server:

Now you just need to click the Next button, and you will be presented with the Deployment Settings page, which is an important one, because here you will have to connect to the Azure SQL database with your credentials, as shown in the following screenshot:

It takes a while depending on the size of the database.

After the process is sucessfully completed, we can see the same database in the SQL Azure database, as can be seen in the next screenshot.

Here, we have successfully connected an Azure SQL database using our SQL Server Management Studio, which is a local entity. You can see a database named Demo Database NAV (9-0) inside the database server, j498jdtrqqf.database.windows.net(SQL Server 13.0.81 - rabins):

In case of an error, try to find the error, resolve it, and repeat the same process.

We will now create a virtual machine which will be used to host the Microsoft Dynamics NAV system. Follow the following steps:

Now we can configure the instance setting in the Microsoft Dynamics NAV Administration tool, as shown in this screenshot:

We can easily connect to the Role Tailored Client after the services are restarted.

Following is the list of prerequisites for this installation process:

The entire process can be understood in just a few steps, which are as follows:

We are first going to separate the application data from the business data.

The following are the steps for separating the application data:

      #cmdlet for removing Application 
      Remove-NAVApplication 
          -DatabaseServer <Server name> 
          -DatabaseInstance <Instance name> 
          -DatabaseName <name of the original DATABASE> 
 
      #cmdlet for mounting Tenants 
      Mount-NAVTenant 
          -DatabaseName <NAVDatabase> 
          -Id <TenantID> 
          -ServerInstance <NAVServerInstance> 
          -OverwriteTenantIdInDatabase 
      ---------- 

It is quite easy to get going with the PowerShell commands by just working around the codes.

For example, we can just write these commands and compile them as follows:

Set-ExecutionPolicy RemoteSigned -Force 
 
Import-Module 'C:BackUpProgramFilesNAV.9.0.44974.NA.DVDWindowsPowerShellScriptsMultitenancyHowTo-MoveCompanyToTenant.ps1' 

This will give you access to all the functions of the PowerShell file:

It is again the PowerShell cmdlet that makes like easier; just locate the folder WindowsPowerShellScripts/Multitenancy in your installation DVD, and you are just one step away from all the possible stuff you need in the multitenancy world.

Just import the file in Windows PowerShell ISE (run as administrator), and execute it to get the result as follows: