Author Posts

March 23, 2016 at 5:10 am

Hey folks,

my colleague has written a script which queries the free disk space of a server via WMI.
He runs it out of the ISE without any errors.

The strange thing is, as long as the ISE is open, every minute there are logon and logoff events in the security log of the target server. This continues until he closes the ISE.

When he closes the ISE, there are no events anymore.

This also happens when he runs the WMI query separately in ISE.
When he runs this script out of a console, it's all fine...no events.

Any thoughts?

March 23, 2016 at 5:39 am

Depends on what's in his script, I imagine. Can't really guess without seeing it.

However, I can tell you that when you use the ISE's "Run Script" option (or press F5), it's a lot like dot-sourcing a script at the console in powershell.exe. That's what allows you to inspect variables and their values after a script has finished running in the ISE. That's very likely going to be the cause of the difference in behavior that you're seeing.

March 23, 2016 at 5:56 am

Hi Dave,

sorry, my bad.

This is his script:


#spaltenköpfe schreiben
$Spaltenkopf = "hostname freeSpace"
get-variable -Name Spaltenkopf | Select-object {$_.Value} | ft -hidetableheaders >D:\FreeSpaceC\Symantec.txt
#Events abrufen
$DRSServers = Get-content D:\FreeSpaceC\symatecsrv.txt
#Abfrage Kommndo

ForEach ($server in $DRSServers)
{
try
{
Get-Variable server >> D:\FreeSpaceC\Symantec.txt
$result = Get-WMIObject Win32_LogicalDisk -computername $server -filter "name='c:'" | select name, freespace | ft -hidetableheaders -ea Stop
$result >> D:\FreeSpaceC\Symantec.txt
}
catch [Exception]
{
if ($_.Exception.GetType().Name -eq "COMException")
{
"Der Server ist nicht erreichbar" >> D:\FreeSpaceC\Symantec.txt
}
}
}
(gc D:\FreeSpaceC\Symantec.txt) | Foreach {$_.TrimEnd()} | where {$_ -ne ""} | Set-Content D:\FreeSpaceC\Symantec.txt

March 23, 2016 at 6:19 am

That is odd. I don't see anything in that script which seems like it should be keeping any open connections. Maybe it's something that the WMI .NET objects do, and we never noticed.

If you're running PowerShell v3 or later, you could try Get-CimInstance instead, and see if it behaves the same way.

April 12, 2016 at 12:55 am

Hi Dave,

thanks for your hints. He re-designed his script and now this behaviour no longer occurs...honestly I don't know why...

Cheers