Uninstalling a program via WMI

First, let’s see how to view the installed program.

Get-CimInstance -Class Win32_Product -ComputerName $computername

To specify which program, you can pipe the result to Where-Object with a query like this.

Get-CimInstance -Class Win32_Product -ComputerName $computername | Where-Object {$_.Name -Like 'Adobe Acrobat 2017'}

You can even use the wildcard in this case to find all Adobe-related programs.

Get-CimInstance -Class Win32_Product -ComputerName $computername | Where-Object {$_.Name -Like 'Adobe*'}

If the output has only one result, you can simply call up the Uninstall() procedure to uninstall the program.

(Get-CimInstance -Class Win32_Product -ComputerName $computername | Where-Object {$_.Name -Like 'Adobe Acrobat 2017'}).uninstall()

If the output has multiple results, you can use the ForEach() method to loop through each app and uninstall it.

$apps = Get-CimInstance -Class Win32_Product -ComputerName $computername | Where-Object {$_.Name -Like 'Adobe*'}
ForEach ($app in $apps) {
  $app.uninstall()
}

Uninstalling a program via Uninstall-Package

Not all installed programs can be uninstalled via WMI. If the above method fails, Uninstall-Package would be a good option next in the line. Also, if it’s a MSI installed program, you have a better chance of uninstalling it this way.

Use the Get-Package cmdlet to find the program and pipe the result to Uninstall-Package to get it uninstalled. The nice thing about this method is that you can uninstall a bunch of related programs in one line.

Get-Package -Name "Kofax*" | Uninstall-Package

The drawback is that you would need to use the Invoke-Command cmdlet to execute it on a remote computer.

