I'm trying to remote install Java Runtime (8 as it happens) using Powershell DSC on a Windows 2012 R2 box, but it appears to be hanging.
I initially tried to install it using a Chocolatey DSC provider, but that gave me a false success (choco claimed it was installed, but no actual files were unpacked). I chalked this fact up to this: http://powershell.org/wp/forums/topic/issue-installing-java-32-bit-using-package-resource/#post-23187
So I unpacked the exe and extracted the two java MSIs and my DSC configuration looks like this:
Package java8x86
{
Ensure = 'Present'
Name = 'Java 8 Update 45'
Path = (Join-Path $localDscFileDir "Java\jre1.8.0_45\jre1.8.0_45.msi")
Arguments = '/s'
ProductId = '26A24AE4-039D-4CA4-87B4-2F83218045F0'
DependsOn = #("[File]javaMsi")
}
([File]javaMsi copies the .msi files to the remote machine).
When I generate my MOF and Start-DscConfiguration, the output hangs on these lines:
VERBOSE: [DEVTEST-3U2LN5Q]: [[Package]java8x86] Parsing 26A24AE4-039D-4CA4-87B4-2F83218045F0 as an identifyingNumber
VERBOSE: [DEVTEST-3U2LN5Q]: [[Package]java8x86] Parsed 26A24AE4-039D-4CA4-87B4-2F83218045F0 as {26A24AE4-039D-4CA4-87B4-2F83218045F0}
VERBOSE: [DEVTEST-3U2LN5Q]: [[Package]java8x86] Package configuration starting
VERBOSE: [DEVTEST-3U2LN5Q]: [[Package]java8x86] Starting C:\Windows\system32\msiexec.exe with /i "C:\DscFiles\Java\jre1.8.0_45\jre1.8.0_45.msi" /quiet /s
VERBOSE: [DEVTEST-3U2LN5Q]: [[Package]java8x86] Starting process C:\Windows\system32\msiexec.exe with arguments /i "C:\DscFiles\Java\jre1.8.0_45\jre1.8.0_45.msi" /quiet /s
I can't even CTRL-C out of that and have to go to the remote machine and kill the Windows Installer process to cause the Start-DscConfiguration to fail
I'm getting to wits end.... it's 2015 and I can't remote setup a Windows box! So much promised by these technologies....
Remove the line
Arguments = '/s'
or else add
Arguments = '/q'
A year later and I seem to have a solution. Not sure if the original problem was to do with the version of the installer I was installing or not.. but this seems to work for me - for now:
xRemoteFile javaInstaller {
DestinationPath = (Join-Path $localDscFileDir "Java\jreInstaller.exe")
Uri = "http://javadl.oracle.com/webapps/download/AutoDL?BundleId=211999"
}
Package java8
{
Ensure = 'Present'
Name = 'Java 8'
Path = (Join-Path $localDscFileDir "Java\jreInstaller.exe")
Arguments = '/s REBOOT=0 SPONSORS=0 REMOVEOUTOFDATEJRES=1 INSTALL_SILENT=1 AUTO_UPDATE=0 EULA=0 /l*v "C:\DscFiles\Java\jreInstaller.exe.log"' #From https://powershell.org/forums/topic/issue-installing-java-32-bit-using-package-resource/#post-39206
ProductId = '26A24AE4-039D-4CA4-87B4-2F64180101F0'
DependsOn = #("[xRemoteFile]javaInstaller")
}
BTW, that download url corresponds to jre-8u101-windows-x64.exe
For what it's worth, I'm successfully installing JDK 7 with:
Package Java
{
Ensure = 'Present'
Name = "Java 7 Update 72 (64-bit)"
Path = "${InstallerPath}\jdk-7u72-windows-x64.exe"
ProductId = '64A3A4F4-B792-11D6-A78A-00B0D0170720'
Arguments = "/s STATIC=1 WEB_JAVA=0"
}
Cheers,
Andrew
In addition to the above.
Experienced this before in the past. With MSI/EXE installations via DSC, if you do not pass the correct [arguments] it hangs until all threads are killed on the remote box.
Kill all threads and when next you run conf, force the configuration!
start-dscConf -force
Related
I have a very simple PowerShell script that uploads a generated test file to an AWS S3 bucket from a Windows 2008 R2 Datacenter server (clean AWS instance). If I run the script remotely on the server using Terraform (remote-exec provisioner), the script fails on the S3 upload with a StackOverflowException. When I run the script directly on the server, it runs fine and uploads the file.
I've experimented with different sizes for the file and 14.5MB seems to be about the maximum that works before the StackOverflowException occurs. Just about any size works fine when I RDP into the server and run the script directly. I've tested 200MB and it works fine.
Any idea why this is happening or what I can do to fix it? The actual file I need to upload is 50MB.
Here are the essential parts to recreate the problem. terraform.tf file:
resource "aws_instance" "windows" {
count = "1"
ami = "ami-e935fc94" #base win 2008 R2 datacenter
instance_type = "t2.micro"
connection {
type = "winrm"
user = "<username>"
password = "<password>"
timeout = "30m"
}
provisioner "file" {
source = "windows/upload.ps1"
destination = "C:\\scripts\\upload.ps1"
}
provisioner "remote-exec" {
inline = [
"powershell.exe -File C:\\scripts\\upload.ps1"
]
}
}
The PowerShell script is very simple. upload.ps1:
$f = new-object System.IO.FileStream C:\Temp\test.dat, Create, ReadWrite
$f.SetLength(40MB) # change this to 14.5MB and it works!
$f.Close()
Write-S3Object -BucketName "mybucket" -Folder "C:\Temp" -KeyPrefix "20180322" -SearchPattern "*.dat"
The error that I receive when launching the script from Terraform (remote-exec provisioner):
aws_instance.windows (remote-exec): Process is terminated due to StackOverflowException.
Running upload.ps1 from RDP on the server itself works fine, including larger files (tested up to 200MB).
Here is the version information:
Microsoft Windows Server 2008 R2 Datacenter
Powershell Version: 3.0
AWS Tools for Windows PowerShell, Version 3.3.245.0
Amazon Web Services SDK for .NET, Core Runtime Version 3.3.21.15
This problem results from a Windows bug. This is all fine and good for a standard Windows server -- you can patch and move on. But, things are more tricky with AWS automation using Terraform.
The ideal solution would allow 1) use of the base AMI, 2) apply the hotfix to itself, and 3) then run the WinRM remote-exec, all from Terraform. Another solution would be to create an AMI with the hotfix installed and have Terraform generate instances using that AMI. However, then you're stuck maintaining AMIs.
Normally, I grab the Microsoft-provided base AMI using a filter:
data "aws_ami" "windows2008" {
most_recent = true
filter {
name = "virtualization-type"
values = ["hvm"]
}
filter {
name = "name"
values = ["Windows_Server-2008-R2_SP1-English-64Bit-Base*",]
}
owners = ["801119661308", "amazon"]
}
Then I use that AMI to create the AWS instance:
resource "aws_instance" "windows" {
count = "1"
ami = "${data.aws_ami.windows2008.id}"
...
}
But, the base AMI doesn't have the hotfix installed allowing you to avoid this WinRM/Windows bug. This is were it gets tricky.
You can use a userdata script to perform a multi-phase setup. In the first boot of the instance (Phase 1), we'll block the instance so that the remote-exec doesn't come in before we're ready. Then, we'll download and install the hotfix and we'll reboot (thanks to Niklas Akerlund, Micky Balladelli and Techibee). On the second boot (in method described here), we'll unblock the instance (enable WinRM) so that the remote-exec can connect.
Here's my userdata/PowerShell script:
$StateFile = "C:\Temp\userdata_state.txt"
If(-Not (Test-Path -Path $StateFile))
{
# PHASE 1
# Close the instance to WinRM connections until instance is ready (probably already closed, but just in case)
Start-Process -FilePath "winrm" -ArgumentList "set winrm/config/service/auth #{Basic=`"false`"}" -Wait
# Set the admin password for WinRM connections
$Admin = [adsi]("WinNT://./Administrator, user")
$Admin.psbase.invoke("SetPassword", "${tfi_rm_pass}")
# Create state file so after reboot it will know
New-Item -Path $StateFile -ItemType "file" -Force
# Make it so that userdata will run again after reboot
$EC2SettingsFile="C:\Program Files\Amazon\Ec2ConfigService\Settings\Config.xml"
$Xml = [xml](Get-Content $EC2SettingsFile)
$XmlElement = $Xml.get_DocumentElement()
$XmlElementToModify = $XmlElement.Plugins
Foreach ($Element in $XmlElementToModify.Plugin)
{
If ($Element.name -eq "Ec2HandleUserData")
{
$Element.State="Enabled"
}
}
$Xml.Save($EC2SettingsFile)
# Download and install hotfix
# Download self-extractor
$DownloadUrl = "https://hotfixv4.trafficmanager.net/Windows%207/Windows%20Server2008%20R2%20SP1/sp2/Fix467402/7600/free/463984_intl_x64_zip.exe"
$HotfixDir = "C:\hotfix"
$HotfixFile = "$HotfixDir\KB2842230.exe"
mkdir $HotfixDir
(New-Object System.Net.WebClient).DownloadFile($DownloadUrl, $HotfixFile)
# Extract self-extractor
Add-Type -AssemblyName System.IO.Compression.FileSystem
[System.IO.Compression.ZipFile]::ExtractToDirectory($HotfixFile, $HotfixDir)
# Install - NOTE: wusa returns immediately, before install completes, so you must check process to see when it finishes
Get-Item "$HotfixDir\*.msu" | Foreach { wusa ""$_.FullName /quiet /norestart"" ; While (#(Get-Process wusa -ErrorAction SilentlyContinue).Count -ne 0) { Start-Sleep 3 } }
# Reboot
Restart-Computer
}
Else
{
# PHASE 2
# Open WinRM for remote-exec
Start-Process -FilePath "winrm" -ArgumentList "quickconfig -q"
Start-Process -FilePath "winrm" -ArgumentList "set winrm/config/service #{AllowUnencrypted=`"true`"}" -Wait
Start-Process -FilePath "winrm" -ArgumentList "set winrm/config/service/auth #{Basic=`"true`"}" -Wait
Start-Process -FilePath "winrm" -ArgumentList "set winrm/config #{MaxTimeoutms=`"1900000`"}"
}
When I upgrade / downgrade my application via a Powershell script, I want to first force the uninstallation of the currently installed version before running the new installer.
How can I do that with Powershell, using the UpgradeCode of the application?
Doing it by application name would be less robust.
Since you mention upgrade code, it must mean that you are talking about an MSI file (Windows Installer). As stated by others such an uninstall is normally performed auto-magically by a properly authored MSI package - it is referred to as a major upgrade - which is essentially an uninstall of the existing version of a product and then the install of the newest version.
The Upgrade Table of the MSI being installed will specify what existing packages on the box will be uninstalled before the new version is installed. In theory you can uninstall any number of existing installations. You can even uninstall a competitive product if you are mad as a hatter. Frankly, and astonishingly, I have never tried to uninstall multiple products during one major upgrade - it is rarely called for. In most cases you uninstall a single, existing product and then install your latest version.
You can modify the Upgrade table using a transform to change how the major upgrade behaves - in other words to make it start or stop uninstalling a specific pre-existing installation.
You can also enumerate all related products that share the same upgrade code by calling this MSI API function (COM - VBScript used as sample):
Set installer = CreateObject("WindowsInstaller.Installer")
' Enumerate all products related to "Microsoft Visual C++ 2008 Redistributable - x86 9.0.30729.4148"
' {AA783A14-A7A3-3D33-95F0-9A351D530011} is the upgrade code
Set upgrades = installer.RelatedProducts("{AA783A14-A7A3-3D33-95F0-9A351D530011}")
For Each u In upgrades
MsgBox u, vbOKOnly, "Product Code: "
Next
Then you can uninstall the products by passing the product code(s) to the msiexec.exe command line (see below for how to do this via MSI API COM automation instead):
msiexec.exe /x {11111111-1111-1111-1111-11111111111X} /L*V "C:\msilog.log" REBOOT=ReallySuppress
Quick Parameter Explanation (since I recommend this option):
/X = run uninstall sequence
/QN = run completely silently
/L*V "C:\msilog.log"= verbose logging at path specified
{11111111-1111-1111-1111-11111111111X} = product guid of app to uninstall
REBOOT=ReallySuppress = prevent reboot without warning (badly authored MSI packages)
If you don't want to uninstall via msiexec.exe, then you can find a myriad of ways to invoke an MSI uninstall here:
Uninstalling an MSI file from the command line without using msiexec.
And you can find the product code of an installed MSI in several different ways: How can I find the product GUID of an installed MSI setup?
UPDATE: I guess I forgot the obvious, you can uninstall directly via MSI API automation. In the script below we get all products sharing the same upgrade code and then uninstall them in sequence.
Note that when run silently you should run with admin rights since the UAC may be suppressed and then the uninstall will usually fail (permission denied). Because of this the below script runs the uninstall interactively - allowing UAC prompting and elevation.
And if it isn't obvious: running this script will uninstall Orca! I use this product as a sample because it is quick to install again (hints on finding the installer quick if you need to towards bottom here - search for "orca"):
BIG DISCLAIMER:
The COM method installer.ConfigureProduct does not accept any arguments that allow us to pass in REBOOT=ReallySuppress. This means that a (very) badly authored package which triggers the ScheduleReboot action (or uses some more obscure magic to cause a reboot) - may reboot the system without warning if you run the below script with admin rights and in silent mode.
There is a newer call ConfigureProductEx which is available as a Win32 function, but it is not exposed via the COM automation interface. If you platform invoke you can use that call - there is a C++ example in section 14 here: Uninstalling an MSI file from the command line without using msiexec. Or you can use the DTF feature from the WiX toolkit (see section 6 in the same link as the C++ example).
UPDATE July 2018:
Set installer = CreateObject("WindowsInstaller.Installer")
installer.InstallProduct "product.msi", "REMOVE=ALL REBOOT=ReallySuppress"
Set installer = Nothing
Perhaps the above snippet is the best uninstall approach? This should suppress any reboots. I don't have the time or the setup to test it right now (on a Linux box), but I wanted to add it before I forget.
Original uninstall script:
Const msiUILevelNone = 2
Const msiInstallStateAbsent = 2
Set installer = CreateObject("WindowsInstaller.Installer")
'installer.UILevel = msiUILevelNone ' Disabled to prevent silent uninstall. Now the UAC prompt will show
' Uninstall Orca, replace upgrade code with yours
Set products = installer.RelatedProducts("{CFF4D510-79B2-1CCD-0061-5741A0565A76}")
For Each product In products
' MsgBox "Product Code: " & product ' Show the product code found, if you want
' The following call when run silently with admin rights may reboot the system without warning!
' This is due to badly authored MSI packages - most packages will not trigger this problem.
installer.ConfigureProduct product, 0, msiInstallStateAbsent ' Uninstall product
' See text above for info on the newer ConfigureProductEx method.
Next
Set installer = Nothing
MsgBox "Finished" ' Just so we know the script ran if nothing found to uninstall
Some Links:
Is there an alternative to GUID when using msiexec to uninstall an application? (uninstall by product name)
How can I uninstall an application using PowerShell?
How can I use powershell to run through an installer?
WIX (remove all previous versions)
Wix upgrade goes into maintenance mode and never does upgrade (various ways to uninstall, by product code, by upgrade code, etc...)
Since the question specifically mentions powershell I'll just put this here too. There are other PS solutions around using WMI and/or Get-Package. This solution is based off of https://outnull.wordpress.com/2016/11/02/uninstalling-application-based-on-upgradecode/ but accepts various forms of upgrade code syntax, and it tries to avoid string manipulation when converting to/from the package/upgrade Guid and the registry representation.
$upgradecode = "{CFF4D510-79B2-1CCD-0061-5741A0565A76}"
$installer = Join-Path -Path $env:SystemRoot -ChildPath "system32\msiexec.exe" -Resolve
function Reverse-Nibbles {
param ( [byte[]] $bytes )
# reverse nibbles of each byte
for($i = 0; $i -lt $bytes.Length; $i++ )
{
$bytes[$i] = (($bytes[$i] -band 0x0F0F) -shl 4) -bor (($bytes[$i] -band 0xF0F0) -shr 4)
}
Write-Output -NoEnumerate $bytes
}
function GuidToRegString {
param ( [guid] $guid )
$bigendian = (Reverse-Nibbles $guid.ToByteArray())
return [System.Runtime.Remoting.Metadata.W3cXsd2001.SoapHexBinary]::new($bigendian).ToString()
}
function RegStringToGuid {
param ( [string] $guid )
$littleendian = (Reverse-Nibbles ([System.Runtime.Remoting.Metadata.W3cXsd2001.SoapHexBinary]::Parse($guid).Value))
return [guid]::new($littleendian)
}
$upcode = GuidToRegString ([guid]::Parse($upgradecode))
if (Test-Path -Path "HKLM:\Software\Classes\Installer\UpgradeCodes\$upcode") {
$products = RegStringToGuid (Get-Item -Path "HKLM:\Software\Classes\Installer\UpgradeCodes\$upcode").Property
foreach ($prod in $products) {
$pguid = [guid]::new($prod)
$p = $pguid.ToString("B")
if ((Test-Path -Path "HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\$p") -or
(Test-Path -Path "HKLM:\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\$p"))
{
$logfile = Join-Path -Path $PSScriptRoot -ChildPath uninstall-$($pguid.ToString("D")).log
$args = #( "/x", $p, "/l*v", """$logfile""", "/q", "COMPLETE_UNINSTALL=1", "REBOOT=REALLYSUPPRESS" )
Write-Host "Uninstalling $p"
$uninst = Start-Process -FilePath """$installer""" -ArgumentList $args -PassThru -Wait
Write-Host $uninst.ExitCode
}
}
}
I am trying to install software using powershell silent scripting. To install this software we need to have JRE installed on machine. For this first we need to check weather JRE installed or not, if not installed then it needs to be installed. What approach needs to be followed?
I have tried with the below of code.
$LASTEXITCODE = 0
$workdir = "C:\Program Files (x86)\Java"
If (!(Test-Path $workdir))
{
$LASTEXITCODE = (Start-Process "D:\jre-6u26-windows-i586.exe" -ArgumentList "/s" -Wait -PassThru).Exitcode
}
If($LASTEXITCODE -eq 0)
{
$DCBdir = "C:\Program Files (x86)\Compart"
If (!(Test-Path $DCBdir))
{
$Installer="D:\sw.exe"
$responsefile="D:\Sresponse.varfile"
$a=#("-q", "-varfile", "$responsefile")
start-process $Installer -ArgumentList $a -wait
}
}
$chkdir = "C:\Program Files (x86)\SWFolder"
if(Test-Path -eq $chkdir)
{
[System.Windows.MessageBox]::Show('Installation completed successfully')
}
When I run script its workingfine as it is checking the previous installation and performing installation if not found the installation. But here I am getting as issue with this code.
If Java installed alredy means it should start the other installation. but here in my case its stopping the complete installation.
after installation completed, I need to display the message like " Installation completed". But here its not working. AnNy wrong in the above code..??
One package manager that I like to use is Chocolatey which has an approved package for JRE, it looks like. A quick check wmi will tell you whether or not java is installed:
$x = Get-WmiObject -Class Win32_Product -Filter "Name like 'Java(TM)%'" | Select -Expand Version
You could also use Test-Path pointed at registry keys you know exist for the package. Once you verify that JRE is not on the machine, then you can call out to Chocolatey to install it.
I'm writing a Powershell DSC script so I can easily configure development environments. I'm trying to get Visual Studio 2012 Addons to install without opening the GUI.
I've downloaded the Specflow .vsix file. When I run
& "C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\VSIXInstaller.exe" /q C:\Users\Public\Downloads\TechTalk.SpecFlow.Vs2010Integration.vsix
on the Powershell command prompt, it works without a hitch. But if I try to do the same thing in a DSC Script resource, I run into problems. Copying and pasting the command above into SetScript results in VSInstaller.exe results in the command never finishing.
I therefore tried the following, based on the Choco Install-VSIX cmdlet:
Script installSpecflowVS {
SetScript = {
$specUrl = 'https://visualstudiogallery.msdn.microsoft.com/9915524d-7fb0-43c3-bb3c-a8a14fbd40ee/file/79327/7/TechTalk.SpecFlow.Vs2010Integration.vsix'
$outfile = 'C:\Users\Public\DownloadsTechTalk.SpecFlow.Vs2010Integration.vsix'
wget $specUrl -outfile $outfile
$psi = New-Object System.Diagnostics.ProcessStartInfo
$psi.FileName='C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\VSIXInstaller.exe'
$psi.Arguments="/q $outfile"
$s = [System.Diagnostics.Process]::Start($psi)
$s.WaitForExit()
return $s.ExitCode
}
TestScript = { return $False }
GetScript = { return $True }
}
In this case, the command completes, but VSIXInstall.exe throws a FileNotFound error which I can see from the log created in in C:\Windows\Temp\
1/18/2017 10:51:51 AM - Searching for applicable products...
1/18/2017 10:51:51 AM - Found installed product - Microsoft Visual Studio Professional 2012
1/18/2017 10:51:51 AM - System.IO.FileNotFoundException: The system cannot find the file specified. (Exception from HRESULT: 0x80070002)
at System.Runtime.InteropServices.Marshal.ThrowExceptionForHRInternal(Int32 errorCode, IntPtr errorInfo)
at System.Runtime.InteropServices.Marshal.ThrowExceptionForHR(Int32 errorCode)
at Microsoft.VisualStudio.Settings.ExternalSettingsManager.GetScopePaths(String applicationPath, String suffixOrName, String vsVersion, Boolean isLogged, Boolean isForIsolatedApplication)
at Microsoft.VisualStudio.Settings.ExternalSettingsManager.CreateForApplication(String applicationPath)
at VSIXInstaller.App.GetExtensionManager(SupportedVSSKU sku)
at VSIXInstaller.App.GetExtensionManagerForApplicableSKU(SupportedVSSKU supportedSKU, IInstallableExtension installableExtension, List`1 applicableSKUs)
at VSIXInstaller.App.InitializeInstall()
at VSIXInstaller.App.OnStartup(StartupEventArgs e)
The file is definitely there; if I supply VSInstaller with something that doesn't exist it gives the following error instead
1/18/2017 10:21:45 AM - VSIXInstaller.InvalidCommandLineException: Path to vsix file 'outfile' is invalid or you don't have required access permissions. Please check the path is valid and you have required access permissions.
The script is running locally on a Windows 7 SP1 virtual machine with Powershell 5. I'm executing it using Powershell ISE with Admin privileges.
There is obviously something different about scripts running via DSC Set-Script. Any ideas how to fix to fix it? Or another way of doing it?
VSIX is per user you need to tell DSC which user to install this as using PSDscRunAsCredential (added in PowerShell 5.0).
Example, where $credential is the credentials for the user that you want to install the VSIX for.
Script installSpecflowVS {
SetScript = {
$specUrl = 'https://visualstudiogallery.msdn.microsoft.com/9915524d-7fb0-43c3-bb3c-a8a14fbd40ee/file/79327/7/TechTalk.SpecFlow.Vs2010Integration.vsix'
$outfile = 'C:\Users\Public\DownloadsTechTalk.SpecFlow.Vs2010Integration.vsix'
wget $specUrl -outfile $outfile
$psi = New-Object System.Diagnostics.ProcessStartInfo
$psi.FileName='C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\VSIXInstaller.exe'
$psi.Arguments="/q $outfile"
$s = [System.Diagnostics.Process]::Start($psi)
$s.WaitForExit()
return $s.ExitCode
}
TestScript = { return $False }
GetScript = { return $True }
PSDscRunAsCredential = $credential
}
Please also see Securing the MOF File on how to properly encrypt the MOF file so you don't leak your credentials.
I have created my own framework for Powershell scripts which I am using on a lot of 2008-servers without issues. Now was the time to try it out on the first 2012-server, but for some reason it fails.
I initially do some checking to ensure that paths are valid, then I try to load the logger
try {
$log = New-Logger -Configuration $log4NetFile -Dll $dll40Path
Write-Verbose "[Enable-Logger] Using 4.0 DLL"
} catch [System.Management.Automation.MethodInvocationException] {
Write-Verbose "[Enable-Logger] Using 3.5 instead of 4.0 DLL"
$log = New-Logger -Configuration $log4NetFile -Dll $dll35Path
} finally {
Write-Verbose "[Enable-Logger] Log is $log"
}
On all our 2008-servers it loads 4.0 without any issues, but on 2012 the $log-variable is always empty, meaning it cannot load the dll.
To ensure that it has nothing to do with the config file I did try the exact same code on 2008, and it worked.
Initial workaround
Did check Powershell-version
Powershell -Command "Write-Host $psversiontable.psversion"
which is 3.0 on the 2012-server. Starting the script with the 2.0 engine like this
Powershell -Version 2 -File alertXymon1-region3queues.ps1 -verbose
and it worked.
Final solution
Did some checking today and figured out that the problem was not caused by the DLL, but a code line that is loading the DLL
[void][Reflection.Assembly]::LoadFrom($log4netDllPath) | Out-Null
Found the post "Powershell 2.0 script not working in PS 3.0" which helped me out.
I have now tested the code without [void] on both Powershell 2.0 and 3.0 and it works like a charm