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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
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.
Detailed Error Information:
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.
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/
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 |
 |
| Installation Option |
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 |
 |
| Web Site Configuration |
 |
| Web Management Console database |
 |
| Session Central Service |
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 |
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 |
The final aspect is to review the installation settings and kick off the install itself.
 |
| Install Progress |
 |
| Progress Bar |
 |
| 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.
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/
Comments
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.-
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.-
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.
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.-