Jan 212014

I admit that as far as technical support experience goes I’m somewhere in between, having worked in the IT industry since 2004, roughly a decade now. But I have seen it all, I might be bold in saying that I have done it all. I have made mistakes and have witnessed mistakes with customers over the phone. I have learned that even the most irate user on the phone can be singing your praises, but not without battle scars.

Here are my “Golden Rules” for technical support:

1. You are the expert, act like one.

You’re in control over the phone. The user has attempted within the bounds of their own knowledge to resolve their issue, but they’ve given it their last keystroke and now they want someone else to take control of the situation and fix their problem. By virtue of a phone call, they have given control to you, a person whom they know to be an expert.

Hint: Even if you’re not an expert at what you are troubleshooting, you can be an expert in finding out the answer.

2. The user you are working with is not an idiot.

If the user is an idiot, then why are they calling you? What’s idiotic about calling you? Resist the temptation to put the phone on hold and say something about the “ID10T error on the phone” in order to share what really is just their ignorance with your co-workers. Your moment of arrogance will bleed through the phone like a snake, and it will end up biting you in the end.

3. Never say: “I don’t know” or “that’s impossible”

User’s don’t like to hear this. It gives them the impression that they have hit a dead end and will have to do more work to resolve the issue. It also gives them the false assumption that you’re not an expert. After all, you’re the expert. Remember rule 1.

4. Your user’s time is ALWAYS more valuable than your own.

In the IT support industry, more often than not you’re working in a cost center, not a profit center. Because of this, your time costs the company money. The more you do within a given amount of time saves money for the company, and if you put things off, or blow off a customer, you’re wasting time and therefore costing more money.

I like to argue that there really isn’t any good way to get a quantitative metric on something so variable as rendering IT support, given that every single problem always has something that sets it apart from others, even password resets. So what I like to follow is to err on the side of caution and make my users time more valuable than my own. Sure, in practice we all slip, so treat this as a guideline. It cannot hurt.

5. Never place blame in front of a user.

It’s important to present a united front to your customers, be it internal or external. We all make mistakes, there are decisions made that we don’t agree with, and from time to time these will make it harder to support our user base. The right way to deal with this is within your own IT organization. Don’t complain to your users. Chances are this will not effect the change you are looking for, instead it will alienate your user base.

Hint: Your user’s don’t care that you have to go through a lengthy process to request access to a widget, they only care that you get their widget access approved in a timely fashion.

6. Never assume.

It’s said that “assume makes an ass of you and me.”

We work in a field where objective information is the rule. There can never be an opinion about how a computer or piece of software works. Because of this, IT affords you a luxury of never having to assume something. Computers work on true and false, never a “maybe.” If you don’t know a fact, you can look it up.

Assumptions are dangerous in IT, because when they prove to be incorrect, something happens that can be catastrophic. For instance, I assumed once that I was on a different print server and ended up deleting all the printers off of a mission critical server. We recovered, but because I was going by assumptions, it made an “ass of me.”

7. Take notes.

When you’re on the phone with lots of users on any given Monday, having notes to fall back on is a good thing, whether it be in the ticketing system or in a spiral notebook. I prefer the ticketing system because it creates an instant troubleshooting log. Be thorough and collect any information you can no matter how useless it seems. This is because of one of your colleagues are helping you and the see a pattern in your notes that you didn’t see,  you just saved yourself a lot of time.

8. Know your toolkit. Use it.

No one ever expects us to be “computer whisperers.” One cannot solve a computer by laying hands on it and yelling “heal thyself…”

…Unless there’s a grounding problem and you’re completing a circuit by doing such, but realistically, aside from the fact that such a thing will probably kill you, you have a toolkit.

Software like the Sysinternals Suite or GRC’s Spinrite, are examples. There are many more tools, too many to list, but if you’ve read this far you already have a toolkit that you use on a daily basis. It’s good to know those tools and the information they provide. They will save you time and make you the expert, so know your toolkit.

9. Be thorough. Never leave out information because it is “obvious.”

What’s obvious to you may not be obvious to a colleague no matter how technically proficient they are. I believe this is the chief cause of effort duplication. If two technicians find the same setting, and the first one made an assumption (there’s that word) that it was a known condition and left it out of their notes, while the second realized it was the root cause but it took them hours to get there, then time was wasted.

10. This is not magic. You are not a wizard. Don’t be arrogant.

It is so easy to become elitist in IT. You learn things that your users may not know. I’ve had users tell me I must be really smart since I’m able to solve their problem. These are people who have intimate knowledge in their own fields. They know things about their own fields that I would never hope to understand. My usual reply to them is “You wouldn’t want me doing your job.”

The answer is that we are specialists in our own field, we are computer experts, we are not financial exports, nor are we doctors. This is not wizardry, this is just a profession.

