Wednesday, September 19, 2012

Windows 8 and the Microsoft Dynamics GP Web Client Series - Part 2b

Windows 8 and the Microsoft Dynamics GP Web Client Series
Part 2b

This series narrate my personal experiences of installing Microsoft Dynamics GP 2013 Beta and the Web Client in an unsupported environment. The following installation steps are for testing purposes only and were done on a test box. If you are to test, please make sure your machine is not a production box.

"While it's not supported, it doesn't mean it won't work. It only means we haven't tested it"...
                                                                                                      Microsoft Dynamics GP Support

Now that we have Microsoft Dynamics GP 2013 and the Web Client Runtime installed, it's time to take a look at the Web Client installation process.

Web Client Installation

The installation process starts with the usual legalese stuff around Licensing Agreement and why you must accept these terms - pretty simple: you don't and you cannot install the software.

License Agreement
Once you pass the first screen, you are at the point of choosing between the two installation options. In the case of a single server (or word warrior workstation like mine) you will want to choose the Single Machine option. However, if you have multiple servers playing in your environment and you want the ability to segment services and what's not, then the Custom option is the way to go.

Installation Option
The Windows User Group window allows you to specify either the Web Client User group or user account and the Web Management Console user group that will be allowed to access the Web Client or administer the environment, respectively. Here we will be using the local accounts we setup in Part 1 of this series.

Typically, most customers will already have an Active Directory group in their domains where they already have Microsoft Dynamics GP users added to, since nowadays you need something similar to access SQL Reporting Services and Business Analyzer reports (if you are into making administration easier). So this is where I recommend using what you already have.

As for the Web Management Console, this will probably continue to be in the domain of the Microsoft Dynamics GP system administrator or simply become an extension to the functions of the overall system administrators in the organization.

Windows User Group
The next option is to enter the domain account that will be used as the application pool identity for the Web Client website. Again, here we will use the account we created in Part 1 of this series.


Web Site Configuration
Next up is creating a database to store our Web Management Console settings. If you are going to use Windows Trusted Authentication, the account you are using should have at least dbcreator rights on SQL Server to be able to do this.

Web Management Console database
Session Central service communicates with the website and maintains stats on all the session services running on the session host machines. Session Central service listens in on port 48650 by default (you can configure your own). If using SSL, you must select the personal store certificate created in Part 1 of this series. The port will automatically be setup on the firewall by the installation.

Session Central Service
As far as analogies go, think of Session Central service as a Distributed Process Manager (DPM). For more information on DPM, take a look at the Microsoft Dynamics GP 2010 Architecture Whitepaper.

Session Service is a Windows service that runs on the Session Host machine and is responsible for authorizing users, creating user sessions, retrieving existing sessions, and monitoring sessions to report back to the Session Central service.  The Session Service will also start a shell instance of Dynamics GP,  also referred to as a Runtime.Process.exe, at the time a requesting GP Web Client users is authenticated as a valid user.

Session Service listens in on port 48651 by default (you can configure your own). If using SSL, you must select the personal store certificate created in Part 1 of this series. The port will automatically be configured on your firewall by the installation.

Session Service
Again, as far as analogies go, think of Session Service as a Distributed Process Server (DPS) instance. For more information on DPS, take a look at the Microsoft Dynamics GP 2010 Architecture Whitepaper.

Finally, we need to specify the Runtime Service URL which by default listens in on port 48652. This URL provides the information for building the user's session address (in the form of https://machineaddress:48652/RuntimeService/pID) where pID is the process ID generated by the GP shell application.

Runtime Service URL
This is the only part of the configuration where an SSL certificate is strictly required.

The final aspect is to review the installation settings and kick off the install itself.

Install Progress

Progress Bar
A key troubleshooting aspect from all of the above is to ensure that the GP Session Central Service and GP Session Service are running. For that, you can check the Services panel under Administrative Tools or Computer Management.

GP Session Central Service and GP Session Services should now be running 

This concludes the installation portion of the Web Client and so far we have not ran into any issues with the process itself.


