I'm creating a puppet custom fact using ruby script to output some AD related details. I learned the ServerManager is a prerequisite module as this is not automatically added in the Windows 2008 R2 build yet. I have manually run my powershell commands in one of my 2008 R2 servers and it worked. However, I am getting the following error everytime I run it as a puppet facter.
Appreciate your help on this. Thanks!
Successful Manually run in Windows 2008 R2 server via Powershell
Import-Module ServerManager
Script
if ( $operatingsystemrelease == '2008 R2' )
Facter::Core::Execution.execute(%q[powershell Import-Module ServerManager])
end
Error
error while resolving custom fact "mycustomfact": execution of command "powershell Import-Module ServerManager" failed: command not found.
Source: Facter
Thank you.
The method you have provided worked perfectly fine for me (I tested it with Ruby 2.5.8, 2.6.6, and 2.7.1), so there must be a deeper reasoning for this not working. Nevertheless, I have a solution. In my own personal experience with Ruby and PowerShell I have always used the ` operator which also executes a command and returns the output. For example, you could do:
if ( $operatingsystemrelease == '2008 R2' )
`powershell.exe Import-Module ServerManager`
end
If that still doesn't work, I would turn to your installation of Windows Server, specifically making sure your environment variables haven't been messed up. As unlikely and wild as things may seem sometimes, there are always those moments that can only be explained with "because windows" ;)
Check that the Powershell module exists in the target server - it wasn't available by default until 2008 R2 I believe.
It should be in a folder by the same name at:
C:\Windows\System32\WindowsPowerShell\v1.0\Modules
You also might need to use 32-bit Powershell instead of 64-bit.
Okay. So I've decided to use external facts instead. And it's working fine.
You may look at Puppet's external facts page.
Update
I managed to use ruby puppet custom facter. I removed only %q[]. Here's the script.
if ( $operatingsystemrelease == '2008 R2' )
Facter::Core::Execution.execute('powershell Import-Module ServerManager')
end
Related
I'm newbie to web development learning by myself. I'm not a cs student. I'm following a book called HTML5 in easy steps. There is a lesson called "Building input forms" which uses free Abyss Personal Edition web server and activeperl scripts.
I want to install activeperl on my machine. I'm on windows 8.1. Activestate site doesn't offer .exe file anymore instead it offers cli installation for windows 10. site says windows 8.1 also be supported.
I tried installing their cli program command for windows which is
powershell -Command "& $([scriptblock]::Create((New-Object Net.WebClient).DownloadString('https://platform.activestate.com/dl/cli/install.ps1')))".
Then I got this error message.[screenshot attached]
screenshot
Then I googled the exception and found that powershell wasn't configured to older versions of windows prior to 2019 to work with tls 1.2.
https://github.com/dotnet/docs/issues/6873
Any tips on how to work around this problem???
Note:
The following is an effective solution for getting the download of the target *.ps1 file to succeed, but additional problems may surface when the successfully downloaded script is executed.
Indeed, since you're using PowerShell v4, script execution failed due to dependence on the v5+ Expand-Archive cmdlet, as discussed in this answer to your follow-up question.
Enable TLS 1.2 as follows, in a ;-separated statement before the .DownloadString() call:
powershell -Command "[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12; & ([scriptblock]::Create((New-Object Net.WebClient).DownloadString('https://platform.activestate.com/dl/cli/install.ps1')))"
Note: Since you're only using the PowerShell instance for a single download known to use TLS 1.2, the above enables TLS 1.2 only.
If you also had to preserve the originally enabled protocols:
PowerShell v5+ syntax:
powershell -Command "[Net.ServicePointManager]::SecurityProtocol += 'Tls12'; & ([scriptblock]::Create((New-Object Net.WebClient).DownloadString('https://platform.activestate.com/dl/cli/install.ps1')))"
PowerShell v4- syntax:
powershell -Command "[Net.ServicePointManager]::SecurityProtocol = [Net.ServicePointManager]::SecurityProtocol -bor [Net.SecurityProtocolType]::Tls12; & ([scriptblock]::Create((New-Object Net.WebClient).DownloadString('https://platform.activestate.com/dl/cli/install.ps1')))"
I know my question is very similar to this one (Visual Studio Package Installation Error: "Failed to initialize the PowerShell host."). But still the answer that was given there didn't solve my issue.
So like the guy in the link above I have a problem in Visual Studio when I try to create a Web Forms Application or when I want to download and install some Nuget packages (example: AWS DynamoDB sdk) it gives me this error:
failed to initialize the PowerShell host. If your PowerShell execution policy setting is set to AllSigned, open the Package Manager Console to initialize the host first.
When I did some browsing I came across this command:
Set-ExecutionPolicy Unrestricted
But that didn't help. I still got the error. In the link above someone shares this command:
start-job { Set-ExecutionPolicy Unrestricted } -RunAs32 | wait-job | Receive-Job
But I don't really know what difference it makes or what it actually does. After trying the first command and doing:
Get-ExecutionPolicy
I got a response that the value is Unrestricted. But in the other command it was still AllSigned. I also tried running Visual Studio as administrator and that didn't help either.
I figured out, that there was a certificate from Microsoft on the Untrusted list, and I needed to delete it, and now it works.
I am trying to install the Datadog agent on Windows using PowerShell only, not manual however, the APIKEY is not being setup. Is there a way to update/set the APIKEY after installation?
First you may need to download the MSI file:
$image_url = "https://s3.amazonaws.com/ddagent-windows-stable/ddagent-cli-latest.msi"
$destin = "C:\path\to\downloaded\ddagent-cli-latest.msi"
(New-Object System.Net.WebClient).DownloadFile($image_url, $destin)
The actual powershell command for installation (with extra optional arguments included as arguments):
msiexec /i C:\path\to\downloaded\ddagent-cli-latest.msi /l*v C:\path\to\installation_log.txt /quiet APIKEY="$DD_API_KEY" HOSTNAME="$HOSTNAME" TAGS=`"$TAGS,COMMA,DELIMITED`
It's been a while since i've done this (8 months or so?), so it could be outdated, but it used to work :).
Note, if you're running this from a remote provisioning script, you'll probly have to schedule this to be executed not-remotely so that the installation command can be run with heightened permissions, which i believe is required. And you may need to make sure the computer is plugged into the power source (i remember hitting some infuriating issue where that was an arbitrary requirement for Windows scheduled tasks to run, and Windows didn't allow me to configure around that).
I just installed nodejs on one of my build servers (Win Server 2008 R2) which hosts a Bamboo remote agent. After completing the installation and doing a reboot I got stuck in the following situation:
The remote Bamboo build agent is running as a windows service with user MyDomain\MyUser. When a build with an inline powershell task is executing it fails with the error (from the build agent log):
com.atlassian.utils.process.ProcessNotStartedException: powershell could not be started
...
java.io.IOException: Cannot run program "powershell"
...
java.io.IOException: CreateProcess error=2, The system cannot find the file specified
Loggin on to the server as MyDomain\MyUser, I have checked that powershell is in the path:
where powershell
C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
I have tried to restart the service and reboot the machine multiple times. No luck. The only thing that works is if I execute my scripts as a bat file with an absolute path to powershell - but I do not want that.
I have searched for solutions on this, but even though this one seems related: Hudson cannot find powershell after update to powershell 3 - the proposed solutions do not work.
What am I missing here?
If you do a default installation of nodejs you will see that it adds nodejs and npm to the path. Sometimes I have seen that the installer adds a user variable named PATH - it might be that the Bamboo agent decides to read the user path without "merging" it with the system path. I think it would be worth a try to give that a look.
As per Atlassian support page, this is related to a bug in Java Service Wrapper. I tried Workaround-2 since there was no user PATH variable in my system. I had to uninstall bamboo agent service and Java 64 versions from the agent machine to apply the workaround-2.
When I create a new WebAPI project (MVC4) I get the following error.
EntityFramework.5.0.0: Failed to initialize the Powershell host. If your powershell execution policy setting is set to AllSigned, open the package manager console to initialize the host first.
jQuery.1.7.1.1: Failed to initialize the Powershell host. If your powershell execution policy setting is set to AllSigned, open the package manager console to initialize the host first.
After Googling I have found a few answers but nothing that works yet.
Error creating new MVC project - EF and JQuery
This answer seems like it should work for me as my last project was a 7z Command Line app and I might have done something daft with 7zip. But I copy pasted the 7-Zip directory from Program Files to Program Files (86) with no luck.
http://social.msdn.microsoft.com/Forums/en-US/vssetup/thread/c934fed4-e44e-4a06-9e3b-eccb9c8aa8d6
There is an answer here that might work (I haven't tried it) but even if it does work I wouldnt want to do this every time I create a new project.
Is anyone able to help me with this one?
I got around a similar error by running PowerShell as administrator with the command Set-ExecutionPolicy Unrestricted, restarting Visual Studio, and opening the Package Manager Console before what I wanted to do.
Make sure you understand the security implications of doing this first.
http://technet.microsoft.com/en-us/library/ee176961.aspx
Restricted - No scripts can be run. Windows PowerShell can be used only in interactive mode.
AllSigned - Only scripts signed by a trusted publisher can be run.
RemoteSigned - Downloaded scripts must be signed by a trusted publisher before they can be run.
Unrestricted - No restrictions; all Windows PowerShell scripts can be run.
I encountered this issue recently, after re-install VS and install the latest VS update 2, things go well. This works for me at least.