Ratakan

Informations :

Microsoft Dynamics GP 2016 - Advanced HTML5 Web Client Planning and Deployment

As we've mentioned in previous blogs, the framework and infrastructure of the Web Client environment has not changed with the new HTML5 client. You will not need to take any additional steps in planning a deployment of the HTML5 client, that you didn't take in a previous deployment. That being said, there's still some information that we feel would benefit the community, based on questions we see in Support Cases. Here are five tips that will help you as you steer and implement a deployment of the HTML5 client.
1. The System Requirements stated in the page I've linked below are minimum requirements, not necessarily the recommended. Every environment is different, and various environmental factors such as network throughput and security restrictions can necessitate a higher starting point for your resource planning.  The best thing that you can do for each new environment that you're starting to plan an implementation for would be to sit down with the IT department, or with your IT department. Hopefully, if you ARE the IT department and you're reading this, you'll have a grasp on the inner workings of your network. Here are some things that I would look for in the initial stages of planning a Web Client Deployment. What is the network throughput between all workstations? Do any clients connect via WiFi? What is the WiFi band? What type of cables are in the building? What is the max network speed of the NICS? The switches? Are there multiple subnets that users are on? What network appliances sit between the user's machine and the server? Is there Web Filtering software/hardware? Software/hardware firewalls? Is there a DMZ? A static IP on the main router? Dynamic DNS like No-IP or DynDNS, and if so, what machine is the host? Are there any applications or appliances utilizing IPv6? Once you start to build a complete map of the network and infrastructure that you'll be integrating with, you'll be ready to start planning.
2. When you're planning the deployment, don't get too overburdened with the technical terms. Focus on the following points:
Who is going to be accessing the Web Client, how important is it that the Web Client is always up for them, and where will they be accessing it from? Apply the knowledge you gathered previously to begin the planning from there.
3. DNS and Certificates don't have flexible rules that you can just "make something work." If you planned something wrong, and purchased a certificate with the wrong DNS name, you can't usually just muscle something together. Certificates are be used to encrypt SSL traffic flowing through the DNS name of the Issued To or the Subject Alternative Name, and cannot be used for any other traffic. The SSL handshake will simply fail. Since certificate traffic requires a 1-1 path, DNS entries work the same way. A single 'A' record in DNS will point to a single IP address. A 'CNAME' record will point a single DNS label to a secondary DNS label; which assumes an 'A' record behind the secondary with an IP address. The certificate name does not have to match the server name, if you are using some other method of DNS name resolution. For example, my Azure test environment is set up with the local Contoso domain, but I access Web Client using a cloudapp.net DNS name. Since I have my public DNS and Azure Endpoints set to route traffic to the correct VM, I can set the hostname of my runtime service to use the cloudapp.net hostname, since I have ensured that traffic to example.cloudapp.net:443 goes to IP address A, and example.cloudapp.net:444 goes to IP address B. The hostname on the destination matches the certificate encrypting the SSL traffic, so the handshake completes.
4. When using multiple session host servers, keep in mind that most routers only allow a 1-1 routing for port forwarding. If you are deploying Web Client for remote access, and the environment doesn't allow conditional forwarding, you'll likely have to set each Runtime process to run on a unique port. You can run the IIS web site on the same port as the Runtime service on the single machine, but let's say for example's sake that you installed a second server with the Runtime and GP installed. A remote user is attempting to access the Web Client, and types in https://example.cloudapp.net/gp. This traffic hits your Firewall on port 443, and you've set the rule to forward traffic on 443 to the IIS server. The IIS server responds, and delivers the login page to the user. After authenticating, now the user gets the Silverlight/HTML5 client, and a connection string to the other server, but this server is using a different certificate. I'm fine to use the same port then, right?
Sure, internally where the traffic can route the unique certificate hostname to each unique machine. However externally, you only have a single static IP address on your router in this example. Both DNS names in your public DNS have to point to the same static IP address of your router. That traffic hits the firewall, routes to the IIS server based on the 1-1 port forwarding rule, and you get an error because you're on the wrong server.
The second server in this example would have to have a unique hostname (for internal access differentiation), as well as a unique port (for external access differentiation.)
5. Draw pictures of your network path. If you're anything like me, visually tracing a route helps in the resolution. Ask questions like, "if this machine made a request to address.domain.com, where would that IP response come from; local or public DNS?" "If this user tried to connect to this hostname from inside the network, what would the IP response be?" DNS isn't magic, it is logical. A computer makes a query, and receives a response. Identify the computer making the query, and identify the computer returning the query. Netsh,  nltest, and netdom are INCREDIBLY powerful command line tools if you are attempting to map out an unfamiliar network.

No comments