Now, it's time to launch the Web Client...

In my first attempt to launch the client I received the following error:


HTTP Error 403.14 - Forbidden


The Web server is configured to not list the contents of this directory.


Most likely causes:

A default document is not configured for the requested URL, and directory browsing is not enabled on the server.

Things you can try:


If you do not want to enable directory browsing, ensure that a default document is configured and that the file exists.

Enable directory browsing using IIS Manager.
1.     Open IIS Manager.
2.     In the Features view, double-click Directory Browsing.
3.     On the Directory Browsing page, in the Actions pane, click Enable.

Verify that the configuration/system.webServer/directoryBrowse@enabled attribute is set to true in the site or application configuration file.

 

Detailed Error Information:

Module
DirectoryListingModule
Notification
ExecuteRequestHandler
Handler
StaticFile
Error Code
0x00000000
Requested URL
Physical Path
C:\inetpub\gpweb
Logon Method
Anonymous
Logon User
Anonymous

 More Information:


This error occurs when a document is not specified in the URL, no default document is specified for the Web site or application, and directory listing is not enabled for the Web site or application. This setting may be disabled on purpose to secure the contents of the server.


Clearly, I did not want to enable directory browsing, but after noticing that the site wasn't even launching it was evident that the ASP.NET client was not installed on the site. As mentioned yesterday, this problem was solved by applying the steps outlined in the TechNet article, Installing IIS and ASP.NET Modules. I once more checked my website and now had the following folder under my Web Client website.

aspnet_client folder under gpweb Website

The fun did not end there. So, I will cover some troubleshooting topics tomorrow, before continuing into other findings.

Until next post!

MG.-
Mariano Gomez, MVP
IntellPartners, LLC
http://www.IntellPartners.com/

6 comments:

BrianG said...

I'm getting "There are no remote servers available to handle the request. " when trying to login. Thanks for blogging this process!

Mariano Gomez said...

Brian,

This tells me your GP Session Services service is down. Go to Administrative Tools | Services and check that the GP Session Services is running.

MG.-

Thomas Garcia said...

Hi Mariano. Thomas from ICON (Dominican Republic) here. I was able to install as per you test and it was beautiful until the "Applying personal settings" progress window logging into Dynamics GP with the web client. The lower-right-hand corner message field shows "Error" right when it is about to show the home actual home page in Dynamics. I reviewed my settings on the home pages (for both 'sa' and a different users I created for testing) and nothing looks bad. Any ideas? If you want just email me to share thoughts on this experiment (tgarcia@iconbc.net).

Mariano Gomez said...

@Thomas:
I'm at the same stage and have not been able to overcome this issue either. This is where the 'unsupported' disclaimer comes into play. I will continue to work through the issue, but don't get your hopes up ;)

MG.-

BrianG said...

@Mariano
Thank you, I did verify that the services were running, but when I looked at the log I got this:

Microsoft.Dynamics.GP.Web.Services.Session.Service.SessionCentralService Error: 0 : Session Central Service was not able to successfully communicate with the Session Service at https://test.XXXX.lcl:48651/SessionService. The exception details are:
System.ServiceModel.Security.SecurityNegotiationException: Could not establish trust relationship for the SSL/TLS secure channel with authority 'test.XXXX.lcl:48651'. ---> System.Net.WebException: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel. ---> System.Security.Authentication.AuthenticationException: The remote certificate is invalid according to the validation procedure.

I guess it's not liking the self signed SSL certificate.

Mariano Gomez said...

@BrianG:

If I read the error correctly, it would sound that you are trying to install this in a multi-machine environment. Is this correct? Also, can you check your certificate thumbprint against the certificate mapped for each port? To do this, go to IIS and check the certificate, then compare the thumbprint value against the certificate hash shown for each port by running netsh http show sslcert from the command prompt.

If they differ, you have a certificate problem, in which case you will have to delete the ports using netsh http delete sslcert ipport=0.0.0.0:portshere

You will then need to uninstall the web client and reinstall.

MG.-