Issues when logged in via Bastion to Rhino.Compute server

I am having problems installing my .rhp plugin such that my Rhino.Compute server in Azure loads it on startup.

When i ping the /sdk endpoint i can see that my plugin commands which should be listed at the bottom are missing. However, I have ‘manually’ installed it to Rhino desktop on the server and can see from Tools> Plugins that it is loaded and enabled.

Would it be that it needs to be placed in a specific folder in order to be accessible to Rhino.Compute when running from IIS as a service ?

(p.s. on my older server setup from couple of years ago the compute server loads it and the /sdk endpoint confirms that its commands are available – i just can’t for the life of me see what is different between my two environments! I don’t need to use Yak do I for an .rhp plugin that i don’t want to make available as a public package?)

Well I don’t know if this is the correct approach, but this appears to have worked for me…

  • log in to the Azure server (using Bastion)
  • stop Rhino.Compute service from IIS
  • start Rhino Desktop app and go to Tools > Plugins > Browse to my .rhp file
  • close Rhino
  • copy the newly created folder
    C:\Users\<USERNAME>\AppData\Roaming\McNeel\Rhinoceros\7.0\Plug-ins\<my plugin folder>
    C:\Users\<MY ISS APP POOL NAME>\AppData\Roaming\McNeel\Rhinoceros\7.0\Plug-ins\<my plugin folder>
  • from IIS restart the service
  • ping the /sdk endpoint to confirm the commands in my .rhp file are now listed at the bottom .

hope that helps someone else.

@MonkeyFace This isn’t the typical way this should be done. When you run the “bootstrap” script from the guide, it will automatically create a new user profile in the RDP called “RhinoComputeUser”. It also creates a randomized password and prints both the username and password to the console window once the bootstrap script is completed.

The process of installing a 3rd party plugin would be to log out of the VM and then log back in using the RhinoComputeUser as the username and the randomized password. Once you’re logged in, you would install your plugin the way you install any plugin. If your plugin is on the package manager, then you can install it that way. If it’s a plugin which needs to be copied to the Grasshopper “Libraries” folder, you can do that too (make sure they’re unblocked). Or you can drag/drop an .rhp onto the Rhino window. Once you’ve verified your plugin is loaded/working, you can log back out and restart your VM.

The reason this works is because IIS uses the RhinoComputeUser as the profile it uses to launch the rhino.compute instance. So, when rhino.compute is run it will look into all the appropriate plugin locations assigned to RhinoComputeUser and load those plugins appropriately.

Also… you can confirm your plugins is loaded by calling one of the two endpoints that were added a few months ago (see changelog).

  • /plugins/rhino/installed - will return a sorted dictionary of Rhino plugins which are installed.
  • /plugins/gh/installed - will return a sorted dictionary of Grasshopper plugins which are installed.
1 Like

Hi @AndyPayne, yes I am familiar with that. However attempting to login via Bastion with the generated creds which in my case were…

 User Name: RhinoComputeUser
 Password: }vth0E|&-@tqAMHi]hE

repeatedly yields the following error:

I highly suspect that this is due to certain characters in the password string being rejected.

Therefore I have been unable to follow the documented workflow and have had to hack things logged in on my Azure VM Admin account - or as you correctly observe on the account being used by IIS.

Perhaps it is possible for me to change the password that was randomly generated? Is it being stored/referenced in multiple places?

Hmm. I haven’t tried Bastion. Are you able to log in to your VM using the Remote Desktop Connection application? I haven’t had problems logging in via that even with the auto-generated passwords. Nevertheless, I think you could change the password for the RhinoComputeUser following this guide. I honestly haven’t tried changing the password to see what effect this might have on the rest of the system, but I can’t think of any side effects off the top of my head.

Unfortunately I am not permitted to use RDP connection any longer as corporate view RDP as a security risk - henceforth can now only use Bastion. So I cannot test this for you. :frowning:

This was my fear as well which is why I didn’t attempt to change the password for that account but since you can’t think of any side effects I’ll give it a go and report back whether this makes the login via Bastion successful…

@AndyPayne , hmm interesting … the ‘RhinoComputeUser’ user account created by the script is added only to the “Remote Desktop Users” group but Bastion does not let me connect as that type of User.

Using cmd.exe > “lusrmgr.msc” I have looked at the accounts and the one i connect to via Bastion is only in the Administrators group and nothing else. So I have added ‘RhinoComputeUser’ to the Adminstrators group as well to see if I can then connect via Bastion. Having restarted the server I still cannot connect using the RhinoComputeUser account. So I cannot change it’s password etc although more and more I think the password is a red-herring and this is an issue with Bastion not being able to login with a second User Account other than the one I created the VM with.

So for now I am stuck with having to use my work around posted earlier as the soln. :frowning:

Ok. Well, thanks for digging in on that. I guess it’s good to know that there are some limitations with using Bastion… but also good to know there’s a bit of a work around as well. Cheers.

For the record in case this helps anyone else - I was able to change the login from Azure Bastion to use the intended “RhinoComputeUser” created in the bootstrap script as follows:

Azure portal > VM > Reset Password > … then simply add the RhinoComputeUser creds.

This kept both my original Admin account and the RhinoComputerUser account but made both work for logging in.
I could then point IIS > RhinoCompute > BasicSettings > Connect As… to the RhinoComputerUser creds so that from now on the installation is inline with the standard set up created by the script. Which means I can test for missing grasshopper plugins by logging in with that account and opening the grasshopper scripts and clicking download & install for any that are missing.