Dynamics GP Technical Airlift 2012 - Web Client part 2

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

1. Certificates
2. SSL
3. Firewalls
4. Domain Users & Groups
5. 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 your deployment.  For instance if you will have extranet access, the certificate authority may need to be an external authority, not via internal Active Directory Certificate Services (ADCS).

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

After this you will also export the certificate, save the pfx file on the web server (or a place that you can access 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 you start the installation of the GP2013 web client.  After you import the certificate above, in IIS, on the default web site (or whichever website you create for the GP web client), you click on Bindings under the Actions pane and add the HTTPS SSL binding with the certificate.

To test that this portion worked, you can click on the Browse https link to open the website.  Because it opens with "localhost" you will see a certificate error.  The certificate has specific DNS names, not localhost, so this is expected.  However if you change the website from localhost to your actual website name, assuming this name matches what you put in the certificate properties in the first place, the certificate error should go away.  This type of error would specifically tell you 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 you have to set a couple of rules 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 your deployment choice.

Domain Users & Groups

Before beginning the installation you will want to ensure you have created both one or more service accounts for the services and groups for the users.  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.
• 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 you 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, 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 zone (as long as there is one or more read-write Domain Controllers you can 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 you provide.  This will be ready for RTM release, not Beta.  The deployment can be exported and imported in case of changes so you don't have to run through the wizard over and over again.  The end result is something that walks you through the settings you'll need.

Final Thoughts

A few random final thoughts around 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, no web client. They will be able to use web client for the portions of their business that they can if they choose.