@x509
I don't understand your post as you quoted only the 'keep in mind ...'
Did you want to quote the whole OAT's post?
which can be resumed by the second sentence:
"However, your script is not adapted to the target audience; the end user."
With the new version of the project, I think it is now adapted to everyone ?
(Except for users that want/prefer a GUI)
I also made a short usage note at the top of WindowsMize.ps1
Code:
#==============================================================================
# Usage
#==============================================================================
#region usage
<#
To don't run a function, comment it (i.e. Add the "#" character before it).
e.g. #Disable-PowerShellTelemetry
To run a function, uncomment it (i.e. Remove the "#" character before it).
e.g. Disable-PowerShellTelemetry
Mostly all functions have a '-State' and/or '-GPO' parameters.
Example:
# Bing Search in Start Menu
#---------------------------------------
# State: Disabled | Enabled (default)
# GPO: Disabled | NotConfigured
Set-StartMenuBingSearch -State 'Disabled' -GPO 'Disabled'
The 2 comments below the title are the accepted values for the parameters.
Change the parameters value according to your preferences.
e.g.
Set-StartMenuBingSearch -State 'Enabled' -GPO 'NotConfigured'
#>
#endregion usage
It's minimal but clear enought in my opinion.
It is not enought ?
More feedback to improve the user experience:
1. Don't refer to "PowerShell Core", instead use the friendly name PowerShell 7.
2. Add "--accept-package-agreements --accept-source-agreements" to the winget command line.
3. Write a short batch file which does GitHub steps 2-6 for the squeamish. You want to keep the original explanations for transparency, but then allow casual users to just "run this batch as Admin after you've extracted the ZIP file".
No I wanted to +1 the point about comments not being meant as criticism.
The various comments in this group are about people who want to help you to improve upon and make more useful to a broader audience your work on this script. A ginormous effort, to quote myself.
There is also other files to automate Photos, Snipping Tool and Notepad.
Could a moderator please edit the first post of this thread with the following content.
It would be really appreciated.
Code:
[CENTER][IMG width="80%"]https://raw.githubusercontent.com/agadiffe/WindowsMize/main/img/WindowsMizeHeader.png[/IMG]
[B]Automate and customize the configuration of Windows.
Debloat, minimize telemetry, apps installation, general settings, and more.[/B][/CENTER]
Hi everyone.
I would like to share with you the PowerShell script I made to automate the configuration of Windows.
It's not just about debloating Windows and minimizing telemetry.
It's also about automating every settings (in a reasonable way :)).
None of the available online scripts met my expectations, so I created my own.
[HEADING=2]🎯 Purpose[/HEADING]
[LIST=1]
[*] Install Windows (semi-unattended) + updates.
[*] Run the script.
[*] Finish some customization.
[/LIST]
[HEADING=2]📝 Characteristics[/HEADING]
[LIST]
[*] Fully non-interactive script: make sure to review everything before running it.
[*] Designed for Windows 11 (most tweaks/settings also work on Windows 10).
[*] Works on both Administrator and Standard account.
[/LIST]
[HEADING=2]💫 Features[/HEADING]
[LIST]
[*] 🖥️ Windows settings
[*] 📁 File Explorer
[*] ⌛ System Properties
[*] ⚡ Power options
[*] 🌐 Network
[*] 📊 Telemetry
[*] 🛠️ Tweaks
[*] 💿 Applications
[*] 💾 RamDisk
[*] ⚙️ Services & Scheduled Tasks
[/LIST]
See the Github README for the detailed list of all tweaks/settings.
[HEADING=2]📌 Link[/HEADING]
https://github.com/agadiffe/WindowsMize
There is also other files to automate Photos, Snipping Tool and Notepad.
Could a moderator please edit the first post of this thread with the following content.
It would be really appreciated.
Code:
[CENTER][IMG width="80%"]https://raw.githubusercontent.com/agadiffe/WindowsMize/main/img/WindowsMizeHeader.png[/IMG]
[B]Automate and customize the configuration of Windows.
Debloat, minimize telemetry, apps installation, general settings, and more.[/B][/CENTER]
Hi everyone.
I would like to share with you the PowerShell script I made to automate the configuration of Windows.
It's not just about debloating Windows and minimizing telemetry.
It's also about automating every settings (in a reasonable way :)).
None of the available online scripts met my expectations, so I created my own.
[HEADING=2]🎯 Purpose[/HEADING]
[LIST=1]
[*] Install Windows (semi-unattended) + updates.
[*] Run the script.
[*] Finish some customization.
[/LIST]
[HEADING=2]📝 Characteristics[/HEADING]
[LIST]
[*] Fully non-interactive script: make sure to review everything before running it.
[*] Designed for Windows 11 (most tweaks/settings also work on Windows 10).
[*] Works on both Administrator and Standard account.
[/LIST]
[HEADING=2]💫 Features[/HEADING]
[LIST]
[*] 🖥️ Windows settings
[*] 📁 File Explorer
[*] ⌛ System Properties
[*] ⚡ Power options
[*] 🌐 Network
[*] 📊 Telemetry
[*] 🛠️ Tweaks
[*] 💿 Applications
[*] 💾 RamDisk
[*] ⚙️ Services & Scheduled Tasks
[/LIST]
See the Github README for the detailed list of all tweaks/settings.
[HEADING=2]📌 Link[/HEADING]
https://github.com/agadiffe/WindowsMize
What's the first Set-UwpAppSetting.ps1 script for? Can you list its functionalities? A clear README/instruction file would be appreciated.
and for 2nd Set-MicrosoftStoreSetting.ps1,
I am actually looking for MS store settings to import/add/integrate inside Windows ISO (WIM) with the help of NTLite, to automate windows installation process, so let me know, how to use this script you share in that context.
Set-UwpAppSetting.ps1 contains the main function to customize UWP app settings.
It stop the app (if running), creates a temporary .reg file, load settings.dat into the regedit, import the settings (the .reg file), and unload settings.dat.
example:
Code:
# on: 1 (default) | off: 0
$VideoAutoplayReg = @{
Name = 'VideoAutoplay'
Value = '0'
Type = '5f5e10b'
}
Set-UwpAppSetting -Name 'MicrosoftStore' -Setting $VideoAutoplayReg
You can use the already existing functions (e.g. Set-MicrosoftStoreSetting) to customize the UWP apps.
I've never used NTLite, but I think there is a section like "run script once on first-logon", or something.
You can use the entire script or extract only the functions you need and make a single .ps1 file.
If you prefer the one file method, here are the functions:
This is only for MS Store, if you need other apps settings, copy/paste their related functions as well.
These functions requires Powershell 7 that you must install before running the script.
If you perform an offline installation, you need to incorporate the .msi installer into your ISO. Releases · PowerShell/PowerShell: e.g. PowerShell-7.5.3-win-x64.msi
My script have the same timing-related problem if you use NTLite.
If settings.dat doesn't exist, it will do nothing.
To solve this problem, I've added (only in this post) the Test-UWPAppFilePath function to test if the file exist.
e.g. Test-UWPAppFilePath -Name 'MicrosoftStore' -Timeout 30
The timeout is in seconds.
30 seconds should be enought. Increase it if it doesn't work.
Originally I've tagged you to give you the names of the registry keys ^^.
But here you are, the code inside the spoiler tag should accomplish what you want.
Don't forget to install Powershell 7 and run the script with pwsh.exe (not with powershell.exe).
@Brink
Do you have 1 min to update the OP please ?
The new content is in the spoiler tag at the end of the post 27.
The part of your script code that gets the user name and SID can be simplified somewhat.
Powershell:
try {
$userName = [Environment]::UserName
if ($userName) {
Write-Host "Current User Name: $userName"
$userSID = [System.Security.Principal.NTAccount]::New($userName).Translate([System.Security.Principal.SecurityIdentifier]).Value
if ($userSID) {
Write-Host "Current User SID: $userSID"
} else {
Write-Error "Error: failed to get the Current User SID"
}
} else {
Write-Error "Error: failed to get the Current User Name"
}
} catch {
Write-Error $_.Exception.Message
}
[Environment]::UserName cannot be used, because if you run the script on a standard account within an elevated powershell, it will return the username of the admin's account.
The same applies if you run the script as NT AUTHORITY\SYSTEM, you will get the wrong username.
And not only the username, you will get all the properties of the Admin's account.
- HKEY_CURRENT_USER' will point to the Admin's HIVE.
- 'Environment variables' & 'Shell Folders paths' are the Admin's values.
etc...
I don't know if it is better or not than (Get-LocalUser -Name (Get-LoggedOnUserUsername)).SID.Value
First method use .Net method and the second pure Powershell.
I added it to my notes to do more research about that.
Thank you for your feedback. It's always interesting to see others code.
If a standard user launches PowerShell and clicks “Yes” on a UAC prompt to run as admin, the process runs elevated.
However, [Environment]::UserName still returns the standard user’s name, because the environment block is inherited from the launching user.
To get the actual security context (i.e., the account under which the process is running), use: [System.Security.Principal.WindowsIdentity]::GetCurrent().Name
The $env:UserName environment variable could potentially be overwritten before your Get-LoggedOnUserUsername returns its value. (E.g., with $env:UserName = "FakeUser".) This variable reflects the launching context, not necessarily the execution context. It is static—it doesn’t update if the process impersonates another user or switches tokens. [System.Security.Principal.WindowsIdentity]::GetCurrent().Name is far more resilient—it queries the actual token of the running thread, and, that’s what matters in elevated, impersonated, or sandboxed scenarios.
Get-LocalUser only works for local accounts—not domain users. (Get-LocalUser -Name (Get-LoggedOnUserUsername)).SID.Value breaks in domain environments, remote sessions, or elevated contexts where the user isn’t a local account.
You can leave out the excess error handling if that's what you want. PowerShell is based entirely on .NET so, there exists no such thing as "pure PowerShell".
P.S., here is a good explanation of the difference between $env:UserName and [Environment]::UserName.
What is the difference between PowerShell's $env:username and [environment]::username and why would they potentially return different users? (I understand there are other ways to get the current u...
stackoverflow.com
P.P.S., if you want to know who launched the elevated script, use:
This gives you the actual originator of the PowerShell process—domain or local, elevated or not.
Your Get-LoggedOnUserUsername works only if someone is interactively logged in. It fails in:
Remote sessions
Headless servers
Multi-user environments
Fast User Switching
Also, it assumes the returned name is a local account, which leads to the next fragility. I.e., your Get-LoggedOnUserSIDonly works for local accounts. If the user is domain-joined, this throws. Also, it assumes the username from WMI matches a local account name—which is not guaranteed. Your Get-LoggedOnUserEnvVariable uses a path that is invalid if the SID resolution failed (e.g., domain user), and, registry hives may not be loaded for non-interactive users. I don't know if any of these problems/limitations could potentially affect the reliability of your script, as I haven't looked at it beyond this trio of functions you wrote, which is clever in intent but fragile in execution. It tries to reconstruct the logged-on user's identity and environment by querying WMI, local user SID, and registry paths. However, it’s built on assumptions that don’t hold in elevated or domain contexts.
If a standard user launches PowerShell and clicks “Yes” on a UAC prompt to run as admin, the process runs elevated.
However, [Environment]::UserName still returns the standard user’s name, because the environment block is inherited from the launching user.
To get the actual security context (i.e., the account under which the process is running), use: [System.Security.Principal.WindowsIdentity]::GetCurrent().Name
The $env:UserName environment variable could potentially be overwritten before your Get-LoggedOnUserUsername returns its value. (E.g., with $env:UserName = "FakeUser".) This variable reflects the launching context, not necessarily the execution context. It is static—it doesn’t update if the process impersonates another user or switches tokens. [System.Security.Principal.WindowsIdentity]::GetCurrent().Name is far more resilient—it queries the actual token of the running thread, and, that’s what matters in elevated, impersonated, or sandboxed scenarios.
I already tried all of these methods before making my function.
For the overwrite of $env:UserName, it's not a problem as I don't use it.
On my VM, User is the admin account, Standard_test is (spoiler xd) a standard account.
When logged-in with the standard account, on an elevated Powershell session:
Get-LocalUser only works for local accounts—not domain users. (Get-LocalUser -Name (Get-LoggedOnUserUsername)).SID.Value breaks in domain environments, remote sessions, or elevated contexts where the user isn’t a local account.
ForEach-Object: Method invocation failed because [Deserialized.System.Management.ManagementObject#root\cimv2\Win32_Process] does not contain a method named 'GetOwner'.
Already tried this method, it doesn't retrieve the correct username either.
I made extensive searches before picking that solution, but maybe not enough.
It's the only one (or the PID explorer + GetOwner) that works with a standard account on an elevated Powershell session.
I will run some tests regarding the remote session with a non-interactively logged-in user.
The script wasn't intended for this use case, but it would be great if it works.
Also, it assumes the returned name is a local account, which leads to the next fragility. I.e., your Get-LoggedOnUserSIDonly works for local accounts. If the user is domain-joined, this throws. Also, it assumes the username from WMI matches a local account name—which is not guaranteed. Your Get-LoggedOnUserEnvVariable uses a path that is invalid if the SID resolution failed (e.g., domain user),
I guess that this part will be fixed with the use of the [System.Security.Principal.NTAccount] class.
If SID retrieval fails, nothing will work. ^^
Because I use $UserSID = Get-LoggedOnUserSID in the Set-RegistryEntry function to make it work on standard account.
It does work in an elevated context, I tested it with a standard account on an elevated Powershell session. oO
When you say "that don’t hold in elevated or domain contexts", I suppose it is only in a non-interactive context, right (assuming the SID is fixed) ?
Set-UwpAppSetting.ps1 contains the main function to customize UWP app settings.
It stop the app (if running), creates a temporary .reg file, load settings.dat into the regedit, import the settings (the .reg file), and unload settings.dat.
example:
Code:
# on: 1 (default) | off: 0
$VideoAutoplayReg = @{
Name = 'VideoAutoplay'
Value = '0'
Type = '5f5e10b'
}
Set-UwpAppSetting -Name 'MicrosoftStore' -Setting $VideoAutoplayReg
You can use the already existing functions (e.g. Set-MicrosoftStoreSetting) to customize the UWP apps.
I've never used NTLite, but I think there is a section like "run script once on first-logon", or something.
You can use the entire script or extract only the functions you need and make a single .ps1 file.
If you prefer the one file method, here are the functions:
This is only for MS Store, if you need other apps settings, copy/paste their related functions as well.
These functions requires Powershell 7 that you must install before running the script.
If you perform an offline installation, you need to incorporate the .msi installer into your ISO. Releases · PowerShell/PowerShell: e.g. PowerShell-7.5.3-win-x64.msi
My script have the same timing-related problem if you use NTLite.
If settings.dat doesn't exist, it will do nothing.
To solve this problem, I've added (only in this post) the Test-UWPAppFilePath function to test if the file exist.
e.g. Test-UWPAppFilePath -Name 'MicrosoftStore' -Timeout 30
The timeout is in seconds.
30 seconds should be enought. Increase it if it doesn't work.
Originally I've tagged you to give you the names of the registry keys ^^.
But here you are, the code inside the spoiler tag should accomplish what you want.
Don't forget to install Powershell 7 and run the script with pwsh.exe (not with powershell.exe).
@Brink
Do you have 1 min to update the OP please ?
The new content is in the spoiler tag at the end of the post 27.
@agadiffe
I need to consult with you regarding this script & NTL integration
and as I don't wanna clutter this thread here for my personal interest so checked your profile for PM, but since you limit who can view your profile, so I can't.
If you don't mind, could you drop me a PM so that we can continue over there?
If you’re running inside a VM and logging in directly as the admin account, then of course $env:UserName and [Environment]::UserName will return the admin—because that’s the interactive session user, not a standard user elevating via UAC.
Run this in an elevated command window outside the VM: net user TestUser /add P@ssword123
runas /user:TestUser "powershell.exe"
Next, in the PowerShell window that opens, run this:
WindowsIdentity ➜ execution token (admin if elevated)
Process Owner ➜ who launched the process (should match $env:UserName)
Next, open an elevated PowerShell inside the VM like you said you did, and use it to run the script code above. If all three return the admin, then you didn’t launch from a standard user—you launched from admin directly. If you want the standard user who launched the elevated PowerShell, only the process owner via WMI will give you that. Everything else reflects either the environment or the token—not the origin.
(You can run net user TestUser /delete in an elevated command window—once you convinced yourself that you’ve seen the truth.)
As for the error you got with GetOwner(), This happened simply because you changed Get-WmiObject to Get-CimInstance.
Not quite. The fragility isn’t limited to non-interactive contexts—it’s about how elevation and identity are resolved.
Even in interactive sessions:
If the user is domain-joined, Get-LocalUser fails.
If elevation is via runas or a service, WMI may return misleading data.
If the registry hive isn’t loaded (e.g., user logged off), HKEY_USERS\$SID is inaccessible.
What’s bulletproof?
Querying explorer.exe ownership via WMI or CIM is the most reliable way to identify the interactive user who launched the elevated session. It works across:
Local and domain accounts
Interactive and elevated contexts
UAC elevation
Mixed environments
Powershell:
function Get-ProcessOwner {
param([string]$ProcessName)
try {
$proc = Get-WmiObject Win32_Process -Filter "Name = '$ProcessName'" | Select-Object -First 1
if (-not $proc) {
Write-Error "Process '$ProcessName' not found."
return $null
}
$owner = $proc.GetOwner()
if (-not $owner.User) {
Write-Warning "Owner of '$ProcessName' could not be resolved — SID may be orphaned or deleted."
return $null
}
return "$($owner.Domain)\$($owner.User)"
} catch {
Write-Error "Failed to resolve owner of '$ProcessName': $($_.Exception.Message)"
return $null
}
}
# Identity layers
$envUser = "$env:UserDomain\$env:UserName"
$tokenUser = [System.Security.Principal.WindowsIdentity]::GetCurrent().Name
$processUser = Get-ProcessOwner -ProcessName "powershell.exe"
$shellUser = Get-ProcessOwner -ProcessName "explorer.exe"
Write-Host "Environment Block: $envUser"
Write-Host "Execution Token: $tokenUser"
if ($processUser) { Write-Host "PowerShell Owner: $processUser" }
if ($shellUser) { Write-Host "Explorer.exe Owner: $shellUser" }
# Elevation detection
if ($shellUser -and ($tokenUser -ne $shellUser)) {
Write-Host "Elevated context detected — launched by: $shellUser"
} elseif ($shellUser) {
Write-Host "No elevation — running as: $tokenUser"
} else {
Write-Warning "Unable to determine elevation status — explorer.exe owner not resolved."
}
-ExecutionPolicy Bypass is not necessary with Powershell 7, but doesn't hurt to have it.
If you perform an online installation, add the command to install Powershell 7.
If it is an offline installation, include the .msi installater file and install it.
Code:
msiexec.exe /i PowerShell-7.5.3-win-x64.msi /qn
There are a lot of resources on internet to help you with NTLite.
You can look at their forum and/or documentation. NTLite Forums
As there is a lot of online contents about NTLite, AI tools should be good to answer your questions. :)
example: Perplexity or ChatGPT or another one (Copilot, Gemini, Grok).
If you still struggle, the best option is to open a new post on NTLite forum as it is a NTLite question.
If you’re running inside a VM and logging in directly as the admin account, then of course $env:UserName and [Environment]::UserName will return the admin—because that’s the interactive session user, not a standard user elevating via UAC.
PS C:\Users\Admin_Bare_Metal> runas /user:SUser "powershell.exe"
Enter the password for SUser:
Attempting to start powershell.exe as user "DESKTOP-ABCDE42\SUser" ...
If all three return the admin, then you didn’t launch from a standard user—you launched from admin directly. If you want the standard user who launched the elevated PowerShell, only the process owner via WMI will give you that. Everything else reflects either the environment or the token—not the origin.
(You can run net user TestUser /delete in an elevated command window—once you convinced yourself that you’ve seen the truth.)
What are the results of those commands if you test it yourself in an elevated session on a standard account ?
I think that you need to be convinced of the actual behavior.
I have not.
Actually, the code you posted works only with "Windows Powershell", it fails with "Powershell 7".
With "Powershell 7" we need to use Get-CimInstance and Invoke-CimMethod, and it also works with "Windows Powershell".
Beside, Get-WmiObject is deprecated and has been superseded by Get-CimInstance.
The Get-LocalUser issue will be fixed by the .Net class as we previously discussed.
I will find a way if the hive is not loaded.
If there is no interactive user, there are not much I can do except allowing to manually enter or via a parameter the username.
You can't use runas as you cannot have an elevated prompt with it, and my script requires admin rights.
Even with:
It will act as if you launched a Powershell session with the Admin account you are logged-in with.
Win32_ComputerSystem.UserName does work with multiple users logged-in (assuming the user has a GUI).
I think it should work for RDP even if multiple users are logged in.
Not sure about Remote session.
It is more reliable.
But if you have multiple users logged-in you can't tell who launched the script. And quser is not available on home edition.
For now, (Get-CimInstance -ClassName 'Win32_ComputerSystem').UserName is the best (only ?) option I have.
Hi everyone.
I want to share with you all the PowerShell script I made to automate the configuration of Windows.
Not only debloating Windows and minimizing telemetry, but automating every settings (in a reasonable way).
None of the scripts available online met my expectations, so I made my own.
Automate and customize the configuration of Windows.
Debloat, minimize telemetry, apps installation, general settings, and more.
Hi everyone.
I would like to share with you the PowerShell script I made to automate the configuration of Windows.
It's not just about debloating Windows and minimizing telemetry.
It's also about automating every settings (in a reasonable way :)).
None of the available online scripts met my expectations, so I created my own.
Purpose
Install Windows (semi-unattended) + updates.
Run the script.
Finish some customization.
Characteristics
Fully non-interactive script: make sure to review everything before running it.
Designed for Windows 11 (most tweaks/settings also work on Windows 10).
Works on both Administrator and Standard account.
Features
Windows settings
File Explorer
System Properties
Power options
Network
Telemetry
Tweaks
Applications
RamDisk
Services & Scheduled Tasks
See the Github README for the detailed list of all tweaks/settings.
:pushpin: PowerShell scripts to automate and customize the configuration of Windows. Easy to use and extensive: Debloat, minimize telemetry, apps installation, general settings, and more. - agadiff...
Haha, yeah I know. But you understood me, I was talking about Powershell cmdlet.
Purpose
Characteristics
Features
Windows settings
File Explorer
System Properties
Power options
Network
Telemetry
Tweaks
Applications
RamDisk
Services & Scheduled Tasks
Link
