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.
Click an Ad
If you find this blog helpful, please support me by clicking an ad!
Friday, May 10, 2013
Monday, May 6, 2013
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.
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.
Thursday, May 2, 2013
Auto-decline WSUS Itanium Updates
I've been really busy lately. While I haven't had the time to post between work and family (remember to keep balance in your life!), I have a TON of things saved up to post about. Let's hope all of the tech isn't obsolete by the time I get around to it, eh?
In that vein, I'm just going to blast some things out with short posts, in the hope that I'll be able to make the time to actually post.
Also, I'll be putting interesting web pages I come across - mostly news and editorial stuff in the blog roll on the right. It links to my Tumblr page, called The LAG.
So today's post is about WSUS updates. I really like WSUS. I really hate WSUS. I like it because it patches my stuff in an automatic and (not very) complicated way. It hasn't changed all that much in a long time. I hate it because it's TOO simple. I know, if I want granularity I need to plop down the cash for something like System Center. I don't want granularity that badly, though! Case in point, every month I have to go through all of the Patch Tuesday updates and decline the Itanium releases. They waste space on my system, and clutter up my view of approved (and actually useful) updates.
That's why I was SO thrilled when a colleague of mine sent me the link to a Microsoft Technet page that had a powershell script that would decline Itanium updates! I tweaked the script a bit and ran a couple of tests just to make sure it was going to do what I thought (it has a test run component, nice!).
After I verified that it was indeed the magical faerie unicorn that I thought it to be, I scheduled it to run every Tuesday night after WSUS synchronizes.
I'LL NEVER HAVE TO DECLINE ITANIUM UPDATES AGAIN!
You'd think that Microsoft could break these out fairly easily within Products and Classifications, but whatever.
In that vein, I'm just going to blast some things out with short posts, in the hope that I'll be able to make the time to actually post.
Also, I'll be putting interesting web pages I come across - mostly news and editorial stuff in the blog roll on the right. It links to my Tumblr page, called The LAG.
So today's post is about WSUS updates. I really like WSUS. I really hate WSUS. I like it because it patches my stuff in an automatic and (not very) complicated way. It hasn't changed all that much in a long time. I hate it because it's TOO simple. I know, if I want granularity I need to plop down the cash for something like System Center. I don't want granularity that badly, though! Case in point, every month I have to go through all of the Patch Tuesday updates and decline the Itanium releases. They waste space on my system, and clutter up my view of approved (and actually useful) updates.
That's why I was SO thrilled when a colleague of mine sent me the link to a Microsoft Technet page that had a powershell script that would decline Itanium updates! I tweaked the script a bit and ran a couple of tests just to make sure it was going to do what I thought (it has a test run component, nice!).
After I verified that it was indeed the magical faerie unicorn that I thought it to be, I scheduled it to run every Tuesday night after WSUS synchronizes.
I'LL NEVER HAVE TO DECLINE ITANIUM UPDATES AGAIN!
You'd think that Microsoft could break these out fairly easily within Products and Classifications, but whatever.
Wednesday, April 10, 2013
Copying Files from a Sharepoint 2013 Document Library and a Rant Against the Cloud
This week, my team finally had our fill of Spiceworks' Knowledge Base. Spiceworks is a GREAT free network scanning and inventory tool, to be sure. When we evaluated it, it did everything we needed (and more). The one thing we were unsure of was the implementation of its Knowledge Base.
In Spiceworks, the Knowledge Base allows you to write articles, how-to's, etc. You can either keep them linked to your own login, share them with the team, or share them with the entire Spiceworks community (which is a fantastic community - I get lots of help there). The problem is that your documents are not stored on your server. They're in Spiceworks' cloud.
The cloud should not be used to store important information. I just don't understand all of these businesses are moving important things into it. The thing is, the cloud is only as reliable as your internet connection. So, who do you trust more to keep things running: Your IT Admin(s), or your internet provider AND the service provider? AT&T doesn't give a damn if your business is without internet.
Anyway, we tried to do it the new way. The cloud way. We put a couple hundred documents into Spiceworks over the course of a few months. Of course, there have been several times where our team was not able to access the Knowledge Base because something was wrong on Spiceworks' end.
Finally, we had had enough, and I built a Sharepoint server in an afternoon. We have datacenter licenses for our VMware hosts, and Sharepoint Foundation 2013 is free, so it cost us nothing. I hooked the back end into our IT SQL server, but Sharepoint will install a SQL Express DB if you need it. Keep in mind that there's a 4GB limit to any databases on an express install, though.
This was my first Windows 2012 server, and, well... meh. We manage things through a remote desktop app called mremote, and RDP makes the new server OS a bit challenging to use. You can't pass the Windows shortcut key, so I actually have to mess with the hot corners to get to the start screen. AND since the Windows shortcut key doesn't work through RDP, I can't hit Win+R and run commands that way (or Win+E to open explorer). Anyone have a better remote desktop app that will pass Windows keys I am all ears. This might not be Microsoft's fault - I probably just need to find a workaround....
I digress. So I got Sharepoint all set up and started dumping in our docs. At a previous job, I had attempted to write a script (this was before I learned Powershell) that would copy all of our files out of a Sharepoint repository to a secondary location every day, but it took so long to run that it was ridiculous. I thought I would give it another try. I found a very helpful blog post by Jeffrey B. Murphy at jbmurphy.com that did almost all of the work for me, and then I just added a few bells and whistles to complete it. They must have improved something somewhere (WebDAV perhaps?) because copying the files is MUCH (MUCH) faster. Here's the script:
Add-pssnapin microsoft.sharepoint.powershell
$StartTime = get-date
$TempFile = "C:\Temp\SPFiles.txt"
#This next command deletes the files that were copied over yesterday - it empties the folder
Get-ChildItem \\DRServer\e$\SharepointKB | Remove-Item -recurse -force
$SiteURL = "http://SharepointServer"
$DocumentLibrary = "Knowledge Base"
$Destination = "\\DRServer\e$\SharepointKB"
$spWeb = Get-SPWeb -Identity $SiteURL
$list = $spWeb.Lists[$DocumentLibrary]
#This section creates a list of all of the files that will be moved and outputs to a text file
$FilesMoved = ($list.items | select File | sort File | ft -wrap)
$FilesMoved | out-file $TempFile
#This section actually copes the files.
foreach ($listItem in $list.Items)
{
$DestinationPath = $listItem.Url.replace("$DocumentLibrary","$Destination").Replace("/","\")
write-host "Downloading $($listItem.Name) -> $DestinationPath"
if (!(Test-Path -path $(Split-Path $DestinationPath -parent)))
{
write-host "Creating $(Split-Path $DestinationPath -parent)"
$dest = New-Item $(Split-Path $DestinationPath -parent) -type directory
}
$binary=$spWeb.GetFile($listItem.Url).OpenBinary()
$stream = New-Object System.IO.FileStream($DestinationPath), Create
$writer = New-Object System.IO.BinaryWriter($stream)
$writer.write($binary)
$writer.Close()
}
$spWeb.Dispose()
$EndTime = get-date
#This section sends me an email including start and end times as well as the file list I created earlier
$Subject = "Sharepoint KnowledgeBase Copied to DR Server"
$Body = "Start Time: $StartTime `r`n`r`nEnd Time: $EndTime `r`n`r`nList of Sharepoint files copied is attached"
Send-MailMessage -To me@myjob.com -From administrator@myjob.com -Subject $Subject -Body $Body -SmtpServer mailserver.myjob.com -attachments $TempFile
Remove-Item $TempFile
By the way, you will need to run this script from a server that has the Sharepoint Powershell extensions installed. Your Sharepoint server is the easy choice; I didn't even look into whether I could install the extension elsewhere, because I tried to go down that rabbit-hole with Sharepoint 2010 and spent way too much time fighting with it.
In Spiceworks, the Knowledge Base allows you to write articles, how-to's, etc. You can either keep them linked to your own login, share them with the team, or share them with the entire Spiceworks community (which is a fantastic community - I get lots of help there). The problem is that your documents are not stored on your server. They're in Spiceworks' cloud.
The cloud should not be used to store important information. I just don't understand all of these businesses are moving important things into it. The thing is, the cloud is only as reliable as your internet connection. So, who do you trust more to keep things running: Your IT Admin(s), or your internet provider AND the service provider? AT&T doesn't give a damn if your business is without internet.
Anyway, we tried to do it the new way. The cloud way. We put a couple hundred documents into Spiceworks over the course of a few months. Of course, there have been several times where our team was not able to access the Knowledge Base because something was wrong on Spiceworks' end.
Finally, we had had enough, and I built a Sharepoint server in an afternoon. We have datacenter licenses for our VMware hosts, and Sharepoint Foundation 2013 is free, so it cost us nothing. I hooked the back end into our IT SQL server, but Sharepoint will install a SQL Express DB if you need it. Keep in mind that there's a 4GB limit to any databases on an express install, though.
This was my first Windows 2012 server, and, well... meh. We manage things through a remote desktop app called mremote, and RDP makes the new server OS a bit challenging to use. You can't pass the Windows shortcut key, so I actually have to mess with the hot corners to get to the start screen. AND since the Windows shortcut key doesn't work through RDP, I can't hit Win+R and run commands that way (or Win+E to open explorer). Anyone have a better remote desktop app that will pass Windows keys I am all ears. This might not be Microsoft's fault - I probably just need to find a workaround....
I digress. So I got Sharepoint all set up and started dumping in our docs. At a previous job, I had attempted to write a script (this was before I learned Powershell) that would copy all of our files out of a Sharepoint repository to a secondary location every day, but it took so long to run that it was ridiculous. I thought I would give it another try. I found a very helpful blog post by Jeffrey B. Murphy at jbmurphy.com that did almost all of the work for me, and then I just added a few bells and whistles to complete it. They must have improved something somewhere (WebDAV perhaps?) because copying the files is MUCH (MUCH) faster. Here's the script:
Add-pssnapin microsoft.sharepoint.powershell
$StartTime = get-date
$TempFile = "C:\Temp\SPFiles.txt"
#This next command deletes the files that were copied over yesterday - it empties the folder
Get-ChildItem \\DRServer\e$\SharepointKB | Remove-Item -recurse -force
$SiteURL = "http://SharepointServer"
$DocumentLibrary = "Knowledge Base"
$Destination = "\\DRServer\e$\SharepointKB"
$spWeb = Get-SPWeb -Identity $SiteURL
$list = $spWeb.Lists[$DocumentLibrary]
#This section creates a list of all of the files that will be moved and outputs to a text file
$FilesMoved = ($list.items | select File | sort File | ft -wrap)
$FilesMoved | out-file $TempFile
#This section actually copes the files.
foreach ($listItem in $list.Items)
{
$DestinationPath = $listItem.Url.replace("$DocumentLibrary","$Destination").Replace("/","\")
write-host "Downloading $($listItem.Name) -> $DestinationPath"
if (!(Test-Path -path $(Split-Path $DestinationPath -parent)))
{
write-host "Creating $(Split-Path $DestinationPath -parent)"
$dest = New-Item $(Split-Path $DestinationPath -parent) -type directory
}
$binary=$spWeb.GetFile($listItem.Url).OpenBinary()
$stream = New-Object System.IO.FileStream($DestinationPath), Create
$writer = New-Object System.IO.BinaryWriter($stream)
$writer.write($binary)
$writer.Close()
}
$spWeb.Dispose()
$EndTime = get-date
#This section sends me an email including start and end times as well as the file list I created earlier
$Subject = "Sharepoint KnowledgeBase Copied to DR Server"
$Body = "Start Time: $StartTime `r`n`r`nEnd Time: $EndTime `r`n`r`nList of Sharepoint files copied is attached"
Send-MailMessage -To me@myjob.com -From administrator@myjob.com -Subject $Subject -Body $Body -SmtpServer mailserver.myjob.com -attachments $TempFile
Remove-Item $TempFile
By the way, you will need to run this script from a server that has the Sharepoint Powershell extensions installed. Your Sharepoint server is the easy choice; I didn't even look into whether I could install the extension elsewhere, because I tried to go down that rabbit-hole with Sharepoint 2010 and spent way too much time fighting with it.
Subscribe to:
Posts (Atom)