from my customer I have the following requirement:
A VMware host shall manage VMs for application clients running on Windows Server 2016. In the plant of the customer there are 75 operators concurrently working with this application.
Therefore, my idea is to create a RDS Host VM which is providing many concurrent Windows sessions. The operators get thin clients and connect via RDP to the hosrt where the application is installed.
Unfortunately I have no experience how to correctly setup the architecture for RDS Host correctly.
From the application developer there is the recommendation to host at maximum 25 sessions per RDS Host. This would mean I need 3 RDS Hosts, that arrange somehow internally which operator is connected via which RDS Host.
How is this connection management performed within RDS? Is there a centralized instance managing it?
What are the virtual hardware requirements for such an RDS Host? Do I just multiply the single session application requirements by 25 ?
In case on host fails, is it possible to dynamically turn on an additional VM that takes over?
Is it correct that I need 75 Device CALs?
Thanks for you help!
Related
I currently use a on premise Microsoft Remote desktop services (session based) to host a few apps and allow users access via RemoteApp.
I'm having to maintain this farm of servers that's becoming more and more cumbersome. Is it possible to use any container platform (AWS, Azure, Kube) to host this layer? Like a bunch of Windows servers with the remote app enabled and just point users there? Each use would use up a container and then tear it down (I prefer it to be single use - so any data stored by the user is destroyed) - and I won't need to worry about patching or managing each of these windows servers individually.
We have several virtual machines on Azure. One running an SQL Server, the others are Windows Virtual Desktop hosts.
We have an application on the WVD hosts that connects to the SQL server but it takes forever to connect and start.
When running the application on the SQL machine using 127.0.0.1 to connect, everything works fine. Whenever I use the private IP of the machine, everything slows down immensely (even when running on the SQL server machine)
Alle machines are in the same VNET and region. Everything is also connected to Azure Active Directory Domain Services in the same VNET.
What might becausing the 'slowness'? Where should I start looking?
Thanks in advance!
I've added an image of the network topology. Could it have anything to do with the AADDS Load balancers? (I'm not at home when it comes to load balancing, etc)
We have a website up and running, and we decided to move to Azure.
The database was migrated to SQL Azure using the DMA (Data Migration Assistant), and we created a VM on Azure, then we published the website on IIS on the VM.
Now, we have two different domains with two different databases, and the old website is much faster than the new one (azure website).
We couldn't find exactly where is the bottleneck; in the database, or in the connection, or in the VM (processor or IIS, ...).
The specifications of the Azure resources:
VM: Standard D2s v3 (2 vcpus, 8 GB memory)
DB: Premium P1: 125 DTUs
Can anyone hint us how to detect the main cause of this slowness?
If your application have load then the best practice to do that host your application on a different azure machine and host your database on a different azure server and make a virtual network between your machines.
When you create an Azure virtual machine (VM), you must create a
virtual network (VNet) or use an existing VNet. You also need to
decide how your VMs are intended to be accessed on the VNet. It is
important to plan before creating resources and make sure that you
understand the limits of networking resources.
Load balancers
Azure Load Balancer delivers high availability and
network performance to your applications. A load balancer can be
configured to balance incoming Internet traffic to VMs or balance
traffic between VMs in a VNet. A load balancer can also balance
traffic between on-premises computers and VMs in a cross-premises
network, or forward external traffic to a specific VM.
The load balancer maps incoming and outgoing traffic between the
public IP address and port on the load balancer and the private IP
address and port of the VM.
Read this to configure.
How can I deploy Access applications to multiple companies, with linked tables to SQL Azure servers?
I'm planning to deploy the Access programs with Microsoft Access runtime, and I'm assuming that I'll need to include the odbc drivers as well? Is there a way to automatically have Azure create a new server when a company signs into my website and downloads a program, and have the Access program link to it? And is there a way to get around the IP address settings in Azure as well? Because companies will be using the programs on multiple PCs. Or is it possible to utilise that and charge per PC?
If you distribute the application pre-linked, then the user should not have to do anything to consume the data.
When using Access with SQL server you can in general use the standard windows built in SQL driver. However in the case of Azure you do need to download + install the native 11 drivers (so I recommend you use that driver during development and setup).
You can also have code include to re-link to the sql server, but as noted, if your application is “already” linked, then you really don’t have to do anything on application startup. Such re-linking would not be required every time the application starts, but only a “one time” re-link is required say if you’re going to change the database, or perhaps the user logon. How to re-link (DSN less) is outlined here:
http://www.accessmvp.com/DJSteele/DSNLessLinks.html
As noted, you really don’t need the above.
As for IP restrictions, in the Azure setup you can turn off such restrictions if you need a connection that will occur from any location, but that does open up a security hole. (when you first create the SQL database you will be prompted for firewall rules).
All of the above assumes you been developing that Access application with SQL server as the back end (you can even use the free edition of SQL express for development on your local machine).
Last but not least:
Because your connection is occurring OVER the internet, then you speed will be MANY times slower then using a local server. Read the following article to get a “grasp” of this speed difference:
http://www.kallal.ca//Wan/Wans.html
So MUCH additional work is required in Access to obtain good performance when your connection is OVER the internet as opposed to SQL server running on your local network.
We are building a client solution that will be hosted on servers in a data-centre. It consists of several servers all related to providing the client solution. There is no internal network to protect but for some reason our UAT environment has the notion of a DMZ in the server diagram.
We have an IIS box which will have a public IP. Then we have two servers DB(Sql Server) and APP that are only on the internal lan with no public IPs. You can only RDP to these servers via VPN. Our IIS server needs sql access so port 1433 is open from IIS box(DMZ) to the sql server. We are also opening several ports from the IIS server to the APP server which hosts WCF services.
My understanding was that a DMZ was meant to protect internal private networks and that these networks should not be accessible from the DMZ but we are now opening up ports to both our APP and DB servers so they are accessible from the DMZ. In the end most of our servers are accessible from the IIS server via certain ports.
We originally wanted to setup our SQL server for AD authentication only but since our IIS server is in the DMZ and has no AD access we will be forced to enable mixed mode authentication in SQL server. This might be another security issue in it's own since we are now forced to store passwords somewhere on the IIS server to be able to auth against sql server.
Are we not perhaps missing the idea of a DMZ?
So with a system where you have a DMZ, there is also a firewall involved.
So your system should look like this I think:
SQL-server hosting internal data
Other servers needed for the company
---- firewall ----
SQL-server hosting data for web solution
AD-server (if needed)
Web-server
FTP-server (could be on the web server also)
With this setup you don't expose company-sensitive database to the outside world and you also don't open up a port in the firewall making it possible for attackers to (maybe) get access to the internal database which has company sensitive data...
Just my suggestion based on the information provided.