Invoke-Command -ComputerName $computername -Scriptblock {Get-Package -Name 'Kofax*' | Uninstall-Package

But what if the Permanently delete option is greyed out like this?

That’s because the Primary admin of the site is still set as the Group owners. You can’t purge the sites that still have any connections to the M365 groups. So, you can either restore the site and change the primary owner to an individual user and then delete it again, or better, you can take advantage of the power of PowerShell.

Install-Module -Name Microsoft.Online.SharePoint.PowerShell
Connect-SPOService -Url https://tenent-name.sharepoint.com
Remove-SPODeletedSite -Identity site_url

It works like a charm, except if you are trying it in PowerShell 7, in which you won’t be able to connect to the SharePoint Online service. Check out this to see how to get around it.

Install-Module -Name Microsoft.Online.SharePoint.PowerShell

It works perfectly in PowerShell 5 but failed miserably in PowerShell 7. It throws an error when trying to connect to SharePoint Online.

The workaround is to use import the module in a compatible mode.

Import-Module Microsoft.Online.SharePoint.PowerShell -UseWindowsPowerShell

But if you only have PowerShell 7 or install the module in PowerShell 7, you won’t be able to import the module in the compatible mode, because no valid module file was found in any module directory.l

You will have to specify the location of the module file to import it. By default, you should be able to locate the installed module from the following location.

%userprofile%\Documents\PowerShell\Modules\

Then run the following cmdlet and you should be all set.

import-Module "%userprofile%\Documents\PowerShell\Modules\Microsoft.Online.SharePoint.PowerShell\16.0.23710.12000\Microsoft.Online.SharePoint.PowerShell.psd1" -UseWindowsPowerShell

For example, there is more than just one encryption method you can use. With -EncryptionMethod, you can specify one of 4 methods to encrypt your drive, AES128, AES258, XtsAes128, or XtsAes256.

Enable-BitLocker -MountPoint "c:" -EncryptionMethod Aes256 -RecoveryKeyPath "E:\Recovery\" -RecoveryKeyProtector

You can also enable BitLocker with a specified AD user account so that when a user accesses the encrypted drive, they will get prompted for credentials for that account.

Enable-BitLocker -MountPoint "C:" -EncryptionMethod Aes128 -AdAccountOrGroup "Western\SarahJones" -AdAccountOrGroupProtector

Have you ever wondered what is wrong with my BitLocker drive that has a warning sign?

Get-BitLockerVolume tells you everything.

Aha…it’s because the Protection is off. Let’s Resume-BitLocker it.

What’s my encrypted system drive’s recovery password?

(Get-bitlockervolume -MountPoint "C:").KeyProtector

Can I save it to Active Directory so I don’t have to keep the file? Sure thing.

Backup-BitLockerKeyProtector -MountPoint "C" -KeyProtectorId (Get-bitlockervolume -MountPoint "C:").KeyProtector[1].KeyProtectorId

But whoops, it says “Group Policy does not permit the storage of recovery information to Active Directory”. What to do?

There are two policies you will need to change here. Open the policy assigned to the GPO, and go to the following location.

Computer Configuration > Policies > Administrative Templates > Windows Components > BitLocker Drive Encryption

And enable the policy called Store BitLocker Recovery information in Active Directory Domain Services

Then go to one of the following sub-locations of BitLocker Drive Encryption, whichever one you would be using.

• Fixed Data Drives
• Operating System Drives
• Removable Data Drives

And enable the policy called Choose how BitLocker-protected operating system drives can be recovered.

If it still doesn’t work, you may have to install the BitLocker management tools on the AD server.

Install-WindowsFeature BitLocker -IncludeAllSubFeature -IncludeManagementTools

With GPO configured to save the BitLocker keys to AD, we can enable BitLocker and save the keys directly to AD in PowerShell.

Add-BitLockerKeyProtector -MountPoint C: -RecoveryPasswordProtector | Out-Null
Enable-BitLocker -MountPoint C: -TpmProtector -EncryptionMethod Aes256 -SkipHardwareTest

It’s actually way easier. To retrieve the logon activities from a remote computer for the past 7 days, all you need is to run this.

Get-EventLog System -Source Microsoft-Windows-WinLogon -After (Get-Date).AddDays(-7) -ComputerName $computer

However, in order to pull the event log from a remote computer, the Remote Registry service needs to be running on that computer. It’s disabled by default for security reasons.

You will need to reenable the service and start it before pulling the log entries.

Invoke-Command -ComputerName $computer -ScriptBlock {
    $service = 'RemoteRegistry'
    Set-Service -Name $service -StartupType Manual
    Start-Service -Name $service
}

Once done, you will need to stop and disable it too.

Invoke-Command -ComputerName $computer -ScriptBlock {
    $service = 'RemoteRegistry'
    Stop-Service -Name $service
    Set-Service -Name $service -StartupType Disabled
}

So, putting everything all together,

$computer = Read-Host "Coomputer Name:"
Invoke-Command -ComputerName $computer -ScriptBlock {
    $service = 'RemoteRegistry'
    Set-Service -Name $service -StartupType Manual
    Start-Service -Name $service
}
$logs = Get-EventLog System -Source Microsoft-Windows-WinLogon -After (Get-Date).AddDays(-7) -ComputerName $computer
ForEach ($log in $logs){
    $user = Get-ADUser -Filter * | Where-Object {$_.SID -eq $log.ReplacementStrings[1]}
    $log.TimeGenerated.ToString() + ' - ' + $user.Name + ' - ' + $log.Message
}
Invoke-Command -ComputerName $computer -ScriptBlock {
    $service = 'RemoteRegistry'
    Stop-Service -Name $service
    Set-Service -Name $service -StartupType Disabled
}

Bonus point, I’ve formatted the output with a real username as well.

To make it happen, we will need help from a Windows .Net class called FileSystemWatcher in System.IO namespace.

The following code, when running, monitors the ID folder and will print the newly changed document before writing an entry to a log file when it detects any changes to the folder.

$log = "$home\Desktop\Log.txt"
$pathtomonitor = "X:\ID"
$timeout = 1000

try {
$FileSystemWatcher = New-Object System.IO.FileSystemWatcher $pathtomonitor
$FileSystemWatcher.IncludeSubdirectories = $true

Write-Host "Monitoring content of $PathToMonitor"
while ($true) {
  $change = $FileSystemWatcher.WaitForChanged('All', $timeout)
  if ($change.TimedOut -eq $false)
  {
      # get information about the changes detected
      Write-Host "Change detected:"
      # invoke some actions here when change detected
      if (!($change.ChangeType -eq 'Deleted')){
          Start-Process $change.name -WorkingDirectory $pathtomonitor -verb PrintTo '\\printerserver\printer1' -PassThru | %{ sleep 10;$_ } | kill
      }
      $change | Out-Default
      (Get-Date).ToString() + ", " + $change.ChangeType.ToString() + ", " + $change.Name | Out-File $log -Append
   }
  else
  {
      Write-Host "." -NoNewline
  }
 }
}
finally{
  $FileSystemWatcher.Dispose()
  Write-Host "My Watcher is done."
}

The monitor happens in an endless loop so to abord the monitoring process, you will have to press ctrl+c to break it. And because of that, you will need the try…finally {} to clean up the mess. When ctrl+c occurs, the code in finally{} will be executed, in which the FileSystemWatcher object can be properly disposed of.

The drawback of this approach is that it monitors folder synchronously so if multiple changes are made simultaneously, only the first one will be recorded. If you don’t anticipate multiple changes to the folder, this would be perfect. But if not, check this one out.

So, if you want to dig into this information, all you need is to open Event Viewer, head into System under Windows logs, and filter out these specific event IDs.

• Event ID 41 – indicating that the computer rebooted without shutting down completely.
• Event ID 1074 – indicating that a reboot was triggered by an application, including when a user restarted or shut down their computer from the Start Menu or by using Ctrl + Alt + Del.
• Event ID 1076 – records the reason why the computer was shut down or restarted. It’s recorded by the first user with shutdown privilege who logs on to the computer after an unexpected restart.
• Event ID 6006 – indicating whether the computer shuts down correctly.
• Event ID 6008 – indicating whether the computer shuts down abnormally or unexpectedly.

But I am not going to lie, it’s quite the work to dig out this information, especially on a remote computer. This is another place where PowerShell really shines in its own way.

Get-EventLog is the cmdlet that pulls event logs not only from your local computer but remote computers on the same network as well.

To pull the system log from a remote computer called Backup,

Get-EventLog -LogName System -ComputerName Backup

The list might be too long. So let’s only pull the logs after Jan 1, 2022.

Get-EventLog -LogName System -ComputerName Backup -After "2022/01/01"

Now here comes the tricky part, how do I find out these specific events based on the above Event IDs? There are no options to filter out directly so we need to pipe the result through.

Get-EventLog -LogName System -ComputerName Backup -After "2022/01/01" | Where-Object {$_.EventID -in (1074,1076,6006,6008)}

One more thing, let’s format the output a bit to show the full event message without being cut off.

Get-EventLog -LogName System -ComputerName Backup -After "2022/01/01" | Where-Object {$_.EventID -in (1074,1076,6006,6008)} | Format-Table TimeGenerated, EventID, Message -Wrap

For regular Microsoft 365 groups, you can simply go to the Exchange Dashboard, open the group, switch to the Settings tab, and uncheck the option “Allow external senders to email this group“.

To make these changes in PowerShell,

Set-UnifiedGroup -Identify $group -RequireSenderAuthenticationEnabled $true

That won’t work if these groups are synced from an on-premise Active Directory. In that case, you will need to set the msExchRequireAuthToSendTo attribute to True in AD’s group properties.

And if you have many to update, the following PowerShell script can lend a hand.

$groups = Get-ADGroup -Filter * -SearchBase "OU=Groups,DC=TestDomain,DC=Local"
$newvalue = $true

ForEach ($group in $groups){
    $groupinfo = [ADSI]"LDAP://$($user.DistinguishedName)"
    $groupinfo.put('msExchRequireAuthToSendTo', $newvalue)
    $groupinfo.setinfo()
    $group.name + ' ' + $groupinfo.msExchRequireAuthToSendTo
}

But as you can see, it doesn’t have the Remote Desktop Service Profile tab. So how do you batch update this property to a large number of users when needed?

Here is a quick example of using PowerShell to find all users that belong to a specific OU and update them with the new network path for remote desktop service profiles.

$users = Get-ADuser -Filter * -SearchBase "OU=Test, DC=Test, DC=LOCAL"
$newpath = ''

ForEach ($user in $users){
    $userinfo = [ADSI]"LDAP://$($user.DistinguishedName)"
    $userinfo.psbase.invokeset('TerminalServicesProfilePath', $newpath)
    $userinfo.setinfo()
    $user.name + ' ' + $userinfo.TerminalServicesProfilePath
}

Enjoy.

On top of that, on some of the computers, I get nothing when I right-click on them in Devices and Printers.

And in Settings > Devices > Printers, I see something even worse.

I am still puzzling why it happens and have no idea what the issue is. I’ve tried to update the printer driver and installed all the updates but nothing helped.

So, I blame bugs caused by Windows Updates. Instead of trying to fix it, I am going to live with it and use PowerShell to manage it when needed.

To list all printers installed on your computer

Get-Printer

To list all network shared printers installed on your computer.

Get-Printer | Where {$_.Type -eq 'Connection'}

And if you don’t want “Let Windows manage my Default Printers”, this is to set any network shared printer as default.

(New-Object -Com WScript.Network).SetDefaultPrinter('\\printersever\printername')

That should be enough, for the time being. But I am still hoping to get the bottom of it, one day.