Getting an overview of reboots revisited

In my previous post I mentioned invoke-command using the -AsJob option. But then I saw a post from Tommy Maynard that made things even quicker and certainly a bit easier.

Instead of doing a "foreach server in serverlist" loop to run the invoke-command scriptblock, you can do an invoke-command on the entire serverlist in one go!

$ServerList = Get-Content C:\Scripts\ServerList.txt.txt

$block = {Get-EventLog System | Where-Object {$_.EventID -eq "1074" -or $_.EventID -eq "6008" -or $_.EventID -eq "1076"} | Select Machinename, TimeWritten, UserName, EventID, Message}

Invoke-Command -ComputerName $ServerList -ScriptBlock $block | ft -AutoSize -Wrap |Out-File C:\scripts\ServerRestart.txt

This certainly cuts down on scriptsize :-)

How much time you save depends on the amount of servers, but I tested it with 5 VM's, and saw some surprising things in my test: Invoke-command feeding the serverlist as described above actually took longer than invoke-command using the -Asjob option.

Usually I get 14 seconds for the old fashioned "foreach" test, then about 6 seconds for the invoke-command feeding the serverlist, and about 2 seconds for the invoke-command with -Asjob.

Here's the test I ran a few times after another:

$ServerList = Get-Content C:\Scripts\ServerList.txt.txt

# Test 1: Old fashioned way

Write-Host -ForegroundColor green "Foreach server in serverlist"

Measure-Command {foreach ($server in $ServerList){Get-EventLog System -ComputerName "$server" | Where-Object {$_.EventID -eq "1074" -or $_.EventID -eq "6008" -or $_.EventID -eq "1076"} | ft Machinename, TimeWritten, UserName, EventID, Message -AutoSize}}|select Seconds|ft -AutoSize

# Test 2: Doing the test with invoke-command, feeding the serverlist in one go

$block = {Get-EventLog System | Where-Object {$_.EventID -eq "1074" -or $_.EventID -eq "6008" -or $_.EventID -eq "1076"}}

Write-Host -ForegroundColor green "invoke with serverlist"

Measure-Command {Invoke-Command -ComputerName $ServerList -ScriptBlock $block}|select Seconds|ft -AutoSize

# Test 3: Doing the test with "Job" functionality

Write-Host -ForegroundColor green "Job Functionality"

Measure-Command {

foreach ($Server in $ServerList){

Invoke-Command -ComputerName $Server -ScriptBlock $block -AsJob

}

While (Get-Job -State "Running") {

}    

Get-Job| Receive-Job |ft -AutoSize

Get-Job | Remove-Job

Write-Host -ForegroundColor Yellow "Done!"

}|select Seconds|ft -AutoSize

The weird thing however, is if I swap test 2 and 3 around, invoke-command using -Asjob consistently works slower than the invoke-command with serverlist.  The old fashioned test still took  14 seconds, but the invoke-command with -Asjob took 2 to 6 seconds, and invoke-command feeding the serverlist consistently took 1 second.

Last try:

So I wasn't sure why the last piece of the script went faster than the middle part, but swapping it consistently made the latter one faster. So I ran each of the two tests in a loop for about 10 times in a row, and lo and behold: The invoke-command using -Asjob was running at 1-2 seconds, and feeding the serverlist in one go ran consistently for 1 second. For both tests, the first run took about 6 seconds, and this could be the same delay that is apparent in the test I listed above.

I assume that somehow a connection is made using Invoke-Command, and this session somehow stays alive.

In the end: Feed invoke-command the serverlist as a whole. It's easier to manage. and a little bit faster consistently.

Getting an overview of server reboots

A quick one that I wanted to keep for reference, after a forum post on powershell.org. Someone wanted to have a list of reboot times from the eventlog and put it in a text file, so I commented:

$ServerList = Get-Content "C:\Scripts\ServerList.txt"

foreach ($i in $ServerList){

    Write-Output $i "`n"+"==========================" | Out-File -FilePath c:\scripts\ServerRestart.txt -Append

    $Output = Get-EventLog System -ComputerName "$i" | Where-Object {$_.EventID -eq "1074" -or $_.EventID -eq "6008" -or $_.EventID -eq "1076"} | ft Machinename, TimeWritten, UserName, EventID, Message -AutoSize -Wrap

    $Output | Out-File -FilePath c:\scripts\ServerRestart.txt -Append

}

This obviously only works if you have enough credentials to access the remote server. This in itself should do the job for not too many servers, or lots in due time, because it runs on one server at a time.

If you want to kick things up a notch, and parallelize things, you can run it as a job with Invoke-Command with "-Asjob":

$ServerList = Get-Content "C:\Scripts\ServerList.txt"

$block = {Get-EventLog System | Where-Object {$_.EventID -eq "1074" -or $_.EventID -eq "6008" -or $_.EventID -eq "1076"} | ft Machinename, TimeWritten, UserName, EventID, Message -AutoSize -Wrap }

foreach ($Server in $ServerList){

Invoke-Command -ComputerName $Server -ScriptBlock $block -AsJob

}

