PowerCLI "Not authenticated" error, possible timeout

[Anonymous]

Hi guys,

I've recently upgrade our vCenter enrionment to 5.1 and trying deploy virtual machine on it using the PowerCLI 5.1 U1.

I'm using Microsoft System Center Orchestrator 2012 for that matter, but the PowerCLI is native and there's no use in special objects or operations.

So, what happens is I manage to create a VM but than, I try to set its hardware - meaning, set its network cards. The 2nd object fails with the following error:

"

Not authenticated. Possible cause of this error is that connection was left unused for a while and session has timed out. In such case use Connect-VIServer to reconnect."

Is there any chance this is related to the SSO or the new version or PowerCLI?

Note: I use specific credentials when I connect to the vCenter

Thanks

[LucD]

Did you already try changing the connection timeout with the WebOperationTimeoutSeconds parameter on the Set-PowerCLIConfiguration cmdlet ?

[Anonymous]

I did not do so yet.

The whole workflow worked just a few days ago, but I will give it a shot.

Can you elaborate please?

Another thing I would like to add: after I deploy the VM, I use the Disconnect cmdlet, wait 10 seconds and than connect again to set the vm hardware

[LucD]

By setting the timeout to a negative value, you will effectively disable the timeout.

Perhaps that will avoid the problem you are seeing.

Are you checking if the VM is ready after the deployment ?

In which way ?

There are many ways to deploy VMs, perhaps it would be clearer if you include the code you are using.

When the new VM needs to run through sysprep it might take some time before it is actually ready for use.

I don't see why a Disconnect-VIServer, followed by a sleep before you Connect-VIServer might make a difference.

Just stay with the open session, do the sleep (if needed) and then continue.

But the sleep is not the best way to wait till the VM deployment is ready.

Again, the best method depends on a number of factors.

Is the VM reachable over the network, do you place an eyecatcher somewhere at the end of the sysprep,...

[Anonymous]

OK, so I have tried to connect the vCenter server in the 1st object of the workflow and disconnect at the last one.

Now I get the following:

You have  modified the global:DefaultVIServer and global:DefaultVIServers system variables. This is not allowed. Please reset them to $null and reconnect to the vSphere server.

I think that Orchestrator works in such a way, that every object opens a new PowerShell session.

[LucD]

It looks as if something is assigning a value to the $global:DefaultVIServer(s) variable(s).

That is not allowed, they are read-only afaik.

These variables are only valid for the duration of a PowerShell session, so you should be getting a "not connected" message when there is indeed a new session set up each time.

Seeing the code that you use could perhaps shed some light.

[Anonymous]

This is the deploy object (which doesn't turn the VM on yet). The variables are pre determined and the snapin is inserted at the beginning.

Connect-VIServer -Server server_name -user user -password password

New-VM -VMHost host -Name vm_name -Location $Folder -Template $Template -Datastore $Datastore -OSCustomizationSpec OS_Spec

2nd object:

Set-VM vm_name -MemoryGB 4 -NumCpu 2 -Confirm:$False

[LucD]

You could try to use the Server parameter on each PowerCLI cmdlet.

You would have to populate a variable with the connection object that is generated by the Connect-VIServer cmdlet.

Something like this

$myConnection = Connect-VIServer -Server server_name -user user -password password

New-VM -Server $myConnection -VMHost host -Name vm_name -Location $Folder -Template $Template -Datastore $Datastore -OSCustomizationSpec OS_Spec

2nd object:

Set-VM vm_name -Server $myConnection -MemoryGB 4 -NumCpu 2 -Confirm:$False

But this requires that the variable $myConnection can be stored globally in the orchestrator and then passed to each object/script.

I'm afraid I don't know enough about this Orchestrator to say if this possible or not.

[Anonymous]

I can do it theoraticaly but I would rather not.

Is the Set-PowerCLIConfiguration global or has to be set in each session?

btw, I see that the default timeout is 300 seconds so it is sufficient. I get like 10 seconds delay when I connect to the vCenter

[LucD]

By default that is global, but you can use the Scope parameter to change this

[Anonymous]

I further investigated (sorry for draging you into QA)..

The set-hardware cmdlet DO take place but the object still fails with timeout.

So.. I have no idea but I'll try the same with a lower version of PowerCLI since the operation shows the same results both in vCenter 4.1 and vCenter 5.1

[Anonymous]

Another update:

when I remover the disconnect-viserver command at the end of the object, it doesn't fail.

NOTE: this line exists on every object - some of them work, some of them does not.

[LucD]

Did you insert the Disconnect-VIServer cmdlet yourself or is it generated by the Orchestrator ?

So it seems the sessions stays open between objects if that line is removed.

That then seems the way to make it work. Or am I missing something ?

[Anonymous]

It's just a platform for my script - so nothing is generated by the Orchestrator.

And you are right, the session probably stay open until a certain timeout. That's why, mabye, I got that error with the read only variable earlier

[LucD]

Could be, but does the flow in total take longer than 300 seconds ?

If yes, perhaps you can try upping the timeout interval now that you removed the DisConnect-VIServer from each object ?

[Anonymous]

That's the thing: each object opens its own session and disconnects it. The faulty object takes 20 seconds.

Do we have a way to open a session but re use it in each object?

There's something with PS Session I think

[LucD]

Isn't that for remote sessions ?

[Anonymous]

Well, I downgraded PowerCLI to 4.1 on the server that runs the objects and now it works... I have no idea why or what is the differenct in that context between 5.1 and 4.1

[LucD]

Neither do I.

Perhaps someone from the Dev Team can shed some light ?

[jmedd]

A colleague of mine had the same issue today, also with 5.1

After connecting, running anything like Get-VM generates the "Not Authenticated" error.

Running the below (as previously suggested) does seem to help:

Set-PowerCLIConfiguration -WebOperationTimeoutSeconds -1