I'm facing an issue actually, i have to run a powershell script on all my VM but this one has to be runned with the minimum of version 3.
Our VM are using the version 2 ans the HyperV the version 4.
I attempt to use the remote access from powershell using "Enter-PSSession" but when i try to run the script this one is using the VM's powershell.
Is it possible to force the script to run on the VM using the powershell version of the HyperV ? Upgrading the version on the VMs is not feasible for the moment.
Thank you
No, this is not possible. PowerShell Remoting executes the code locally on the target computer.
If your code doesn't work and you can't upgrade WMF (PowerShell) on the target computers, then you would have to rewrite your code. Maybe you can use WMI, C#, legacy commandline utilities++ to achieve the same thing?
Related
I am trying to automate deployment to Azure Service Fabric with Jenkins and ServiceFabric PowerShell extension. Jenkins ServiceFabric plugin is not a good option in my case due to lack of control and flexibility over deployment process.
I've faced following issue - Jenkins can't recognize SF PowerShell cmdlets
Connect-ServiceFabricCluster : The term 'Connect-ServiceFabricCluster'
is not recognized as the name of a cmdlet, function, script file, or
operable program. Check the spelling of the name, or if a path was
included, verify that the path is correct and try again
ServiceFabric setup is correct because tt works like a charm when I run the script locally from PowerShell.
So, I've tried to run Jenkins locally instead of service mode as suggested in different posts over the internet, but this haven't resolved the issue.
The other things i've tried:
run the script with self-elevation to admin
run x86/x64 powershell modes
run the script via calling PowerShell exe from cmd runner instead
powershell plugin
forcing "unrestricted" mode
double-dot before script name
I'm still receiving the same result.
So, I tried ServiceFabric Python Cli as an alternative, but faced the other issue - it returns "Bad SSL handshake" on "sfctl cluster select" with certificate, which worked with PS ServiceFabric cmdlets locally
Any ideas?
This is similar to Azure/service-fabric-issues issue 491 which was about a mismatch between the Azure Service Fabric SDK and the Service Fabric runtime.
For instance:
The 2.7 SDK will work against a version 6.0 cluster, but the task will not work on with the 2.8 SDK installed on the agent.
Plus:
Service Fabric PowerShell cmdlets requires PowerShell 3.0 or higher.
Service Fabric uses Windows PowerShell scripts for creating a local development cluster and for deploying applications from Visual Studio. By default, Windows blocks these scripts from running.
To enable them, you must modify your PowerShell execution policy. Open PowerShell as an administrator and enter the following command:
Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Force -Scope CurrentUser
So: if that script is working locally, but not through a Jenkins job on a Jenkins agent, look for differences between the local execution environment (where it is working) and the Jenkins one (where it fails).
The user might not be the same and/or the runtime version might not be compatible with the SDK version.
Do you have Jeknis PowerShell Plugin installed in your system ??
if so can you add your commands into the Power Shell dialog box and see if it works :)
I am trying to run an Exchange Management Shell script via managed code.
Our PowerShell version is version 4.
I am trying to use the runspaceConfiguration.AddPSSnapin() method to add the exchange SnapIn Microsoft.Exchange.Management.Powershell.E2010, however this line fails, giving :
no snapins have been registered for Powershell version 4.
A quick Get-PSSnapIn -registered shows the SnapIn is installed but registered to PS version 1.
In regEdit, I have found the registry key for the snapIn for PowerShell v1, used the export function to script the key, changed the target version to 4 and ran the export command, which has created the new key '4' under PowerShell as expected, with the snapin details copied across. However I still get the 'no snapins have been registered for Powershell version 4.', even though the key is there in the registry.
Is there something else I should be doing to register the snapin to PowerShell version 4?
Thank you for your time.
You are correct in that this is a 32/64 bit build issue. After I set the target build to x64 in VS and redeployed, all magically seemed to work fine.
The error message regarding Powershell versions is a massive Red Herring in this case.
Say you are scripting in Powershell 4.0 environment and you want to make sure the script works in Powershell 3.0. How do you ensure its backward compatible?.
Ok the question as phrased is a little more specific into what you are looking for. Sounds like you are asking for requires.
The#Requires statement prevents a script from running unless the Windows
PowerShell version, modules, snap-ins, and module and snap-in version
prerequisites are met. If the prerequisites are not met, Windows PowerShell
does not run the script.
That way, while you are scripting, you can enforce the functional version of your script.
#Requires -Version 3.0
So now while you are building and debugging your script you know that it will work on systems with at least 3.0. It recognizes minor builds as well if that matters.
I recently came across this requirement for my own needs and realize now that what I suggested up above will not get you the exact results I think you are looking for. What you should do instead is when you run your script call a new PowerShell session and use the -Version switch which Starts the specified version of Windows PowerShell(TechNet).
So when you are testing your script run it like this:
powershell -Version 2 -File myscript.ps1
Here an example to get the Version of "Get-ChildItem":
(Get-Command Get-ChildItem).Version
using get-module of the required Command, you can do it like:
(Get-Module (Get-Command Get-NetTCPConnection).Source).PowerShellVersion
For clarification:
(Get-command <your cmdlet>). Source gives you the installed location
As some of you have seen, I'm a newbie with Chef, and there seems just so much to learn that it's hurting my head :(...
One of the things I ran into earlier testing was that some example recipes I found would fail because I am using Win2K8 as the NODE and that has Powershell V2 rather than Powershell V3.
So, as a kind of learning exercise, I would like to try to make a Chef cookbook to deploy PS V3 to Win2K8 R2. I think that I'll also need to get .NET Framework 4.5.x in order to install the PS V3 .msu (Windows6.1-KB2506143-x64.msu).
So, how do I make such a cookbook?
i've been looking around and found a dotnetframework cookbook and I've added that to my WORKSTATION.
I've also found this:
http://thinkofdata.blogspot.com/2014/07/installing-microsoft-net-framework.html
which seems like a different approach than using the dotnetframework cookbook?
I guess I'm confused about all of this? Are both of these approaches (using the dotnetframework cookbook vs. the one from the link above) "ok"?
Also, if I want to do the former, how do I actually do that? What do I need to put into my recipes/default.rb?
Finally, for now at least, what about executing the .msu after that, to do the PS V3 upgrade? How do I do that?
Sorry for all the questions (and hopefully I won't get flamed too much for them). I'll continue to bang away but hopefully you all can help point the way!
Thanks in advance,
Jim
You could use the windows_package command to be able to do this slightly differently (and not have to rely on a file download to determine whether or not something was installed on a box), but then you would have a dependency on the windows cookbook. This will work after downloading the Chef Development Kit and just using:
chef-apply install_powershell_4_0.rb
This also installs powershell 4.0 via the Windows Management Framework 4.0 installer rather than powershell 3.0 (which is why .NET framework 4.5 needs to be installed prior to installing WMF 4.0 because otherwise powershell isn't updated and stays at 2.0).
The server will reboot 3 times between each install, so you will have to run the chef-apply command to continue (or actually install chef client).
Here is the install_powershell_4_0.rb file:
#Create installs directory to house downloads
directory 'c:/installs' do
end
#Install Windows 7 and Windows Server 2008 R2 Service Pack 1 (KB976932)
remote_file "c:/installs/windows6.1-KB976932-X64.exe" do
source "http://download.microsoft.com/download/0/A/F/0AFB5316-3062-494A-AB78-7FB0D4461357/windows6.1-KB976932-X64.exe"
end
execute "c:/installs/windows6.1-KB976932-X64.exe /quiet" do
action :nothing
subscribes :run, resources(:remote_file => "c:/installs/windows6.1-KB976932-X64.exe")
end
#Install .NET 4.5
remote_file "c:/installs/dotNetFx45_Full_setup.exe" do
source "http://download.microsoft.com/download/B/A/4/BA4A7E71-2906-4B2D-A0E1-80CF16844F5F/dotNetFx45_Full_setup.exe"
end
execute "c:/installs/dotNetFx45_Full_setup.exe /quiet" do
action :nothing
subscribes :run, resources(:remote_file => "c:/installs/dotNetFx45_Full_setup.exe")
end
#Install Windows Management Framework 4.0
remote_file "c:/installs/Windows6.1-KB2819745-x64-MultiPkg.msu" do
source "http://download.microsoft.com/download/3/D/6/3D61D262-8549-4769-A660-230B67E15B25/Windows6.1-KB2819745-x64-MultiPkg.msu"
end
execute "c:/installs/Windows6.1-KB2819745-x64-MultiPkg.msu /quiet" do
action :nothing
subscribes :run, resources(:remote_file => "c:/installs/Windows6.1-KB2819745-x64-MultiPkg.msu")
end
You then should be able to open a powershell command prompt and see 4.0 as the PSVersion via running:
$psversiontable
I have written a powershell script and it should work both in version 1 and version 2.
Can more than one powershell versions co-exist in a single machine ? Or should i have powershell versions in separate machine ?
Well, the answer is yes and no.
Technically, on PowerShell 2.0 system, you can access PowerShell version 1.0 using
-version 1
parameter of powershell.exe
Similarly, on PowerShell 3.0 system, you can acccess PowerShell verison 2.0 using
-version 2
You cannot have both installed seperately on the same machine. PowerShell itself provides a way to go to the earlier version.