Proactively monitor connected vhdx files

PowerShell Help
1

Hi everyone, We use Fslogix Office 365 container and we often have the problem that the O365 profile disk is not disconnected from the system when the user logs off from the system. Therefore the disk cannot be mounted again when the user logs on again.

Currently we are always notified by our customers in case they have no disc attached. I’ve been trying to write a script to proactively monitor whether all discs have been unmounted by users who are no longer logged on. (Fslogix should unmount the disk automatically, but as I said sometime that does not work) So I wrote a script for this purpose and it works inside Powershell ISE, but when I run it through Task Scheduler it doesn’t work at all. In general I would like to get some feedback on the script. What could be done differently or better. Many thanks.

[pre]

 #Get all Users with a active and inactive rdp session

$queryResults = (qwinsta /server:mah-svr-101 | foreach { (($_.trim() -replace "\s+",","))} | ConvertFrom-Csv)  

$DisRDPSessions = $queryResults.SESSIONNAME 
$ActivRDPSessions = $queryResults.USERNAME

#Removing admin and system session from the array
  
$a= Get-ADGroupMember RDS2016

$disRDSUsers = $a.SamAccountName | where {$DisRDPSessions -contains $psitem}
$activRDSUsers = $a.SamAccountName | where {$ActivRDPSessions -contains $psitem}

$connectedRDSUsers = $activRDSUsers + $disRDSUsers
   
#Get all connected Fslogix Disks

$Volumes = Get-WmiObject Win32_Volume

$VolumeLabel = $Volumes.Label

#Filterling for the Fslogix Disks

$O365DISKS = $VolumeLabel | Where-Object { $_ -like "O365-*" }

$activDISKS = $O365DISKS.trim("O365-")

#Check if a VHD is connected although the RDS session has ended

$DismountVHDs = $activDISKS | where {$connectedRDSUsers -notcontains $psitem}


#Sending an Alert 


if ($DismountVHDs) 
    
    {

    ##############################################################################
    $From = "email@email.com"
    $To = "email@email.com"
    $Cc = "email@email.com"
    $Attachments = "C:\scripts\ForAlerting\MAH Workaround - Example.png"
    $Subject = "ALERT: MAH-SVR-101 -> ODFC disk could not be removed."
    $Body = "The following Disks could not be removed from the server:
$DismountVHDs
Workaround: Log in to the RDS server and open Disk Manager: Selects the VHDX mentioned in the alert e-mail and disconnects it from the system. The name of the VHDX always starts with ODFC_ as shown in the example."
    $SMTPServer = "mail server"
    $SMTPPort = "587"
    Send-MailMessage -From $From -to $To -Cc $Cc -Subject $Subject `
    -Body $Body -SmtpServer $SMTPServer -port $SMTPPort -Attachments $Attachments `
    -Credential $cred 
    ##############################################################################

    }

[/pre]

2

You should be aware that PowerShell ISE is not really a valid test environment. The console in ISE is an emulation, and therefore doesn’t assure correct performance on the OS itself. The PowerShell team wrote up a list of differences back in 2009 that describes some of the issues. And it’s all moot at this point because PowerShell ISE is no longer being actively developed and will not support v6+. So, ISE is useful for context highlighting and autocompletion while writing your script, but you should not trust the console execution.

What happens when you run the script in the actual PowerShell console? (not with Task Scheduler) Do you get any error messages or any other useful output? Have you attempted to run your script with Set-PSDebug enabled? (I recommend -Trace 2) We can’t really troubleshoot your script without some information on what’s going wrong.

The other thing to check (assuming the script works as intended) would be permissions in Task Scheduler. If the Task Scheduler user account executing the script doesn’t have administrative privileges on the target system you’ll have problems, especially if you’re trying to execute against a remote or cross-domain system. It’s also possible that the Task Scheduler user doesn’t have access to your script at all due to permissions (e.g. read access to the directory where the script is saved).