Chaining Together Veeam SureBackup Verification Jobs

So my most recent conundrum in implementing Veeam Backup and Replication 6.5 Enterprise was getting SureBackup up and running. I wanted to set aside each Sunday to check all of my backup jobs.

Veeam has wisely allowed backup jobs to be chained; I set my first backup job to start at a certain time, and set the next job to start when the first one finishes, and so forth. It's such an elegant way to do things, and I commend Veeam for implementing it. What I don't understand is why they didn't make this feature accessible for any job that could be scheduled. I don't do replications, so I'm not sure if you can do it there, but I know for a fact that you cannot do it with SureBackup jobs.

Therefore, I needed to dust off my chops and head back to starting and running jobs via Powershell. I got my script syntax and methodology from a great post in this thread on the Veeam forums by v.Eremin.


Add-PSSnapin VeeamPSSnapin
$Job1 = Get-VSBJob -name "SB_Daily_1"
$Job2 = Get-VSBJob -name "SB_Daily_2"
$Job3 = Get-VSBJob -name "SB_Daily_3"

#This starts the first Job, then puts the script to sleep for 5 minutes
Start-VSBJob $Job1
Start-Sleep -s 300

#This section checks the status of the last job every 5 minutes, and starts the next one if it's done.
If($Job1.GetLastState() -ne "Working") {Start-VSBJob $Job2}
Else
{
do
{
Start-sleep -s 300
$status = $Job1.GetLastState()
}while ($status -eq "Working")
Start-VSBJob $Job2
}

#This section checks the status of the last job every 5 minutes, and starts the next one if it's done.
If ($Job2.GetLastState() -ne "Working") {Start-VSBJob $Job3}
Else
{
do
{
Start-sleep -s 300
$status = $Job2.GetLastState()
}while ($status -eq "Working")
Start-VSBJob $Job3
}

So, first you need to load the Veeam PowerShell Snap-In, and then you declare your job names as variables for later use. Then, you start the first SureBackup job.

Within each subsequent section, you check if the last job is still working. If not, start the next job, and if it is still processing that job the script enters a do-while loop wherein it goes to sleep for 5 minutes, then checks the status of the first job again. If it's still processing, the script re-executes the do-while loop. Finally, when it sees that the job is finished, it will start the next job.

This loop is repeated for each subsequent job.

Create an Outlook Rule to Act on Emails Received during a Certain TIME Period

I ran into this conundrum while trying to suppress active CPU alarms during our weekly antivirus scans. I don't want to discard CPU activity alarms altogether, and Outlook only has a canned rule for acting on emails received on certain days.

What you need to do is create the rule with the criteria looking at certain text IN THE EMAIL HEADER!

As far as the specific text to look for, I opted to use "2013 23:" (the clock for headers is the 24 hour variety). I left the year in there so that the rule wouldn't falsely trigger on other instances of "23:", which is a pretty generic search term.

Sure, I'll have to edit the rule next year, but this will get me by.

Auto-Decline WSUS Windows Embedded Updates

I decided to take the script to decline Itanium updates that I posted recently to the next level, and tweaked it to also remove Windows Embedded updates. Here is the script that I'm running now:


$WsusServer = "wsusserver.contoso.com"
$UseSSL = $false
$PortNumber = 80
$TrialRun = $false #change this to $true to see what it will effect!

#E-mail Configuration
$SMTPServer = "mailserver.contoso.com"
$FromAddress = "administrator@contoso.com"
$Recipients = "me@contoso.com"
$MessageSubject = "PS Report - Declining Itanium/Embedded Updates"

Function SendEmailStatus($MessageSubject, $MessageBody)
{
$SMTPMessage = New-Object System.Net.Mail.MailMessage $FromAddress, $Recipients, $MessageSubject, $MessageBody
$SMTPMessage.IsBodyHTML = $true
#Send the message via the local SMTP Server
$SMTPClient = New-Object System.Net.Mail.SMTPClient $SMTPServer
$SMTPClient.Send($SMTPMessage)
$SMTPMessage.Dispose()
rv SMTPClient
rv SMTPMessage
}

#Connect to the WSUS 3.0 interface.
[reflection.assembly]::LoadWithPartialName("Microsoft.UpdateServices.Administration") | out-null
$WsusServerAdminProxy = [Microsoft.UpdateServices.Administration.AdminProxy]::GetUpdateServer($WsusServer,$UseSSL,$PortNumber);

#$itanium = $WsusServerAdminProxy.SearchUpdates('Itanium') | ?{-not $_.IsDeclined}
#$itanium += $WsusServerAdminProxy.SearchUpdates('ia64') | ?{-not $_.IsDeclined}
#Although the above seems faster it also seaches in the description of the update so use the below just to search the title!
$itanium = $WsusServerAdminProxy.GetUpdates() | ?{-not $_.IsDeclined -and $_.Title -match "ia64|itanium"}
$itanium += $WsusServerAdminProxy.GetUpdates() | ?{-not $_.IsDeclined -and $_.Title -match "Embedded Standard 7"}
If ($TrialRun)
{$MessageSubject += " Trial Run"}
Else
{$itanium | %{$_.Decline()}}

$Style = "<Style>BODY{font-size:11px;font-family:verdana,sans-serif;color:navy;font-weight:normal;}" + `
"TABLE{border-width:1px;cellpadding=10;border-style:solid;border-color:navy;border-collapse:collapse;}" + `
"TH{font-size:12px;border-width:1px;padding:10px;border-style:solid;border-color:navy;}" + `
"TD{font-size:10px;border-width:1px;padding:10px;border-style:solid;border-color:navy;}</Style>"

If ($itanium.Count -gt 0)
{
$MessageBody = $itanium | Select `
@{Name="Title";Expression={[string]$_.Title}},`
@{Name="KB Article";Expression={[string]::join(' | ',$_.KnowledgebaseArticles)}},`
@{Name="Classification";Expression={[string]$_.UpdateClassificationTitle}},`
@{Name="Product Title";Expression={[string]::join(' | ',$_.ProductTitles)}},`
@{Name="Product Family";Expression={[string]::join(' | ',$_.ProductFamilyTitles)}},`
@{Name="Uninstallation Supported";Expression={[string]$_.UninstallationBehavior.IsSupported}} | ConvertTo-HTML -head $Style
SendEmailStatus $MessageSubject $MessageBody
}

Again, I can't take credit for the script itself; that honor belongs to ...... whoever submitted it to this technet page.

Lost All Admin Access to a SQL Server; PSTools to the rescue!

So today I was troubleshooting why a local scheduled task to back up a SQL Express database hasn't been running. Oddly, in SQL Server Management Studio (SSMS) I could see that the sa account had been disabled, and that only the 'builtin/Users' account had login rights. BuiltinUsers didn't have admin rights, either.

Hooray for this post over at mssqltips.com, which allows you to leverage psexec to get a SSMS login under the NT AUTHORITY/SYSTEM account, and then change the permissions. The command is this:

PsExec -s -i "C:\Program Files (x86)\Microsoft SQL Server\110\Tools\Binn\ManagementStudio\Ssms.exe"

You may need to modify the path, and you need to run it from the SQL Server itself after copying PSTools over to the SQL Server. Also, this command is all one line, and there is a space between SQL and Server. I don't have the time to fight a formatting war right now....

I highly recommend that admins keep a copy of the various PSTools programs around, as they can be very handy. I even found a GUI front-end for them.

This is also a stark reminder that you can lock down an application as much as you want, but the minute someone gets admin access (or physical access) to the system itself, all bets are off.