Hello,
I'm curious if anyone else has had issue getting Windows authentication with WS-man setup within CALM for the Login Check and remote execution of scripts. I have followed the docs and redone the setup a few times for validation, but the login check still fails with a vague error that just says to check out WINRM troubleshooting help.
What's odd is that after I provision the Windows image, I can manually invoke commands for remote execution and login with the following command against the newly provisioned IP:
PS C:\Users\Administrator> Invoke-Command -ComputerName 10.32.4.246 -ScriptBlock { $PSVersionTable.PSversion } -Credential administrator@domain.com
My Karan service is installed and configured with a domain administrator, all PS commands in the document have been run as "administrator" on the Karan server and the target base Windows image as required.
CredSSP has been run on the Karan server to allow all hosts as Trusted Hosts and the command to enable CredSSP on the target Window image was run prior to taking the image as well (I also have it in the code block in the blueprint).
All GPEDITs and Local Security policies have been updated per the guide and the user added was the domain administrator.
The one area of confusion is around the Task to add for the EXECUTION_MODE and what mode it should be. I have created a task as required in the documentation, but its very vague as to where to create this so I am not entirely sure this is correct (or if it is the problem) and was hopeful someone might have a screenshot of where they set this on a windows image that is working? I have set it to "EXECUTION_MODE=" as I plan to mess around adding scripts to be executed on the server after getting past this first part.
Not sure if anyone has any thoughts or a process they have run that works well, but I'm stumped at the moment and was curious if anyone else out there hit this and got past it on their end that might be able to share.
Thanks for any help!
-Keith
Page 1 / 1
Thanks @Chandru
This makes more sense now in the context of how you explain it. The one thing I am noticing as I go back to testing this is that the script I want to execute on the newly provisioned VM doesn't work as a shell script with the credentials I have stored in the blueprint. It only works as an EScript which is the opposite of what I think I saw last night (or it was too late for me to read clearly on my end ).
From the discussion above, it seems like the option for Shell with the credentials should be able to execute a remote command from the Karan server on the newly provisioned VM. But from what I am now seeing, this isn't working or I have something else up with either the credentials I have stored of how I am executing this. I have waited as much as 5 minutes for the sysprep to be done. Should this be working as a Shell script with the stored credentials?
thanks!
-Keith
This makes more sense now in the context of how you explain it. The one thing I am noticing as I go back to testing this is that the script I want to execute on the newly provisioned VM doesn't work as a shell script with the credentials I have stored in the blueprint. It only works as an EScript which is the opposite of what I think I saw last night (or it was too late for me to read clearly on my end ).
From the discussion above, it seems like the option for Shell with the credentials should be able to execute a remote command from the Karan server on the newly provisioned VM. But from what I am now seeing, this isn't working or I have something else up with either the credentials I have stored of how I am executing this. I have waited as much as 5 minutes for the sysprep to be done. Should this be working as a Shell script with the stored credentials?
thanks!
-Keith
As a simple rule, anything that needs to be run inside Calm container needs to be escript and anything that needs to be run on the destination vm should be script.
We are using escript in our example to pause Calm from trying to login to the deployed vm. The reason we need to do is because sysprep takes sometime before we can login to the windows vm. Since we skipped the check login upon create, calm will not try to login to the vm and jumps to the Create Action and start executing tasks under it. The first task is to sleep for 120 seconds. Since it is an escript the escript engine running inside Calm will execute the script (sleeping for 120 seconds) and then move to the next task. The next task requires Calm (via Karan) to log into the vm deployed and execute the commands you have given in the task.
Thanks @Chandru - I think it is making sense now. It looks like we are bypassing the login and simply putting the tasks (scripts) to be called after the VM has been provisioned.
When I add a simple task to just output the version of powershell on the VM to a file location, the blueprint shows it as a success, but I don't actually see the file on the VM. Should this second task that has the script be an EScript or a Shell script with credentials? I was thinking an Escript from what I have read, but this is where some of the CREDSSP and Local mode stuff got a little confusing in the docs. I tried this as an Escript and it didn't work:
$PSVersionTable.PSversion > "C:\Users\Administrator\psversion.txt"
I just tried it as a shell script and gave it the credentials (domain account that the Karan service is running as) and that seems to work now when I check the VM that was spun up by CALM! You have been very helpful...thank you!
I am going to try some more advanced stuff tomorrow and re-read the Escript/Shell portions again and I might have a few questions that I will post to some new threads in this category. I think I am past the initial login hurdle by unchecking it..thank you. Seems like the way to go for now is to just bypass that check.
Thanks!
-Keith
When I add a simple task to just output the version of powershell on the VM to a file location, the blueprint shows it as a success, but I don't actually see the file on the VM. Should this second task that has the script be an EScript or a Shell script with credentials? I was thinking an Escript from what I have read, but this is where some of the CREDSSP and Local mode stuff got a little confusing in the docs. I tried this as an Escript and it didn't work:
$PSVersionTable.PSversion > "C:\Users\Administrator\psversion.txt"
I just tried it as a shell script and gave it the credentials (domain account that the Karan service is running as) and that seems to work now when I check the VM that was spun up by CALM! You have been very helpful...thank you!
I am going to try some more advanced stuff tomorrow and re-read the Escript/Shell portions again and I might have a few questions that I will post to some new threads in this category. I think I am past the initial login hurdle by unchecking it..thank you. Seems like the way to go for now is to just bypass that check.
Thanks!
-Keith
Hi Chandru,
Thanks for the quick response. That works if I uncheck that - but that doesn't do the login check then right? By unchecking that I am just telling the blueprint not to perform the task correct? So I would expect I don't need the task that I created then if I am unchecking that.
I did hear that there might be an issue with this timing, so I was hoping your sleep task would fake it out, but I am not sure yet why I can't get that to work.
here is what I did that was a success. I left the task above in there and I have no package script bring called (that will be next in my testing to run commands). This worked well when I unchecked the login check. thanks for any insight.
-Keith
Thanks for the quick response. That works if I uncheck that - but that doesn't do the login check then right? By unchecking that I am just telling the blueprint not to perform the task correct? So I would expect I don't need the task that I created then if I am unchecking that.
I did hear that there might be an issue with this timing, so I was hoping your sleep task would fake it out, but I am not sure yet why I can't get that to work.
here is what I did that was a success. I left the task above in there and I have no package script bring called (that will be next in my testing to run commands). This worked well when I unchecked the login check. thanks for any insight.
-Keith
Hi Chandru,
Thanks for the info. Yes, I am able to execute commands remotely to the host that I build once it is up and online. I am not having much success with the sleep on the first run. I noticed your screenshot has the MSSQL service with tasks associated with the Create step, but I don't seem to have that when I create a new generic blueprint (attached). I am able to create a task, but it sits out there by itself. When I run the Launch, it seems the other steps in the "Action" tab are the ones that are executed. This seems like the one created automatically upon compilation, but was curious if this looks like the right location to set the sleep if you are just spinning up a generic VM?
I'll try to play around some more, but not sure I am putting the sleep in the right place at the moment. thanks for any help!
Thanks for the info. Yes, I am able to execute commands remotely to the host that I build once it is up and online. I am not having much success with the sleep on the first run. I noticed your screenshot has the MSSQL service with tasks associated with the Create step, but I don't seem to have that when I create a new generic blueprint (attached). I am able to create a task, but it sits out there by itself. When I run the Launch, it seems the other steps in the "Action" tab are the ones that are executed. This seems like the one created automatically upon compilation, but was curious if this looks like the right location to set the sleep if you are just spinning up a generic VM?
I'll try to play around some more, but not sure I am putting the sleep in the right place at the moment. thanks for any help!
The execution mode tells where the script needs to be exeucted. Local means it will be on Karan server. Local is only required when you are using CredSSP for authentication. If you want to execute some scripts on the remote machine you don't need to set the execution mode.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.