SCVMM Service deployment and NO_PARAM server: NO_PARAM: NO_PARAM

I have to say.  This particular error is my favorite of all time (so far).

Here is the scenario:

• I deploy a Service form a Template.
• I wait.
• The Job fails.
• I check the SCVMM Job log and see something resembling this:

Error (2912)

An internal error has occurred trying to contact the NO_PARAM server: NO_PARAM: NO_PARAM.

NO_PARAM

Recommended Action

Check that WS-Management service is installed and running on server NO_PARAM. For more information use the command "winrm helpmsg hresult". If NO_PARAM is a host/library/update server or a PXE server role then ensure that VMM agent is installed and running.

Error (20400)

1 parallel subtasks failed during execution.

Error (2912)

An internal error has occurred trying to contact the NO_PARAM server: NO_PARAM: NO_PARAM.

NO_PARAM

Recommended Action

Check that WS-Management service is installed and running on server NO_PARAM. For more information use the command "winrm helpmsg hresult". If NO_PARAM is a host/library/update server or a PXE server role then ensure that VMM agent is installed and running.

Error (20400)

1 parallel subtasks failed during execution.

 

I can tell you from experience that this error has absolutely nothing to do with WinRM.  In fact, if you spend time there, it is wasted.

So, what happened?

In a nutshell; your script / installer ran, and it did not throw a single error.  Not one.  But, your timeout setting was too low due to something, anything and SCVMM gave up waiting for the Exit Code 0 that your script had finished.

Recall, that there was no error, so SCVMM did not have one to pass back up the chain to you and put in the job log.  That is where all of this NO_PARAM business is coming from.  Literally, no error was passed to something as a parameter and that particular piece of code is simply stating that it didn’t receive one.

And SCVMM reports this error as an error and pattern matches it and attempts to give you some guidance around it – where the WinRM part comes from.

 

I first caused this to happen because my script was stalled with a dialog box that was open, waiting for someone to respond, and since everything you define in your Service Template runs headless, there is no way to even know the dialog appeared – other than to logon to your VM and see that the script process continues to run.

I have also seen this happen again when there is high disk IO causing the various installers or configuration scripts to actually run slower.

Just to give a few clues as to why you see this in the first place, as it is a real mystery until you figure it out.  It took me a couple weeks to sort it all out.  Now, I avoid it – I spread my VMs across my hosts by selection.