Tuesday was the unofficial first day of the conference for me with the agenda being one of two things for those who chose to come a day early. There was a sales presentation for those on the business development side and there was technical training on the web client for the rest of us.
Generally you have to pay for training but due to the importance of this product release and the new content, Microsoft put this training on for free – which was awesome. They really want to make sure the Partner channel is informed and ready for the web client specifically, and understand the “stack” dependencies to be able to troubleshoot it when it does release.
The training ended up filling up very quickly and they even had a waitlist. So many people signed up that they had to pair people up to share virtual machines to do the hands on lab portion. They had 40 VM environments and over 90 people registered. Fortunately, I was one of the “leads” which meant I got to have my hands on the keybaord for the hands on portion. Everyone learns differently and I definitely learn by doing, and/or writing things down, so I was happy not to be just a spectator.
Here in no particular order are some of the key takeaways I got out of the day. These are my observations and notes, so please take them with a grain of salt if you plan on relying them as the complete facts!
I’m not a network guru by any stretch but if you are going to get into GP 2013 and web client, you will want to make sure your technical consultants are well versed in network setup, troubleshooting network issues, SSL, certificates, firewalls etc. Gone are the days where the technical “expert” simply needed to click setup.exe and go next-next-next through a GUI installation wizard.
The web client can be a standalone installation, in the sense of using one server with all of the components. That will be common in demo environments with partners putting it all on a laptop for presentations. However I imagine the most common deployment will be some splitting of the components on their own servers. This is a brief explanation of the components. Sometimes I describe the components as if they will be on their own servers; ignore that if you intend to install everything on one and keep all of the requirements in mind for that environment.
1. Web Server
2. Member Servers aka Session Hosts
3. SQL Server
This server must be running Windows Server 2008 R2 64 bit for the operating system. There are components that are in R2 that are required so this is the minimum standard. One web server is required; you can load balance if you wish. A good note on this item, the web server really doesn’t have much of a function in the end once the silverlight app is running so from the sounds of it, most clients should not require multiple web servers in their deployment.
Two websites get installed on this server: the GP web client website and a GP web client management website for managing the sessions and tenants.
One major service runs on the web server: the Session Central Service. This is the traffic cop of sorts that directs traffic to one or more Session Hosts as new users connect.
The session host also must be running Windows Server 2008 R2, for the same reasons as above.
The session host is the server (or servers) where the Dynamics GP client is installed and where all the instances of Dynamics GP run.
This server is the workhorse of the web client environment so it sounds like in most environments, most clients may ultimately use multiple session hosts to manage the web client users’ workload, if there are lots of web client users.
When a user goes to the web client URL (i.e. https://ourwebserver/gp), they log in with an Active Directory account and the web server authenticates that. If validated, a runtime instance of Dynamics GP starts on the Session Host. The Session Central Service (the traffic cop) determines which Session Host is least busy and ready to accept a connection. The runtime instance of dynamics.exe starts sends information back to the silverlight application so they now have a “link” to communicate back and forth. At this point the web server is out of the picture, hence my comment in that section about it not necessarily being a key component.
One note to avoid confusion, Active Directory is used to log into the web client URL to authenticate as a valid GP user. The silverlight web client application still requires the user to log in to GP with a valid GP user ID and password.
This server really doesn’t change. There is no special O/S requirement, it continues to be the same as it always has been with the web client because how GP connects to SQL doesn’t change.
The client side requirements are pretty simple, however for some the operating system requirement will be problematic if they are still using XP or Vista.
Operating System requirement is Windows 7 or higher, or Windows Server 2008 R2 (if using a terminal server) or higher.
Browser wise, Internet Explorer 8 or higher will be required.
Silverlight 5 is the required version but the first time the web client is launched it will apparently prompt you to install the right Silverlight version if you don’t have it already.
The key services are as follows and what they do:
1. Session Central windows service
As mentioned above, it’s essentially a traffic cop and this runs on the web server only. It tracks the current runtime processes running on every session host and determines session host availability for load balancing (without requiring any special configuration for that function).
2. Session Host windows service
This service runs on each session host, one service per host. It’s purpose is to authorize web client users against Active Directory.
3. Runtime Service (WCF service)
This runs on the session host, per instance of GP with a unique WCF endpoint for each GP process. It handles the interaction between the GP silverlight application and the underlying physical GP client process running on the session host.
4. Tenant Management Service
5. Tenant Discovery Service
These two services I didn’t get enough details on, they refer specifically and only to multi-tenancy situations.
I’ll stop this part for now here… and continue with some more details on what we covered in the “Jump Start” training. So much to share, so little time : )
(originally posted on www.kuntzconsulting.ca, and migrated to this site in October 2017)