OnQ

On Confirmation

After much wondering and guesswork, Microsoft Small Business Server 2003 Unleashed is finally hitting bookshelves around the US! For some reason, delivery has been a little hit and miss, as there are some bookstores that still show the book as "unpublished" but reports are beginning to trickle in of sightings on shelves in brick and mortar locations.

Those who have preordered copies from Sams Publishin should start receiving them soon. Those who preordered from other resellers will hopefully start receiving their copies around the first of the year.

On Documentation

While getting caught up on some billing and administrative whatnot this weekend, I ran across a few items that I wanted to review when they came up, but just didn't have the time. Fortunately, I had saved them for later review, which means about 4 times a year I'll go through the archive and do a quick scan through all the stuff that's collected there and usually end up deleting most of it.

There was a common theme I picked up when going through the pile this weekend, and it's definitely worthy of a blog post, if not a whack from Susan's famous 2x4.

Technicians look at errors and use them to find solutions to problems.
Good technicians document these errors for later review.
Great technicians share this documentation with others so that they can avoid reinventing the wheel.

Here's what I mean:

For the past two years, I've been participating in the SBS public newsgroups, the forums on smallbizserver.net, and several mailing lists. By participating, I mean that I've been responding to posts/messages/whatever, trying to help those who have submitted pleas for help. [Granted, I've been a lot less active in the newsgroups of late, spending more time in the forums at smallbizserver.net, but that's another story.] And by no means am I the only person doing so. A great number of people in the SBS community do this as well, especially the MVPs. The great thing about the newsgroups and the forums at smallbizserver.net is that Google indexes them both, so it's fairly easy to find a post or response to an issue with a simple Google search. The experienced folks in the community know this. Folks new to the community usually figure it out fairly quickly.

Anyway, I ran across a couple of messages this past weekend that exemplify the point I'm trying to make. While these may seem self-serving at first, that's not what I'm trying to get at. There are hundreds of examples of this throughout the community. I just happened to notice these because they've got my name attached to them.

Example #1: A post to one of the SBS mailing lists where the author noted that he found the solution to his problem by Googling the error and finding a solution I had posted in one of the newsgroups.

Example #2: A post on a rather famous blog where the author noted that she found the solution to her problem by Googling the error and finding a solution I had posted in one of the newsgroups.

OK, so it was the same newsgroup post that was the answer to both issues, but the point is the same. Because I posted the specific errors and the solution in the message, someone else who had the same problem was able to find the solution by searching on the error. I try to do that whenever possible for exactly this reason. Even if the error and the solution aren't in the same post, in the case of newsgroup postings or message threads on smallbizserver.net, you can generally scan through the thread returned by the search and find the solution, if it's been put in there.

When working with my clients, I try to get them to write down the specific errors they see, word for word, to help me find the solution more quickly. I then document those errors in my internal database for future reference. For the more interesting errors/solutions, I'll create blog posts or post to the newsgroups or mailing lists or whatnot. The bottom line, if I've run across a problem, chances are someone else might hit it, too, and if I can get information on a fix out there in some way that will help someone else find and fix the problem quickly, then why not?

Now, to the real reason for this post - it's from an older post on Susan's blog, but the sentiment cannot be reiterated enough. Down at the bottom of the post, Susan has this to say:

Calling into Product Support Services means that the issue will now be documented, my SRX case will be filed and the next time someone hits this issue it will be known immediately and that person fixed right up.

And she's exactly right. One of the key reasons that the folks on the CSS support lines are so successful is that they have a great internal knowledgebase to look up errors and find previous cases where those errors were reported and the solutions that fixed them. This is not intended in any way to detract from the technical abilities of those working the line. I know a number of those folks, and they're some of the best in the business. But there's a reason they ask for the exact errors that you see and often request complete log files and other troubleshooting data. That's so they can look to see if other cases have reported this information and find the documented fix for it. But more importantly, if your issue, like the one Susan discussed in the post, is unique and one that they haven't run across before, they can get it documented so that the next time someone calls in with the error, the solution can be found and delivered quickly.

So, two notions to wrap up this post. First, if you participate in the public forums, either requesting or providing troubleshooting, be sure to provide sufficient details about the errors and solutions so that both can be Googled. I can't tell you how many times I've run across the solution to a problem within the first two hits from a Google search.

