REF:
https://www.bleepingcomputer.com/news/security/microsoft-warns-of-critical-powershell-7-code-execution-vulnerability/

[excerpt quote=\"
Customers are urged to install the updated PowerShell 7.0.6 and 7.1.3
versions as soon as possible to protect their systems from potential
attacks.
\" /]

fyi

--
Sailfish
CDC Covid19 Trends: https://www.facebook.com/groups/624208354841034
Rare Mozilla Stuff: http://tinyurl.com/z86x3sg

On Sat, 3 Jul 2021 at 16:59:18, Sailfish
<NIXCAPSsailfish@NIXCAPSunforgettable.com> wrote (my responses usually
follow points raised):
>REF:
>https://www.bleepingcomputer.com/news/security/microsoft-warns-of-critic
>al-powershell-7-code-execution-vulnerability/
>
>[excerpt quote=\"
>Customers are urged to install the updated PowerShell 7.0.6 and 7.1.3
>versions as soon as possible to protect their systems from potential
>attacks.
>\" /]
>
>fyi
>
"Customers are urged to install the updated PowerShell 7.0.6 and 7.1.3
versions as soon as possible to protect their systems from potential
attacks."

_and_? First time I've ever seen a recommendation to install two
versions of anything.

To save people time (assuming 7.1.3 is what we should be going for!):

https://github.com/PowerShell/PowerShell/releases/download/v7.1.3/PowerShell-7.1.3-win-x86.msi
(85.8 MB)
https://github.com/PowerShell/PowerShell/releases/download/v7.1.3/PowerShell-7.1.3-win-x64.msi
(95 MB)
Note: requires Windows Management Framework 4.0 or newer; get from
https://docs.microsoft.com/en-us/powershell/scripting/windows-powershell/
wmf/overview?view=powershell-7.1
(https://www.microsoft.com/en-us/download/confirmation.aspx?id=54616 if
you want the latest, 5.1 [which is OK on 7 SP1]) if you haven't got. My
attempt to follow the instructions fell over there!

Is this really a big deal? I don't develop software (if that's
relevant); I think this (while trying to follow the instructions to
install WMF5.1) is actually the first time I've ever (knowingly) run
powershell.
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

1. If it's green, it's biology
2. If it smells, it's chemistry
3. If it doesn't work, it's physics.

On Sun, 4 Jul 2021 18:12:59 +0100, "J. P. Gilliver (John)"
<G6JPG@255soft.uk> wrote:

>"Customers are urged to install the updated PowerShell 7.0.6 and 7.1.3
>versions as soon as possible to protect their systems from potential
>attacks."
>
>_and_? First time I've ever seen a recommendation to install two
>versions of anything.

I think they meant...

If you have v7.0, make sure it's the latest version (v7.0.6).

If you have v7.1, make sure it's the latest version (v7.1.3).

Anyway, that's my interpretation.

--

Dennis

J. P. Gilliver (John) graced us with on 7/4/2021 10:12 AM:
> On Sat, 3 Jul 2021 at 16:59:18, Sailfish
> <NIXCAPSsailfish@NIXCAPSunforgettable.com> wrote (my responses usually
> follow points raised):
>> REF:
>> https://www.bleepingcomputer.com/news/security/microsoft-warns-of-critic
>> al-powershell-7-code-execution-vulnerability/
>>
>> [excerpt quote=\"
>> Customers are urged to install the updated PowerShell 7.0.6 and 7.1.3
>> versions as soon as possible to protect their systems from potential
>> attacks.
>> \" /]
>>
>> fyi
>>
> "Customers are urged to install the updated PowerShell 7.0.6 and 7.1.3
> versions as soon as possible to protect their systems from potential
> attacks."
>
> _and_? First time I've ever seen a recommendation to install two
> versions of anything.
>
> To save people time (assuming 7.1.3 is what we should be going for!):
>
> https://github.com/PowerShell/PowerShell/releases/download/v7.1.3/PowerShell-7.1.3-win-x86.msi
>
> (85.8 MB)
> https://github.com/PowerShell/PowerShell/releases/download/v7.1.3/PowerShell-7.1.3-win-x64.msi
>
> (95 MB)
> Note: requires Windows Management Framework 4.0 or newer; get from
> https://docs.microsoft.com/en-us/powershell/scripting/windows-powershell/
> wmf/overview?view=powershell-7.1
> (https://www.microsoft.com/en-us/download/confirmation.aspx?id=54616 if
> you want the latest, 5.1 [which is OK on 7 SP1]) if you haven't got. My
> attempt to follow the instructions fell over there!
>
> Is this really a big deal? I don't develop software (if that's
> relevant); I think this (while trying to follow the instructions to
> install WMF5.1) is actually the first time I've ever (knowingly) run
> powershell.

"Any .NET 5, .NET Core, or .NET Framework-based app using a
System.Text.Encodings.Web package version listed below is exposed to
attacks."

Since it affects any app that uses the .NET framework, it's probably
important for most developers to install the fix. As far as Windows
non-developers that don't use PowerShell, their only exposure may be
from execution of existing code that was built on the susceptible .NET
framework? It's unclear whether installing the PowerShell fix will also
fix apps built on the susceptible .NET framework but seems unlikely,
from my reading.

Since I'm not a Windows app developer, someone who is may be able to
provide more clarification.

Cheers

--
Sailfish
CDC Covid19 Trends: https://www.facebook.com/groups/624208354841034
Rare Mozilla Stuff: http://tinyurl.com/z86x3sg

"J. P. Gilliver (John)" <G6JPG@255soft.uk> wrote

| Is this really a big deal? I don't develop software (if that's
| relevant); I think this (while trying to follow the instructions to
| install WMF5.1) is actually the first time I've ever (knowingly) run
| powershell.