While (Get-Job -State "Running") {    

    Write-Host -ForegroundColor Yellow "Running..."

    Start-Sleep 1        

}    

Get-Job| Receive-Job |Out-File C:\scripts\ServerRestart.txt

Write-Host -ForegroundColor Yellow "Done!"

Which will give the following output:

Get-Job| Receive-Job |Out-File C:\scripts\ServerRestart.txt

Id     Name            PSJobTypeName   State         HasMoreData     Location             Command                  
--     ----            -------------   -----         -----------     --------             -------                  
35     Job35           RemoteJob       Running       True            localhost            Get-EventLog System | ...
37     Job37           RemoteJob       Running       True            127.0.0.1            Get-EventLog System | ...
Running...
Running...
Running...
Running...
Running...
Done!

This should speed things up a bit, as now all machines run it simultaneously. The only thing that doesn't get done that way is the divider-line at the top.

To be totally neat, you should clean up the jobs too:

Write-Host -ForegroundColor Yellow "Clearing Up completed jobs"

Get-Job -State "Completed" |Remove-Job

Now you should be able to do a Get-Job and see if there are any failed jobs. Yes yes, that could be automated too..

SSH via Powershell

In hosting environments, you rarely see only one flavor of operating system, so to be able to manage linux systems with Powershell via SSH is a big help. With Windows Server 2016, SSH connectivity will be built in, but until that time you can quite easily get it right now.

Step 1:
Go to https://sshnet.codeplex.com and download the .Net 4.0 binary from the downloads section and place the "Renci.SshNet.dll" file somewhere where you can access it. In my example I put it in C:\Scripts

Most likely Chrome will ask you whether it is safe to download, obviously say "Keep":







Step 2:
Go to the file, rightclick and select Properties, then unblock the file.



Step 3:
Here comes the example code. Quick explanation: First you load the DLL, then you create an object with the DLL file (I'm sure there's a technical programmy way of saying this, but I have no clue), then you suddenly have all these cool features like "Connect" and "RunCommand". It is not an interactive thing (as far as I know), and you only have a single command you can run, so you can't create a scriptblock and run it all at once.

#Load the SSHNet Library

[void][reflection.assembly]::LoadFrom( (Resolve-Path "C:\Scripts\Renci.SshNet.dll") )

#The variables you need to log on

$server = "Server01"

$login = "someuser"

$password = "somepassword"

#Call the SSHNet Library as an object

$SshClient = New-Object Renci.SshNet.SshClient($server, 22, $login, $password)

#Connect to client using SSH

  $SshClient.Connect()

    

   if ($SshClient.IsConnected) {

    Write-Host "Connected to " $server

    #Run the command on the linux host

    $cmd = $SshClient.RunCommand('ls -l')

    

    if($cmd.Result -ne '')

    {

        Write-Host Output from $server

        Write-Host $cmd.Result

    }

    

  }

$SshClient.Disconnect()

$SshClient.Dispose()

Which gives the following output:

Connected to  Server01
Output from Server01
total 12
-rw-r--r-- 1 Akos users 136 Feb 21  2008 local.cshrc
-rw-r--r-- 1 Akos users 157 Feb 21  2008 local.login
-rw-r--r-- 1 Akos users 174 Feb 21  2008 local.profile

Of course this is a simple example, but you can load in a CSV file with server, login and password info, and then have a command run on however many servers as you want. It's always fun being able to tell your boss that you're doing that thing on 50 servers, and then getting a cup of tea while your script is doing your work for you. This SSHNet client can also upload files using sftp but I haven't tried that yet.

Adding PowerShell code in blog posts

For a while I was adding Powershell code in this blog, and it didn't look as neat as all the other blogs I was visiting, so I looked around, and of course I could have been beautifying my blog for a long long time:

LazyWinAdmin: Blogger - Adding PowerShell code in your blog post...

I looked at the code that LazyWinAdmin provided, but that did not work as well as the Falchion plugin from here. 

Now I can type something in the ISE, select the code and do "CTRL+Shift+C" and it then runs a Powershell script which generates the HTML code which I can paste into the Blogger site. I may eventually create a Github account and publish Powershell code through that, but this is a little bit simpler for now.

That left me with the Powershell window output, which LazyWinAdmin gave CSS code for that you can insert into the custom code for the template of your Blogger site:

CSS Code

.PoshConsole {
  color: #EEEDF0;
  background-color: #012456;
  font-family: consolas;
  font-size: 0.99em;
  padding: .25em;
  padding-top: 0.25em;
  padding-right: 0.25em;
  padding-bottom: 0.25em;
  padding-left: 0.25em;
}

Which can then be used with adding <pre class="PoshConsole">Something</pre> in the HTML editor.

One thing I did notice, is that my black background and gray text did not work so well with all of this beautification, that's why I moved to a more light template.

I noticed some other CSS style sheets in the sourcecode of the LazyWinAdmin page to make different types of styles, but I will let people hunt around for that themselves. He didn't put that in his blogpost, so I'm not sure if he wants the world to see that ;)