Running Sparx on Windows 10 multi session

[Modesto Vega]

I know Sparx runs fine on Windows 10. However, does anybody know if it runs as well on Windows 10 multi session. According to https://docs.microsoft.com/en-us/azure/virtual-desktop/windows-10-multisession-faq:
"[Windows 10 multi session] formerly known as Windows 10 Enterprise for Virtual Desktops (EVD), is a new Remote Desktop Session Host that allows multiple concurrent interactive sessions."

Is anybody aware of any potential issues?

[Glassboy]

From a quick read, if the profile management includes the users' registry hives and they're set to persistent you should be fine.  That would be fun to have a play with. 

[Geert Bellekens]

We tested that on both Windows 10 as Windows Server, and it works just fine.

Geert

[BruceTOGAF2]

Is there a similar discussion about Running Sparx on an Azure Virtual Server?  What is the recommended architecture and Sparx product to support 20 simultaneous Sparx EA users on Azure?

[Geert Bellekens]

Is there a similar discussion about Running Sparx on an Azure Virtual Server?  What is the recommended architecture and Sparx product to support 20 simultaneous Sparx EA users on Azure?

We are running EA on Azure using WVD with 45 floating licenses.

No complaints so far.

Geert

[BruceTOGAF2]

When you run Sparx EA on Azure using Windows Virtual Desktop;
1. Is the Sparx EA client installed in each user's workstation?
2. Is the Sparx EA client installed once only in the Azure VM?
3. Are you using a Sparx Floating License Server?
4. Are you having an individual Sparx license number for each user?
5. Does the Sparx EA client 'Connect to Server' or Connect to Cloud'
6. Do you have an Azure RDS instance installed with the DB Server containing the Sparx Repository DB?
7. Are you using Sparx Cloud Service, Sparx Pro Cloud Server or neither?

[Geert Bellekens]

When you run Sparx EA on Azure using Windows Virtual Desktop;
1. Is the Sparx EA client installed in each user's workstation?

No, EA is only installed on the Azure Virtual Machine, and exposed to WVD

2. Is the Sparx EA client installed once only in the Azure VM?

Yes, only once

3. Are you using a Sparx Floating License Server?

Yes, installed locally on the same Azure Virtual Server

4. Are you having an individual Sparx license number for each user?

No, we use floating licenses

5. Does the Sparx EA client 'Connect to Server' or Connect to Cloud'

They connect to an SQL server database

6. Do you have an Azure RDS instance installed with the DB Server containing the Sparx Repository DB?

The SQL Server is installed on a different Azure Virtual Server. We didn't choose for Azure SQL because of issues with the Active directory integration.

7. Are you using Sparx Cloud Service, Sparx Pro Cloud Server or neither?

Neither, we don't really have a use for the cloud server.

Geert

[BruceTOGAF2]

Hi Geert,

My client is moving from PostgreSQL in AWS to MS-SQL Server in Azure. I am considering the various architecture options.

There seems to be little benefit in the traditional archiecture of Sparx EA client and ODBC installed on each user's workstation.

The Sparx EA client installed once only in the Azure VM sounds like the ideal environment especially if this integrates well with the Floating License Server and Windows Active Directory. 
Does the Azure VM have to be a very high specification (memory and CPU) to enable 50 users to simultaneously run a Sparx session in the Azure VM?
Would this architecture support Sparx Pro Cloud Server?

In my last contract I created new Sparx users by importing users from Windows Active Directory.  Does this Azure VM environment complicate this import process?

[Geert Bellekens]

At this one client (45 floating licenses) we definitely didn't go for the highest tier.
I don't know the details, but I believe they went for a specification just above the minimal, something like 8 core 16 MB ram for the server hosting EA

With v15.1 you don't even have to import users from Active Directory, you can simply link EA groups to AD groups.
Users are then automatically added/removed when they try to log-on.

Apparently there is an option to "merge" (federate?) your local AD with the Azure AD. For some reason (external companies maintaining the infrastructure) they wasn't finished in time, so we had to setup a separate users for our Azure environment. With proper planning (and a cooperative sub-contractor ) this could be avoided (or so I have been told, I'm not a specialist)

Pro Cloud Server can also be installed in Azure, but it seems logical to do that on another VM.

Geert

[Guillaume]

Hello,

A client is looking at moving from an On Premise EA + central DBs to a full Cloud solution using Ms Azure services to host both the DB and EA application.
- EA will no longer have to be installed and updated on each user's PC
- It will be possible to install and provide third party add-ins (like EA, it won't have to be installed on each PC)

I gathered some answers from this thread i.e. I understand that Azure Virtual Desktop works well to run EA.
For the DB, has anyone successfully used Azure SQL to host the EA dbs, and connect from EA via the Pro Cloud Server ? What are the alternatives in Azure,  MySQL ?

Thanks

[Geert Bellekens]

Hello,

A client is looking at moving from an On Premise EA + central DBs to a full Cloud solution using Ms Azure services to host both the DB and EA application.
- EA will no longer have to be installed and updated on each user's PC
- It will be possible to install and provide third party add-ins (like EA, it won't have to be installed on each PC)

I gathered some answers from this thread i.e. I understand that Azure Virtual Desktop works well to run EA.
For the DB, has anyone successfully used Azure SQL to host the EA dbs, and connect from EA via the Pro Cloud Server ? What are the alternatives in Azure,  MySQL ?

Thanks

I believe Azure SQL works for EA, but the problem (a few years ago) was that we couldn't get the security based on our Active directory working for Azure SQL.
We opted back then to install an SQL server in Azure.
If in fact Azure SQL fully supports AD security, or you can live with SQL Server logins, you can definitely use Azure SQL.
We don't use PCS

Geert

[Guillaume]

Hi Geert,

Thank you for the information. If I understood well, the AD issue was related with the access from EA to the Azure DB via ODBC, not with the EA Security pemission itself.
Since we will use the PCS, I believe that SQL user logins will be used for the ODBC access from the PCS. EA will connect via the "Cloud Connection" to the PCS via https.

Thanks
Guillaume

[Geert Bellekens]

Hi Geert,

Thank you for the information. If I understood well, the AD issue was related with the access from EA to the Azure DB via ODBC, not with the EA Security pemission itself.
Since we will use the PCS, I believe that SQL user logins will be used for the ODBC access from the PCS. EA will connect via the "Cloud Connection" to the PCS via https.

Thanks
Guillaume

Yes indeed.

Geert

[Modesto Vega]

Hi Guillaume,

A service account is used to run the PCS windows service, this service account must have permissions to access the repository. Your client is going to have to run PCS on a server VM, so having PCS and SQL Server running on the same VM makes sense and will work fine.

If model security is a requirement, AD is the easiest way to achieve this on Azure but your client could use Sparx EA users (not that I recommend it).

From memory, Azure SQL supports AD but I have never had Sparx EA and PCS running on an environment architected the way you described.

[Guillaume]

Thanks for your feedback