Remote Desktop setup on Server 2012 R2 Standard
-
@flomer said:
@scottalanmiller Hmm... I get a creeping feeling that there might be a server here and there that might be running without the striclty required number/type of licenses. My present project just got a bit more expensive
The need for RDS CALS is your expense here. Normal user CALS are not typically that much of a factor.
-
@flomer said:
@scottalanmiller Hmm... I get a creeping feeling that there might be a server here and there that might be running without the striclty required number/type of licenses. My present project just got a bit more expensive
When you choose Windows, especially for software that is going to require remote desktops rather than running as modern software, you have decided on an extremely expensive solution. That's a ton of money that you need to spend before even getting started. If you choose SQL Server as part of the mix, that cost goes up dramatically again.
Using Windows for custom software is something that you do either because you have already spent all of that money and don't care any more or you lack the skills to make things that are cheaper and are "buying" your way out of needing those skills. Choosing Windows as a requirement for a product incurs immense cost both in acquiring proper licensing as well as in license management. Not to mention a huge loss of flexibility in general and a loss of optional deployment scenarios.
-
Since this is your own software, why not build it so that you don't have these costly requirements?
-
@scottalanmiller said:
If you choose SQL Server as part of the mix, that cost goes up dramatically again.
SQL Server Express is perfectly designed for this scenario and is 100% free, so that statement is not true.
That statement is true for many scenarios with custom software, but not his example.
-
@scottalanmiller Well, back in the late ninties we used to be a Unix shop, since our software required laaarge servers and lots of processing powers. The customers really wanted us to change to Windows, and over the years we even started using Java rather than C++/Motif, so now we are stuck in Windows-land for most projects. Since we are using Java, I guess I will inform the project leaders that Windows licenses actually might be a bigger cost than we originally thought... Only one of our customers still use Linux, but it's their system that we never have any problems with
-
Java? For fat clients? Ugh. Better than some options, but not good at all. What is driving you to have fat clients at all? That was already considered a bad practice by the later half of the 1990s except where special needs made modern technology impossible. Most of those cases are gone by now.
I would look at good customer education here. Clients moving FROM Linux to Windows is absolutely crazy. Offering both is fine, but the cost of licenses, lack of flexibility, lack of support options.... that's nuts. Especially if you have Java which runs better on Linux already!
-
@scottalanmiller Customer education is not so easy... We want them to choose our product, and like I said, the users were all afraid of Unix/Linux. In many ways some of us working with the software have always looked at Windows as being inferior. After many years I guess it is getting quite usable, but I am surprised about all the licenses we require and the complication it all leads to...
Thanks for all the answers!
I'll order the necessary RDS CALs and get this sorted out right.
-
What is making your product have these kinds of requirements at all? Seems like there would be easier fixes that would improve the product and remove the need for any of this.
-
@scottalanmiller said:
What is making your product have these kinds of requirements at all? Seems like there would be easier fixes that would improve the product and remove the need for any of this.
This is an application that already exists. You do not rewrite things on a whim.
-
@JaredBusch said:
@scottalanmiller said:
What is making your product have these kinds of requirements at all? Seems like there would be easier fixes that would improve the product and remove the need for any of this.
This is an application that already exists. You do not rewrite things on a whim.
Agreed, but it is worth considering and evaluating. It is only the client, not the full product (I'm building a bit of the design from the way it is talked about) that would need a rewrite. Might be easier than assumed.
-
Also assuming that there is not a specific reason that a Java client is needed. Likely it is not needed, but there are exceptions, of course.
-
Well, the main application itself, is a "server" that is started automatically as a service. It gathers data and performs calculations based on the input. Data may be exported, but not always, but stored in proprietary databases. The user interface comes up by way of Interactive Services Detection, and is a bit of a pain... The application is being rewritten as we speak and will use HTML and a browser for GUI in the next version. BUT, the customer is only allowing RDP traffic to the server, not http, so...
-
@flomer said:
Well, the main application itself, is a "server" that is started automatically as a service. It gathers data and performs calculations based on the input. Data may be exported, but not always, but stored in proprietary databases. The user interface comes up by way of Interactive Services Detection, and is a bit of a pain... The application is being rewritten as we speak and will use HTML and a browser for GUI in the next version. BUT, the customer is only allowing RDP traffic to the server, not http, so...
Just one customer or most or all? If it is just a few... that's their own issue, right? If they refuse secure HTTPS and demand RDP... sure. But that's on their end, not your end. Why get involved, right?