Second, if you spend more than 15 minutes Googling a problem and can't find a workable solution, pick up the phone and call CSS. If they've already got the solution in their systems, you'll likely be back up and running fairly quickly (of course, that depends on the nature of the error, but you already know that so I won't dwell on that here). If they don't, once they do get the solution, it will be documented and available for future callers who may have the same situation.

But the bottom line is this: document, document, document. If you don't have the documentation, you're going to have a harder time navigating to the solution.

On Sightings

Tim Barrett has one. Amy Babinchak got hers. I'm still waiting on mine.

But the book is out there. I know of at least two people who have not only seen it, but have held it in their hands. If you have received yours already, or if you have held it in your hands while in a bookstore, please drop me a note (comments below are just fine) and let me know where you saw said book.

Of course, I'm talking about Microsoft Small Business Server 2003 Unleashed from Sams Publishing. In case you didn't know...

On Ethics

I had a plum dropped into my lap tonight. A potential client contacted me because the consultant they were working with on a project had to bow out for some reason, and they were referred to me by a mutual acquaintance. They are planning on a complete server rebuild of their SBS 2003 installation this weekend and need some help with it.

Within just a few questions, I found out what's really going on. They are changing their company name and need to modify their DNS records to make that happen. Unfortunately, when the site was originally installed, they used the public DNS name for their internal Active Directory namespace. The consultant that they had worked with told them (correctly) that if they wanted to change the internal domain name, they would need to reformat and rebuild the server.

I could have left it at that and taken the job and netted a nice little profit this weekend. Instead, I discussed with my contact that he really didn't need to change the internal domain namespace even though they are changing their public domain name. All of the work they want to do, in fact, can probably be handled with about an hour of effort on my part, if they can live with the internal domain name staying the same.

As a business owner, there's no way I could accept the job as originally proposed when there was a solution that would cost them so much less to achieve. Because that's exactly what I would want from a vendor I contacted for service. If there's a better way to get something done, especially if it will cost me less, I want to know about it.

Now this potential client may have other issues that would also be best served by a complete rebuild, and my contact is looking into that. For example, if the server was not built correctly in the first place and is having performance issues, sure, a rebuild might be a good solution, especially if they really want to change the internal domain name. Or the business owner or other key contact may say that they don't care what the cost is, they need to change the internal domain name. Whatever the next conversation with the client holds, I'm going to work with them to determine what the best course of action will be for their business. Sure, I could have made easy money on a rebuild, but if that's not in their best interest, then it's not in my best interest. I'm not interested in making a fast buck if it's possibly going to have a negative impact on my reputation down the line. So long as I act in the best interest of my clients, it's a win-win for everyone involved.

On December 13

It's official, the book is out! An actual printed copy has been sighted!

Tim Barrett, one of my co-authors on the book, just IM'd me and said that he just got his hands on one that he will be using to promote sales of the book in his user group meeting tomorrow night. He assures me that the cover is in fact orange as we expected.

Those of you who preordered copies should start receiving them soon. Those of you who didn't, well, now that you know it's out there, you can go order or pick up your copy.

Apparently, no special consideration was given to the primary author's home town. A quick check of my local bookstores yesterday and today revealed that they have no copies to put on the shelves. I'm sure that's just an oversight...

On smallbizserver.net

If you haven't been to the smallbizserver.net site, you must be living under a rock. I have it right up there next to Susan Bradley's blog as the two best places to get information and answers about Small Business Server.

If you haven't been to the site since December 10, then you've missed the following announcement that was also posted to the SBS 2003 public newsgroup:

"As per December we are proud to announce that Eriq Neale is now part of the Smallbizserver.Net Remote Support Team. Eriq is known for his excellent contributions to the Smallbizserver.Net forum and specifically the Mac forum. Also Eriq being located in the United States makes it possible to get support 24 hours per day.

We welcome Eriq to our Support Team as our 3rd Magical M, the M of McGuru.

Small Business Server - Frequently Asked Questions:
http://www.smallbizserver.net/Home/tabid/36/Default.aspx

Remote Support Services by M&M:
http://www.smallbizserver.net/Support/tabid/219/Default.aspx"

I'm really, really excited about this. First, it's an honor even being associated with such an outstanding site. Second, being asked to help out with Remote Support through the site was something I never even considered.

