Command-line view of ports in use
Here is a quick and easy way to dig into what ports are being used, and what apps are using them.

Step 1: Find out what ports are being used:
C:\>NetStat -o
Which will return the following (your list will probably be much longer):

Proto Local Address Foreign Address State PID
TCP EC968728:1108 somesite.corp.com:https ESTABLISHED 4072

Step 2: See what app (& more) is using that port:
C:\>TaskList /FI "PID eq 4072" /FO LIST /V
Which will return the following

Image Name: OUTLOOK.EXE
PID: 4072
Session Name: Console
Session#: 0
Mem Usage: 105,320 K
Status: Running
User Name: ****DomainName****\bgroth
CPU Time: 0:01:44
Window Title: Inbox - Microsoft Outlook

There you have it!

I used the following pages to dig into the NetStat and TaskList commands:

Top 10 Ways to De-Motivate Geeks

Top 10 Ways to De-Motivate Geeks

Everyone has a price. Sometimes, though, the cost isn't measured in
dollars and cents. I recently read the article Top Ten Ways to
Motivate Geeks, and being a geek myself, I got thinking about the
inverse argument: what can a manager do to piss off their technical
underlings such that they are less productive? After talking with a
few of my fellow geeks, I present, in no particular order, our humble
list of ways to de-motivate the technophiles that work for you. Note
that I use the word "geek" to represent anyone that works with
technology on a day-to-day basis, but particularly people working in
software development or IT.

Disclaimer: This is not directed at my current employer or its
management, and is not intended to describe any single person or any
single company. It was compiled from the opinions of several geeks
working at several companies in multiple states. Please don't fire me.

1. Insult their ability or intelligence

The best geeks are confident, almost to a fault (sometimes not
almost). As it is with any creative person, they don't do what they do
just to pay the bills. They don't just do what they do, they are what
they do. If you directly insult their programming ability, you're not
just insulting their code, you're insulting them as a person, and as
an artist.

Sound too wishy-washy? Maybe so. The best have a thick skin, and can
absorb criticism pretty readily. I'm not suggesting that you should
avoid criticizing them entirely — knowledge is a combination of
instruction, experience, and feedback. Without a critical review once
in awhile, they'll just start assuming that they're the best of the
best. (This is undoubtedly why peer code reviews are becoming popular
in XP environments.) Instead, restrict your criticisms to the product
of their ability, not their ability itself.

Another thing to remember: misusing terminology implicitly insults a
geek's intelligence. "Oh, that problem can be solved easily! Just
re-instance the variable with a generic!" Huh? If you don't know the
answer to a problem, don't offer your opinion — particularly if you're
not a geek yourself, or if you don't have the domain knowledge
required to contribute. Don't believe that by clobbering together a
bunch of language keywords that you'll convince anyone (particularly
someone who understands what all those words mean) that you know what
you're talking about.

2. Take credit for their work

This is directly related to #1. Remember, a good geek's work is a
labor of love. When you take credit for their work, you might as well
make a pass at their significant other while you're at it. If you're
going to take credit, limit it to credit for directing them only, and
leave any technical work that you weren't directly involved in out of
it. In fact, for bonus points, mention the geeks' contributions to
your superiors. Good geeks are team players, but they're also proud,
and it bothers them to never get recognition except as "a member of
(manager)'s team".

