I still remain very active on Experts Exchange, fitting it in with client work. Very handy thing to do while wait for an OS or application to install, server to reboot, or mailboxes to move.
During the weekend I also became a page editor for the Exchange Server topic area, and in the last few minutes I have just hit the landmark level of 8 million points.
What makes a good expert become a great expert?
Becoming one of the great experts on Experts Exchange (EE) is not easy, it takes a lot of hard work.
However many people become good experts, but fail to go that extra mile to become one of the greats.
How do you become a great expert?
Here are some points on how to become a great expert. Examples, where given, apply to Exchange server type questions because that is my specialization. They could apply to other topic areas equally as well.
- Read the Question.
So many of the answers I see are not suitable because the responder has failed to read the question properly. Most common is responding with an Exchange 2003 technique for an Exchange 2000 problem. I have been guilty of this myself.
Check the question text for what platform is being used, and if required, ask them to confirm. In some cases the underlying Windows version also plays a part.
If the questioner states that a certain solution is not suitable, then don't offer it as a solution, unless it is the only solution. Be prepared to explain why (see below - justify your answer).
- Only respond if you know the answer or are really sure that you are pointing the questioner in the right direction. Don't waste the questioners time.
Many of the responses I see are totally wrong. Asking a questioner to check the services are running for an intermittent mail delivery issue is simply a waste of time.
If you are taking a punt, because you are pretty sure, but not 100%, then say so. That way another expert might come along and correct you, support you or give an alternative.
- Know your strengths and your weaknesses.
One of my weaknesses is Exchange 5.5 - I haven't worked with that version for some time. Therefore I avoid where possible any questions relating to Exchange 5.5 because I cannot answer them to the high standard that I have set myself.
If you don't know, then skip the question, rather than getting the hopes up of the poster, only to have them dashed because your response isn't correct.
- Follow up.
Don't abandon the questioner. If you don't know the follow up question, say so.
However due to the nature of Experts Exchange, don't expect another expert to chip in with a response. Some of the topic areas are very high traffic. Once the question has gone past the first page, most experts don't look at them again. You should suggest that the questioner asks the follow up question separately, or posts a pointer to the original question.
- Give accurate answers.
By this I don't just mean technically accurate, but the whole answer is polished.
If you are posting URLs, then make sure that they work. I check all of my URLs, even those that come back to my own web site. I have made errors before, so now check.
Check your answers. If you are sending someone to a certain window in a tool, then check the full path and quote the full path. Don't presume that the person who has asked the question knows their way around the application.
- Justify your answer.
Don't give one word answers as they don't really help. They answer the question, but they don't tell the questioner why. Give a brief explanation and where possible a URL, preferably back to the software developer's own web site which explains things in more detail.
As well as providing a response to the specific question, I also see part of the role in answering the question is to educate others.
With the way that Experts Exchange works, someone might look at the response in six months time when looking for another answer.
Therefore where appropriate I will provide alternatives or additional things to look out for.
The migration to a new server questions are classic examples of that.
- Be consistent.
If you develop a technique, then stick to it. If you keep changing techniques, then someone will post that you said such and such three months ago. Develop the technique, and if you change it, be prepared to explain why. A web site or blog can help with this (see below).
- Have a web site or a blog.
Take your best answers and turn them in to a blog or web site article. Many of the things on amset.info started off as an answer to a question on EE. Where I needed to research the response to a question or develop a technique, I would post the answer.
Once I was sure it works, take the answer, clean it up, apply screenshot and font changes to make it more presentable and it then becomes a good quality web page that you can refer to in future answers.
- Presentation.
The presentation of a question is very important. If presented correctly then it gets the information across in a clear way, and anyone else looking at the question will understand what you mean.
Obviously, punctuate the answer correctly, with good spelling.
EE doesn't have a built in spell checker, so I use a free Internet Explorer plug-in called iespell (http://www.iespell.com/). If I am using a machine that doesn't have this installed, then I will use either Word or Outlook to spell check the response, then copy and paste it back in again.
Use common acronyms only - not any that you use internally within your company or group that may not be in widespread use. If you do need to use a non-standard acronym, then use the complete phrase first, then put the acronym in brackets later: Experts Exchange (EE).
Avoid the use of txt speak - m8, l8r, etc. This looks unprofessional and can be difficult to read. This is a public professional forum and it should be treated as such.
Other shorthand should also be avoided, w/ (with) and b/c (because) which are almost exclusively used in the USA. Remember that these forums are available to anyone in the world, whose first language may not be English and they may not understand what you have written.
Space the answer out as it makes it easier to read. Think how newspapers and magazines are laid out. The text is rarely in a single block. Look at the presentation of this blog posting - each point is separated out.
- Don't steal another person's work.
That doesn't just mean lifting a post from elsewhere on the site, but also from other web sites and blog postings. This is particularly the case with Microsoft KB articles and major web sites that update frequently (like my own).
Post a link instead, so that if the information is updated, the latest information is always available.
Copying and pasting someone else's work is theft - pure and simple.
As far as I am concerned, if I find anyone copying my work, then I will ask for it to be removed.
By paying close attention to the answers that you give, your work and knowledge will become trusted and welcome.
Last week it was speculated in the Experts Exchange Newsletter who would be the first to six million points in a single topic area - me or objects (see here http://blog.sembee.co.uk/archive/2006/03/03/8.aspx).
Overnight (9th - 10th March) I won that little race.
To give you an idea of the level of achievement, my six million points in the Exchange Server Topic Area is more than anyone other than the top five (at the time of writing) experts have on the entire site.
I guess the next target is first to 10 million points overall!
A constant theme on many of the Internet forums is the use of self generated SSL certificates versus purchased SSL certificates, particularly when deploying RPC over HTTPS or Outlook Web Access.
Many people will advocate that using a self generated certificate is fine and will do the job.
This could be a certificate generated from the selfssl.exe tool that is supplied with the IIS Resource Kit, or Microsoft's certificate application.
However I am not one of them, and always deploy Exchange with a purchased certificate.
Use of SSL Certificates
SSL Certificates have two main tasks.
- To prove that the server you are accessing is the server that you meant to access.
- To encrypt the connection between the application being used to access the server, and the server itself.
There are three things that your web browser looks for when accessing a secure site.
- that the name on the certificate matches the address being accessed
- the certificate is issued by someone the browser trusts, or the certificate matches one already installed on the web browser
- the certificate is valid.
If any of those three fail, then you will get a warning message popup.
With self generated certificates, you will get the warning message when you access the server. This is because the certificate hasn't been issued by a trusted authority.
You can get round that warning message by importing the certificate in to the web browser. However that makes a lot of work with deployment, complicates matters and also means that you have to repeat the exercise when the certificates expires.
It also doesn't help when people are accessing your site from a public computer where you cannot install the certificate, such as an internet café or their machine at home.
And that is where self generated certificates start to cause problems.
You can tell your users to ignore the message when connecting to your site, but users have a habit of only hearing what they want to hear. They will hear "ignore the message" but forget the bit "when using our site". In these days of phishing and spoof web sites network administrators need to give out a consistent message - and telling users to ignore a security warning is a very example of failing to do that.
A security warning of any kind looks unprofessional and shows a lack of concern for security.
So what are the alternatives?
The best alternative is to purchase an SSL certificate.
However many administrators think that they need to go to one of the big SSL certificate issuers such as Verisign and pay US$400 or more per year - and that is just for a 40 bit certificate.
That is not the case.
I do my deployments using RapidSSL certificates. They cost US$69 per year and that is for a 128bit certificate. Their root certificate is in most of the popular web browsers so there is no complication there.
If you do need to deploy the certificates to Pocket PC devices, then that can be easily done (see http://www.amset.info/pocketpc/certificates.asp).
You could also certificates from Certificates for Exchange which are trusted by Windows Mobile 5.0 with MSFP and higher. Nothing to install on the devices making deployment easy.
You may also see some "free" SSL certificates around. These should be looked at carefully, paying particular attention to the root certificate support. If the root certificate isn't in the majority of web browsers then you will have the same problem as when issuing your own certificates - prompts and imports.
Do Self Generated Certificates Have a Place?
Yes they do. I use them all the time in lab environments. When I have control over every item accessing the service, then I will use the a self generated certificate and make all of adjustments as required to get it to work correctly. However in a production deployment, they are never used.
Yet another mention in the Experts Exchange Newsletter. This is starting to get embarrassing.
See the original here: http://www.ee-stuff.com/Newsletter/022806newsletter.htm
However here is the quote:
Kudos: There aren't enough superlatives to describe what Sembee has accomplished since he joined EE a little over two years ago. First he makes Rookie of the Year, and follows that up as Expert of the Year. Then he becomes the first EE member to crack the 7,000,000 point level; 5.8 million of those points -- more than all but five members have in total are in the Exchange Server topic area. It's a race to see whether he or objects will be the first to reach 6,000,000 in a single topic area.
