I keep seeing many posts with people struggling to execute code on remote machines, it is usually not due to permissions issues, (enable PS Remoting), but mainly due to the fact that they forget that the remote machine does not know the value of the locally assigned variable.

### Using (new way) PSv3+

With PowerShell Version 3 and newer, $using was introduced. If you want to pass a local variable to the remote machine , just add$using: in front of the variable name (e.g. $using:localvariable), and the local value will be given on to the remote machine. This is so much simpler and easier to read than the ‘old’ argumentlist way. # Using '$using'
# PowerShell v3+
$localvalue01 = 'SampleValue01'$localvalue02   = 'SampleValue01'

Invoke-Command -ComputerName $remotecomputer -ScriptBlock { write-output$using:localvalue01
write-output $using:localvalue02 } ### Argumentlist (old way) In this sample, we are looking at using an argument list to pass the values of the variable to the remote machine. You define the values you need per usual on your local machine, and then you add an$argumentlist as parameter.

The order you list the variables is important, as the one first variable listed is addressed with $args[0], the variable next to it (to the right) is addressed with$args[1] and so forth.

# Argument lists
# PowerShell v2 and lower
$localvalue01 = 'SampleValue01'$localvalue02   = 'SampleValue02'

Invoke-Command -ComputerName $remotecomputer -ScriptBlock { write-output$args[0] #holds the value for $localvalue01 write-output$args[1] #holds the value for $localvalue02 } -ArgumentList$localvalue01, \$localvalue02

I keep forgetting this and have to look it up the few times I need it… so I’m going to post it here:

1. When setting NTFS permissions, select local machine (not the domain or whatever)
(Don&#8217;t forget to change &#8220;DefaultAppPool&#8221; here to whatever you named your application pool)


That’s it ¯_(ツ)_/¯

The application has failed to start because the side-by-side configuration is incorrect

Ugh, yeah one of those… alright let’s have a look…

# install your service
C:\Windows\Microsoft.NET\Framework[64]\[version]\InstallUtil.exe [path to application]

C:\Windows\Microsoft.NET\Framework[64]\[version]\InstallUtil.exe /u [path to application]



So after (successfully) installing it, it does not want to start, so we have to do some tracing.

Eventlogs tells you only so much unfortunately so we look in the SxsTrace.exe  for help

# start trace
C:\windows\system32\SxsTrace.exe Trace -logfile:log.etl

# press ENTER to stop the trace

# parse the trace logs
C:\windows\system32\SxsTrace.exe Parse -logfile:log.etl -outfile:SxSTrace.txt


This will open the SxSTrace.txt file which will have all the information about the error.

If that did not create any helpful information (but I hope it did) there are other steps that might help:

Sfc /scannow
sfc /scannow /offbootdir=c:\ /offwindir=c:\windows (If above fails)

and let’s try DISM

DISM.exe /Online /Cleanup-image /Scanhealth
DISM.exe /Online /Cleanup-image /Restorehealth

Last resort options are a System Restore or updating .NET to the latest version.

You probably have heard or read about the current issues with chips and their vulnerability.

A fundamental design flaw in Intel’s processor chips has forced a significant redesign of the Linux and Windows kernels to defang the chip-level security bug.

CVE-2017-5754 (Meltdown) and CVE-2017-5715 (Spectre)  are two nasty exploits and you might want to check your systems if they are patched.

Luckily the Microsoft Security Response Center has released a PowerShell module named SpeculationControl which can be installed from the PowerShell Gallery.

Install-Module -Name SpeculationControl -Force

Get-SpeculationControlSettings



Additionally maybe look at Mike’s post