I have it disabled. (Though with this news I'm going to
double-check.) On my XP boxes I never installed it at
all and it's not installed by default.

PS is like Windows scripting in earlier days. It's not
standard to disable it, but it's mostly only used by
admins, and if you're coding there's usually another,
easier way to do things. MS invented PS to appeal to
Linux server admins who are used to running one-
trick-pony applets via commandline.

On Sun, 4 Jul 2021 at 10:59:22, Sailfish
<NIXCAPSsailfish@NIXCAPSunforgettable.com> wrote (my responses usually
follow points raised):
>J. P. Gilliver (John) graced us with on 7/4/2021 10:12 AM:
[]
>> Is this really a big deal? I don't develop software (if that's
>>relevant); I think this (while trying to follow the instructions to
>>install WMF5.1) is actually the first time I've ever (knowingly) run
>>powershell.
[]
>Since it affects any app that uses the .NET framework, it's probably
>important for most developers to install the fix. As far as Windows
>non-developers that don't use PowerShell, their only exposure may be
>from execution of existing code that was built on the susceptible .NET
>framework? It's unclear whether installing the PowerShell fix will also
>fix apps built on the susceptible .NET framework but seems unlikely,
>from my reading.

Not that I know anything about it, but your summary makes sense - code
built with older components still (in theory) vulnerable, _users_
probably not protected by changing those components. So little point in
my trying to update powershell.
>
>Since I'm not a Windows app developer, someone who is may be able to
>provide more clarification.
>
>Cheers
>
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

He [Alfred Kinsey] wouldn't ask 'Have you ever slept with a horse?' He would
say, 'When did you first sleep with a horse?' [RT 2018/5/5-11]

On 04/07/2021 22:08, J. P. Gilliver (John) wrote:
>
> On Sun, 4 Jul 2021 at 10:59:22, Sailfish
> <NIXCAPSsailfish@NIXCAPSunforgettable.com> wrote (my responses usually
> follow points raised):
>>
>> J. P. Gilliver (John) graced us with on 7/4/2021 10:12 AM:
>>>
>>>  Is this really a big deal? I don't develop software (if that's
>>> relevant); I think this (while trying to follow the instructions to
>>> install WMF5.1) is actually the first time I've ever (knowingly) run
>>> powershell.
>>
>> Since it affects any app that uses the .NET framework, it's probably
>> important for most developers to install the fix. As far as Windows
>> non-developers that don't use PowerShell, their only exposure may be
>> from execution of existing code that was built on the susceptible .NET
>> framework? It's unclear whether installing the PowerShell fix will
>> also fix apps built on the susceptible .NET framework but seems
>> unlikely, from my reading.
>
> Not that I know anything about it, but your summary makes sense - code
> built with older components still (in theory) vulnerable, _users_
> probably not protected by changing those components. So little point in
> my trying to update powershell.

No, I think Sailfish is wrong. AIUI, Powershell is an interpreter of
text code, just like Perl, Python, or Windows Scripting Host. Thus old
code developed on an old version of PS will be run not by that
development version, but by the runtime version on the PC on which it is
being run. Thus, it's probably best to upgrade it, to avoid the
possible security vulnerabilities given above.

