Microsoft Dynamics GP 2013 on Windows Azure: The Deployment Process

Welcome to the third installment on Microsoft Dynamics GP 2013 on Windows Azure. In the previous article I showed how to provision the various VMs needed in our environment - see Microsoft Dynamics GP 2013 on Windows Azure: Provisioning Process. The following is a summary of the VMs with the applications and services they will be running:

Server NameFunction
ip-ads01 AD DS server
ip-sql01 Database Server
ip-gp01 GP and Session Service
ip-gpweb IIS, Web Client, WMC, and Session Central

The deployment started out with some prep work, as follows:

Active Directory Server (AD DS)

On the AD DS server, I setup a few domain user accounts and security groups that will be needed to run both Microsoft Dynamics GP's Session Service and Session Central Service services on the GP server (ip-gp01) and the Web Client and Web Management Console application pools on IIS (ip-gpweb). In addition, I have created two security groups, GP Web Admins to add any Dynamics GP web administrative user, and GP Web Users to add any domain account that will be accessing the Microsoft Dynamics GP via the web client interface.

Active Directory Users and Computers

Microsoft Dynamics GP Server (Session Host)

With the domain accounts and groups needed out of the way, I proceeded to install Microsoft Dynamics 2013 and the Web Client Runtime on ip-gp01. The installation is straight forward as you would expect with most GP installs. If you have configured your DNS server properly the ODBC configuration done by Dynamics GP should happen without a hitch. Upon completing the initial file installation, you will run Dynamics Utilities to setup the application system database - thanks to the new named system database feature in Dynamics GP 2013, I have called this DYNGPSYS - and setup the sample company, Fabrikam.

On this server also, I will setup a self-signed certificate pointing to my public DNS for this machine,, which I will export and import on my local machine. Another certificate is created for the private DNS, ip-gp01.ip-forest.local to create a secure communication between the web server and the session host.

For this, I use a tool called selfssl.exe which you can download below. Selfssl is a part of the IIS Resource Kit. From the command prompt with elevated administrative rights you can run the following command:

selfssl / /V:365 /P:443 /T

Once selfssl generates the certificate, you can proceed to import the certificate into the Personal root and the Trusted Root Certification Authority folder using the Certificates mmc snap-in on the ip-gp01 VM. In addition, this same certificate must be imported on the IIS VM in the Trusted Root Certification Authority folder to provide a secure path to Session Service.

IIS Web Server

Next up was prepping the web server, ip-gpweb. The first task of order is to add the Web Server  (IIS) role to this VM, carefully making sure you select ASP.NET 4.5 from the Application Development Role Services for IIS - ASP.NET 4.5 is required by the Web Client components.

Following the installation of IIS, you will then proceed to create a physical folder for the web client files - I took the easy way out and setup a C:\inetpub\gpweb.

In addition, I imported both certificates created for ip-gp01 to the Trusted Root Certification Authority folder to provide a secure path to the session host machine.

Finally, I used the selfssl.exe utility to create a self-signed certificate for the public DNS name of my machine,

selfssl / /V:365 /T /P:443

I use this certificate to setup the web site in IIS, which is also a pre-requisite to the web client installation process:

Website created with self-signed certificate

Web Client Installation

The Web Client installation happens in two phases since I have provisioned a web server and plan to use a separate session host machine.

The Web Server

On the IIS server, you will need to run a custom install to select only the Web Server components.

