Project Server Help Blog

My participation in on-line communities began during the bad old days of dial-up BBS and continued through participating in UseNet groups since the very early days of Compuserve, and I have a deep appreciation for the wealth of information and support these forums provide. Through the years, I’ve often wished that I could point people to a good how-to for effective newsgroup posting. With the introduction of this blog, I thought it was high time to whip one up!

The first thing you should do when you seek help in the Microsoft Communities news groups is not to start writing! Rather, you should start by searching the archives to see if someone has already asked the same question and an answer is readily available, which spares you the wait time. You should consider leveraging Google Groups to do your searching as Google retains the most history available for your search, unlike the Microsoft news servers, which contain only 30 days of history. To search the Microsoft.public.project.server newsgroup on Google, use this URL: http://groups.google.com/group/microsoft.public.project.server

Note that you can search other project newsgroups or other Microsoft Newsgroups if you substitute the name of the group after the last forward slash in the URL. For instance, “microsoft.public.project” for the Project client newsgroup or “microsoft.public.project.developer” for the developer’s group.

• Verify that you cannot find a post that sheds light on your problem, and then start writing. The most important information you should specify in your post is the software version you are using, and if possible, include the service packs or updates applied to your system. Keep in mind that three versions of Microsoft software can be considered supported at any one time, so if you don’t include this information, your first turnaround message is likely going to be someone asking you for this information.
• Next, include a careful and complete description of the problem. Be certain to explain the actions to take to recreate the problem. Always include copies of any error messages that you receive being careful to copy and paste, or carefully transcribe them if necessary. Do not try shorthand or abbreviate this information! More is better.
• Include information describing what you have done to troubleshoot the problem. For instance, if one user experiences a problem, do other users experience the same problem when they take the same actions? Does the user experience the problem on one machine or all machines? Do only some users experience the problem and not others? If so, what might these users have in common? If you haven’t used some probing techniques like this before you start posting, go back to the system, experiment a little, and report your findings. This type of preliminary trouble-shooting can save days of back-and-forth in the newsgroup.
• Avoid “me-too” posts. By this I mean, you find a post that sounds like it may be your problem, so you jump in and add a reply that starts with “I have this same problem…” and ends with “have you found a solution?” There are several problems with this type of approach. Firstly, you might have similar symptoms, but a very different problem. Keep in mind that many software errors are “catch-all” in nature and can be quite meaningless in that they can apply to hundreds of error conditions. In these situations, you are starving your potential respondents of valuable information. Another problem with “me-too” posts is that the original post may no longer be available on the server for a respondent to retrieve. Remember that someone reading directly from the Microsoft source servers can only access 30 days of history, so do not make your volunteer helper have to go off searching and hunting, as your question will seem more like work than a pleasure to answer. Always take the time to describe as much about your experience as possible and do not jump to conclusions that same symptoms equals same problem.