@travisdh1 said in YouTube Months in Review: July and August 2020:

@EddieJennings You've been busy!

That I have. I didn't do a practice session for every objective because I ran out of time before the test. But taking the time to talk through most of them was a good way for me to determine if I needed to go back and review details.

@EddieJennings said in Use PowerShell to Disable UAC on Windows 10:

@Obsolesce said in Use PowerShell to Disable UAC on Windows 10:

What special case needs UAC completely off?

I'm curious about this as well.

Installing malware 🙂

@jmoore said in YouTube Month in Review: June 2020:

@EddieJennings Good info thanks eddie!

You're welcome. My RHCSA videos are truly "practice sessions" for me, but the information should be accurate. 🙂

Try this instead:

$FolderPath = Get-ChildItem -Recurse -Depth 2 -Path "P:\Public" -Force

Where -Depth is the how many levels deep you want to go.

If you want to see what a cmdlet can do, you can use:

Get-Help Get-ChildItem -Full

@EddieJennings said in YouTube Months in Review: February and March 2020:

100 Subscribers!

👍

Going to work on this, finally, after dinner tonight.

Thanks for those that posted.

@flaxking said in PowerShell - Using Variables to Delete SMTP Proxy Addresses in AD:

if they do not have previous experience with objects

Describes me. lol

There's also a lot more that can be done, especially with the credentials... storing them as an encrypted file and retrieving them for the function (function just for that, functions using other functions), keeping all the parameter data in an object to retrieve, or from CSV, etc....

It depends on how far down the rabbit hole you want to go, and how much time you want to spend making it.

Honestly, I'd do this kind of thing with a different project, but this can work too. There's a lot you can do.

@WrCombs said in How did you learn?:

How did you learn Power-shell scripting?
any books worth looking at? Looking at expanding some more, and I know Automation makes jobs way easier.

