Jaa

Opalis 6.3: Running PowerShell scripts on 64-Bit Operating Systems

  • Artikkeli

Last week I posted about using a PowerShell script to automate VM cluster maintenance, and talked about how the VMM PowerShell snap-in is 64-bit, while Opalis is 32-bit (and therefore runs PowerShell in 32-bit mode). I thought I would take a second and create a separate post on this to call this out specifically because it's important, it's already being asked about, and will likely be a source of confusion unless you know about it before you try it.

If you're running Opalis on a 64-bit OS like Windows Server 2008 R2 (like I do), and you install the PowerShell ISE, you'll notice that you get two versions – one for 64-bit and one for 32-bit (x86).

image

The key thing for you to remember is that you should always test your PowerShell scripts by running them on your Opalis server using the x86 version of the PowerShell console or ISE. This will put you in the same environment that Opalis will use for running the script, and you will have the same issues that Opalis would have in running 32-bit mode against 64-bit snap-ins. The tell-tale sign of the 32-bit/64-bit problem is trying to load a snap-in and it doesn't show up. Switching over to the 64-bit ISE and showing the snap-ins ("Get-PSSnapIn") will likely show the snap-in to confirm the issue. If you have a 32-bit/64-bit issue, there are two potential ways to get around it:

  1. Use PowerShell remoting to loop back to the Opalis server and use the 64-bit environment. You can do this by using Invoke-Command $env:computername. This works well for lots of things where you might need to run the 64-bit environment, except where you are doing things like running CmdLets that will also remote to another machine and perform other actions. If you are looping back to the Opalis server and then the command is remoting to another server (like the VMM server), you're using credentials to connect back to the Opalis server, and then telling the Opalis server to forward your credentials to the VMM server. This is called a "double-hop", and it's not allowed by default. If you try to do something that requires a double-hop, you'll get an error like this one:

image_thumb4

If you want to continue to loop back to the Opalis server first, then you will have to enable and use CredSSP during the remote sessions. If you want to find out more about the CredSSP topic, you can check out these links:

  • Remote directly to the intended machine where the script action will occur. This way there is no double-hop – you just need to specify the required credentials to access the remote machine. This is obviously the less problematic approach and requires fewer adjustments to overall security.

Just to repeat the example I gave previously, here's a script I would use to connect from Opalis to a VMM server and use the 64-bit environment to run a script:

image_thumb7

Note that I am using variables (though I'd probably use Custom Start parameters in the actual workflow. I am also using try/catch to throw exceptions so Opalis will stop the workflow if an error occurs (normally it will show success regardless of the outcome).

Be sure to check out Making Custom Objects and Integration Packs using PowerShell Scripts for more details on using PowerShell on Opalis (specifically in QIK CLI).

Comments

  • Anonymous
    October 01, 2011
    Hi, if you connect to vmm for example but are using a remote SQL-Database then the connection will also fail due to the credssp-story