>> Since I'm not a Windows app developer, someone who is may be able to
>> provide more clarification.

Nor in general terms am I, but I do have some development experience,
and I'm fairly sure that what I've written above is correct.

--

Fake news kills!

I may be contacted via the contact address given on my website:
www.macfh.co.uk

On Sun, 4 Jul 2021 at 16:48:15, Mayayana <mayayana@invalid.nospam> wrote
(my responses usually follow points raised):
>"J. P. Gilliver (John)" <G6JPG@255soft.uk> wrote
>
>| Is this really a big deal? I don't develop software (if that's
>| relevant); I think this (while trying to follow the instructions to
>| install WMF5.1) is actually the first time I've ever (knowingly) run
>| powershell.
>
> I have it disabled. (Though with this news I'm going to
>double-check.) On my XP boxes I never installed it at
>all and it's not installed by default.

I don't _remember_ installing it on this (7-32) machine. But it's there
(I don't know what version - I think it may be 1.0).
>
> PS is like Windows scripting in earlier days. It's not
>standard to disable it, but it's mostly only used by
>admins, and if you're coding there's usually another,
>easier way to do things. MS invented PS to appeal to
>Linux server admins who are used to running one-
>trick-pony applets via commandline.
>
>
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

He [Alfred Kinsey] wouldn't ask 'Have you ever slept with a horse?' He would
say, 'When did you first sleep with a horse?' [RT 2018/5/5-11]

On Sun, 4 Jul 2021 at 22:56:51, Java Jive <java@evij.com.invalid> wrote
(my responses usually follow points raised):
[]
>No, I think Sailfish is wrong. AIUI, Powershell is an interpreter of
>text code, just like Perl, Python, or Windows Scripting Host. Thus
>old code developed on an old version of PS will be run not by that
>development version, but by the runtime version on the PC on which it
>is being run. Thus, it's probably best to upgrade it, to avoid the
>possible security vulnerabilities given above.

Perhaps you can help me then.

I try to run PowerShell-7.1.3-win-x86.msi (having downloaded it).
I get a popup saying it needs Windows Management Framework 4.0 or later.
I get and unzip that (KB3191566, which is WMF 5.1).
As instructed on the download page, I open (presumably my existing)
PowerShell in admin mode,
I try to run Install-WMF5.1.ps1. (I get told to try again with .\ 1st.)
I get "...ps1 cannot be loaded because the execution of scripts is
disabled on this system."
I give up.

Surely, if this is something they're recommending we do, it ought to be
simpler than this!
>
>>> Since I'm not a Windows app developer, someone who is may be able to
>>>provide more clarification.
>
>Nor in general terms am I, but I do have some development experience,
>and I'm fairly sure that what I've written above is correct.
>
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

I still say a church steeple with a lightning rod on top shows a lack of
confidence. D McLeod

J. P. Gilliver (John) wrote:
> On Sun, 4 Jul 2021 at 22:56:51, Java Jive <java@evij.com.invalid> wrote
> (my responses usually follow points raised):
> []
>> No, I think Sailfish is wrong. AIUI, Powershell is an interpreter of
>> text code, just like Perl, Python, or Windows Scripting Host. Thus
>> old code developed on an old version of PS will be run not by that
>> development version, but by the runtime version on the PC on which it
>> is being run. Thus, it's probably best to upgrade it, to avoid the
>> possible security vulnerabilities given above.
>
> Perhaps you can help me then.
>
> I try to run PowerShell-7.1.3-win-x86.msi (having downloaded it).
> I get a popup saying it needs Windows Management Framework 4.0 or later.
> I get and unzip that (KB3191566, which is WMF 5.1).
> As instructed on the download page, I open (presumably my existing)
> PowerShell in admin mode,
> I try to run Install-WMF5.1.ps1. (I get told to try again with .\ 1st.)
> I get "...ps1 cannot be loaded because the execution of scripts is
> disabled on this system."
> I give up.
>
> Surely, if this is something they're recommending we do, it ought to be
> simpler than this!
>>
>>>> Since I'm not a Windows app developer, someone who is may be able to
>>>> provide more clarification.
>>
>> Nor in general terms am I, but I do have some development experience,
>> and I'm fairly sure that what I've written above is correct.
>>

The first thing you do, as a "young Powershell apprentice",
is change the script execution rights. Initially it is locked
down, to prevent accidents.

Copied straight from my cryptic notes file:

*******
In Command Prompt [we will change over to the Powershell execution shell...]

powershell
Get-ExecutionPolicy (returns Restricted)
Set-ExecutionPolicy Unrestricted (or could be: RemoteSigned, AllSigned, Restricted)
D:\filesha1.ps1 somefile.bin (Full path for .ps1 files, .\ for workdir shorthand
exit (exit Powershell, return to Command Prompt)
*******

Paul

"J. P. Gilliver (John)" <G6JPG@255soft.uk> wrote

| I don't _remember_ installing it on this (7-32) machine. But it's there
| (I don't know what version - I think it may be 1.0).

Yes, it's pre-installed on Win7+. I rechecked my Win7
machine and found no trace of PS. I guess I may have
removed it, but I don't remember now. However, there
are instructions online for removing/disabling. I get the
sense that it can be uninstalled in Win7 but perhaps only
disabled in Win10.

This is like a lot of things MS have done. PowerShell.
Windows Script Host. HTAs. WMI. ActiveX. They come
up with clever, handy tools that programmers and admins
find useful, but which are too powerful to be safe.

Remember "Melissa"? Some office worker who knew enough
about VBScript and MS Word docs to get himself into trouble,
creating some kind of nuisance file as a prank. It spread and
crippled American business for a couple of days. He got caught
because he didn't know that Word DOCs embed the author's
name in them. :)

After that, a lot of network admins who didn't really
understand Windows went around disabling Windows Script Host,
but left scripting in MS Office because it was so pervasively
used. PS is turning out to be a similar case. It's exploitable
and unnecessary, but MS have also encouraged its use by
admins as a kind of DOS replacement. So it's ubiquitous and
most people don't know about it.

On Mon, 5 Jul 2021 at 01:22:49, Paul <nospam@needed.invalid> wrote (my
responses usually follow points raised):
>J. P. Gilliver (John) wrote:
>> On Sun, 4 Jul 2021 at 22:56:51, Java Jive <java@evij.com.invalid>
>>wrote (my responses usually follow points raised):
>> []
>>> No, I think Sailfish is wrong. AIUI, Powershell is an interpreter
>>>of text code, just like Perl, Python, or Windows Scripting Host.
>>>Thus old code developed on an old version of PS will be run not by
>>>that development version, but by the runtime version on the PC on
>>>which it is being run. Thus, it's probably best to upgrade it, to
>>>avoid the possible security vulnerabilities given above.
>> Perhaps you can help me then.
>> I try to run PowerShell-7.1.3-win-x86.msi (having downloaded it).
>> I get a popup saying it needs Windows Management Framework 4.0 or later.
>> I get and unzip that (KB3191566, which is WMF 5.1).
>> As instructed on the download page, I open (presumably my existing)
>>PowerShell in admin mode,
>> I try to run Install-WMF5.1.ps1. (I get told to try again with .\ 1st.)
>> I get "...ps1 cannot be loaded because the execution of scripts is
>>disabled on this system."
>> I give up.
>> Surely, if this is something they're recommending we do, it ought to
>>be simpler than this!
>>>
>>>>> Since I'm not a Windows app developer, someone who is may be able
>>>>>to provide more clarification.
>>>
>>> Nor in general terms am I, but I do have some development
>>>experience, and I'm fairly sure that what I've written above is
>>>correct.
>>>
>
>The first thing you do, as a "young Powershell apprentice",
>is change the script execution rights. Initially it is locked
>down, to prevent accidents.
>
>Copied straight from my cryptic notes file:

Thanks for this!
>
>*******
>In Command Prompt [we will change over to the Powershell execution shell...]
>
>powershell
>Get-ExecutionPolicy (returns Restricted)

It did indeed.

>Set-ExecutionPolicy Unrestricted (or could be: RemoteSigned,
>AllSigned, Restricted)

(Is that something I should put back, or has it only changed it for this
powershell session?) Worked, once I'd remembered I should have started
powershell as administrator.

>D:\filesha1.ps1 somefile.bin (Full path for .ps1 files, .\ for
>workdir shorthand

I got:

D:\...\Install-WMF5.1.ps1 : Expected WMF 5.1 Package:
"Win7-KB3191566-x86.msu" was not found.
At line:1 char:21
+ .\Install-WMF5.1.ps1 <<<<
+ CategoryInfo : ResourceUnavailable: (:String)
[Install-WMF5.1.ps1], FileNotFoundException
+ FullyQualifiedErrorId : Install-WMF5.1.ps1

The folder contains _only_ Install-WMF5.1.ps1 (the script I was running)
and Win7-KB3191566-x86.msu (the file it said it couldn't find), both
having been put there (and the folder created) when I unzipped
Win7-KB3191566-x86 [Windows Management Framework (WMF) 5.1].zip .

This is like pulling teeth!

>exit (exit Powershell, return to
>Command Prompt)

I did that (-:
>*******
>
> Paul
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

"Mary Poppins is a junkie" - bumper sticker on Julie Andrews' car in the '60s

J. P. Gilliver (John) wrote:
> On Mon, 5 Jul 2021 at 01:22:49, Paul <nospam@needed.invalid> wrote (my
> responses usually follow points raised):
>> J. P. Gilliver (John) wrote:
>>> On Sun, 4 Jul 2021 at 22:56:51, Java Jive <java@evij.com.invalid>
>>> wrote (my responses usually follow points raised):
>>> []
>>>> No, I think Sailfish is wrong. AIUI, Powershell is an interpreter
>>>> of text code, just like Perl, Python, or Windows Scripting Host.
>>>> Thus old code developed on an old version of PS will be run not by
>>>> that development version, but by the runtime version on the PC on
>>>> which it is being run. Thus, it's probably best to upgrade it, to
>>>> avoid the possible security vulnerabilities given above.
>>> Perhaps you can help me then.
>>> I try to run PowerShell-7.1.3-win-x86.msi (having downloaded it).
>>> I get a popup saying it needs Windows Management Framework 4.0 or later.
>>> I get and unzip that (KB3191566, which is WMF 5.1).
>>> As instructed on the download page, I open (presumably my existing)
>>> PowerShell in admin mode,
>>> I try to run Install-WMF5.1.ps1. (I get told to try again with .\ 1st.)
>>> I get "...ps1 cannot be loaded because the execution of scripts is
>>> disabled on this system."
>>> I give up.
>>> Surely, if this is something they're recommending we do, it ought to
>>> be simpler than this!
>>>>
>>>>>> Since I'm not a Windows app developer, someone who is may be able
>>>>>> to provide more clarification.
>>>>
>>>> Nor in general terms am I, but I do have some development
>>>> experience, and I'm fairly sure that what I've written above is
>>>> correct.
>>>>
>>
>> The first thing you do, as a "young Powershell apprentice",
>> is change the script execution rights. Initially it is locked
>> down, to prevent accidents.
>>
>> Copied straight from my cryptic notes file:
>
> Thanks for this!
>>
>> *******
>> In Command Prompt [we will change over to the Powershell execution
>> shell...]
>>
>> powershell
>> Get-ExecutionPolicy (returns Restricted)
>
> It did indeed.
>
>> Set-ExecutionPolicy Unrestricted (or could be: RemoteSigned,
>> AllSigned, Restricted)
>
> (Is that something I should put back, or has it only changed it for this
> powershell session?) Worked, once I'd remembered I should have started
> powershell as administrator.
>
>> D:\filesha1.ps1 somefile.bin (Full path for .ps1 files, .\
>> for workdir shorthand
>
> I got:
>
> D:\...\Install-WMF5.1.ps1 : Expected WMF 5.1 Package:
> "Win7-KB3191566-x86.msu" was not found.
> At line:1 char:21
> + .\Install-WMF5.1.ps1 <<<<
> + CategoryInfo : ResourceUnavailable: (:String)
> [Install-WMF5.1.ps1], FileNotFoundException
> + FullyQualifiedErrorId : Install-WMF5.1.ps1
>
> The folder contains _only_ Install-WMF5.1.ps1 (the script I was running)
> and Win7-KB3191566-x86.msu (the file it said it couldn't find), both
> having been put there (and the folder created) when I unzipped
> Win7-KB3191566-x86 [Windows Management Framework (WMF) 5.1].zip .
>
> This is like pulling teeth!
>
>> exit (exit Powershell, return to
>> Command Prompt)
>
> I did that (-:
>> *******
>>
>> Paul

Did you set the working directory to the goods in question ?

For example:

Administrator Command Prompt

cd /d D:\myexperiment\
powershell
.\Install-WMF5.1.ps1 <=== maybe powershell inherits $CWD ?

Now, the working directory should be

D:\myexperiment\
Install-WMF5.1.ps1
Win7-KB3191566-x86.msu

and all the goods are within reach. If the .ps1
file referenced the MSU as

Win7-KB3191566-x86.msu

as a relative path, it should find it. If Powershell
even insists on absolute paths for objects, then the
script could be altered to

.\Win7-KB3191566-x86.msu

to make it crystal, that we desire the file to be
with respect to the working directory.

I'm not a big fan of Powershell, and most of the
time all I get is red text. Maybe someone else runs
Powershell without the red text and can get this
right on the first try.

Security theater is... so theatrical. Well,
we're running as Administrator, with our script
set to UnRestricted, so... Having to spell out
the working directory makes this so much safer :-)

Paul

On Mon, 5 Jul 2021 at 16:10:04, Paul <nospam@needed.invalid> wrote (my
responses usually follow points raised):
>J. P. Gilliver (John) wrote:
>> On Mon, 5 Jul 2021 at 01:22:49, Paul <nospam@needed.invalid> wrote
>>(my responses usually follow points raised):
[]
>>> powershell
>>> Get-ExecutionPolicy (returns Restricted)
>> It did indeed.
>>
>>> Set-ExecutionPolicy Unrestricted (or could be: RemoteSigned,
>>>AllSigned, Restricted)
>> (Is that something I should put back, or has it only changed it for

(?)

>>this powershell session?) Worked, once I'd remembered I should have
>>started powershell as administrator.
>>
>>> D:\filesha1.ps1 somefile.bin (Full path for .ps1 files, .\
>>>for workdir shorthand
>> I got:
>> D:\...\Install-WMF5.1.ps1 : Expected WMF 5.1 Package:
>>"Win7-KB3191566-x86.msu" was not found.
>> At line:1 char:21
>> + .\Install-WMF5.1.ps1 <<<<
>> + CategoryInfo : ResourceUnavailable: (:String)
>>[Install-WMF5.1.ps1], FileNotFoundException
>> + FullyQualifiedErrorId : Install-WMF5.1.ps1
>> The folder contains _only_ Install-WMF5.1.ps1 (the script I was
>>running) and Win7-KB3191566-x86.msu (the file it said it couldn't
>>find), both having been put there (and the folder created) when I
>>unzipped Win7-KB3191566-x86 [Windows Management Framework (WMF) 5.1].zip .
>> This is like pulling teeth!
>>
>>> exit (exit Powershell, return to
>>>Command Prompt)
>> I did that (-:
>>> *******
>>>
>>> Paul
>
>Did you set the working directory to the goods in question ?
>
>For example:
>
>Administrator Command Prompt
>
> cd /d D:\myexperiment\
> powershell
> .\Install-WMF5.1.ps1 <=== maybe powershell inherits $CWD ?

I explicitly did - _inside powershell_ - cd to the folder containing
(only) the .pa1 and .msu files.
>
>Now, the working directory should be
>
> D:\myexperiment\
> Install-WMF5.1.ps1
> Win7-KB3191566-x86.msu
>
>and all the goods are within reach. If the .ps1
>file referenced the MSU as
>
> Win7-KB3191566-x86.msu
>
>as a relative path, it should find it. If Powershell
>even insists on absolute paths for objects, then the
>script could be altered to
>
> .\Win7-KB3191566-x86.msu
>
>to make it crystal, that we desire the file to be
>with respect to the working directory.

Both files were contained in a .zip downloaded directly from MS. And
I've looked at the .ps1 in notepad - all references to .msu files have
no path or .\ before the name.
>
>I'm not a big fan of Powershell, and most of the
>time all I get is red text. Maybe someone else runs
>Powershell without the red text and can get this
>right on the first try.

This does seem excessively complicated, to fix something _they_ are
telling us about!
>
>Security theater is... so theatrical. Well,
>we're running as Administrator, with our script
>set to UnRestricted, so... Having to spell out
>the working directory makes this so much safer :-)
>
> Paul
>
(-:
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

"Bother," said Pooh, as Eeyore sneezed the crack all over Owl.

J. P. Gilliver (John) wrote:

>>>> Set-ExecutionPolicy Unrestricted (or could be: RemoteSigned,
>>>> AllSigned, Restricted)
>>> (Is that something I should put back, or has it only changed it for
>
> (?)

The system stuff seems to tolerate the "Restricted" setting,
wheres user John does not seem to tolerate such a choice
very well.

If you don't plan on doing this step daily, yes, you can
set it back to Restricted. But now, having been informed of
the "trick", you won't get caught up the next time. That's
how I learned it, by not having my first script run.

Paul