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
Related
When I run a powershell script, I get the following warning:
WARNING: Multiple variants of AWS Tools for PowerShell (AWSPowerShell,
AWSPowerShell.NetCore or AWS.Tools) are currently installed. Please
run 'Get-Module -Name
AWSPowerShell,AWSPowerShell.NetCore,AWS.Tools.Common -ListAvailable'
for details. To avoid problems with cmdlet auto-importing, it is
suggested to only install one variant. AWS.Tools is the new
modularized version of AWS Tools for PowerShell, compatible with
PowerShell Core 6+ and Windows Powershell 5.1+ (when .NET Framework
4.7.2+ is installed). AWSPowerShell.NetCore is the monolithic variant that supports all AWS services in a single large module, it is
compatible with PowerShell Core 6+ and Windows Powershell 3+ (when
.NET Framework 4.7.2+ is installed). AWSPowerShell is the legacy
module for older systems which are either running Windows PowerShell 2
or cannot be updated to .NET Framework 4.7.2 (or newer).
Screenshot:
How do I fix the warning? Do I uninstall one or 2 of these modules? Which ones?
Going purely by the error message:
How do I fix the warning?
You ensure that only one of the three listed module (groups) is installed:
Modern, modular group of related modules:
AWS.Tools.*, core module is AWS.Tools.Common, installation-helper module is AWS.Tools.Installer
Legacy modules (monolithic):
AWSPowerShell
AWSPowerShell.NetCore
Do I uninstall one or 2 of these modules? Which ones?
Yes. Which ones to uninstall and thereby implicitly which one to keep depends on your needs and which powershell version you have:
(a) If you're running Windows PowerShell 5.1 and have .NET Framework 4.7.2+ installed, or you're running PowerShell (Core), keep the AWS.Tools.* modules.
(b) If you're still running Windows PowerShell 3 or 4, and have .NET Framework 4.7.2+ or higher installed, keep the AWSPowerShell.NetCore module.
(c) If you're still running Windows PowerShell 2 or a higher version, but cannot install .NET Framework 4.7.2+, keep the legacy AWSPowerShell module.
For instance, to go with (a):
Note
To be safe, run with elevation (as admin), so that removal of modules that were installed in the AllUser scope can be removed.
Any non-installed modules among the specified ones are quietly ignored.
Start a new PowerShell session afterwards (modules already imported in the current session remain in memory, even after uninstallation; however, you can also remove them individually from memory with Remove-Module).
Get-Module -ListAvailable AWSPowerShell, AWSPowerShell.NetCore |
Uninstall-Module -Force
I have been running PowerShell v3 for some time on several different systems. On occasion I wish to check compatibility or other issues with v2 so I switch to v2 within an existing PowerShell with this:
PS> powershell -version 2
As a matter of course I then use either $hosts.Version or $PSVersionTable to do a sanity check. But on one machine when I did this they both reported I was still in a V3 shell. I tried again from scratch; same result. I also tried invoking it from a DOS shell instead of a PowerShell; again, same result. Then to check my own sanity(!) I went to another system, did the same sequence, and it worked as expected--I did indeed switch from a V3 to a V2 environment.
The only other observation I have is that on the system that worked, I got a 2009 copyright notice when it started up the inner shell; on the system that did not it showed 2012.
Final detail: of the two machines mentioned, it worked on Win8 and failed on Win7 enterprise but I really doubt that is a relevant factor here.
I would be really surprised if (a) this is a PS bug or (b) I am the only one seeing the issue, yet web searching has been fruitless for me thusfar. Any thoughts on why this might be happening?
One reason would be that .NET 2.0 is not installed on the failing system, I cant recall if it had to be already installed prior to v3 or you can install it after upgrading to v3.
Quick search turned up this, just an idea? Maybe V2 is not installed?
Is Version 2 installed?
my application needs SQL Compact SP1 and SP2 installed (Entity Framework), but there is nothing on MSDN where I can determine silent install parameters for those two files (SSCERuntime-ENU-x86.msi for SP1 and SSCERuntime-ENU.exe for SP2). And on top of that, 64bit SP1 needs to be installed like this: install x86 file and then install x64 file on 64bit machine. Any thoughts appreciated.
OK, I've figured that out myself - all you need is to take these install files, run CMD and run them with wrong parameter, for example: C:\SSCERuntime-ENU-x86.msi -myAwesomeFlag. Because of course given parameter will not be found, install process displays MessageBox with a list of all possible parameters and their options. This works for both servicepacks and .NET 4 installation package.
Generally speaking .msi install parameters are normalised compared to .exe (which can be anything the developper choose). I recommend using this command with those parameters for silent install: msiexec /i SSCERuntime_x86-ENU.msi /qn /norestart
q is for quiet
n is for No UI
norestart ensure that the computer doesn't reboot right now, this is useful if you deploy software with tools like SCCM, Chocolatey, etc. Otherwise if the software needs a reboot it will reboot the computer and if a user is working on it he will not be really happy ;)
I'm working on writing a WiX project to install a .Net Addin that is built for Microsoft POS 2009. During the development of the project, you had to run the command:
AddinUtil.exe -PipelineRoot:
{directory to the Addins folder for
POS 2009}
so that POS 2009 would recognize your Addin. Now that I'm getting ready to do the deployment, I was wondering how this is done on during the install process, so that the user doesn't have to do this after they run the installer?
Do I just call the AddinUtil.exe from an Exec command during the install phase, or is there a tag that is available inside of WiX 3 that can handle this? I recall several instances where I've seen other guys call external applications from WiX, and I'm just curious to find out if this is the best method or not for this scenario.
Note: I'm basing this on POS 2009, but I think this winds up being a general ".Net Addin Installation" question.
I should mention... the AddinUtil that I'm using is the standard .Net 3.0/3.5 AddinUtil that is part of the .Net framework which exists in %windir%\Microsoft.Net\Framework\v3.5\ directory.
I would just call a custom action.
<CustomAction Id='Addin' Directory ='PATH' ExeCommand='[PATH]AddinUtil.exe' Return='asyncNoWait'/>
Do PowerShell scripts run under Mono?
I would like to run them on a Mac.
There is an open source version of PowerShell called Pash designed for Mono. It is not complete, but may be able to do what you need:
http://pash.sourceforge.net/ (this project has not been active for quite some time)
Checkout the re-start at: Pash-Project on GitHub.
Powershell has now been open-sourced and is available here.
As of right now it is V6.0 alpha. I've been running it on OS X for a lot of file operations and it has been working very well.
Note that you may need to install .Net Core to get Powershell to behave properly. Also note that system.management.automation.runspaces works right out of the box (for runspacepools).
The powershell.exe stub is actually a native win32 program, not a managed assembly. It may be possible in the future to host the System.Management.Automation assembly in Mono, but I'm fairly sure it doesn't work at the moment.