mirror of
https://github.com/Set-OutlookSignatures/Set-OutlookSignatures.git
synced 2026-04-26 10:45:52 +03:00
[GH-ISSUE #124] Getting "Exception setting "OutputEncoding": "The handle is invalid." when trying to compile the Intune-SetOutlookSignatures-Remediate.ps1 #53
Labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/Set-OutlookSignatures-Set-OutlookSignatures#53
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @rayakajamon on GitHub (Sep 3, 2024).
Original GitHub issue: https://github.com/Set-OutlookSignatures/Set-OutlookSignatures/issues/124
Originally assigned to: @rayakajamon on GitHub.
Issue happens in the latest release
Previously solved issues and documentation
Code of Conduct
What happened?
Getting "Exception setting "OutputEncoding": "The handle is invalid." when trying to compile the Intune-SetOutlookSignatures-Remediate.ps1
Initially thought it was due to edits we made when adding our parameter values but I then tried a new copy w/o any edits and still get the error.
PS C:\windows\system32> C:\HES\Set-OutlookSignatures_v4.14.1\Set-OutlookSignatures_v4.14.1\sample code\Intune-SetOutlookSignatures-Remediate-Copy.ps1
Exception setting "OutputEncoding": "The handle is invalid.
"
At C:\HES\Set-OutlookSignatures_v4.14.1\Set-OutlookSignatures_v4.14.1\sample code\Intune-SetOutlookSignatures-Remediate-Copy.ps1:32 char:46
... tEncoding = [Console]::OutputEncoding = New-Object System.Text.UTF8En ...
Directory: C:\path\to
Mode LastWriteTime Length Name
d----- 9/3/2024 1:40 PM Set-OutlookSignatures
Invoke-WebRequest : Not Found
At C:\HES\Set-OutlookSignatures_v4.14.1\Set-OutlookSignatures_v4.14.1\sample code\Intune-SetOutlookSignatures-Remediate-Copy.ps1:60 char:9
@GruberMarkus commented on GitHub (Sep 3, 2024):
Does this happen in PowerShell ISE, or in powershell.exe or pwsh.exe?
@rayakajamon commented on GitHub (Sep 3, 2024):
ISE and when trying to run it in Intune.
Have not tried it in the other. Should I?
@GruberMarkus commented on GitHub (Sep 3, 2024):
Never use ISE to run PowerShell scripts. It's an environment that has lots of restrictions.
How exactly do you run it in Intune? Are you sure it runs in the user context and not in the system context?
@rayakajamon commented on GitHub (Sep 3, 2024):
Ok, never heard that about ISE. Let me get with my Endpoint engineer on your question. Thanks
@GruberMarkus commented on GitHub (Sep 4, 2024):
I just tested the detect and remediate sample code in a fresh test tenant. The detect script works fine, and the remediate script has no problems defining the output encoding.
My guess is that the script in your Intune environment is configured to run in system context instead of user context.
Nonetheless, there is a problem in the remediate script: When extracting the downloaded ZIP file, it creates folders instead of files in some cases. This then leads to problems running Set-OutlookSignatures.
Find an updated version attached for your convenience. The next release will contain this updated version.
For further support regarding Intune, I have to refer you to our partner ExplicIT Consulting, which provides commercial support for the Intune sample code.
Please let me know if your questions are answered and if this issue can be closed.
@rayakajamon commented on GitHub (Sep 4, 2024):
Hi Markus, this is the result when running the above version.

@GruberMarkus commented on GitHub (Sep 5, 2024):
Hi Ray,
glad to see that the initial issue is solved.
The updated code can not have solved the initial issue, as the code part giving the encoding error was not changed and runs before the updated code.
Was the root cause that "Run this script using the logged-on credentials" was not enabled in Intune?
@rayakajamon commented on GitHub (Sep 5, 2024):
Hey Markus, yes, I believe that was exactly it. Once that was enabled, we got a different result.
@GruberMarkus commented on GitHub (Sep 5, 2024):
Glad to hear that i could solve your initial issue.
Regarding the message
Invoke-WebRequest: Not found: You probably ran the updated code I provided but did not modify the variables in the sample code. Very likely, you left $versionToUse at the default value "vX.X.X".If this is not the case, please open a new issue.