A continuation of the first part of my articles on the GP 2013 Web Client, this post goes through some of the other training things that were covered that are installation-related. Some of the things in this article are:

  • Certificates
  • SSL
  • Firewalls
  • Domain Users & Groups
  • Deployment Strategies

As I mentioned in the first article, this is not an exhaustive resource for installing the web client. To be quite honest, there are several areas which are pretty new to me so there may be instances where I don't have the terminology described quite correctly… drop me a line via the comments if there are any glaring errors!

Certificates

First, a certificate must be requested and it can be one of three types: Self-Signed, Internal or External (3rd Party).  Some notes:

  • Self-signed certificates are recommended for test environments and single-server deployment only.
  • Internal or External certificates will depend on the deployment. For instance, if there is a need to have extranet access, the certificate authority may need to be an external authority, not via internal Active Directory Certificate Services (ADCS).

The training covered creating an internal certificate only. High level, this is done via ADCS, on the domain controller, using MMC snap-ins. First, create a Certificate Template, one that is exportable. Then use the Certification Authority snap-in to administer a certification authority (CA) based on the template created. Last, go to the Certificates snap-in, create a new certificate, set the properties (the DNS names of the server machines) and enroll.

After this, export the certificate, save the pfx file on the web server (or a place that can be accessed from the web server), and on the web server import that certificate and enroll it on that machine.

During installation, only websites with valid certifications and SSL will be in the drop-down list of sites to install the GP web client to. There are four places during the installation where the certificate name comes into place:

  • IIS web site (required)
  • Runtime Service (required)
  • Session Central Service (optional but recommended)
  • Session Service (optional but recommended)

SSL

The website must have SSL binding before starting the installation of the GP 2013 web client. After importing the certificate above, in IIS, on the default website (or whichever website is created for the GP web client), click on Bindings under the Actions pane and add the HTTPS SSL binding with the certificate.

To test that this portion worked, click on the Browse https link to open the website. Because it opens with "localhost" expect to see a certificate error. The certificate has specific DNS names, not localhost, so this is expected. However, if the website is changed from localhost to the actual website name, assuming this name matches what was put in the certificate properties in the first place, the certificate error should go away. This type of error would specifically tell the installer it's a name mismatch (as opposed to "no certificate installed" types of errors).

Firewalls

Firewall settings come into play when we are dealing with both intranet and extranet or DMZ traffic. Some firewall setup is already a part of a standard Dynamics GP installation when it comes to the proper settings to allow SQL server port traffic through. Typically a couple of rules need to be set on port TCP1433 and UDP1434 inbound rule on the SQL server to allow traffic through, such as the web server trying to communicate with the SQL server.

I won't get into details here except to say there are firewall implications to consider depending on the deployment choice.

Domain Users & Groups

Before beginning the installation ensure both one or more service accounts for the services and groups for the users have been created. The recommendation for our demo installation was this:

  • Two groups - GPWebUsers for the actual web client users and GPWebMgmtUsers for the Web Management Application users.
  • The user account for the application pool identity - i.e. something like GPWebAccount
  • User accounts for the Session Central Service & Session Service service accounts

Deployment Strategies

This topic can't be covered in a single blog but to give an idea of some of the planning elements that must be taken into consideration, these are the types of deployments we did talk about.

  • Stand-alone deployment, for testing or demoing. One firewall between the internet & intranet, one internal user, and all components installed on one server/machine.
  • Intranet-only deployments. All users are internal. Using several servers - one or more web servers, one or more session hosts, possibly load balancing on the web servers.
  • Extranet deployments such as hosting environments. Because Active Directory is required, one option discussed was putting a read-only Domain Controller within the extranet/DMZ (as long as there is one or more read-write Domain Controllers it is possible to have read-only DCs).
  • Mixed deployments. Various issues to plan out including how the URLs will work. Will all users use the same URL or will it be different for internal users vs. external users?

They are developing a Web Client Deployment Tool which will help with providing a specific task list for deployment based on the inputs provided. This will be ready for RTM release, not Beta. The deployment can be exported and imported in case of changes so the wizard does not have to be run through over and over again. The result is something that walks the installer through the settings they'll need.

Final Thoughts

A few random final thoughts about the web client. Initially, the phase 1 Web Client will be limited to Financials and Distribution modules. The phased approach will follow this release plan approximately, with the exact timing unknown:

  • Phase 2 US Payroll, Human Resources. No plans for Canadian Payroll to be web client-ready at this point.
  • Phase 3 Project Accounting
  • Phase 4 Field Service
  • Phase 5 Manufacturing

What this specifically means is clients using those applications will be using "rich client" only, not web client. They will be able to use the web client for the portions of their business that they can if they choose.