SQL Express Upgrade Error

Server Support,

I went to upgrade my old MSDE database to SQL 2005 Express on our McAfee EPO server and I was receiving a ‘-1’ error during the upgrade process with the detail of:

You selected Mixed Mode authentication, but did not provide a strong password. To continue you must provide a strong sa password.

I went through a bunch of different items, but this link detailed that the error is in fact caused by a bum installer of Microsoft’s design:

Copy C:\Program Files\Microsoft SQL Server\90\Setup Bootstrap\BPA\bin\BPAClient.dll to C:\Program Files\Microsoft SQL Server\90\Setup Bootstrap\BPA

This was one of those ‘no way’ errors that aggravated me to no end.  Why didn’t they fix this?

Power Detection

Server Support,

It’s rather rudimentary, but I do not get a proper notification when we lose power.  Part of this was being spoiled for my first several years that I worked here because there was always someone at work, either an off-shift supervisor or a security guard, who would call me to let me know if power had been lost.  Another part, though, was simply overcoming the technical hurdles of getting the APC UPS units to get a notification through to me via SNMP.  My workaround thus far was to rely on a particular error the key access system for the doors would send me when there was a power hiccup, but after the last brief outage I determined that relying on that fallback measure wasn’t very reliable and that I should set about getting the SNMP messages to work.

The first step was to set up the antiquated network management cards for the APC units.  This was rather simple and just entailed pointing their SNMP settings at the HP Systems Insight Manager setup that I use.  (As an aside, I should point out now that my older APC card had a limit of eight characters for the password but I didn’t notice it until I guessed my way back onto the unit).  I then had to compile the MIB files, but when I tried to import the CFG file into Insight I was getting errors over the lines that had a severity of SEVERE.  After  searching around I came across this post that clued me in and after changing all the ‘SEVERE’s to ‘WARNING’s the CFG successfully imported.  This wasn’t a big deal to me since I planned on setting Insight up to e-mail me WARNING messages as well anyway. (Just looking within Insight it would appear that the error is being generated because there is no ‘SEVERE’ setting within the package.  I would then theorize that swapping out all the ‘SEVERE’s for ‘CRITICAL’s would also work.)

I then wanted to set Insight up to send me an e-mail AND a cellular text message.  After looking around I’d found that I could text my T-Mobile phone by sending an e-mail to <phone number>@tmomail.net.  On older versions of Exchange I remember how to allow a specific system to anonymous relay, but I couldn’t find an equivalent setting in Exchange 2007.  I’d set up a separate connector specific to the Insight server, but it turns out that the relay settings need to be set within the Exchange Management Shell.  After doing that I was getting my text messages from the APC UPS units, but the only issue left to resolve is to figure out how to get the texts in a more consistent fashion since I would receive some texts right away, and others upwards of an hour after the event that generated it.  Long term I might have to rely on a pay-for service, although an even pricier out-of-band method that removes the e-mail server from the loop is even more appealing.

Exchange 2007 Mailbox Size Limit Alerts

Coding, Server Support, ,

I’d grown spoiled with my MOM pack for Exchange 2003 since I was able to tweak it to alert me (the admin) when a user’s mailbox was being issued size limit warnings.  Several times I was able to catch users stuck with items tucked away out of their view, or the storage of large files that’s better suited to the file server.  After moving to Exchange 2007 though Microsoft removed the event log entry that I used to trigger the MOM condition.  My fix was to create a script that would run on the same schedule as the one used to issue mailbox size warnings.  After combing a variety of pages I came up with the following imperfect, but sufficient script:

function send-email($SmtpServer,$From,$To,$subject,$Body){
$smtp = new-object system.net.mail.smtpClient($SmtpServer)
$mail = new-object System.Net.Mail.MailMessage
$mail.From = $From
$mail.To.Add($To)
$mail.Subject = $subject
$mail.Body = $Body
#$mail.IsBodyHtml = $true
$smtp.Send($mail)
}

get-mailboxstatistics|out-file mstat.txt
get-childitem mstat.txt|select-string -pattern “Issue”|out-file results.txt
$File=get-childitem “results.txt”
$FileContent=get-content “results.txt”
[string]$formattedLength = $file.Length
if($file.Length -gt 5){
send-email email.server.com “server@example.com” “admin@example.com” “Mailbox size alert” $FileContent
}

I apologize for the lack of comments, but what I’m doing is snagging the stats, searching for the word ‘Issue’ to see if a warning or some such was issued, then checking the resulting file size of the search and if it’s oversized (i.e. actually contains something) it’s emailed off to the desired contact.

(UPDATE: this e-mail size alert works for Exchange 2010 as well)

(UPDATE 12/6/2013: this e-mail size alert does not work for Exchange 2013.  I’m working to brew up a solution.)

Head in the Clouds

Uncategorized

Cloud computing is the ultimate vendor lock-in strategy.

Before the ‘cloud’, vendors had to rely on poorly written software that would work to extract maintenance fees from customers who were looking to make the software they had already purchased operable.  Now though, vendors don’t even have to worry about that!  Like a landlord over a renter who lives on the top floor and owns too much furniture, cloud tech vendors only have to wait until the customer has a sufficient block of data or resources in the off-site app and then they can put them on the treadmill of increasing ‘tech rent’.

Find the Mailbox

Server Support, ,

I was getting two errors in the log along these lines on my Exchange 2007 server every thirty minutes:

Unable to update Mailbox SD in the DS. Mailbox Guid: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx. Error Code 0x80070005

I tried the items like this that instruct on how to find the troublesome mailbox (adfind, etc), but nothing would turn up.

At the same time I was looking up how to purge a disconnected mailbox* and I came across this page.  Putting two and two together, I put this line into the Exchange console:

Get-MailboxStatistics | where-object {$_.MailboxGuid -ne $null} | Select DisplayName,MailboxGUID

I was then able to hunt through the output to find the naughty GUIDs and reset the permissions.  Luckily our environment doesn’t have too many mailboxes so I was able to just eyeball it.  I’m sure that there’s a different way to craft the command so that it can just kick out the desired desired mailbox instead of a complete list, but it wasn’t worth the time to find that for our environment.

*Yet another item that was in the GUI of Exchange 2003 that you need obscure commands for in Exchange 2007.