Thank you, Mariette and Marina, for including me in your team. I'm thrilled to be working with you two!

On Blogging

When I put together my last post on the joys of LiveMeeting and the Macintosh, I did something a little different. At the time I decided to do the post, I was sitting at a PC, not at my normal desktop Mac. That's just one of the benefits of using a web-based blog publishing system - I can blog from anywhere, including my PDA. But I digress.

So I wrote the blog page on the PC and, as I usually do, I checked the appearance of the final result, because I had used a lot of special HTML formatting in the post. Lo and behold, the main page looked and read fine, but the "read more" page was all out of whack. Thinking it had something to do with my special formatting affecting the CSS in the site, I went back and removed the formatting. No change. Then I went through and looked at several other entries on the site, and they were all out of whack, just like the most recent post.

That's when I realized that I committed one of the sins that I yell at other web developers about: when I updated the templates on the site, I didn't check for cross-platform compatibility. Ironically, the site looked fine from my Mac browsers, but it choked in IE 6.

So over the course of several hours this morning, I went through and finally found the source of the problem and restored the formatting of the site to normal. In the process, I came up with three morals to this story.

Moral 1: Always, always, always do a cross-platform check on your web pages. Open the site in multiple browsers on multiple platforms. Normally, stuff developed for the web works fine on Windows and breaks on the Mac. But in this case, it worked fine on the Mac, but broke in Windows, because...

Moral 2: IE 6 does not adhere to CSS specifications correctly. I ran across a number of sites discussing the problems of certain standard CSS functions not working correctly in IE. I found and fixed a few that I had introduced when I customized the template I was using. But the core problem came from...

Moral 3: Never assume that when you acquire software from a vendor that they know what they're doing. In this case, the developer of the template I was using munged the headers of all but the main index template. I didn't find the exact piece that caused the problem, but when I copied the headers from the main index template over to the other templates, the pages started displaying correctly again.

Now I can sleep better knowing that the regular readers of this blog (all both of them) won't have to deal with odd formatting when they read an extended or past entry on the site, as they apparently have been doing without complaining for several months.

Unless they've been reading from a Mac...

On Improvements

I've been preparing for the Macintosh in SBS webcast coming up on December 8. Through the process, I've learned quite a bit about the changes that Microsoft has made in the LiveMeeting product after they acquired it from Placeware. But first, a couple of observations:

• Susan Bradley rocks. Most of you already know that. She has bent over backwards to help me get this webcast together.
• Microsoft seems to have actually improved the Macintosh support for a predominantly Windows product.

Still getting this webcast out the door is not going to be a piece of cake. Here are some of the challenges I'm having to overcome to get this to a point where I'm even comfortable presenting this webcast.

Presenting from a Macintosh

In this new version of LiveMeeting, not only can you attend a meeting using a Mac, but you can present as well. Given a few conditions.

First, you can only connect using Safari on the Mac. The presenter (and meeting) console are available as Java tools, but for some reason, LiveMeeting refuses to allow Netscape or Firefox connect, even though they can run the Java applications just fine.

Second, the console is completely different from the PC console. Yeah, yeah, yeah, this is the ActiveX versus Java builds, but it would have been nice if the interfaces were at least somewhat similar.

Third, there is no audio support for the Java console as attendee. If you want to attend a LiveMeeting from a Mac and listen to the audio, you have to hope that the meeting has a dial in number so you can audio conference. Just remember to press #6 on your phone when you get connected so your connection is muted. Trust me, no one wants to listen to the sound of corn chips being eaten during a meeting.

Fortunately, Microsoft has improved the presenter tools from the Mac in one key area - you can now share the desktop from a Mac. This improvement, of course, is the only reason I'm able to do this webcast at all. There's really not much value in a webcast that has screenshots - I've got blog posts that do that. No, the real value here is being able to show, real time, what's going on in the Macintosh interface, especially for those who have not seen the interface before or in a long time.

Preparing the presentation

LiveMeeting uses the PowerPoint slide show as its basic presentation methodology. No big deal, I'm used to doing slide decks, all the way back to the days of Persuasion. (Raise your hand if you remember that tool. Yeah, I didn't think there would be many of you.) You can either create the slides in the LiveMeeting presenters interface, or you can create one off-line in PowerPoint and upload it into the meeting space when you are ready.

