I have re-installed all the enterprise, portal and asp.net 4.5 clients on all the servers, on all of the standard windows machines they chat and communicate 100%, except when it comes to connecting to the remote vps servers.  The server that i am using for the remote connect option, is accesible, and I can manage all the remote vps servers via the server manager software from microsoft, they all have delegated access enabled and working, but if I use the remote option in solid cp, it contuninually gives this error in the log files and in solid cp it says solidcp does not have permissions to access the remote servers. despite having full comms between all the servers in the microsoft environment/software managers.

[9/8/2019 2:04:10 PM] ERROR: 'Microsoft Hyper-V 2012 R2' GetExternalSwitchesWMI
System.Exception: Invoke error: You do not have permission to perform the operation. Contact your administrator if you believe you should have permission to perform this operation.
   at SolidCP.Providers.Virtualization.PowerShellManager.ExceptionIfErrors(List`1 errors)
   at SolidCP.Providers.Virtualization.PowerShellManager.ExecuteInternal(Command cmd, Boolean addComputerNameParameter, Boolean withExceptions)
   at SolidCP.Providers.Virtualization.HyperV2012R2.GetSwitches(String computerName, String type)
   at SolidCP.Server.VirtualizationServer2012.GetExternalSwitchesWMI(String computerName)

I have even installed a seperate vps configured with the enterprize server and portal with a fresh db and try connect to a remote vps with the same results, there has to be a rights issue, or something like that that is causing this issue.

I have even run the hvremote script and tested from both client and server and the tests run 100% as it should be configured for hyper v core remote management..  Please I need to resolve this or look for another cp to manage our vps's

OK I have tracked this issue down to the user of the solidcp app pool on the server being used to connect to the remote servers. I got onto one of the core servers cleared all the logs and everything, and started to track this issue down, when connecting from solidcp to the server, I noticed a failed login coming from the primary server (The one used to connect to the remotes, referred to from now as the primary server) with the user SCPServer, I checked that all the passwords were setup and configured correctly, to no avail it kept on failing the login.

I then took a hit an miss option, because all the servers are in a domain, I configured the website app pool on the primary server with the SCPServer user I created in the domain users, then I edited the app pool on the primary server and setup the user as domainSCPServer and entered the correct password, an what do you know I can now connect to the remote servers and manage the VPS's on them.

So My question is if the servers you are using are in a domain, how are the app pools supposed to be configured, and / or what steps are to be taken when getting SolidCP to talk to these remote servers. As the servers are HyperV core, you dont install software or run scripts which setup access on these servers. So I assume your primary server  has to use a user, that has permissions on the remotes..

This just might be a reason why servers in a domain have this issue, and other setup might not have this problem.

Hello,

Glad you was able to track down the issue. When SolidCP connects to remote HyperV servers it does indeed use the SCPServer user configured in the app pool. This is set during the installation of SolidCP Server component.

We then run the commands from within this user. We do normally suggest creating the SolidCP User in the domain if one is present.

I believe if no domain is present you need to create the same SCPServer user and password on the remote machines for the login to work.

Regards,

Trevor

Maybe this needs to be added to the documentation when setting up VPS with the remote option, I just dont understand why the previous versions up to 1.4.2 worked 100% and when installing 1.4.3 it re created the app pool or changed it from what it was, such a long time ago since we started with this, not sure if we used the domain user or not. Anyway the main thing is it is now working again.