Here’s how it’s done:
Get-ProvisionedAppxPackage -Online | ` Where-Object { $_.PackageName -match "xbox" } | ` ForEach-Object { Remove-ProvisionedAppxPackage -Online -AllUsers -PackageName $_.PackageName }
Here’s how it’s done:
Get-ProvisionedAppxPackage -Online | ` Where-Object { $_.PackageName -match "xbox" } | ` ForEach-Object { Remove-ProvisionedAppxPackage -Online -AllUsers -PackageName $_.PackageName }
Well, it’s all new again, and this time the old methods are reported as being deprecated at the end of June. Here’s a starting synopsis:
To connect:
Connect-MgGraph -Scope User.Read.All
(or User.ReadWrite.All
)
To get user info:
Get-MgUser -UserID username@domain.com
To change immutable ID to “a”:
Update-MgUser -UserID username@domain.com -OnPremisesImmutableId "a"
One cannot change ImmutableID to $null, but it can be changed, so an AD/AZ ‘hard match’ is probably still possible. Have not verified yet.
A customer had several of these errors being reported in Azure AD Connect. They were all users which had been converted to cloud-only. Several solutions are on Microsoft and related sites, none worked except this on the domain controller which has AAC:
set-adsyncscheduler -synccycleenabled $false
set-adsyncscheduler -synccycleenabled $true
Start-ADSyncSyncCycle -PolicyType Initial
Here is how to add Send As permissions for a user, to a distribution list, in Powershell.
Install modules if needed:
Set-Executionpolicy Bypass -Scope Process Install-Module PowerShellGet -Force -AllowClobber Install-Module ExchangeOnlineManagement -Force -AllowClobber
Connect to the tenant:
Connect-ExchangeOnline -UserPrincipalName adminuser@domain.com
Add-RecipientPermission -Identity distgroup@domain.com -Trustee user@domain.com -AccessRights SendAs
The hidden NTFS “System Volume Information” folders on Windows machines, can build up and up and up in size. I’ve seen instances ranging from 20G to hundreds of gigabytes, and every time this occurs, the overall system slows down, and often slows down a whole lot. SpaceSniffer is my favorite method of identifying this situation, but there are many. The only preventative I have been able to identify so far, is here.
But here we are discussing cleanup. If you have SentinelOne (S1) installed on this machine, you need to know that S1 considers deletion of volume shadows to be very bad actor behavior. This is because it often is a way that cryptolockers and others delete last-known-good checkpoints. S1 will not let you clear SVI, unless you disable it first, and it will complain very loudly if you try. Instructions for disabling S1, are at the end of this article. There may well be other security tools which will behave similarly, and need similar interaction beforehand.
vssadmin delete shadows /all
wmic shadowcopy delete /nointeractive
diskshadow
delete shadows all
Any of these can take a while, especially if SVI is big, e.g., more than 20-30 gigabytes. It can get huge occasionally, hundreds of gigabytes. I recently saw 1,022 shadow copies deleted (the first and third methods tell you the count) from one server.
Special cases do occur. Here are steps which can help a lot.
vssadmin resize shadowstorage
for the relevant drive(s) (try /? for syntax…), first to 10%, then back to whatever it was. Sometimes Windows will do a lot of steady cleanup for you, sometimes over hours of time. You’ll see it by watching File Explorer.cd "C:\Program Files\SentinelOne\Sentinel*"
.\sentinelctl.exe unload -slam -k "<passphrase>"
Then, and only then, will the cleanup commands above work.
.\sentinelctl.exe load -slam
If you should need to reenable S1 and your command prompt is not where you need it, here’s a paste:
cd "C:\Program Files\SentinelOne\Sentinel*" .\sentinelctl.exe load -slam
Here’s a search which got me to it, once logged into HPE.com.
You’ll also need a driver, which does not come with the SPP.
This can be helpful for Windows 10 and 11, and probably newer server OSes as well. There are risks of problems being caused large and small, you have been warned :-)
Get-AppxPackage -allusers | foreach {Add-AppxPackage -register "$($_.InstallLocation)\appxmanifest.xml" -DisableDevelopmentMode}
To get the link speed of all NICs in Powershell:
Get-NetAdapter | select interfaceDescription, name, status, linkSpeed.
This one makes sure general settings are likely helpful, and also deals with two common troublemakers:
# General powercfg /change monitor-timeout-ac 0 powercfg /change monitor-timeout-dc 15 powercfg /change standby-timeout-ac 0 powercfg /change standby-timeout-dc 120 powercfg /change hibernate-timeout-ac 0 powercfg /change hibernate-timeout-dc 180 powercfg /change disk-timeout-ac 0 powercfg /change disk-timeout-dc 60 # Unhides and zeroes hidden "System unattended sleep timeout" which can cause problems # including, sometimes, automatic unwanted logoff powercfg -attributes sub_sleep 7bc4a2f9-d8fc-4469-b07b-33eb785aaca0 -ATTRIB_HIDE powercfg -setacvalueindex scheme_current sub_sleep 7bc4a2f9-d8fc-4469-b07b-33eb785aaca0 0 # Disable hybrid sleep both AC powered and DC powercfg -setacvalueindex scheme_current sub_sleep 94ac6d29-73ce-41a6-809f-6363ba21b47e 0 powercfg -setdcvalueindex scheme_current sub_sleep 94ac6d29-73ce-41a6-809f-6363ba21b47e 0 # Reapply current power scheme powercfg -setactive scheme_current
One can disable using UI and registry, but the processes still run and take more RAM than is obvious in Task Manager. Removal takes this:
Get-AppxPackage -Name MicrosoftWindows.Client.WebExperience -AllUsers | Remove-AppxPackage -AllUsers