| Server Name | Function |
| 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, ip-gp01.cloudapp.net, 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 /N:CN=ip-gp01.clouldapp.net /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.
 |
| ASP.NET 4.5 |
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, ip-gpweb.cloudapp.net.
selfssl /N:CN=ip-web.cloudapp.net /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 (https://manage.windowsazure.com).
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:
- 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.
- 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 - http://support.microsoft.com/kb/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
- 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 http://www.microsoft.com/silverlight/
- 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!
MG.-
Mariano Gomez, MVP
IntellPartners, LLC
http://www.IntellPartners.com/
0 comments:
Post a Comment