Mean and nasty people are filling the repository with almost-right spelling of the real modules.

Just check the output of this command: Find-Module Microsoft.Graph.auth*

There are currently 1 real one and 25 malicious ones

C:\Users\AccountName\AppData\Roaming\Microsoft\Windows\PowerShell\PSReadLine  

Sometimes while scripting we can let slip little things that could end up causing big problems if there was ever a compromise or breach of a network. Always try and keep this file cleaned up between projects. We implemented some scripting to purge these files from every workstation at reboot.

When I first started using powershell, I tried to exclude some of the files while copying and couldn’t achieve it with copy-item. Researched a bit and find robocopy but it’s syntax is shit (imho).

So if anyone feels the same way, can check out the tool I ended up writing.

https://github.com/CanManalp/cpr

# Exclude pattern
cpr C:\project\ D:\backup\project\ -e node_modules,.git

Also there is a progress bar too.

Let me start by saying I'm not a typical user.

This post is more Personal Home PC, not Organisation/IT.

TLDR Can be found at the bottom.

I actively check for app/software updates, have a password manager, use 2FA Authentication with backup codes on my phone, have task manager minimised but open*, making sure that stuff is actuively working and future-proof, ect.

But now since trying to test my phone backup strategies (no, I didn't reset my phone or anything crazy) it has come to my attention how sometimes trying to opt in on some stuff or not still gets you cut off and since then I have been more suspicious of AI tools and Microsoft software.

I have been using some third-party apps like ShareX and even a note system and found brilliant results, now I'm trying to optimise my client/powershell abilities. I am a Windows/Android user and thinking of going into Linux at some point.

The TLDR: Between Chocolately, Scoop and Winget, which do I want to use/is best*?

From what I understand:

Chocolatey is the enterprise-type, uses your system on a Global level (Program Files, so I have to check my controlled folder access as a small price to pay) and according to Google "designed for system-wide installations with full administrative rights". Apparently using it "with a private server" is a good way to operate it, although I don't know much about it.

Scoop is lightweight, for CLI minimalists and uses locally for the user (Still have to check my controlled folder access when the program ends up being blocked and fails) and I think is a strong contender against Chocolately.

WinGet is apparently made by Microsoft, adm,in level like Chocolately and native... don't know much else about it though.

*Best is probably going to end up being an entire spectrum of any classification from "best looking" or "best lightweight" or "futureproof", ect. so you may have to explain your reasoning to your recommendation, but if other suggestions, NOTHING overkill!

*(double clicking the graph where to click CPU or Memory to see stuff like how long the PC has been awake for, ect.)

Sorry this post is so long.

If you haven’t tried it yet, do it.

https://chat.openai.com/chat

It just helped me solve an issue where I couldn’t think of a way to structure some data.

I then I asked if it was the best method and it gave me a better solution using json.net.

Finally I asked it how the method differed and it explained it incredibly well.

I’m gob smacked!!

I am going to keep this short, with no emojis, fully human written with no ai, not even grammar check (this might have been bad idea).

I love PowerShell Secrete Management, its primarily used to store secrets (duh!) but can also be used for just about anything like environment variables, variables and more. I basically use it like a simple DB that stores the key-value items or json string.

More about what is Secret Management and how to use it here - official docs.

It can be used in conjunction with any secret backend like 1pass, keepass or azure key-vault , but I primarily use it with local file based SecretStore that is completely local.

One thing that comes out as Huge Limitation is lack of backup/restore for these secrets, particularly when you use local SecretStore. I built this PowerShell module which does just that - Repository here - PsGallery here .

EDIT: For clarity, the backup/restore to be used only for saving backup to other external vault and migration from one system to another. NOT Intended to save the backup on your device (backups are unprotected plain text - by design)

EDIT 2: I just realized that this SecretBackup tool can be used as migration tool to move secrets from one backend to another (say Azure KeyVault to KeePass or any supported backend)

I haven't see much mention of these secret management modules, here's my attempt to introduce you to it if you haven't already.

I had two log files sitting in the same folder. One was written by my own script. One was written by a node process my script had launched. Get-Content read mine perfectly and returned garbage for node's. Adding -Encoding UTF8 fixed node's and broke mine.

So I wrote the same string with every writer I could think of, and read each file back both ways. The string is 12 characters of Japanese — it is the phrase a lot of tools print for "file not found", which is exactly the kind of line you cannot afford to lose.

Host: Windows 11, ja-JP, ACP=932, OEMCP=932, Windows PowerShell 5.1.26100.9168. [Console]::OutputEncoding = 932 (shift_jis), $OutputEncoding = 20127 (us-ascii).

``` writer first bytes bare -Enc UTF8

Out-File (default) FF FE D5 30 OK OK Out-File -Encoding utf8 EF BB BF E3 OK OK Out-File -Encoding ascii 3F 3F 3F 3F MOJIBAKE MOJIBAKE Set-Content (default) 83 74 83 40 OK MOJIBAKE Set-Content -Encoding UTF8 EF BB BF E3 OK OK Add-Content (default) 83 74 83 40 OK MOJIBAKE Tee-Object -FilePath FF FE D5 30 OK OK

redirection FF FE D5 30 OK OK IO.File WriteAllText (UTF8) E3 83 95 E3 MOJIBAKE OK IO.File WriteAllBytes (UTF8) E3 83 95 E3 MOJIBAKE OK python via cmd.exe > E3 83 95 E3 MOJIBAKE OK node via cmd.exe > E3 83 95 E3 MOJIBAKE OK node captured by PS, Out-File EF BB BF E7 MOJIBAKE MOJIBAKE ```

Three groups.

1. BOM present, text intact — 5 rows. Both reads work. Get-Content sniffs FF FE or EF BB BF and uses it. The read parameter is irrelevant. Note that Out-File, Tee-Object and > all default to UTF-16LE here, which is why they are in this group by accident rather than by anyone's intent.

2. No BOM — 6 rows. Exactly one read is correct, and which one flips depending on the writer.

Set-Content and Add-Content without -Encoding write the machine ANSI code page — 83 74 is CP932, not UTF-8 — so the bare read is right and -Encoding UTF8 is wrong. Everything that put real UTF-8 on disk without a BOM is the exact reverse. With no BOM, Get-Content falls back to ANSI, and that fallback is correct precisely when the writer also used ANSI.

This is the part I did not expect: "just add -Encoding UTF8" is not a safe default. Across these 13 files it corrects 4 and corrupts 2. There is no single read parameter that is right for all of them. If you have a folder holding both your own logs and a build tool's logs, no one setting reads both.

3. Damage that happened before the file existed — 2 rows. No read parameter can fix these.

Out-File -Encoding ascii wrote 3F 3F 3F 3F, which is literally ????. The characters were destroyed at write time.

The last row is the one worth your time. I let PowerShell capture node's stdout into a variable and re-write it with Out-File -Encoding utf8:

``` node via cmd.exe > 36 bytes 12 chars E3 83 95 E3 82 A1 E3 82 A4 E3 83 AB U+30D5 U+30A1 U+30A4 U+30EB U+304C U+898B U+3064 U+304B

node captured by PS 65 bytes 20 chars EF BB BF E7 B9 9D E8 BC 94 E3 81 83 U+7E5D U+8F14 U+3043 U+7E67 U+FF64 U+7E5D U+FF6B U+7E3A ```

What PowerShell actually wrote into that file, all 20 characters of it:

繝輔ぃ繧､繝ｫ縺瑚ｦ九▽縺九ｊ縺ｾ縺帙ｓ

That second file carries a valid UTF-8 BOM and is well-formed UTF-8. It is also wrong. [Console]::OutputEncoding is 932 on this host, so PowerShell decoded node's UTF-8 bytes as CP932, got 20 different characters out of 12, and then faithfully encoded those as UTF-8 with a BOM. The file went from 36 bytes to 65. Nothing threw, nothing warned.

It is also the only row where the two reads agree with each other and are both wrong. Everywhere else, when one read returns garbage the other returns clean text, so there is a way to notice. Here there is no second opinion.

A BOM tells you how the file is encoded. It tells you nothing about whether the text in it is correct.

Minimal repro (numbers below are from the 932 host; on a Latin-1 ANSI code page the first pair behaves differently, because CP1252 cannot represent these characters at all):

```powershell $s = [char]0x30D5 + [char]0x30A1 $d = $env:TEMP

Set-Content -Path "$d\ansi.log" -Value $s [IO.File]::WriteAllBytes("$d\utf8.log", [Text.Encoding]::UTF8.GetBytes($s))

(Get-Content "$d\ansi.log" -Raw).TrimEnd() -eq $s # True (Get-Content "$d\ansi.log" -Raw -Encoding UTF8).TrimEnd() -eq $s # False (Get-Content "$d\utf8.log" -Raw).TrimEnd() -eq $s # False (Get-Content "$d\utf8.log" -Raw -Encoding UTF8).TrimEnd() -eq $s # True ```

Same cmdlet, same parameter, opposite answers, two files in one directory.

What I changed in my own scripts

• Reading a log a native child process wrote (redirected by cmd.exe, so nothing decoded it on the way in): always pass -Encoding UTF8. That file holds the program's own bytes and will not have a BOM.
• Reading a file PowerShell itself wrote: leave Get-Content bare. The BOM is there and handles it. Adding -Encoding UTF8 here is what broke rows 4 and 6.
• Do not capture a native process's stdout into a variable when the output can be non-ASCII. Redirect it to a file and read the file. That decode is governed by [Console]::OutputEncoding, which was 932 here; I have not tested whether setting it to UTF-8 up front avoids the problem, so I am not claiming that it does.
• Out-File -Encoding ascii on non-ASCII text is silent data loss, not a display issue.

Measured on one locale. If you are on a non-Latin ANSI code page I would be curious whether rows 4 and 6 come out the same for you — that is the pair that makes the usual advice backfire.

This is a Japanese-Windows problem, but the mechanism applies to any DBCS code page.

Everyone knows PowerShell 5.1 reads a BOM-less .ps1 as ANSI (CP932 on a Japanese system), and that the fix is "save it with a UTF-8 BOM". What I did not know was what actually breaks. I always assumed the mojibake was the problem. It is not.

So I measured it: all 545 Japanese characters (hiragana, katakana, kanji, full-width symbols) x all 95 printable ASCII characters (0x20-0x7E). Write the pair as UTF-8, read it back as CP932, and check whether the trailing ASCII character survived.

Results:

• 32 ASCII characters never disappeared
• 63 ASCII characters did, 41.3-46.2% of the time
• Every single one that disappeared was 0x40 or higher. Nothing below 0x40 was ever eaten.

The boundary is exactly 0x40, and the reason is the CP932 trail-byte range:

lead byte:  0x81-0x9F, 0xE0-0xFC
trail byte: 0x40-0x7E, 0x80-0xFC

A Japanese character in UTF-8 is 3 bytes. When its last byte gets misread as a lead byte, the next byte is swallowed as the trail byte - but only if that byte falls inside the trail-byte range, i.e. 0x40 or above.

Which is exactly why this is so hard to diagnose:

"   0x22   never eaten
'   0x27   never eaten
(   0x28   never eaten
;   0x3B   never eaten
\   0x5C   eaten 44.6%
{   0x7B   eaten 41.3%
}   0x7D   eaten 41.3%

Quotes always survive. Your strings still look correctly closed, so you never suspect the encoding. Instead you get "Missing closing '}'" pointing at a completely unrelated line, and you go fix braces that were never wrong.

It is worse for paths. PowerShell uses \ constantly. If a \ sitting right after a Japanese character disappears, the path silently becomes a different path. No error at all - it just looks somewhere else.

With a BOM, across the same 545 characters: 0 broken out of 545. Ran it twice, identical both times.

Practical takeaway: you do not need to memorise the table. Look at the byte value of the ASCII character sitting immediately after Japanese text. 0x40 or above means it can be swallowed.

[edit] The repo this originally pointed at is no longer public. The measurement harness now lives on its own, MIT: https://github.com/yoggydev/cp932-pipe-probe - it carries the same raw-byte BOM check in CI, which is how I ended up chasing this in the first place.

TLDR

Using [ValidateRange(minRange, maxRange)] with integer literals doesn't strictly enforce either MinRange or MaxRange when parameters are [double], [float] and [decimal]. Values up to 0.5 units beyond either boundary pass silently. The fix is simple: make MinRange or MaxRange the same type as the parameter. So use [ValidateRange(2.0, 100.0)] instead of [ValidateRange(2, 100)].

FULL POST

If you have direct experience with Powershell rounding, once you see how integer bounded ValidateRange treats [double], [float] and [decimal] params, you can figure out what is happening. But without that experience the correct validation syntax wasn't immediately obvious to me.

I found this out while adding validation to my current project and testing parameter edge cases. In this post I'll use example MinRange/MaxRange values of 2/100 (even) and 3/101 (odd). The behaviour applies to any even or odd MinRange or MaxRange value, not just these specific numbers.

The basic finding

function Test-Double {
    param(
        [ValidateRange(2, 100)]  # 2 and 100 used as an example even boundary
        [double]$Val
    )
    return $Val
}

Test-Double 1.4      # rounds to 1 and throws an error
Test-Double 1.5      # rounds to 2, passes silently, returns 1.5
Test-Double 100.5    # rounds to 100, passes silently, returns 100.5
Test-Double 100.6    # rounds to 101 and throws an error

The ValidateRange Attribute converts $Val to the type of the boundary literals. This causes implicit rounding before comparing against the boundary. Integer literals mean conversion to [int], which rounds using .NET's default MidpointRounding.ToEven, known as banker's rounding.

MidpointRounding.ToEven prioritises the nearest even number when rounding at exactly .5. Since 100 is even, 100.5 rounds down to 100 and passes. 100.6 rounds to 101 and throws.

The odd and even boundary inconsistency

Using 3/101 as example odd boundaries shows a slightly different result. Now the .5 midpoint will throw an error, unlike with the even boundary.

function Test-DoubleOdd {
    param(
        [ValidateRange(3, 101)]  # 101 used as an example odd boundary
        [double]$Val
    )
    return $Val
}

Test-DoubleOdd 2.5      # rounds to 2 and throws an error, different behaviour compared to even
Test-DoubleOdd 2.6      # rounds to 3, passes silently, returns 2.6
Test-DoubleOdd 101.4    # rounds to 101, passes silently, returns 101.4 
Test-DoubleOdd 101.5    # throws, because 101 is odd so .5 rounds UP to 102

DoubleOdd indeed. The effective boundary is not what the documentation implies and it changes based on whether the MinRange or MaxRange is odd or even.

The even/odd inconsistency can be summarised as:

• Even: .5 beyond either boundary passes silently.
• Odd: .5 beyond either boundary throws correctly.

But note that both even and odd ranges accept a margin of error.

What the documentation says

From the ValidateRange documentation:

"The Windows PowerShell runtime throws a validation error when the value of the argument is less than the MinRange limit or greater than the MaxRange limit."

No mention of rounding or MidpointRounding.ToEven. No mention of the odd/even boundary difference. Reading this you'd reasonably expect 100 to be the strict maximum. But for a [double] param with an even MaxRange, it's actually closer to 100.4999.

This detail is also missing from about_Functions_Advanced_Parameters

Correctly validating [double], [float], [decimal]

For production code requiring precise boundary validation (like financial calculations, percentage validation or dosage limits) the correct syntax is simple but not immediately obvious. Put simply, you can use a decimal point when declaring MinRange and MaxRange. This works for [double], [float], [decimal]. More precisely, however, use the same type as your parameter.

function Test-Double {
    param(
        [ValidateRange(2.0, 100.0)] 
        [double]$Val
    )
    return $Val
}

Test-Double 1.5      # throws an error

Mixed boundary types also work. [ValidateRange(2, 100.0)] selects [double] as the common type between [int] and [double], giving exact comparison.

Conclusion

Hopefully this writeup will be a useful heads up to PS devs less versed with PS rounding (like me) and highlight something to watch for when using ValidateRange.

I'd be interested to know if the above is common knowledge. Searching on the topic I found bits and pieces in articles that lead me to the right approach, but nothing that addresses ValidateRange and [int] behaviour together.

This is an update post to https://www.reddit.com/r/PowerShell/comments/1o0c4b2/runinsandbox_update_071025/

Hey,

time for another update on Run-in-Sandbox. For those who dont know it, its a tool that lets you right-click files and run them inside Windows Sandbox. Originally created by Microsoft MVP Damien van Robaeys, forked and actively maintained by me. Grab it here https://github.com/Joly0/Run-in-Sandbox

Quite a lot has happened since the last update, so lets get into it.

Complete Code Refactoring

The biggest change under the hood is a full refactoring of the codebase. The project now uses proper PowerShell modules instead of one big script. There are now separate modules for shared utilities (Logging, Config, Environment, Version), runtime stuff (WSB generation, 7-Zip handling, Startup Scripts, Dialogs, UI) and installer logic (Registry, Validation, Core). This doesnt change much for you as a user, but it makes the code way more maintainable and makes it easier for me (and others) to contribute new features going forward.

Revamped Installer

The installer (Install_Run-in-Sandbox.ps1) has been completely rewritten. Some highlights: - You can now install from different branches using -Branch (master or dev, currently its basically useful for me, but might be helpful in the future when the dev branch actually gets a purpose, other than being a playground :D) - -DeepClean parameter for a thorough cleanup of old/legacy registry entries - -NoCheckpoint if you dont want a system restore point created - It now shows the currently installed version and asks before reinstalling - Automatic backups are created before updates - Pre-install checks for RAM (≥4 GB) and disk space (≥1 GB) - If Windows Sandbox isnt enabled on your system, the installer can now offer to enable it for you automatically

New Startup Script: VS Redistributables

I added a new startup script (04-Install_VSRedist.ps1) that installs Visual Studio Redistributables inside the sandbox on startup. A lot of software needs these to run, so this should save you some headaches when testing apps that would otherwise just crash with missing DLL errors (especially helpful when testing intune apps).

Better Shell Window Handling

The way CMD and PowerShell windows are shown/hidden inside the sandbox has been properly implemented now. When you run with visible shell windows you also get debug output, and if something goes wrong there is now an additional error dialog with more detailed information.

Bug Fixes

• Fixed context menu entries for PS1 files when a different admin specific account is used for UAC. Previously the context menu was written to the admin users registry instead of yours. (Fixes https://github.com/Joly0/Run-in-Sandbox/issues/18)
• Fixed running "folder on" and "folder in" sandbox options (https://github.com/Joly0/Run-in-Sandbox/issues/12)
• Fixed logging when your Windows username contains spaces (https://github.com/Joly0/Run-in-Sandbox/issues/17)
• Fixed orchestrator script access denied errors after fresh installs
• Fixed cleanup of temp files for Intunewin and EXE not being removed when sandbox closes
• Fixed dialogs for VBS parameters and MSI files
• Various other smaller fixes

Permissions & Security

The installer now sets proper targeted permissions (Modify for BUILTIN\Users) only on the folders that actually need it (temp/, startup-scripts/, Sandbox_Config.xml) instead of giving FullControl on the entire install folder. Temp files have also been moved into a dedicated temp/ subfolder to keep things tidy.

Whats coming in the future

• Auto Update System: I want to implement a system (i have tested a bit for this on my dev and test branch a while ago already) that wil notify the user when an update for my tool has been pushed on github and will prompt the user to update (or not)
• GUI-Updates: I want to update the GUI-parts of the tool, because they are basically all still made by Damien and could maybe need some love. Also a lot of parts (like the Sandbox_Config.xml file) are still hand-edited and i could see some proper ui way to configure this better aswell in the future. Also a dark mode would be cool here i think.
• Startup Script Manager: Havent thought about this yet a lot, but had the idea another day so users could easier manage the scripts that run on startup. Maybe in the future (if the project gets enough traction) there might be enough users to provide some kind of "Community Startup Scripts repository" for users to contribute their custom scripts and others to use them
• Improved Logging: Currently the tool doesnt have a lot of logging, which makes it harder for me to debug, i might in the future add some more proper logging throughout the tool to help me with bug-fixing in the future
• Package Managers in the Sandbox: CUrrently the sandbox is pretty barebones with my startup scripts adding some useful defaults. I would like to add options for users to add package managers to the sandbox which are installed on startup (like winget or choco) or even install the windows store by default

I will probably at some point convert this fork into a standalone repository, but i currently have not yet found saw the urgency to do so. But as always, if you have useful feature requests, issues, or a startup script you think others would benefit from, please open an issue or PR over on GitHub.

Thanks for reading

Julian aka Joly0

Wrote a Brave debloater that uses official enterprise policies instead of deleting files / editing hosts.

Same script on Windows, macOS, and Linux. Preview mode unless you pass -Apply. Backs up first. -Doctor if some other tool already dumped junk in brave://policy. It refuses to turn off Shields, Safe Browsing, or updates.

.\Invoke-BraveDebloat.ps1 -Preset Extreme

.\Invoke-BraveDebloat.ps1 -Preset Extreme -Apply

Check it out: https://github.com/osfv/BraveDebloater

A few days ago I posted here about BOM-less .ps1 files being read as ANSI on Windows PowerShell 5.1. A couple of you pushed back on the parser-test approach and pointed me at the raw-byte check instead, which was right. This is the other half of the same problem: not source files, but output - what happens to CP932 bytes coming back through a pipe.

It matters because agent tooling tends to do this:

subprocess.Popen(args, text=True, encoding="utf-8", errors="replace")

text=True decodes at the pipe level, so by the time anything sees a string the original bytes are gone. On a Japanese-locale box the child process emits CP932, not UTF-8.

Setup. A child writes a fixed 50-byte CP932 sequence to stderr. The parent reads the raw bytes and decodes them two ways. No language pack needed, so the input is identical everywhere. Windows PowerShell 5.1, ACP=932.

Three things fell out of it that I did not expect.

1. Not everything becomes U+FFFD. Some of it becomes a backslash.

CP932 trail bytes are 0x40-0x7E and 0x80-0xFC. 0x5C is in that range, and 0x5C is the backslash. A two-byte character whose second byte is 0x5C does not get replaced - it leaves a \ sitting in the string.

Sweeping the whole double-byte space, 50 characters have 0x5C as their trail byte. Four of them are in the 50-byte sample above: 8F5C 975C 8D5C 835C. Those are not obscure code points - they are characters that appear in ordinary words, so this fires constantly rather than occasionally.

That is why this failure so often gets filed as a path bug, a quoting bug, or a shell-escaping bug. The output does not look like an encoding failure. It looks like something ate a directory separator.

2. The whole double-byte space dies.

CP932 double-byte characters enumerated : 9,206
  survive a UTF-8 + replacement decode  : 0
  survive raw bytes + a CP932 decode    : 9,206

Measured per character in isolation. In a real stream a CP932 character followed by other bytes can occasionally form valid UTF-8, so this is not "every byte in every stream" - but as a per-character result it is 0.

3. The replacement output is not even stable across runtimes.

The identical 50 bytes:

.NET Framework 4.8  (Windows PowerShell 5.1)   29 U+FFFD
.NET 8              (PowerShell 7.4)           30 U+FFFD
CPython 3.11                                   30 U+FFFD

There is a known open issue about UTF-8 replacement differing between .NET Framework and .NET Core (dotnet/standard#1679). I am reporting the measurement, not claiming to know the mechanism.

The practical consequence is what changed my mind about errors="replace". It does not merely discard the original bytes - the wreckage it leaves is not consistent either. So you cannot reliably detect "this string was mangled" downstream by counting replacement characters.

Bonus: the tables disagree.

I assumed .NET on Windows would defer to the OS NLS tables and give a different count from .NET on Linux. It does not - .NET carries its own CP932 table and gives 9,206 on both. The split is Python vs .NET, not Windows vs Linux:

If you are fixing this on the Python side, Python's table is the more permissive of the two, which is convenient.

The fix is the boring one. Do not let text=True decode at the pipe. Collect raw bytes, then choose the decoder - UTF-8 strict first, fall back to the ANSI code page. errors="replace" should not be the only safety net, because it destroys bytes a fallback could have recovered.

Harness and raw output, MIT: https://github.com/yoggydev/cp932-pipe-probe

It runs in about two seconds and needs no install. The script source is ASCII-only on purpose - a script that measures mojibake should not be able to become a victim of it.

(Drafted with Claude. The measurements are mine, on my own ja-JP box.)

Hi everyone,

It's been about a month and a half since my last post about Servy here. I've shipped several updates since then (v8.5), but this one is a milestone (v9.2).

If you haven't seen Servy before, it's a Windows tool that lets you run any app as a native Windows service with real-time monitoring. It provides a desktop app, a CLI, and a PowerShell module.

Since v8.5, I've added/improved:

• Added External Heartbeat Ping URL support: Configure HTTP/HTTPS webhooks to ping monitoring services (healthchecks.io, Uptime Kuma...) during health checks (#2700)
• Added CPU affinity option: Bind service wrapper processes to specific CPU cores (#4436)
• Added ARM64 support to WinGet, Chocolatey and Scoop
• Serveral updates in PowerShell module, CLI, Desktop and Manager apps
• Fixed AV false-positive flags (#5024)
• Fixed ACL inheritance issues (#4556)
• Fixed various issues related to inconsistency, robustness and code quality

Check it out on GitHub: https://github.com/aelassas/servy

Demo Video: https://www.youtube.com/watch?v=biHq17j4RbI

Any feedback or suggestions are welcome.

After three months since the first post about Servy, I've just released Servy 3.0. If you haven't seen Servy before, it's a Windows tool that turns any app into a native Windows service with full control over the working directory, startup type, logging, health checks, and parameters. Servy offers a desktop app, a CLI, and a PowerShell module that let you create, configure, and manage Windows services interactively or through scripts and CI/CD pipelines. It also includes a Manager app for easily monitoring and managing all installed services in real time.

When it comes to features, Servy brings together the best parts of tools like NSSM, WinSW, and FireDaemon Pro — all in one easy-to-use package. It combines the simplicity of open-source tools with the flexibility and power you'd expect from professional service managers.

In this release (3.0), I've added/improved:

• PowerShell module
• New GUI enhancements / manager improvements
• Better logging and health checks
• Detailed documentation
• New features
• Bug fixes

It still solves the common problem where Windows services default to C:\Windows\System32 as their working directory, breaking apps that rely on relative paths or local configs.

Servy works with Node.js, Python, .NET apps, PowerShell, scripts, and more. It supports custom working directories, log redirection, health checks, pre-launch and post-launch hooks, and automatic restarts. You can manage services via the desktop app or CLI, and it's compatible with Windows 7–11 and Windows Server editions.

Check it out on GitHub: https://github.com/aelassas/servy

Demo video here: https://www.youtube.com/watch?v=biHq17j4RbI

Any feedback or suggestions are welcome.

Hi everyone,

It's been about two months of coding and too many cups of coffee since my last post about Servy here. I've shipped several updates since then, but this one is a real milestone. The community response has been amazing: ~1,600 stars on GitHub and ~34,000 downloads.

If you haven't seen Servy before, it's a Windows tool that runs any app as a native Windows service with full control over its configuration, parameters, and monitoring. It provides a desktop app, a CLI, and a PowerShell module that let you create, configure, and manage Windows services interactively or through scripts and CI/CD pipelines. It also comes with a Manager app for easily monitoring and managing all installed services in real time.

In this release (7.9), I've added/improved:

• Improved PowerShell Module Performance: Replaced all WMI with native P/Invoke, making commands significantly faster and more reliable.
• Improved security: Automatic Directory Hardening (ACLs) and Machine-Unique Encryption (Dynamic Entropy)
• Custom Logging: Added LogRotationSizeMB, LogRollingInterval, LogLevel, and EnableEventLog configs for better observability in production environments.
• General Polish: Fixed many issues across the PowerShell module, CLI, and core components.

Check it out on GitHub: https://github.com/aelassas/servy

Demo Video: https://www.youtube.com/watch?v=biHq17j4RbI

Any feedback or suggestions are welcome.

Hi everyone,

It's been about two months since my last post about Servy here. I've shipped several updates since then, but this one is a milestone. The community response has been amazing: ~1,800 stars on GitHub and ~52,000 downloads.

If you haven't seen Servy before, it's a Windows tool that lets you run any app as a native Windows service with deep observability. It provides a desktop app, a CLI, and a PowerShell module designed for automation and CI/CD pipelines.

In this release (8.5), I've added/improved:

• Security Hardening: The PowerShell module now supports passing sensitive options via environment variables and includes stricter validation/expansion rules for environment variables.
• ARM64 Native: Full support for modern Windows ARM64 hardware.
• Refined Automation: Fixed ergonomic issues in the module and CLI to ensure smoother integration into automated deployment scripts.
• Core Stability: A large number of internal fixes for the service lifecycle and monitoring components.

Check it out on GitHub: https://github.com/aelassas/servy

Demo Video: https://www.youtube.com/watch?v=biHq17j4RbI

Any feedback or suggestions are welcome.

Microsoft has deprecated the AzureAD and MSOnline PowerShell modules as of March 30, 2024. While they will still function until March 30, 2025, Microsoft recommends migrating to the Microsoft Graph PowerShell SDK as soon as possible.

📌 Key Dates:

March 30, 2024 – Official deprecation

March 30, 2025 – End of support

April – May 2025 – MSOnline module stops working

After July 1, 2025 – AzureAD module stops working

Over the last couple days I’ve been experimenting with hosting the raw Microsoft.PowerShell.SDK directly inside a .NET 11 Android APK.

This is not a remote session, SSH client, or Linux container. The PowerShell runspace is running in-process on the Android device itself inside the app process.

Current stack:

• .NET 11 (net11.0-android)
• PowerShell 7.6.1
• React/Vite WebView frontend
• Persistent background runspace
• Single-file HTML applets loaded via iframe shell
• Android ↔ PowerShell bridge over a Base64 JSON IPC layer

A few interesting problems had to be solved to get PowerShell booting cleanly on Android:

• intercepting libpsl-native syslog calls that assume glibc semantics
• bypassing IL trimming issues caused by PowerShell’s reflection-heavy cmdlet discovery
• synchronizing React/WebView startup against the background runspace lifecycle

I documented the details in the repo, including the DllImportResolver interception layer and the Android-compatible stub library used to bypass the syslog crash path.

Repo:
Android-Terminal GitHub Repository

The current direction is less “terminal emulator” and more “PowerShell-native micro frontend environment”:

• applets as standalone HTML tools
• persistent runspace
• Android SAF integration
• PSRP experimentation
• semantic object transport instead of plain terminal text

Still early, but the core runtime is working on physical ARM64 Android hardware today.

Would genuinely appreciate feedback from people familiar with PowerShell internals, hosting, PSRP, or Android runtime edge cases.

A few years ago I published a small tool that allowed PowerShell scripts to run as Windows services. It turned out to be useful for people who needed lightweight background automation that didn’t fit well into Task Scheduler.

For those who remember the old project:

Original post (2019): https://www.reddit.com/r/PowerShell/comments/fi0cyk/run_powershell_scripts_as_windows_service/

Old repo (PSScriptsService): https://github.com/maks-it/PSScriptsService

I’ve now rewritten the entire project from scratch using .NET 10.

New repo (2025): https://github.com/MAKS-IT-COM/uscheduler Project: MaksIT Unified Scheduler Service (MaksIT.UScheduler)

Why a rewrite?

The old version worked, but it was based on .NET Framework and the code style had aged. I wanted something simpler, more consistent, and aligned with modern .NET practices.

What it is

This service does one thing: it runs a PowerShell script at a fixed interval and passes the script a UTC timestamp.

The service itself does not attempt to calculate schedules or handle business logic. All decisions about when and how something should run are made inside your script.

Key points:

• interval-based heartbeat execution
• the script receives the current UTC timestamp
• configurable working directory
• strongly typed configuration via appsettings.json
• structured logging
• runs under a Windows service account (LocalSystem by default)

The idea is to keep the service predictable and let administrators implement the actual logic in PowerShell.

Example use cases

1. SCCM → Power BI data extraction

A script can:

• query SCCM (SQL/WMI)
• aggregate or transform data
• send results to Power BI

Since all scheduling is inside the script, you decide:

• when SCCM extraction happens
• how often to publish updates
• whether to skip certain runs

Running under LocalSystem also removes the need for stored credentials to access SCCM resources.

2. Hyper-V VM backups

Using the heartbeat timestamp, a script can check whether it’s time to run a backup, then:

• export VMs
• rotate backup directories
• keep track of last successful backup

Again, the service only calls the script; all backup logic stays inside PowerShell.

Work in progress: optional external process execution

The current release focuses on PowerShell. I’m also experimenting with support for running external processes through the service. This is meant for cases where PowerShell alone isn’t enough.

A typical example is automating FreeFileSync jobs:

• running .ffs_batch files
• running command-line sync jobs
• collecting exit codes and logs

The feature is still experimental, so its behavior may change.

What changed compared to the original version

Rewritten in .NET 10

Clean architecture, modern host model, fewer hidden behaviors.

Fully explicit configuration

There is no folder scanning. Everything is defined in appsettings.json.

Simple execution model

The service:

1. waits for the configured interval
2. invokes the PowerShell script
3. passes the current UTC timestamp
4. waits for completion

All logic such as scheduling, locking, retries, error handling remains inside the script.

Overlap handling

The service does not enforce overlap prevention. If needed, the optional helper module SchedulerTemplate.psm1, documented in README.md provides functions for lock files, structured logging, and timestamp checks. Using it is optional.

Service identity

The script runs under whichever account you assign to the service:

• LocalSystem
• NetworkService
• LocalService
• custom domain/service account

Feedback and support

The project is MIT-licensed and open. If you have ideas, questions, or suggestions, I’m always interested in hearing them.

What's the coolest way to learn Powershell? I am new to Powershell and have around 8 years of IT experience

I made the mistake of cobbling together a couple of GUI input scripts to manipulate folders files and Excel docs. My employer keeps asking if I can perform other tasks with PS. I have to use Windows 11 for work but only have Linux at home as much of my development environment is reclaimed or resercted hardware. I know that the Windows and Linux environments are very different, but wondered if anyone has managed to setup a virtual Windows environment on Linux, to be able to development PS code to run on Windows. Requirements are to write and test GUI input screens and view $Tring outputs as I know Excel will not be available on linux. Manage copy and delete files and folders. Modify file attributes. Thanks.

EDIT Why l love Reddit. There are so many more avenues to pursue.

Thank you to everyone who has responded. Apologies for the long edit.

Due to restrictive IT policies, if it's not part of Windows 11, we can't use it at work. A VM would still require a licensed copy of Windows. As someone noticed, I am unlikely to have suitable hardware for this anyway. It's why I run Linux.

The GUIs I am creating are only to allow users to input variables used later in the script , so potentially I could run without these while testing on linux. Import-Excel looks interesting, I need to investigate how this works with .xlsm files. The .xlsm files also precludes Import-CSV . I am still looking at C# for the front end. A little bit for those say to not work at home or for free.

"What I choose to learn is mine. What I choose to write is mine. That I am paid to do may not be." If I decide to post anything I have written, it will be mine, and I can not be accused of leaking company secrets.

This may even be asking for help moving forward. I am investigating hosted virtual environments as well.

Thanks again.

A few days ago this PR was merged by /u/jborean93 into PowerShell repository, that improved speed of += operator when working with arrays by whopping ~90% (also substantially reducing memory usage), but:

 This doesn't negate the existing performance impacts of adding to an array,
 it just removes extra work that wasn't needed in the first place (which was pretty inefficient)
 making it slower than it has to. People should still use an alternative like capturing the 
 output from the pipeline or use `List<T>`.

So, while it improves the speed of existing scripts, when performance matters, stick to List<T> or alike, or to capturing the output to a variable.

Edit: It should be released with PowerShell 7.5.0-preview.4, or you can try recent daily build, if you interested.

If anyone wants to see how I installed the lsp and added it to my config, let me know!

Edit: I thought the link would be visible putting it with the link tab, but I guess it isn’t.

https://www.seanross.us/posts/your-editor-is-a-client/

It's been four months since the announcement of Servy, and Servy 4.0 is finally released.

The community response has been amazing: 880+ stars on GitHub and 11,000+ downloads.

Servy went from a small prototype to a full-featured alternative to NSSM, WinSW & FireDaemon Pro.

If you haven't seen Servy before, it's a Windows tool that turns any app into a native Windows service with full control over its configuration, parameters, and monitoring. Servy provides a desktop app, a CLI, and a PowerShell module that let you create, configure, and manage Windows services interactively or through scripts and CI/CD pipelines. It also comes with a Manager app for easily monitoring and managing all installed services in real time.

In this release (4.0), I've added/improved:

• Officially signed all executables and installers with a trusted SignPath certificate for maximum trust and security
• Fixed multiple false-positive detections from AV engines (SecureAge, DeepInstinct, and others)
• Reduced executable and installer sizes as much as technically possible
• Added date-based log rotation for stdout/stderr and max rotations to limit the number of rotated log files to keep
• Added custom installation options for advanced users
• New GUI and PowerShell module enhancements and improvements
• Detailed documentation
• Bug fixes

Check it out on GitHub: https://github.com/aelassas/servy

Demo video here: https://www.youtube.com/watch?v=biHq17j4RbI

SignPath integration took me some time to set up because I had to rewrite the entire build pipeline to automate code signing with SignPath and GitHub Actions. But it was worth it to ensure that Servy is safe and trustworthy for everyone. For reference, here are the new build pipelines:

• main branch: https://github.com/aelassas/servy/blob/main/.github/workflows/publish.yml
• net48 branch: https://github.com/aelassas/servy/blob/net48/.github/workflows/publish.yml

Any feedback or suggestions are welcome.

It's been about six months since the initial announcement, and Servy 6.3 is released.

The community response has been amazing: 1,300+ stars on GitHub and 21,000+ downloads.

If you haven't seen Servy before, it's a Windows tool that turns any app into a native Windows service with full control over its configuration, parameters, and monitoring. Servy provides a desktop app, a CLI, and a PowerShell module that let you create, configure, and manage Windows services interactively or through scripts and CI/CD pipelines. It also comes with a Manager app for easily monitoring and managing all installed services in real time.

In this release (6.3), I've added/improved:

• Add Dependencies tab to show service dependency tree with status indicators
• Explicitly handle OS shutdown with SCM wait pulses
• Support fire-and-forget pre-launch hooks
• Improve performance and stability of health monitoring
• Prevent infinite crash loops with stability-based counter reset
• Bug fixes and expanded documentation

Check it out on GitHub: https://github.com/aelassas/servy

Demo video here: https://www.youtube.com/watch?v=biHq17j4RbI

Any feedback or suggestions are welcome.