11.  Never “cold hold” a user on the phone.

This is rude, and no, saying “please hold” does not give you a pass. Always give the choice to the user. More specifically I am talking about the pesky mute button. If I ever ran a call center, I’d give the mute button a timer and call it a cough button.

People are psychological creatures. When you hear someone on the other end of the line it has better psychological impact than whenever the person on the other end of your line is met with a wall of silence. Plus, if they speak up and you forget your mute button is on its pretty embarrassing.

So unless you get permission from the user, no mater how odd this sounds, don’t mute.

12. There are no problems, only opportunities.

This may be the most important. Take responsibility for resolving the problems you are presented with and treat them as an opportunity. This allows you to prove yourself, and this is where the pay raises and promotions come from.

Always go above and beyond in doing technical support. It seems like a mundane job that lacks the real meat and bones of working with servers and configuring databases, but in the end you are the conduit between the user and the rest of IT. Treat that time as an opportunity, and good things will come.

I know some of this sounds like a self help guide, and perhaps some of it is. Perhaps I should write a book on it. 🙂

If you have additional rules or something you’d like to add, just comment, and perhaps I will edit them into this post.

Jan 212014

Recently I encountered a little trap with the VB Replace() function. Beware that if you only use the required parameters, like…

strString = Replace(strString,"{find}","{replacewith}")

…it does a binary only comparison. This can muck up instances where you intend to replace a known string, but some instances may come up with mixed case.

W3 Schools has an excellent reference page on replace() here.

Binary only is case-sensitive. The solution is to use textual, which is case-insensitive:

strString = Replace(strString,"{find}","{replacewith}",1,-1,vbTextCompare)

The parameters 1,-1,vbTextCompare is as follows:

  • 1 means “start at position 1”
  • -1 means “find all instances”
  • vbTextCompare is a constant (literally 1), that tells the function this is a text comparison. It’s alternate is vbBinaryCompare.

This can save a headache later on when you’re dealing with an scenario where case in strings are questionable, I would assume it’s always questionable unless you are looking explicitly for a binary match.

But I didn’t make VB. Oh well.

Jan 152014

If you’re working with SCCM 2012 Desired Configuration Management and want to create a CI for local machine certificates, here’s part 1 of a 2 part equation that is evolving. The remediation script is still in the works, but for right now, here’s a script that does the following.

  1. Query the Local Machine for a list of certs assigned to it.
  2. Check the list of certs for a valid machine certificate.
  3. Verify that the certificate has not expired.
  4. Verify that the certificate has the proper template (that you specify).
  5. And finally, verify that the certificate has the proper subject (again, that you specify).
  6. If items 3, 4, and 5 are all in agreement, echo “True” back to SCCM, or “False” if no machine certs are valid.

Note that there are a few strings you need to specify. $template and $subject need to be set or this isn’t going to work. You can also set $hostname to your hearts content. There’s obviously a lot of different ways you can modify this script, but for creating a CI in SCCM 2012 DCM this is a good start. Have fun!

### Check for existence of valid machine certificate ###
# By Robert Hollingshead
# Contributions by Steven Buck
# Transform function for Template property from
# http://social.technet.microsoft.com/Forums/windowsserver/en-US/187698d0-5602-4301-9d0c-85e89d948ea2/user-powershell-to-get-the-template-used-to-create-a-certificate?forum=winserversecurity
# Checks the certificate store for a valid machine
# certificate then outputs True.

# Function to get Template.
function Transform-Certificate {
 [Parameter(Mandatory = $true, ValueFromPipeline = $true, ValueFromPipelineByPropertyName = $true)]
    process {
        $temp = $cert.Extensions | ?{$_.Oid.Value -eq ""}
 if (!$temp) {
            $temp = $cert.Extensions | ?{$_.Oid.Value -eq ""}
        $cert | Add-Member -Name Template -MemberType NoteProperty -Value $temp.Format(1) -PassThru

# Assume the store doesn't contain a valid cert.
[bool]$ValidCert = $false # Assume false.

# Get hostname+fqdn
$hostname = [system.net.dns]::gethostbyname(($env:computername)).Hostname

# Put the template string to match here. * is wildcard
$template = "*{a chunk of your template name to verify}*"

# Put the subject string to match here.
$subject = "CN=$hostname"

# Analyze each certificate in Local Machine.
foreach ($Certificate in (get-childitem -Path Cert:\LocalMachine\My | Transform-Certificate))
    If ($Certificate.Subject -eq $subject)  # If certificate has a proper subject.
        If ($Certificate.NotBefore -le (Get-Date)) # If certificate has not expired.
            If ($Certificate.Template -like $template) # If cert has proper template.
                $ValidCert = $true # It's true!

If ($ValidCert -eq $true)
        write-host "True"
        write-host "False"