Run Powershell scheduled task without pop up

I found this solution a while back by calling the PowerShell Script via a .VBS script. Not ideal but, it negates the window flash:

command = "powershell.exe -nologo -command C:\Scripts\YourScript.ps1"  
set shell = CreateObject("WScript.Shell")
shell.Run command,0

Schedule this .VBS in the task scheduler and it will call your script the same as before.

What does the “@” symbol do in Powershell?


PowerShell will actually treat any comma-separated list as an array:


So the @ is optional in those cases. However, for associative arrays, the @ is required:


Officially, @ is the “array operator.” You can read more about it in the documentation that installed along with PowerShell, or in a book like “Windows PowerShell: TFM,” which I co-authored :). –  Don Jones

Run N parallel jobs in powershell


The Start-Job cmdlet allows you to run code in the background. To do what you’d ask, something like the code below should work. Use Wait-Job -Any to emulate throttle.

foreach ($server in $servers) {
    $running = @(Get-Job | Where-Object { $_.State -eq 'Running' })
    if ($running.Count -le 8) {
        Start-Job {
             Add-PSSnapin SQL
             $list = invoke-sqlcmd 'exec getOneMillionRows' -Server...
    } else {
         $running | Wait-Job
    Get-Job | Receive-Job

Working with Datatables in Powershell


I’m creating this post for my own reference for the most part, however hopefully it will assist someone else as well.

The following can be ran in PowerShell to create a basic data table:

$Table = New-Object System.Data.DataTable

For each column you want in the table, you’ll want to run something like the following:

$column = New-Object System.Data.DataColumn ‘NameofColumn’,([COLUMNTYPE])

Or to simplify things:

$Table.Columns.Add((New-Object System.Data.DataColumn ‘NameofColumn’, ([COLUMNTYPE])))

In the above, ‘NameofColumn’ is whatever you want the column title to be. It can contain spaces and symbols. COLUMNTYPE should be replaced with the type of column you want it to be. I most commonly use ‘string’ and ‘datetime’. You can reference for additional column types.

After you’ve created your table with the columns you want, you’ll need to start populating the table. The code below will show you how to add a row to the table, and assumes there are 3 columns, Name, Department, and Email.

$row = $Table.NewRow()
$row.’Name’ = “John”
$row.’Department’ = “IT”
$row.’Email’ = “[email protected]

If you find yourself needing to edit  a row, you have two ways IMO that you can do this. The first way is to explicitly call a particular row. You would do this by calling:


In the above, the [0] references the first row. Using [1] would reference the second row, and so on. If you were to run:


You would get the value for the Name column of row 1 ([0]) returned. You can do the following to change the value.

$Table.Rows[0].Name = “NewName”

To delete the row you would run:


The second way you can change a value is a bit more useful. You can essentially search the table for the row you want, and then change the value of a column.

To do this you use Where-Object. The following example will change the department column for the row where the name is equal to “Joe”.

($Table.Rows | Where-Object {($_.Name -eq “Joe”)}.Department = “NewDepartment”

Finally, if you find yourself needing to delete a row you can do so using the same two methods we used for modifying a row/column. You can delete a row by running:


and also by doing:

($Table.Rows | Where-Object {($_.Name -eq “Joe”)}).Delete()

Using Windows PowerShell to run old command line tools (and their weirdest parameters)


Problem 1: Name conflicts

Solution 1A: Use the .EXE extension

Solution 1B: Use CMD /C

Solution 1C: Use a PowerShell equivalent

Problem 2: Special PowerShell characters

Solution 2A: Use CMD /C

Solution 2B: Use the PowerShell escape character

Efficient Windows PowerShell Administration with WMI and CIM

Timothy Warner, author of Sams Teach Yourself Windows PowerShell in 24 Hours, differentiates between the often-confused terms WMI and CIM, and explains how best to use these technologies with Windows PowerShell.

Let’s imagine that you and I started a business manufacturing and selling network interface cards (NICs). Industry standards would be pretty important to us, right? How could we make it easier for our Ethernet NICs to work natively with systems based on, say, Windows, Linux, and OS X? What about compatibility with different network architectures, protocols, and client/server applications? (Whoa-I’m glad we don’t really need to worry about that particular set of problems!)
Continue reading “Efficient Windows PowerShell Administration with WMI and CIM”

What does PowerShell’s [CmdletBinding()] Do?

It’s not unusual to see folks write PowerShell scripts and functions whose first line is [CmdletBinding()]. What’s it do?

It’s generally a big part of advanced functions, or what some folks call “script cmdlets.” Basically, it turns on cmdlet-style parameter binding capabilities, either for a script or for a function. You really get four magical capabilities with it:

  • The ability to add [Parameter()] decorators to parameters – see “about_functions_advanced_parameters” in PowerShell for more detail. Technically, these can be used without adding [CmdletBinding()], but you almost always see them together.
  • The ability to use Write-Verbose and Write-Debug in your script or function, and have their output controlled by -Verbose and -Debug parameters of that script or function. You don’t need to declare those parameters – [CmdletBinding()] adds them.
  • Your script or function picks up the other common parameters, too, like -EV and -EA (see “about_common_parameters”)
  • The ability to have -whatif and -confirm added to your script or function, by specifying something like [CmdletBinding(SupportsShouldProcess=$True,ConfirmImpact=Medium)]. You still have to implement support for these switches by using $pscmdlet.ShouldProcess() in your script.

Unblock a file with PowerShell?

If you are using PowerShell v3, you can use the Unblock-File cmdlet.

The “blocking” part is simply an alternate data stream of the file, named “Zone.Identifier”. You can display it in CMD by using input redirection (no other way to get to a stream in CMD, though):

H:\Downloads> more < test.exe:Zone.Identifier

You can find them using dir /r on Windows Vista and later:

2009-10-24  12:18        54.538.056 test.exe
                                 24 test.exe:Zone.Identifier:$DATA

Also in CMD you can easily get rid of that by overwriting it (using output redirection, this time):


which isn’t quite the same as removing the ADS completely, but works in that Explorer doesn’t complain anymore.

There doesn’t seem to be native support for handling ADS from within PowerShell (as mentioned on The PowerShell Guy’s blog here. That article also has some information how to get that functionality in PowerShell). You could, however, simply call cmd:

cmd /c "echo.>test.exe:Zone.Identifier"

That works from PowerShell as well.

Another option would be Mark Russinovich’s streams utility which allows you to inspect a file’s ADS and also to delete them. So

streams -d myDownloadedFile.exe

does work as well.