When Aneka request a machine and the machine is created in the cloud provider but it is not installed there are some aspect to review:
1. The machine is not getting the runspace. To review if it is the case you should go to the container log. By default the next path:
C:\Program Files(x86)\Manjrasoft\Aneka.4.0\Runtime\Daemon\Containers\nameContainer\logs\aneka.log
If in the following line is in the log: WindowsPublicDaemonInstaller before runspace and the following one is not in the log: WindowsPublicDaemonInstaller runspace it could be the case. In this case you should be sure that the Aneka service has associated a user administrator account to run.
For doing this you can give the option Windows+R and insert the string services.msc
For doing this you can give the option Windows+R and insert the string services.msc
It could also happen that the following error is appearing in the log.
http://ec2-54-79-105-251.ap-southeast-2.compute.amazonaws.com:5985:aneka:Manjrasoft!:compuu:ec2-54-79-105-251.ap-southeast-2.compute.amazonaws.com:user-passw:aneka-System.Security.SecureString:error:Connecting to remote server failed with the following error message : WinRM cannot process the request. The following error with errorcode 0x8009030d occurred while using Negotiate authentication: A specified logon session does not exist. It may already have been terminated.
Possible causes are:
-The user name or password specified are invalid.
-Kerberos is used when no authentication method and no user name are specified.
-Kerberos accepts domain user names, but not local user names.
-The Service Principal Name (SPN) for the remote computer name and port does not exist.
-The client and remote computers are in different domains and there is no trust between the two domains.
After checking for the above issues, try the following:
-Check the Event Viewer for events related to authentication.
-Change the authentication method; add the destination computer to the WinRM TrustedHosts configuration setting or use HTTPS transport.
Note that computers in the TrustedHosts list might not be authenticated.
-For more information about WinRM configuration, run the following command: winrm help config. For more information, see the about_Remote_Troubleshooting Help topic.
Possible causes are:
-The user name or password specified are invalid.
-Kerberos is used when no authentication method and no user name are specified.
-Kerberos accepts domain user names, but not local user names.
-The Service Principal Name (SPN) for the remote computer name and port does not exist.
-The client and remote computers are in different domains and there is no trust between the two domains.
After checking for the above issues, try the following:
-Check the Event Viewer for events related to authentication.
-Change the authentication method; add the destination computer to the WinRM TrustedHosts configuration setting or use HTTPS transport.
Note that computers in the TrustedHosts list might not be authenticated.
-For more information about WinRM configuration, run the following command: winrm help config. For more information, see the about_Remote_Troubleshooting Help topic.
Then in the services screen you should look for the Aneka service and select the properties option when given right click
Then in the tab Log On it is possible to verify the user that is configured