Since you are working on Azure, to expose the website, you will need to create a new end-point on port 443 for the web server using the Azure Management portal (

The Session Host Server

A custom installation to install the Session Server will do here.

The only tricky aspect is the runtime service, which requires a certificate to configure the service for SSL. Here I chose the cert previously created on ip-gp01. Note I am using port 443, which differs from the standard port, as it is the port I used when creating the certificate with the selfssl.exe utility.

Now that all is in place, you should be able to launch Internet Explorer from any machine outside of the Azure network and access Dynamics GP.

What I learned from this exercise:

  1. Due to Azure's tight security, the provisioned servers have just the necessary TCP and UDP ports opened. On the SQL Server VM, you will need to open ports 1433 and 80 if deploying SSRS. SQL Server will also need to be reconfigured to support Mixed Mode Authentication prior to beginning the installation of Dynamics GP.

  1. On the Dynamics GP and IIS servers, you will need to install .NET Framework 3.5 prior to running the Setup.exe application - by default, Windows Server 2012 installs .NET Framework 4.5. This could prove a bit confusing under Windows Server 2012, since during the confirmation process of adding the role, you are confronted with a warning message requesting an alternate path to the .NET Framework 3.5 installation files.
Add Roles and Features Wizard

    As it turns out, the resolution is fairly well documented in Microsoft Support KB article 2734782 -, which calls for running the Deployment Image Servicing and Management tool (Dism) from the command line. Now, I happened to have the Windows Server 2012 installation files on a 32GB pen drive a carry around. By remoting into the GP and IIS servers with my local drives enabled I was able to point to the Sources folder on my pen drive allowing the .NET Framework 3.5 to be installed.
    Dism /online /enable-feature /featurename:NetFx3 /All /Source:(folder_name)\sources\sxs /LimitAccess
  1. It's easier to download the Silverlight client on your local machine and move it to your IIS VM, than attempting to install it from your IIS VM directly. As it turned out, Internet Explorer security on Azure disables scripting, so accessing any Microsoft website, ironically becomes a nightmare. You can download Silverlight from

  1. The tenant configuration file, TenantConfiguration.xml, must list (not point to, i.e., no UNC path) the paths on the session host server for each of the GP application runtime files requested. The tenant configuration file is a part of the Web Client files on the IIS VM.

There may certainly be other details that I may have forgotten to point out and other issues you may encounter along. This wasn't an easy process and frankly required quite a bit of research and bugging people like Microsoft's Daryl Anderson to get this right, but the effort was well worth it.

Until next post!

Mariano Gomez, MVP
IntellPartners, LLC


Tamar said…
I couldn't locate the selfssl download link. Can you please post it? it would be very helpful to me as the version I currently have runs only with .net 3.5 and I need a version that runs with 4.5.

Unknown said…

We have a requirement to use the web client but to make use of different launch files (to accommodate different forms and reports dictionaries).
Although we set various tenants to point to different locations, it seems the web client is only wanting to use the dynamics.set and dex.ini contained in this tenantconfiguration.xml file.

We have another install (not R2) of the web client, and with this there is no tenantconfiguration.xml file at all, and we are able to accomplish our desired result.

Has this functionality been removed in GP 2013 R@, and if so, is there another way to meet our requirement?

Thank you
Neil Palmer
Mariano Gomez said…

You can find selfssl.exe at the following link:

Mariano Gomez said…

Are you doing a scale out deployment of web client (not Single Machine)? If so, you should be able to install Tenant Services.

A Single Machine deployment only supports 1 tenant, regardless of whether you have Tenant Services installed.

Beat BUCHER said…
Hi Mariano,
For the purpose of doing a proof of concept, could the Web services, the GP apps & SQL server all be installed on a single VM in Azure ? what about the web client ?
Thanks in advance,
Mariano Gomez said…
Yes, it can all be installed on the same VM.

Mariano Gomez, MVP
BlueTube said…
Hi Mariano, This may be off topic but I was wondering if you have any experience deploying Dynamics GP 2015 via GPO. We have about 25 users and it doesn’t make sense to go to each PC and install GP and the other add-on (including Integration Manager, Management Reporter and 3rd party software). I tried to use the template but it doesn’t work very well because there are several pre-requisites such as Redistributed C++, Dot Net, Etc.). If you are aware of anything , please let me know.
Mariano Gomez said…

Don't assume I know what the acronym "GPO" stands for. However, I have experience deploying GP on Citrix, Terminal Server, and Azure.

Beat BUCHER said…
In short GPO stand for Group Policy Object... a mechanism created way back in Windows 2000 to manage deployment of settings across all PC's from a same domain..
I've never used GPO to try to deploy a Dynamics GP client, but from my experience, it's much easier to manage 25 users thru Citrix or Terminal Server. I have over 100 users in our company accessing GP from 5 continents around the world thru Terminal server and no issues with that.
BTW, the deployment package wizard does a great job to deploy to a handful local PC's where a full client is required.
BlueTube said…
Thanks Beat, The deployment package is fine if you have to go around and install GP on each PC but not for GPO deployment (i.e. silent deployment). Citrix/RDS are both fine but, from my experience they're "ALL or NONE" solution. meaning, you either deploy all your apps on them or none. You can't deploy, for example, GP on it and not Office, and other apps used by each Client PC and these apps tend to work with (integrate) with each others and they perform best when running on the same box.

Thanks for your input.

Popular posts from this blog

Power Apps - Application Monitoring with Azure Application Insights

DBMS: 12 Microsoft Dynamics GP: 0 error when updating to Microsoft Dynamics GP 2013 R2

eConnect Integration Service for Microsoft Dynamics GP 2010