This particularly holds true for creative decisions. If you allow your
geeks creative latitude (and you should, see #5), reward them when
they take advantage of it and come up with a great idea. They will
remember it, and they'll be more apt to come up with creative
solutions the next time around. Likewise, if you take credit, they'll
remember it — but they'll start asking themselves why they bother to
come up with good ideas anyway.

3. Don't communicate enough with them

Geeks are information junkies. This is what lets them constantly
improve their skills and continue on the search for better ways to
solve problems. This also means that they want to know what's going on
in the company around them, and particularly the projects they're
involved in themselves. Within reason, answer their questions to the
best of your knowledge. This doesn't mean you should divulge things
that the geeks shouldn't know (for example, it's probably best you
don't get into financial specifics), but they should be made to feel
like they're "in the loop".

The best geeks aren't just geeks, they're also strategists, and
capable of understanding business. They want to know what the
company's primary goals are, so they can adequately improve their
skills to follow suit, and align themselves with the right projects.
This is more about self-preservation than anything else, but it also
stems from a natural desire to be on the cutting edge of everything.
The grand majority of geeks are very forward-thinking, and aren't
interested in using technology that's stagnated. They'd much rather
try out that new circular saw than be comfortable working with the
same handsaw they've been using for years.

Although you should be sure to communicate with them, you should
never, ever, ever lie to them. Geeks spend the grand majority of their
time dealing with factual data that is constrained by logic. They are
also likely to be able to follow logic through multiple complex
stages. If you do decide to lie to a geek, don't ever go back on your
statements, and don't try to layer more lies on top. Geeks will be
able to reason their way through your nonsense, and being naturally
cynical, they will start to disbelieve everything you say.

4. Communicate with them too much

While it's true that geeks want to be in-the-know, they don't want to
know about certain things (even if they sometimes think they do). For
example, unless they're wearing a sales-engineer hat, they should be
left pretty well out of the sales cycle. Their deterministic nature
will make it more difficult for them to understand why a client
doesn't see that their software is fantastic, because the code is so
clean and it uses this really cool idea for caching that they came up
with in the shower one morning.

Likewise, the job of a salesperson is to promise everything under the
sun to the client, and then produce just enough of what they promised
so the client doesn't get pissed off. Don't tell the geeks what the
sales staff is promising customers, or you'll start to see bottles of
Maalox show up on their desks.

5. Stifle them

Software development is a lot like art. When confronted with the task
of drawing a likeness of a person, anyone can draw a stick figure.
Likewise, anyone can learn VBA in a few weeks and jam together
something to track their coffee expenses. This artistry is one of the
reasons why software engineers and mathematicians are not
interchangeable. Geeks might not readily compare themselves to
artists, but they're much more on that side of the spectrum than, say,
statisticians.

The worst possible thing that you can do to a geek is say: "Here's a
fun and interesting problem, but because of (insert illogical reasons
here), you have to solve it in this way only." Even worse, keep them
in the dark about the restrictions until after they've finished a
creative and effective solution, and then give them some nonsensical
reason why it can't be used, like "Our customers know Java! We can't
possibly sell something that's not written in Java!"

6. Give them impossible deadlines or ask them to work ridiculous hours

Nothing destroys morale (and by extension productivity) faster than
hopelessness. Everyone wants to feel like their work is going to make
a difference, so if your geeks believe that success is impossible no
matter what they do, they're not going to bother. Bad morale is viral,
too, so it only takes one person on a team to become discouraged for
the entire team to be in danger. Worse yet, once they've caught the
hopelessness bug, ask your geeks to work 14 hour days to meet the
impossible deadline. Likewise, if you don't set reasonable deadlines
and instead ask that everything be completed yesterday, don't be
surprised when your geek ignores new requests and continues to work on
what they're already working on. Remember, you said that task was
absolutely vital two weeks ago. If every task ends up at #1 priority,
it falls to the geek to prioritize them, and that gives them the
opportunity to prioritize based on what they want to do on a given day
rather than what's best for the project.

That being said, crunch-time is a reality in almost all software
development projects. It's impossible to perfectly estimate the amount
of time required. Dozens of books have been written on the topic and
yet no one really has the magical formula. Sometimes the timeframe
will be have to be compressed in order to get the contract, or the
customer will change their requirements, or there'll be a flaw in the
design that makes you take a couple steps back, or whatever. Asking
geeks to work lots and lots of overtime will not yield more work. In
fact, there are some very good arguments that stretching the schedule
past 40 hours actually results in lowered production, because fatigue
creates "negative" work which has to be corrected later during more
lucid periods.

7. Make them work on "soul-crushing" projects

Every geek has been involved in, or knows someone who has been
involved in, a project that can only be described as "soul-crushing".
The first requirement for a project to be soul-crushing is that the
people that work on it consider it to be boring. Geeks, being creative
individuals, want to be intellectually stimulated by their work. If
they wanted every day at work to be the same, they would get a job
driving a truck, or digging ditches. (This is of course not meant to
denigrate the truck drivers or ditch diggers of the world. It's just
not my thing.)

There is a difference, however, between projects that are simply
routinely boring and projects that are soul-crushing. To rise to the
next level of pain, a project must meet other criteria. Here are some
examples:
It requires the creation of hundreds of similar components that are
just different enough that they can't be adequately abstracted.
Just the development will stretch on for years, with no end in sight.
Then, the geeks get to support it for the rest of their natural lives.
It's guaranteed to lose the company money.
It's built on a terrible foundation, or it tries to re-use or
re-purpose code that should never have seen the light of day in the
first place.

Projects don't start out being soul-crushing. Some projects are
horribly uninteresting, but any project can be exciting to the right
people under the right conditions. The existence of soul-crushing
projects in a company can be a sign that the company is in trouble.

8. Make them misrepresent their work

Salespeople are capable of walking into a company and telling
boldfaced lies about the stability or the features of a product.
That's good, because that's their job. It's a little like dating… you
lie to the other person until they love you for who you really are.
Without salespeople, the money would run out before the product is
stable enough to sell, and the geeks couldn't cover the monthly bills
on their MMORPG habit.

There's a reason geeks aren't good at sales. The best geeks are
hopeless perfectionists that can never be fully convinced that "good
enough" is good enough. When they look at their work, they see it
"end-to-end", through the sexy interface to the flaky API, through to
the buggy back-end and the twisted database with 14 bolt-ons that one
day, they really, really want to fix if they could just have a little
more time before it ships.

This understanding of their software (which I call "x-ray vision")
allows them to do their job, but at the same time, it makes them doubt
the product. They know that there's a kludge in that function around
line 43. They know that the memory requirements are such that the
software won't scale past about 10 concurrent connections given the
current hardware. Worst of all, they know that the software hasn't
been tested yet, or if it has been tested, it has dozens of
outstanding issues in the bug tracker. None of these things are
apparent when all you can see is the sexy interface, which is as far
as the salespeople and the customers see.

Unless sales is part of their job description, don't make geeks lie
about their work, not to the customer, not even to their co-workers.
Even worse, when they tell you the software's not ready or that guy in
marketing that promised that customer a holographic smell-o-vision
interface is nuts, don't…

9. Ignore them when they know what they're talking about

Sometimes, there's a fine line between confidence and egotism.
Sometimes, there's a fine line between giving an honest opinion and
crying wolf. If a geek raises the red flag and starts waiving his/her
arms at you, pay attention to them at least long enough for them to
try to plead their case. If you don't believe them, don't just ignore
them — reason with them why you disagree. Remember that geeks are,
above all else, built on logic. If you think they're being overly
emotional, chances are there's a reason for it, and you might want to
pay it heed. If you don't take them seriously, it raises the chance
significantly that they won't take you seriously next time.

10. Don't adequately protect them from customers

First, it's important that you remember that the customer is not
always right. Sometimes customers make stupid requests because they
don't understand what they want, or they don't understand what they're
asking for. Some customers think using the telephone, and ask for
something that they feel will solve a problem before reasoning out the
situation on their end. It's important that you don't make geeks field
too many of these requests. Unless everyone is sitting around playing
World of Warcraft because there's no work to be done, one of your jobs
as manager is to triage the resources that you have available.

Unless they're paid to do so, geeks don't want to have to figure out
what clients want for themselves. They want you to translate the
"client-speak" into objectives, which they will then translate into
code. If the geeks are spending their time on the front lines, they're
not spending their time in the trenches, making the product better. If
their business card doesn't say "support tech", don't put them on tier
1, because this will only result in less code being generated, and one
very pissed off developer.

What's New in SQL

Have you ever used the coalesce function it will reset a NULL value to the value you pass it.