We have the old vizionapp remote desktop 2011.
I have install RM2012 and allow the upgrade of the 2011 RemoteDestop database.
Then run the last exe of ASGRemoteDesktop and lauch the “Upgrade 2012 environment”.
After that ASGRemoteDesktop was up and operational locally but not on remote connection.
Because we are stuck I have restore the old vrd2011 database and it work perfectly with remote connection on the same SQL server, with the same configuration like firewall rules and the ”allow remote connection” option on sql server.
Telnet on the 1433 port works too.
Environment: windows server 2008 R2 std + SQL server 2008 R2 and win 10 for the remote connection PC.
We continue with the old version until the issue… but please, HELP
What error do you get? I think something that the SQL server can't be connected? Or the database? Please check your security of the old database and compare to the newly created - use Microsoft SQL Management Studio - I think you have some security roles assigned for the old database that you now also need for the newly created database
(14-01-2021, 03:46 PM)DevOma Wrote: What error do you get? I think something that the SQL server can't be connected? Or the database? Please check your security of the old database and compare to the newly created - use Microsoft SQL Management Studio - I think you have some security roles assigned for the old database that you now also need for the newly created database
no real error just : Connection Check Failed for the user domain\user
and the same user or another work fine locally.
I think the problem is on the database, because the SQL server works fine with the other "2011remotedesktop" database.
I already checked the Autorisation section on Management Studio (see attachement) but not sure if it's the only way to check.
If you click F1 in the app and navigate to the chapter "Working with Environments=>Working in database mode=>Necessary permissions on SQL server instance" - there it is described which roles you need for your user
The error tells me that you can't connect the database with the current user - you also can assign this domain user to the db_owner - and try again - if it works you have to look for the right permission - but the error is definitely that the database can't be accessed for the user you are using...
Do you really use vRDDbUser in your environment specification? It is also possbible to use "Windows Integrated Auth" - then your Domain-User must have access to the database server - but if you use an internal database user it has nothing to do with your domain account
I try to set a user to db_owner = KO
set permission to select, connect, execute for admin, owner, and a user = KO
I try to remake the user selection in ASGRD and add a new group with the same list of user than the built-in grour "administrator" = I no longer have access to the content of the database at all, ASGRD is empty and all the options are grayed out. It's even worse and don't know how to roll back.
There is no reason to configure any security groups inside ASGRD if you can't even connect to the database - that only make sense if you can start ASGRD successfully
You can deactivate permissions with the following SQL
DELETE FROM ItemProperties WHERE ItemId = '1BF121C1-EFC4-4851-9407-D652D3B7C5BF' and RolePropertyId = '2924F6D4-8AB0-4EA4-8FE7-1BB078EC86B7'
And then again - how did you configure your environment - in Environment Manager - select your environment and choose Edit - In "Access the database" properties do you have an internal SQL user for authentication against the SQL Server or do you "Use Integrated Authentication"? You should be able to test your database connection at this point - you should compare with your settings of your old instance - if you use the internal user (vrddbuser) make this user to db_owner in database for the correct database - else do the same for your Windows Account that you use (not in login dialog of ASGRD) - the Windows Account that you are logged on to your local system will be used (Integrated Auth :-))
(15-01-2021, 09:46 AM)DevOma Wrote: There is no reason to configure any security groups inside ASGRD if you can't even connect to the database - that only make sense if you can start ASGRD successfully
You can deactivate permissions with the following SQL
DELETE FROM ItemProperties WHERE ItemId = '1BF121C1-EFC4-4851-9407-D652D3B7C5BF' and RolePropertyId = '2924F6D4-8AB0-4EA4-8FE7-1BB078EC86B7'
And then again - how did you configure your environment - in Environment Manager - select your environment and choose Edit - In "Access the database" properties do you have an internal SQL user for authentication against the SQL Server or do you "Use Integrated Authentication"?
You should be able to test your database connection at this point - you should compare with your settings of your old instance - if you use the internal user (vrddbuser) make this user to db_owner in database for the correct database - else do the same for your Windows Account that you use (not in login dialog of ASGRD) - the Windows Account that you are logged on to your local system will be used (Integrated Auth :-))
Before, I was able to start ASGRD locally with success !
your sql line restore the connections list on the sql server. thanks
in Environment Manager all option are grey except connect. I cant' clic on edit and test the database connection at this point .
" - you should compare with your settings of your old instance - " I'm not sure but if it's only at : ASGRD db> properties > Autorisation > it's the same than RemoteDesktop db ( connect, select, execute for vRDDbUser)
but not sure to understand because we always connect with integrated Auth
But in your posted screenshot you have the vrddbuser granted to the database - and not your DomainUser!
Goto your SQL Management Studio - I have only the english categories but I think you will find it in your french setup too
Security=>Logins=> Select your user or your domain user group => Properties => category "User Mapping" - scroll to your database or compare there which role is enabled - for testing purposes you should try to set db_owner for your ASGRD database - and then you should be able to connect!
(15-01-2021, 12:54 PM)DevOma Wrote: But in your posted screenshot you have the vrddbuser granted to the database - and not your DomainUser!
Goto your SQL Management Studio - I have only the english categories but I think you will find it in your french setup too
Security=>Logins=> Select your user or your domain user group => Properties => category "User Mapping" - scroll to your database or compare there which role is enabled - for testing purposes you should try to set db_owner for your ASGRD database - and then you should be able to connect!
ok thank you for the path, see attachement of our mapping users setting.
Also, I have a new information. I have test a succeful remote connection from a rds server + domain administrator session + Int. Auth only
not works if a type manualy the credential Domain\administrator + password
not work if another user session + manually domain\administrator or domain\user manually or Int. Auth
Once again - login to asgrd and authentication against the sql server are 2 different things!!! The settings for your database environment connects the database - if this is successful you can login with an ASGRD user - and if permissions are enabled these permissions will be checked!
So first scenario - your domain admin (Windows Account) has database permissions and can connect the database! Great!
Second / third one - manually Domain/User - that can be only done for the ASGRD user - has nothing to do with the Windows Account that you are currently running on your local Windows session! If you have "Use integrated auth" specified for the connection the database will be connected by the windows Account!
Can you just try to create a new ASGRD Database? Perhaps you will see some more detailed error then? So try to create a new Database environment - and try also to use "Integrated Auth" - so you should see if that works or not - and perhaps it fails you get some more information about what is going wrong
But where does the user "vRDDbUser" comes from - I just think that you have used this account for your connection in the old version! If you can't edit directly via GUI - I think the old file for the environments was named vRD.config?!? For newer versions it is environments.xml - you also can right click a environment in the list of the environments and choose "Copy" - then you will have the connection string - and there you should also be able to see if the vRDDbUser is used or not...
(15-01-2021, 03:31 PM)DevOma Wrote: Once again - login to asgrd and authentication against the sql server are 2 different things!!! The settings for your database environment connects the database - if this is successful you can login with an ASGRD user - and if permissions are enabled these permissions will be checked!
So first scenario - your domain admin (Windows Account) has database permissions and can connect the database! Great!
Second / third one - manually Domain/User - that can be only done for the ASGRD user - has nothing to do with the Windows Account that you are currently running on your local Windows session! If you have "Use integrated auth" specified for the connection the database will be connected by the windows Account!
Can you just try to create a new ASGRD Database? Perhaps you will see some more detailed error then? So try to create a new Database environment - and try also to use "Integrated Auth" - so you should see if that works or not - and perhaps it fails you get some more information about what is going wrong
But where does the user "vRDDbUser" comes from - I just think that you have used this account for your connection in the old version! If you can't edit directly via GUI - I think the old file for the environments was named vRD.config?!? For newer versions it is environments.xml - you also can right click a environment in the list of the environments and choose "Copy" - then you will have the connection string - and there you should also be able to see if the vRDDbUser is used or not...
In the environnement Manager the protection is "User Based".
If I copy the string >>> " Data Source=SRV-002;Initial Catalog=ASGRD;Integrated Security=True"
I created a TEST_ASGRD db and it's the same issue: Ok with Windows Int. Auth by administrator session
Can you also copy the connection string from old installation? Just to see if you also have used "Integrated Security=True"?
And again - your Administrator seems to be in a valid group to have permission for the database - all other users not! Do you have a Database Administrator who can check that? It's related to the Windows Accounts you are using...
(18-01-2021, 09:17 AM)DevOma Wrote: Can you also copy the connection string from old installation? Just to see if you also have used "Integrated Security=True"?
And again - your Administrator seems to be in a valid group to have permission for the database - all other users not! Do you have a Database Administrator who can check that? It's related to the Windows Accounts you are using...
So you have to look on the database instance again - Security => Logins - there could be Domain Groups, Users or internal users listed - I don't know to which group your users belongs - but if you find the right group (like Domain Users) - click Properties and again User Mapping - that have you done already or the internal users that are not used :-)
(18-01-2021, 12:36 PM)DevOma Wrote: Ok also Integrated Auth
So you have to look on the database instance again - Security => Logins - there could be Domain Groups, Users or internal users listed - I don't know to which group your users belongs - but if you find the right group (like Domain Users) - click Properties and again User Mapping - that have you done already or the internal users that are not used :-)
I think we lost vrddbuser. it's set everywhere but I can't found it in AD.
so I add a new ASGgroup (domain group) that I'm a member add a can test log in a remote connection with succes but the list is empty.
under ASG db > security > users >ASGgroup > dbowner is set
No vRDDbUser is a local database user - you can use this user instead of using "Integrated Windows Security" - you only have to ensure that you are assigned to any group that has permission to the database!!!
on the remotedesktop 2011 db there is only vRDDbUser set .
yes I'm sure I'm a memeber of ASGgroup.
I 've tried also with my own login, set in security of the server and select the ASGdatadase in the list
then on the ds security ASGdb mapped on my domain user logins (connect, execute and select) but still empy...
some informations:
- actually the owner of ASG db is our Domain administrator ( like the remotedesktop2011db)
- I have a Schema named vRDDbUser on remotedesktop2011 db ( I try to add the same to ASGdb but ... still same issue)
- the authorisation provider is always dbo who is mapped with domain administrator
- when a try to see the effective Authorisation on ASGgroup on ASGdatabase, I receive a message that impossible because, ASG group doesn't exist or I'm not allowed
Just try to work on your remote workstation - create a new SQL database environment (inside ASGRD - option: Create new database) - if that's working, just import your data from 2012 database again...
(19-01-2021, 09:57 AM)DevOma Wrote: Just try to work on your remote workstation - create a new SQL database environment (inside ASGRD - option: Create new database) - if that's working, just import your data from 2012 database again...
- Ok I 've copied the remotedeskto2011 ,
- upgrade to remotedesktop2012,
- from my workstation, lauch ASGRD2020 create a new database ASGRD2020db and succesfully connected on this empty db.
- lauch the environnement wizard and choose upgrade from 2012 environnement and get the error :
>>An error occured on executing an sql statement (LogsRemoveByDaysAndCount) but IT WORKS on my Remote Workstation and the other workstation too!
- I 've tried on RDS server and I get the error : Error Initializing the desktop ( Object reference not set to an instance on an object )
I continue to search. I don't understand why the first issue, because there is no right to the new DB execpt me who am the owner... (alreadey tested)
Thank's a lot for your help this make a big step for us.