Unless you're on a Mac, that is. Though LiveMeeting offers a tool to convert a PowerPoint slide deck into its online slide format, it doesn't work from the Mac. All I could do from the Mac was upload the converted slide format media. No problem. Let me just export from PowerPoint on the Mac into the LiveMeeting document format. Hm. Not an option. OK, so I search the Microsoft web site for the conversion tool. Oh, yeah, there it is. Let me download it, except that it's not available for Office 2004, or any version of Mac Office. No problem. I'll download the tool to my PC, convert the deck, upload the stuff from my Mac into the meeting space, and go on from there. Interestingly, a 300K slide deck becomes an 8MB LiveMeeting file. And when I go to upload it from my Mac, LiveMeeting still won't accept the upload.

This is where I figure out that I can connect in to the meeting as presenter from my PC and can then disconnect without closing the meeting. I'm glad I stumbled across this nugget of information, because I'll need it later.

So I upload the file from the PC (and since it will do the slide deck conversion automatically, I didn't need to download the tool to convert the deck into the LiveMeeting format) and can still modify the presentation inside the LiveMeeting console using my Mac.

Broadcasting Audio

So I've got my presentation uploaded, I've been able to share my desktop, now to the last piece - audio. As a presenter, I have a phone number I call into so I can present the material by voice. In my test meeting, where I've got several workstations in my office connected, I fire up the audio on the PC after I dial in, and I can't hear anything on the PC. Nothing. Nada. Zip. Zilch. What we call "dead air" in radio parlance.

Susan points out that I need to click the Start Broadcast button in my presenters console. Oh, wait! There's no Start Broadcast button in the Mac presenter's console. This is where I learn that not only can I log in and out of LiveMeeting as a presenter without ending the session, but I can also log in as presenter from multiple machines. Excellent. So I log in as presenter from my PC, find the Start Broadcasting button, and lo and behold, audio across the internet! Unless you're on a Mac, but I've already covered that.

Recording the Meeting

After doing more testing on audio quality and desktop sharing speed, I'm ready to test the recording function. There is a Recording button in the Mac presenter's console, and when I click that, I find the equivalent of the Start Broadcasting button. I bypass that for the moment, as I'm already broadcasting and I want to start recording. Sure enough, I can start, pause, and stop recording in the Mac presenter's console. What's even cooler is the audio level indicator that moves based on the sound of my voice into the phone. In the Macintosh presenter's console. So we can tell audio levels from the Mac console, but we can't actually listen to the audio on the Mac. Anyway, I record the test session and stop it when I'm done. Pretty straightforward.

More audio

After a successful test that proves I can do what I want in this webcast, even if the setup is a little weird, I give the green light to move forward with the scheduling. That's when I decide to play with the audio a little more. After clicking the Stop Broadcast button in the Windows presenter's console, I go back to the Mac presenter's console and click the Recording button again. The console clearly shows that there is no audio connected, but with the click of a button, the console implies that I can actually start the broadcast from the Mac after all. So I try it. Sure enough, it seems to connect to the teleconferencing system, because I can see the audio levels move in the meter when I talk. But nothing is coming across the internet audio. I bang on it a little further, then I look at the Audio console in the Windows presenter's console. It doesn't think there's a broadcast going. I click on the Start Broadcasting button, audio starts flowing from the teleconference system across the internet.

I'm not 100% certain this isn't a glitch given that I started the broadcast from the Windows console initially. I'll have to test another conference setup and try to initiate the broadcast from the Mac side without even logging in to the Windows presenter's console and see what happens.

Come time for the actual webcast, here's what I plan on doing to prepare for the show:

1. Log in as presenter from a Windows PC.
   
2. Upload the PowerPoint slide deck from the PC.
   
3. Log in to the presenter's console from the Mac.
   
4. Modify the presentation deck to include the Desktop sharing slides for the Mac demos.
   
5. Call into the teleconference line.
   
6. Start the audio broadcast from the PC.
   
7. Start the recording from the PC or the Mac.

Yes, it would be nice if I could get all the parts and pieces working from the Mac side, but I'll take what I can get. The biggest hurdle, sharing a Mac desktop in a meeting, has been overcome, so the rest is really just a minor annoyance, and an annoyance I can certainly get around.

And, for all this effort, I sure hope people show up for the meetings. Both of them. (Meetings, not people, that is.)