This (https://channel9.msdn.com/Series/GetStartedPowerShell3/01) combined with doing tasks in PowerShell. In my opinion, as others have states, it's easier to learn via doing tasks. Added bonus is you complete a task with PowerShell or script it, then see if / how you can improve your script.

@Dashrender said in Remove-Item cannot remove crap in Documents folder:

@Obsolesce said in Remove-Item cannot remove crap in Documents folder:

@Dashrender said in Remove-Item cannot remove crap in Documents folder:

@Obsolesce said in Remove-Item cannot remove crap in Documents folder:

@JaredBusch
I had a little bit of fun... whether useful to you or not.

You can run this script as a regular user that has permissions to create and run scheduled tasks and create a file in specified directory.

This will create a powershell script, and a scheduled tasks to run the script as the SYSTEM account. Then it will delete the script and the scheduled task.

I could test most of it, but not some of it for obvious reasons.

<#---- CHANGE THESE VARS: ----#> # Users to exclude from profile manipulation script, separated by pipe: $excludedKnownUsers = "Administrator|SpecialUser1" # New Script: $newLocalScriptPath = "$ENV:SystemDrive\scripts" $newLocalScriptFile = "testScript.ps1" # SID ending: (likely 21 if domain users) $sidEnd = 21 # Scheduled Task Name: $TaskName = "_Test Task 1" # Scheduled Task Description: $Description = "This is a test scheduled task that runs as the SYSTEM account and will be ran and then deleted at the end of this script." <#-------- END CHANGE --------#> # New Script: $newLocalScript = "$newLocalScriptPath\$newLocalScriptFile" # Gethers list of user profile paths: $userPaths = Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\*" -ErrorAction SilentlyContinue | Where-Object {($_.PSChildName -split '-')[3] -eq $sidEnd -and ($_.ProfileImagePath -split "\\")[2] -notmatch $excludedKnownUsers} # Creates a 'script in memory': $testScript = $null foreach ($userPath in $userPaths.ProfileImagePath) { $testScript += "Remove-Item -Path "$userPath\Documents" -Force -Recurse`n" $testScript += "New-Item -ItemType Junction -Path $userPath -Name 'Documents' -Target '$userPath\Nextcloud\Documents' -Force`n" } # Create a PowerShell script and save it as specified in vars: if (-not(Test-Path $newLocalScript)) {New-Item -Force $newLocalScript} $testScript | Out-File $newLocalScript -NoNewline -Force # Task Action: $Action = New-ScheduledTaskAction -Execute "powershell.exe" -Argument "-ExecutionPolicy Bypass -File $newLocalScript" # Task Trigger: (task will be manually run immediately and then deleted, so keep 1 year out) $Trigger = New-ScheduledTaskTrigger -Once -At (Get-Date).AddYears(1) # Task Compatibility: $Compatibility = "Win8" # 'Win8' is 'Windows 10' in the GUI # Task Settings: $Settings = New-ScheduledTaskSettingsSet -Compatibility $Compatibility -StartWhenAvailable -AllowStartIfOnBatteries # Run task as local SYSTEM account with highest privileges: $Principal = New-ScheduledTaskPrincipal -UserId 'S-1-5-18' -RunLevel Highest # Create the scheduled task: Register-ScheduledTask -TaskName $TaskName -Description $Description -Action $Action -Trigger $Trigger -Settings $Settings -Principal $Principal -Force <#--------------------------#> # Run the scheduled task: Get-ScheduledTask -TaskName $TaskName | Start-ScheduledTask # Remove the created script: Remove-Item $newLocalScript -Force # Delete the scheduled task: Get-ScheduledTask -TaskName $TaskName | Unregister-ScheduledTask -Confirm:$false

This seems like a HUGE security problem - normal users can schedule a task to run as SYSTEM? Then any virus could do the same thing. So what am I missing?

I assume regular user would need elevated privileges at least... But I didn't test as a non-local admin, which is different than elevated privileges. But either way, that script can be automated and run as a user in the local admin group too with successful results.

I think your script affects every user on the machine - assuming that's Ok for the envivronment - yep, have the local admin run it - and done.

Yeah I designed it like that on purpose, because if users are using the device, whether it's one or 10 (unlikely), IMO they should all be redirected. But that can be changed no problem. But at least if it's one main person using it, it'll hit that one. If others do, they can be excluded. But you can always get the current signed on user and use that as in JB's original script, or in an automated way using other means I could add in if needed.

@wrx7m said in Windows 10 Updates - Trigger "Update and Restart":

@IRJ said in Windows 10 Updates - Trigger "Update and Restart":

@wrx7m said in Windows 10 Updates - Trigger "Update and Restart":

@IRJ said in Windows 10 Updates - Trigger "Update and Restart":

@wrx7m said in Windows 10 Updates - Trigger "Update and Restart":

A simple restart command doesn't perform the update step, just the restart, so the update doesn't get applied.

This has been an issue for a very long time with windows. I am surprised it hasn't been fixed yet. It's really annoying

Well, at least with Win 7, a standard reboot applies updates. At least, I think it does. The main difference between Win 7 and 10, is that they have switched to the osoclient.exe to manage the updates.

I'm pretty sure server 2008 and onward had the issue. I don't remember dealing with it on workstations

I still have a 2008 R2 box and can test it on the next go 'round. I won't have it much longer, as I am dumping it prior to EOS.

LOL - Didn't make this cutoff. Next week, hopefully.

I think I may have found a quicker/more clean means of doing this with just

Get-ChildItem -Path "Drive-Letter" -Recurse -Force

It prints everything out to the console or to a file for review, than you just have to read it.

Why not filter out the files that you don't need to rename?
Summat like:

(Get-ChildItem -Path "path\to\folder" -Recurse | Where-Object {$_.Name -contains '•'} | Rename-Item -NewName {$_.Name -replace '•',''} -verbose -ErrorAction SilentlyContinue -ErrorVariable daError)

What version of .net is installed on the server?

I'm failing to remember which version of Powershell had a hard but silent requirement for a particular version of .net.
If memory serves it would install successfully (no errors) but would actually fail to install if the correct ver of .net was not already installed.