OnQ

On Awards

eriq — Thu, 01 Jan 2009 16:26:00 GMT

I'm proud to say that, as of this morning at 8:30am CST, I received my notification that I've been awarded MVP status for the Small Business Server product for another year. I greatly appreciate this recognition from Microsoft for my activities in the community over the past year, and I'm looking forward to continuing the same through 2009. With the launch of Third Tier and our series of webinars on SBS 2008, I'm excited about what this new year will bring.

On SMB Conference Call

eriq — Wed, 17 Dec 2008 15:28:00 GMT

Just a reminder that I'll be the guest joining Karl Palachuk in this weeks' SMB Conference Call. We'll be talking about (if you can believe it), the SBS 2008 Unleashed book as well as SBS 2008. Registration is still available for the call. Hope to see you there!

On Availability

eriq — Thu, 04 Dec 2008 12:43:08 GMT

While December 10 is the "official" release date, I'm proud to say that Windows Small Business Server 2008 Unleashed has completed its press run and is en route to resellers as we speak. How do I know this, you ask? Simple - I've put my own hands on one:

Soon, those of you who have placed pre-orders will be getting you copies delivered to you, and those of you who choose to wait until you see a book on a shelf before purchasing should be able to go to your favorite bookstore and take a gander.

There are a number of people I need to thank who helped out with this project - it was far from a solo effort:Amy Babinchak, Steve Banks, Tim Barrett, Susan Bradley, Dean Calvert, Cris Hanna, Kevin James, Jeff Middleton, and Kevin Weilbacher added significant contributions to the book. Loretta Yates from Pearson was a great editor to work with through the project. And my wife, Anna, put up with the long nights and work weekends over the last year as the core writing of the book was done.

Hopefully you'll get as much out of the book as we did putting it together for you!

On False Positives

eriq — Thu, 27 Nov 2008 13:19:00 GMT

Sophos is not immune, either.

Over the last couple of years, several anti-virus vendors have had some bad press related to false positives that deleted significant or important files from systems. My anti-virus vendor of choice, Sophos, has not been one of those mentioned. Until today.

Last night, I received antivirus alerts from several systems that Sophos had found and taken action on several files, most notably QuickBooks files (C:\Program Files\Intuit\QuickBooks 2009\Components\PConfig\Data1.cab, although it was the same thing for versions all the way back to 2006 as well). I had already been in the process of changing the default actions of Sophos to "quarantine" instead of "delete" but had not hit all of my systems with that update yet. I put a quick call into Sophos tech support early this morning (gotta love that 24x7 support when you need it) and found out that their update that was released last night before 9pm CST had a false positive string in it, and the scheduled scans I had set to run at 9pm on these systems used that false positive update and nuked these QB files. Sophos did report that they have already released additional updates that have alleviated the problem, but because of the timing of the updates and the timing of my scheduled scans, several of my clients have QuickBooks data files that I get to go back and restore.

In the grand scheme of things, this isn't huge (like nuking a Windows system file) but for my accounting and financial services clients, well, it's a good thing it happened on Thanksgiving morning so it will minimize the impact on their operations. We'll be able to restore the specific file from backup in most cases, and worst case do a reinstall of the app on a workstation. Much better than having to rebuild a box or reload the OS.

Over the weekend, I'll be finishing up getting my Sophos configs updated to "quarantine" and not "delete" to help protect against future false positives. Still, just goes to show, it can happen to anyone. Past history of false positives (or lack thereof) shouldn't be the only deciding factor in choosing an anti-virus solution for your business or your clients.

On Migration - Opening Eyes

eriq — Mon, 03 Nov 2008 16:01:22 GMT

If the only thing I do for the community the rest of the year is to get a few more IT Professionals to not only think seriously about SBS 2008 migrations but to actually start training on the process, I'll take it. That's how important I believe it is. The SBS 2003 to SBS 2008 migration is NOT your familiar SBS 2000 to SBS 2003 Swing Migration. SBS 2008 is a completely different product, and as a result, the path to get there is completely different as well.

I started talking about the need to learn about migration back in August in a post from this blog. I mentioned it again in a guest blog I'm doing for Network World this month. Susan Bradley talked about it in a post from October 30, 2008. There have been discussions about the migration story in the SBS 2008 newsgroups and over on smallbizserver.net. Several threads about migration have cropped up in a number of SBS-related Yahoo groups.

The common theme from the folks who worked with the migration process during the SBS 2008 beta is this - learn about the migration before you do one, and start that learning process now. If you're assuming that because it's all wizardized that SBS 2008 will have any similarity to SBS 2003, that's a faulty assumption. This is a vastly differnet product, and there will be a learning curve to becoming proficient in supporting the product. That learning curve is even steeper when it comes to migration.

Please, if you haven't already, look at the SBS 2008 Migration Document from Microsoft. Keep checking the link to the Latest Version to make sure that you are working from the most recent update to the document (the development team has assured us that they will be continually updating the document as they identify issues that need to be corrected). Test the migration process against a clean, freshly-built SBS 2003 server. Test the migration process against your own server (virtually, in a lab). Test the migration process against one of your customer's servers that's a really crusty server with lots of apps installed (virtually, in a lab). Trust us, the time you figure out there's an "oops" within the process is when you're testing the process for your own training or documentation, not when you're out trying to do one of these things for a customer.

On Blogging

eriq — Wed, 29 Oct 2008 20:27:11 GMT

As part of the marketing for the upcoming Windows Small Business Server 2008 Unleashed book, I've been given the opportunity to have a blog space over at Network World for the next month. I'm excited about the opportunity to share my experiences with SBS 2008 with that audience, and hopefully the information will be well received.

The first post in that series went live today. You can read Small Business Server 2008 - Start Looking Now at your convenience. Enjoy!

On Roles

eriq — Mon, 27 Oct 2008 21:41:00 GMT

One of the more powerful features of SBS 2008 is the User Role concept, based on the roles that were available in previous versions of SBS. These Roles are like account templates that can establish a common group of settings for one or more users in the network. Unlike the SBS 2003 Account Templates, however, the SBS 2008 User Roles are much more active, and if you're not careful, you can get yourself into unintended trouble.

Let's take a trivial example. You have a user with a large mailbox, and you don't want that user subject to to the default Exchange mailbox quota. You go in and modify that user's settings in the SBS console, and that user now has no Exchange quota. Super.

Down the line, you learn that you can modify the folder redirection settings for users by modifying the User Role. So you go into the Standard User Role and update the folder redirection settings. You save the changes to the role, and when you do, it lets you know that it's going to apply those changes to all the users who have the role assigned. Great, that's exactly what you want. Life is good.

Suddenly, you get a call from the user with the large mailbox and that user tells you that he (or she) can't send or receive e-mail. Oops! When you reapplied the role, you inadvertantely reset the Exchange quota for that user. So you wipe the egg off your face nad go take care of that.

Unlike when you run the Change User Role wizard and have the option to Add To or Replace the user's settings when the role is applied, if you make a change to the Role, any user who had Role settings modified from the Role defaults will have those custom settings overwritten. Working with Roles is not like working with Security Groups in AD, where you can adjust certain settings for one group and not impact other settings. All settings contained within a role get pushed back out to the users who have the role assigned when you make changes.

So what's an SBS admin to do?

First, get out of the habit of having custom settings based on a user if you're going to be using Roles (and I'm not suggesting that you shouldn't use Roles, I'm just saying that you need to know what you're in for if you do). If you have a user, or a group of users, who have one setting different from one of the standard roles, create a new Role for those users and modify the settings for those roles. In the example of the user with the large mailbox, you could create a new role based on that user's settings and call it something like Standard User with No Exchange Quota. Then if you need to add a new user who also needs to have no Exchange quota, you assign that new user to that new Role.

Second, document the changes that you make. Nothing can cause you embarassment with a client quite like making a change from the "default" settings, then making another change that impacts the undocumented change, ending up with the user unable to send and receive e-mail, for example. The more you document, the greater the likelihood that you won't end up with unexpected results. OK, that's a bit of a pipe dream in this industry, but still, any documnetation is better than no documentation at all.

My recommendation for how to approach using User Roles in SBS is to leave the three roles created by SBS alone and create new roles for any customzations you want to make. Have a new user that needs no special configuration? Make them a Standard User. Have someone who needs folders redirected? Change them to the Standard Users with Folder Redirection role. If their mailbox grows larger than the default quota, add them to the Standard User with Folder Redirection and No Exchange Quota role. Could that get ridiculous before long? Absolutely. But if you come up with the configurations you want and create roles for them, your management life will get a LOT easier than if you have individual users with custom user settings that might get modified if you accidentally change a role.

Now is the time to think about these things, not after you've started an installation of SBS for a client. And certainly not after you lock the big boss out of his (or her) e-mail.

On Migration - Exchange and Quotas

eriq — Mon, 27 Oct 2008 17:45:00 GMT

This post will be the first in what I hope will be a short series related to issues I've encountered in my SBS2008 migration of my internal server. I'd love to say "hey, everything worked as advertised" but we're not quite that lucky. But to start off, I have a very common setup that will probably catch some folks off-guard, so here it is in the blogosphere for someone to find and figure out.

First, I have a large mailbox. Like 8GB. Yeah, it needs pruning, I know. My first hint of trouble was when I ran the move mailbox part of the SBS migration. The move mailbox process stopped because of the default quotas in Exchange 2007. Yes, 2GB is far better than the 200MB default in Exchange 2003, but that's beside the point. So I went right in and removed the quotas on the mail store and fired up the move mailbox tool again. This time it completed without error.

Jump to this morning. I am going through the migration CHM file and get to the point about the users not showing up in the SBS console. I can either do the ADSIEDIT fix for that, or I can just run the Change User Role wizard (or whatever it's called). Boom, all of my users show up in the console. Woo hoo!

A little bit later, Susan (yes, that Susan) pings me that my mail is getting rejected because my mailbox is full. D'oh! That's right, the default Standard User role has the 2GB Exchange quota enabled by default. Dummy that I was, I didn't change the user role before applying it (I actually ran across this during migration testing and made a note about changing the Standard User role to remove the Exchange quota, but forgot about it this morning while I'm trying to do a gajillion other things) and now my 8GB mailbox is dying over 2GB quota. No problem, I change the User Role, then I open my user object to make sure the setting is removed, and all is well.

Would that it were that simple.

An hour later, I still can't get into OWA (well, I can get in, but it's yelling at me that I'm over quota and won't do anything until I fix it - if you haven't seen the OWA UI for being over quota, try it - there's nothing subtle about it). I quit and restart Outlook, it fires off the Mailbox Cleanup wizard (again, yes, I should do a cleanup, but that's not the issue). I look at the my user object in the SBS Console, no quota. I look at the message store in the Exchange console, no quota. I ping David Shackelford and he has me run a couple of PS cmdlets, all show the quota is disabled. Dave suggests I restart the Transport service. No love.

Finally, Dave sends me to http://technet.microsoft.com/en-us/library/bb684892.aspx and suggests I restart the Information Store service. Bingo, OWA and Outlook stop yelling at me, and mail starts flowing again.

I don't know why Exchange couldn't figure out in a two-hour window that I had adjusted the quota settings, but it didn't. I had to forcibly restart the information store before it woudl check the quota again and allow me to get back to my precious e-mail.

So, lessons learned for today:

Modify the quota settings on the mail store before migrating any user mailboxes over if you have users with mailboxes over 2GB.
Modify the Standard User Role before you touch any user objects during your migration and remove the Exchange quota if you have users who are above the limit.
If you should get a user who goes above the quota and you need to restore their access quickly, adjust the quota settings, then restart the Information Store service. No, you shouldn't have to do that, but it fixes the issue.

On 18 months

eriq — Fri, 26 Sep 2008 18:54:17 GMT

Back in March 2007, I put up a couple of posts about the missing audible alarm in the Dell PERC RAID controller. There was a flurry of activity following those posts, and that's been the most read pair of posts from this blog. Well, 18 months has passed, and I haven't posted much else about the situation, mostly because nothing much has changed. One of the last conversations I had with someone within Dell engineering was that they were looking into adding the alarm back in the PERC 6 controller, but no revisions were planned for the PERC 5. I'm OK with the latter part of that, as it would be difficult to go back and re-engineer the existing card, so long as the next card would get it back.

But last week I put in two new servers, the first ones I've rolled out with the PERC 6 controller, and guess what - no audible alarm on the controller. Either version. (One of the servers I rolled has both the PERC 6/i and the 6/E, neither has the alarm.)

I had reason to contact Dell yesterday for another set of issues and, as luck would have it, I spoke with the same engineer who worked with me the first time I called in about the missing alarm. While he helped me resolve the other issues, we talked more about the missing alarm and how I was really disappointed to find out that the latest card still doesn't have it. Once again, I asked about how best to provide feedback to Dell regarding this issue, and once again he pointed me to the Dell IdeaStorm site. While talking, we both went to the site and searched on "audible alarm" and guess whose post was the first one returned in the search - yep, the one I put up in April of 2007. Surprisingly, unlike other posts with lower scores on that page, this item has not been marked as "reviewed" which means that Dell has not been keen enough to even look at this issue.

Well, it's time to get back in the saddle on this issue, because I think that Dell has made a significant mistake in removing the alarm from the controller. Sure, I understand that they received a number of calls from customers who didn't like hearing the alarm when something went wrong with the controller, but the correct response is not to remove the alarm altogether. Ship the controller with the alarm disabled by default, and let those of us who rely on the alarm as a warning sign enable it if we choose.

So, for those of you who work with Dell servers who still see this as a huge shortcoming, please take as many of the following actions as you are comfortable with.

Locate my post on IdeaStorm and comment/promote it.
Contact Dell Support for one of your servers in production and ask them how to enable the audible alarm on the PERC controller. When they tell you it can't be done, escalate the call.
Contact your sales agent at Dell and explain to them how you're considering switching to a different hardware vendor that does offer RAID controllers with audible alarms.

This is one of those cases where I think the community absolutely can make a difference.

On Callback Support

eriq — Mon, 25 Aug 2008 21:13:50 GMT

There has been a recent discussion in one of the mailing lists about Microsoft's new callback support model for SBS. This model went into effect on August 1, and was announced on the Official SBS Blog on July 2, 2008. Over the weekend, I had an opportunity to make use of the new callback model, and wanted to share my experiences with it here.

Caveat: as you may or may not know, I used to work in PSS (now CSS) on the SBS team in Las Colinas, and still keep in touch with several of the folks there. I was present on the lines when the switch to have first-level calls get routed to India went into play. While I have my own thoughts about the process, I have to admit that I get a bit frustrated when calling in and dealing with a first-level tech (no matter where they are located) who doesn't have the experience and background that I do. When I do call in, I have to be patient with the process and let it work, because trying to get around the process, in my experience, has just caused more problems. That said...

Over the weekend, I went into a customer's server to install the August security updates. As per our normal practice, I did a full restart of the server before installing any of the updates. Only the server did not come back up. I'm in Texas, the server is not. Once my client got on site, we saw the dreaded "Cannot load operating system" message on the screen. While I had him track down the install media to boot into Recovery Console, I placed a call to the Partner Business Down support line.

I placed the call at 12:15pm. Within 5 minutes, I was speaking with a call router. Even though the core problem was an OS load issue and I knew I'd get the best support by talking to someone in the Setup team, I could not bring myself to outright lie about the OS, and agreed to the callback plan for SBS support. We went through the severity assessment at length and she eventually agreed that this was a business down case. I provided my partner ID for the case, and even though I renewed my partner status on 8/21, that update did not reflect in their system. I spent 5 minutes on hold while she tracked down my partner status, and eventually came back indicating that she had updated my partner status in their system (even though my expiration date of 2009 shows on the partner web site), and she gave me the case number at 12:36pm. Longer than I would have liked to get to that point, but I can't really complain. She then advised that I could expect a callback in the next one to two hours, and I got ready to work on issues while waiting on the callback.

To my surprise, an SBS engineer called at 12:40pm, just 4 minutes later. I hadn't even had time to get my client through the next part of the Recovery Console troubleshooting. I was fairly impressed, no, let me be honest, I was completely surprised at how quickly I received the call back. I have to say that the call router did a good job of setting expectations, but I never expected to get the call back so quickly. I was very, very impressed at that point.

And that's where the good impression stopped. Over the next few hours, I got pretty much what I expected from first level support. Without going into detail on the problem or the troubleshooting or the resolution, I can only say that the MS tech provided exactly one valid suggestion towards an identification of the problem. He offered several red herrings that I refused to follow, because I knew they would go nowhere. I have to acknowledge that he did at least consult with someone on the Setup team (which is where I really wanted to go in the first place) to make some recommendations that I already had documented on my own to-do list.

As it turned out, I ended up not really needing the support from MS after all, as the problem didn't end up outside of my area of expertise, but when dealing with a non-booting system, especially one that I cannot get my hands on, I know what my limits are and when I will need the assistance of someone from MS. I don't know if I would have had trouble escalating that call to a higher level or how long it would have taken to do so, and fortunately I did not have to find out.

So my first foray into SBS callback support was a mixed bag. I ended up not having to call in as early as I did, because I got a callback immediately. But I still ended up with the same caliber of front-line support that I've unfortunately come to expect from Microsoft. I'm quite glad I didn't just turn my customer over to the MS support tech and walk away, which was an option, because the MS tech would have had him perform tasks that would have put the server in more jeopardy, not less.

Anyway, for those of you who have been complaining about the length of time it can take to get a callback from MS for SBS support, here's an example of when it can take very little time at all to get a callback. I'm not expecting that should I have to call in again any time soon that I'll get anything resembling that kind of turnaround, but it is nice to know that it's at least possible.

On RTM

eriq — Thu, 21 Aug 2008 20:41:08 GMT

Folks, in case you haven't heard by now (and if this is the first place you've seen/heard this, then I probably have a few other blog suggestions for you to follow), the SBS Development Team released SBS 2008 to Manufacturing today. This means that the product will be in the channel in some form in the next 6-8 weeks. This marks the end of several years of development by Microsoft, and nearly two years of testing that I've been involved with, along with a lot of other people.

I think the development group has done an amazing job with the product given the circumstances. Is the product solid? Based on what I've seen, I think so. Does it have some holes? Without a doubt. But given that the team was essentially developing against a deadline and not against a feature set, this is understandable.

What does this release mean to you? If you're a small business IT consultant (or at least play one on TV), it's time for you to get off your duff and work with the product so you get to know it and, therefore, develop your ability to support it for your clients. If you are a business owner, it's time to start thinking about if the upgrade makes good business sense to you.

I've already been seeing the arguments pro and con for the product out in the community, and for those that have asked about my take on it, my standard reply still stands - whether it makes sense to upgrade now or later depends entirely on the specifics of the client. Some people will need/want to move as soon as they can get their hands on the product. Others will wait until they have a clearer need for it. In my general conservative approach, I'm going to be taking a "wait and see" attitude for most of my clients. However, I have one that will be migrated pretty much as soon as we can get our hands on the software. It just depends.

Through this process, I've made some good friends on the Dev team, and I've been privileged to be involved in parts of the process that many people never get to see. I know they're all relieved to have finished this product, and they deserve whatever celebration is in store for them. The folks that have worked countless hours to bring you SBS 2008 definitely deserve major kudos - this was not an easy product to produce, and those of us on the testing team were not the easiest people to work with. But in the end, I think we're getting the best product that could be released at this time.

Over the next few weeks, I'll be talking more about my observations about SBS 2008 both here and on eOnCall. I'm also in the last stages of working on SBS 2008 Unleashed for Sams, due for release in November of 2008. But if you really want to know what the product is about, you have no choice but to get your hands on it and start working with it. No amount of reading blogs or sitting through web seminars or watching demonstration videos will give you the experience you need to run or support this product. Get out there and get after it!

On Migration

eriq — Tue, 19 Aug 2008 02:25:40 GMT

In the last few weeks, I've had an opportunity to give a presentation about the Migration options with SBS 2008 to a couple of different groups, one in Dallas and one in Detroit. As I went through the presentations, it became clear that the majority of folks in both rooms had not looked at the SBS 2008 migration document that's been produced by Microsoft, mostly because they didn't even know it was out there. So even though I will be giving the presentation at a few more groups over the next few months, I wanted to get my key point about Migration and SBS 2008 out there for those people who won't be able to hear about it from one of these presentations.

My talk focused on the MS Migration story for a variety of reasons. One, I know Jeff Middleton isn't ready with the Swing Migration process for SBS 2008 (but I also know he's working on it), and I really can't speak to a process I haven't seen. Plus, I'm not trying to take the thunder from Jeff about Swing when he does release the SBS 2008 edition. But I have gone through the MS migration process several times as part of the research for the SBS 2008 Unleashed book and the beta testing for the product, and doing the migrations uncovered for me what I believe is the most important thing you can do as a consultant to get ready for SBS 2008:

Learn the migration process. Period.

Whether you use the MS process or Jeff's Swing Migration, you will benefit greatly from starting to work with the migration process now. Don't wait until you get in front of your first migration for a client and try to review the white paper the night before. Don't download the Swing docs on the way to the client site. In fact, don't even schedule time with a client for migration until you've spent time learning how to do a migration.

There will be benefits and drawbacks to both migration processes. Learn what those are and understand why you are choosing one migration process over another. There will be times that a Swing will be the best migration method. There will be times when the MS process will be the best migration method. If you don't know both processes inside and out, you will not be able to make the correct decision for your client, which could end up being very costly for both of you.

We have what is supposed to be the final version of the Microsoft white paper on migration (in both web form and CHM (compiled help file) form) already available, so there is no reason you cannot start reading up on migration right now. You should, in fact. Then when Jeff releases the SBS 2008 version of the Swing Migration process, you can read through that and get familiar with it as well. Then you'll be well-versed in how to get your existing SBS 2003 customers onto SBS 2008 in the best way possible.

The other key reason I believe it's important to learn about migration is that it is the best way to learn about SBS 2008 in general. If you just join the beta and download and install the product, you'll get to see the surface of what's going on. But the migration process touches on every aspect of SBS 2008 - from Active Directory to Exchange to SharePoint to Group Policy and so on - so when you go through the migration process, you will learn about each of those apects of SBS 2008, and if you have not seen SBS 2008 yet, this will be a good way to get your hands dirty.

I will be up front, though. This will take time and effort on your part. The migration process is not easy, and not fast. If you try to skim through the docs or speed throgh a few trial runs,you WILL miss key aspects of the process and could run into problems down the road.

If you plan to be serious about supporting SBS 2008 as part of your business venture, start now to learn about migration so you'll be in a position to succeed when you are ready to move your clients, not in a position to fail miserably.

On Two Weeks with the iPhone

eriq — Sat, 26 Jul 2008 00:48:02 GMT

Last week, my eOnCall episode covered my first week with the iPhone. OK, yeah, I cheated a little bit because I recorded the episode on Wednesday, when I hadn't really used it for more than about 4 days, but who's counting. It made for interesting Internet Radio at least. So I thought it was time to do a little deeper analysis of my life with the iPhone thus far for the blog, for those who read this and don't listen to eOnCall.

When I decided in March that I was going to get the iPhone 3G (after Exchange support was announced for iPhone 2.0), I took a hard look at how I was using my existing Windows Mobile device and what features I could live without, if need be. Once I developed my list, and reviewed what should and might not be supported on the iPhone, I determined that the benefits still outweighed the odds, and since I had so many clients who were going to want me to support their iPhones, I knew I would be getting it shortly after the product released.

The fates were not in my favor on that last bit, however. A few weeks before the July 11 iPhone release date was announced, I booked a flight to Redmond for a work project at Microsoft, leaving on July 13. If I was going to have any semblance of support for my customers who were planning on getting the device that weekend, I knew I'd have to wait in line on Friday or Saturday, and given that there would likely be some problems that would need to be addressed the day after I got the unit, I decided it would have to be Friday.

I got up early Friday morning and made my way to my local AT&T store, a store that I had already checked with earlier in the week to ensure that they were on the list of stores that would be getting the iPhone. In my haste (and sleepless state) I neglected to eat breakfast before leaving, so I stopped at Sonic on the way to the store. When I arrived at the store, the line wasn't terribly long, but I got out my folding chair and parked myself at the end of the line. About 15 minutes after I arrived, and AT&T employee came through and was counting the customers in line. About 10 people in front of me, he stopped and started talking to them. Sure enough, they received 80 phones, and cut the line off at 75 people. I didn't make the cut. I only marginally wished that I hadn't stopped for breakfast at that point. Instead, I headed to the office, and started trying to reach the local Apple stores by phone to see if they were going to have enough stock for me to drive the hour to the store locations and wait in line.

I called the Willow Bend store, and not only did they assure me that they would have plenty of iPhones, they also said that the wait was about 2.5-3 hours. An hour drive time later, I found myself in line with the rest of the idiots.

Nine hours later, I made it into the store. That is where the 3 hour activation nightmare started. Yes, your math is correct. 12 hours in the Willow Bend mall to spend $300 on a phone. I left at 11pm to make my way home. I not only missed a bunch of billable work, but I also missed margarita night at Sweetwater. Five minutes after leaving the store, however, I had the phone configured to sync with my Exchange server, which was the #1 reason I wanted to get the phone, and seeing how easily that mission was accomplished, I was able to get some sleep that night, knowing that I'd be able to walk my clients through that setup easily.

What I didn't have was my old cell phone number active on the phone. That took a call to AT&T Saturday morning to get worked out, and even at the end of that call, it wasn't completely working. I was able to make outbound calls, and I could send and receive text messages, but I could not receive calls. All inbound calls continued to go to my Verizon voice mail. They did advise that it could take 24 hours to complete the switch, so I prayed for no emergency support calls on the weekend and went on my way to get ready for Redmond.

Sunday I still didn't have inbound calls, which made it difficult to take a call from a customer with a dead server, but fortunately my normal phone system, and my wife, took care of that while I was jetting over the western US. When I landed in Seattle, I attempted to call AT&T, but their service centers were closed on Sunday. Great.

Cutting to the chase, the phone got switched over on Monday and started working as expected. Now it was time to really put the device through its paces. In my spare time, however. And that basically brings us to today.

So what follows are the tasks I was using my Windows Mobile phone for and how I've adapted those tasks to the iPhone. And my take on how successful the transition has been.

E-mail

This is my #1 priority for a cell phone, besides making and receiving calls. Given that cell phone reliability and call quality really hasn't changed in 10+ years, I'm not even looking at that aspect of the iPhone, other than it works about like any other AT&T phone. It is what it is. But e-mail was key.

Windows Mobile: I had native Exchange ActiveSync on my device, and several folders that I read on the phone. I have dozens of mail folders in Exchange, but I only wanted to read a few of them on the phone. Sending e-mail was important, too, but my primary use was reading.

iPhone: Exchange sync just works. My Inbox (I almost typed iNbox, how silly) gets updated immediately when I get new mail, and I'm able to send e-mail easily. I have access to all of my mail folders, but the iPhone only syncs those when I open them, so if I want to read from some of my more voluminous mailing lists (which are automatically sorted into folders by Exchange), I can, and I don't have to worry about the phone syncing every time a message comes into one of those folders. That feature alone should save some battery (more on that later).

I don't like that I'm forced to read mail in the "newest on top" format, and there is no option for how to sort mail on the iPhone. I'm a "new messages on bottom" reader, and I'm really hoping that a future update will give me the option to read the way I'm used to. In the meantime, I'm adapting.

I also hate that the mail application shows EVERY folder in my mailbox, and there is no way to collapse folders and sub folders. There are only a few mail folders I really want to access on the iPhone, but they come at the bottom of the list, and it takes multiple pages scrolls to get to the parent folder where they're located. Again, hopefully an update will address some of this.

One thing I love about mail on the iPhone it that it's much easier to handle multiple e-mail accounts. I have several accounts that I can now follow on my phone, and I wasn't able to easily do that with my Windows mobile device.

But the last thing that drives me nuts about mail on the iPhone is that I have one, count it ONE, e-mail signature for outgoing messages, no matter how many accounts I am sending from. One signature, just not going to cut it.

Mileage tracking

Windows Mobile: The #2 task I used my Windows mobile phone for was keeping track of my car mileage in Pocket Excel for tax purposes. I had some nice formulas built into the spreadsheet to help calculate mileage, and at the end of the year, I'd sync that file to my PC, extract the data, and send it off to my accountant for processing. Easy, efficient.

iPhone: I have looked at a number of apps in the Apple Store, but have yet to find one that does what I want for mileage. Oh, there are several apps that help you track gas mileage, but nothing for travel mileage that gets as granular as I want. Right now I've reverted to pen and paper, but I'm hopeful that one of the developers I've contacted will add a module like what I've suggested. In the meantime, this is a big loss, but not a deal breaker.

Calendaring

Windows Mobile: In my business, it's key for me to have an accurate calendar with me at all times, and syncing my phone to Exchange is something I've grown really accustomed to. Windows Mobile handles this nicely, once you have all the DST patches in place everywhere.

iPhone: Ugh. Calendaring has a long way to go. Yes, the iPhone syncs all of my calendar appointments to the iPhone, but they all come over as REQUESTS, not as ACCEPTED appointments. So when the 15-minute reminder goes off, it's not a notification of a pending appointment, it's a "please confirm this request." If I click "Maybe" the appointment stays on the calendar and life goes on. This has become my default action. If I click "Accept," the appointment stays in my calendar, but whomever set the appointment gets ANOTHER "so and so accepted this appointment" e-mail in their box. 90% of the time, that's me, so when I accept an appointment I set for myself, I get an e-mail indicating that I accepted my own appointment.This has got to change in future releases.

I don't spend much time creating new appointments in my phone, much less for multiple people, but I do understand that there are issues with doing this on the iPhone. I don't want to belittle that fact, but it's not something I do regularly, so it's not been a major deal for me.

The issue that IS a major show-stopper for me, though I havent' had time to review it yet, is that calendar items are apparently not stored in GMT, but in local time. When I went to Redmond, a paltry two time zones away from my beloved Central, my 8AM CDT appointments showed up as 8am PDT appointments. The time on my phone synced with the local service providers, but apparently did not adjust for time zone. Fortunately, I had no appointments I was trying to keep while there, and I don't travel between time zones that often, but it was a major point of note and I will be looking into that as time permits.

Contacts

Windows Mobile: Syncing my contacts with exchange makes it very easy for me to have phone numbers for customers, family, and friends in my phone. And I can take pictures of those people with my phone and it gets updated to my Exchange server, so I can see their faces in e-mails in Outlook.

iPhone: the iPhone pulled my contacts down fine. I have heard there are issues with modifying contacts on the iPhone and those changes don't get sent back to the server. I have deleted contacts from my iPhone (former employees) only to have them NOT delete from Exchange, but actually get sent back down to my iPhone. Annoying? Yes. Cause for a revolt? No. Again, hopefully will get addressed in future updates.

Apparently the iPhone doesn't perform well with a large number of contacts, either. It takes a very, very long time to search through contacts in the Contacts app (which I never get into any more) or in the phone app.

Voice Dialing

Windows Mobile: I had to purchase a voice dialing software for my Windows Mobile phone a long time ago, and I got really used to using it, especially while driving. Made making calls a nice, simple process.

iPhone: No voice dial software. Sure, you can "voice dial" through AT&T's service, but you have to dial a number to get to where you can voice dial, and so what's the point? I've adapted to either not making outgoing calls while driving, or waiting until I'm stopped to find the contact and dial their number. Not happy about this, either.

GPS

Windows Mobile: I had purchased a bluetooth GPS receiver and Destinator software for my Windows Mobile device. It worked very well for tracking my current location and for turn-by-turn directions. I really needed to update my maps this year by purchasing the new version, but I held off on that given the GPS support built into the iPhone.

iPhone: yeah, it has GPS support, and it can do turn by turn directions, but it definitely works like a 1.0 product in that regard. Being able to search for local items in Google Maps is really nice, and much nicer than what I got with Destinator, because it's real-time querying the web. However, the maps always point North is Up on the iPhone, and that's taking some getting used to. Also, the GPS is prone to hanging up, and has been the main reason I've had to reboot the iPhone the few times I've had to reboot it. Some other apps make use of the GPS locator, and those get wonky, too, when the GPS drops off the planet. iPhone 2.0.1 supposedly has some GPS enhancements in it, so we'll see how well it works then.

Battery Life

Windows Mobile: Sucked. I was having to charge my battery every night. I know most of that was the constant syncing with Exchange, but it got old, quick. In some cases, I had to take a USB cable with me so I could charge the phone with my laptop, and a car charger was simply not an option.

iPhone: Yes, everyone hates that you can't change out the iPhone battery, including me. And I'm having to charge my iPhone every night, even after charging it during the day as well. And I'm not using a LOT of the iPhone features, either. I have WiFi and Bluetooth turned off, I've filtered more of my e-mail into sub folders out of the Inbox to keep Exchange sync to a minimum, and I don't listen to music on my iPhone at all. Car charger and secondary USB cables are an absolute must, and I have yet to get a car charger that actually works.

Internet Access

Windows Mobile: I hated Pocket IE on my Windows Mobile device. Access was slow, and the web was practically useless, so I hardly ever used it.

iPhone: Internet browsing ROCKS! Apple nailed the browser on this device. Granted, there are many web sites that use dynamic content that is not going to work on the iPhone, but I've already seen several sites redesign alternate pages specifically for the iPhone, and that's going to become more prevalent, I think. I look up lots of stuff on the web now that I never would on my WM device.

Applications

Windows Mobile: I had acquired several apps for my WM phone, including a couple of solitaire games. I tried several times to download apps directly to the phone from the Internet, but had very limited success. I resorted to primarily using only the native apps, save for GPS, voice dial, and games.

iPhone: I have yet to get through all of the apps in the Apple Store, not because I've not had time to look, but because there are so many. And more are added every day. I'll have a future post outlining my favorite iPhone apps at a later time, but the iPhone wins hands down in this category for me.

Twitter

Windows Mobile: I started updating my tweets via SMS messaging about 6 months ago, and it worked.

iPhone: I downloaded and started using Twitteriffic and won't look back. Not only can I easily update my tweets, I can see what's happening with the tweets of the people I'm following. Great app.

Touch Screen

Windows Mobile: I carried a HTC 6700 for the last six months and hated it. The touch screen was constantly going out of alignment to the point that I had to turn off my passcode to get into the phone because the screen just wouldn't respond in the correct locations. The 6700 was the worst implementation of touch screen in the HTC series of devices I've used for the last 4 years.

iPhone: Dude, it just rocks. The iPhone exemplifies what touch screen was meant to be, especially with the multi-touch capability. Other vendors can only attempt to copy what Apple has done here and hope to come close to the success of the interface.

So that pretty much covers what I had been doing with my old phone and how I've adapted to the iPhone. The stuff that's broken is way broken, but the stuff that works is solid. Overall, I'll say that I'm about even on productivity for what I was doing with my phone after switching. I'd love to say I'm more productive, but I can't. Maybe in a month or two, but not now. My productivity increase will likely come from updates to the iPhone software and new apps for the device. Time will tell, but that's where I am thus far.

If you stuck with me this far through the post, please note that I'm going to be trying out posting from a couple of different iPhone blogging apps in the next few weeks. Hopefully, that will allow me to blog more quickly those things I've been wanting to get out. And yes, I'll blog about that, too.

On Redmond in July

eriq — Sat, 19 Jul 2008 21:39:00 GMT

Be warned, this is a long post. But the payoff at the end may well be worth the read.

This past week, I had an opportunity to work on a project at Mothership Redmond. In addition to the fabulous weather (highs in the upper 70s compared to the 100s back home, yet sunny and clear skies, go figure), I had was able to catch up with some people who I don't get to see very often: Amy Babinchak, Steve Banks, Mark Crall, Chris Rue, and Oliver Sommer. And those were only the folks who were on the same work project. I was also able to spend some time with Terri Schmidt, documentation manager for WEBS, and Kevin Beares, a name that should be familiar to everyone in the community. and while I do not want to belittle the time I spent with these folks and the discussions we had, the highlight of the trip for me happened on Friday.

Dean Paron, Group Program Manager for SBS, invited me to sit in on a ship room meeting the team had Friday morning. Since I'm not an idiot, I accepted the invitation without batting an eye, even though I had no idea what a "ship room meeting" was. But after sitting in on the meeting, I have a much deeper understanding of the process the team goes through to develop the product and bring it to market. And after confirming the NDA line, I'm blogging about it to shed some light to others who may be interested.

Anyone who has worked on any type of software development project, whether large and formalized like what MS and other large companies use or smaller and independent, will understand some of the basics of the development cycle. In the case of SBS, the process is a little differnet than for other products, because what the SBS team is developing is the "glue" that will allow all the disparate MS component technologies to run seamlessly on the same box. Oh, and there's the management tools, too. But the development folks on SBS are not writing code for Windows Server 2008 or Exchange Server 2007, instead they are taking those products and writing integration code. In many ways, this is a more challenging process, because to meet your own design goals, you have to deal with the building blocks that have been handed to you. If the team found, for instance, that the User Management tools would work a whole lot better if there were a change made in Windows Server 2008, they're not going to be able to go in and modify code in that product. Sure, they could request accomodations from that team while the product is in development, but once Server 2008 shipped, that was what they have to use to build their code.

Once they get the product matured to the point that they're ready for other people to start using it, they make the code available to certain groups of external users. This comes in the form of CTP (community technology preview) releases and then the beta releases. Generally, these external releases start with a very small group of outsiders, then expands to a larger audience as the product gets closer to release. SBS just announced the release of the RC1 build late this week, and it will be available to beta participants early next week. Many more people will look at RC1 than looked at RC0, or Beta 2, or Beta 1, etc.

The goal, as I understand it, of these releases is twofold. Early in the process, the goal is to get feedback on the functionality of the product as well as identifying any problems (bugs) in the code so that those bugs can be fixed in later releases. Later in the process, the functionality aspects are pretty much set in stone and the team is more interested in finding and fixing the problems instead of adding or removing major elements. That's where we are in the process of SBS at this point - the feedback Microsoft is looking for in RC1 is "what doesn't work" and "how significant of an impact will it have if it's not fixed."

People who participate in the beta process access software and feedback through the Connect site that Microsoft has put together for this process. When someone finds a bug, they are expected to enter that bug into Connect, then it gets on the developers' radar and they can start addressing the issue identified in the bug. But just because you enter a bug does not mean it will get addressed by the team the way you want it to. There are several bugs (and suggestions) that I've entered into the system that have not and will not be addressed by development, at least not in this release of SBS. Am I frustrated about some of them? Sure. But I also know I've identified a couple of bugs that did get fixed, and fixed immediately.

OK, so that's what we see on the outside. When I sat in on the ship room meeting Friday, I got to see what happens on the inside. And I have a better understanding of how and why the process works the way it does.

After Dean introduced me to the team in the meeting (more to confirm that I was under NDA), Cassie Hicks opened the list of outstanding bugs and went through them with the team to determine which bugs would get addressed and have fixes entered into the system before the next build was done, which was scheduled for Friday night. As each bug was introduced, the owner of the bug identified the status of the bug, and if a fix was not imminent, there was a brief discussion about what the next steps of the bug would be. No, I can't discuss any of the bugs that were brought up in the meeting, but it was pretty cool to see the process in motion.

Following the ship room meeting, a pizza party ensued celebrating several teams that had releases that week, including the announcement of SBS 2008 RC1. I was invited to attend with the rest of the team, which was an honor, and got to listen to all of the thank yous to all of the related team members who helped with each of the releases. While everyone ate, I was able to talk a little with Boodhisatva Deb and Sean Daniel, as well as Cassie Hicks. But the icing on the cake, so to speak, was getting to witness Kevin Kean have his head dunked in a large bowl of whipped cream (and yes, you can just make out my face in the background of the video).

All in all, a great week in Redmond, but now it's time to return home and take care of important matters. After I deal with a 4 hour delayed flight, that is...

On Public Preview - Setup and Protection

eriq — Sun, 01 Jun 2008 12:26:00 GMT

The first time you boot up the system from the SBS 2008 install DVD, you'll notice a significant difference between this installation process and previous SBS installs. There is no integrated setup.. This comes partially from the image-based setup routines of Windows Server 2008, and partially from design decisions by the development team. Gone are the days where you can "customize" your SBS install, save for a very few items. In reality, about the only things you can configure during setup are the layout of the hard drives, the name of the server, the name of the default administrator account, and the internal domain name, and even the latter is restricted to certain limitations for you by default.

In general, I'm not opposed to this move. By ensuring a consistent installation across all builds of SBS 2008, the development team has hopefully reduced some of the support calls that will come into Microsoft. One of the more frustrating things for me personally when I'm called in to provide support on an SBS box for a partner is seeing an SBS 2003 box installed without Exchange. Or without Sharepoint. Or without any of the tools that make the box an SBS box and not just another Windows Server 2003 box. Knowing that all the parts and pieces at least started out on the server (yes, you can go into Add/Remove Programs and pull out specific pieces after installation - more on that later) should reduce some of the support footprint moving forward.

So you want to install SBS so that user data, Exchange, and Sharepoint exist on a different volume or partition on the server? No problem. You just won't do that during installation. You'll get to use the Move Data wizards to relocate those features elsewhere on the server after installation completes. But during the installation process, everything, and I mean EVERYTHING, gets put on C:. Don't want Exchange on C:? Move it after installation. Don't want user shared folders on C:? Move it after install. Don't want the core OS on C:? Won't happen in this version. Everything goes on C:. Period.

That includes the trial editions of Windows Live OneCare and Forefront Security for Exchange, and this is where I take issue with the installation process, although I undestand it's really more an issue with marketing. The SBS 2008 propeganda includes anti-virus/anti-malware/anti-spam protection for the server as a feature. This "feature" is a pre-installed 120-day trial for these two products. Personally, I don't plan to install or use either of these products, because my operation already has products we use with our existing customer base that we will be putting on new installations. I will be going through the extra steps at the end of the installation to remove these two products from the server (through Add/Remove programs), and I really wish I didn't have to. I fully understand that Microsoft wants to get more into the subscription businss through these two products (both Windows Live OneCare and Forefront Security for Exchange are subscription products, not "package"products), but I hate that they're included in the install as "features" that don't work until you activate them, and I have no way to say "Hey, I don't want that stuff on my server to begin with." How many times have we gone through the uninstall process on a piece of software, only to have that software leave some trace of itself behinnd? I have not played enough wiht OneCare/Forefront to know how much of the products are left on the box after install, but it is something I will be looking into.

I would rather see Microsoft include the installers for OneCare and Forefront on the SBS installation DVD and give the installer the option to go back after the server is set up, but that would lead to fewer installs of the products, and therefore fewer subscriptions, so I don't see that going away. (Yes, even though the product is in public beta and is called "Release Candidate 0," there is still a possibility that some aspects of the software could change before the final build is released. So it's possible that this behavior could change, but I'm not holding my breath.) It's just that System Builders are given the option to not include OneCare and Forefront when they pre-load a server with SBS 2008, and I think the VARs should be given that option as well. I fully understand that Microsoft still wants to push SBS 2008 as a user-installable product, and for the DIY market, I'm OK with giving them some sort of protection right out of the box, knowing full well that many DIYers never got around to installing anti-virus/anti-malware on their SBS 2003 boxes. But let's not force it down the VAR's throat.

My last note on setup deals with the Answer File. The SBS development team put together a tool to create an Answer File that SBS setup will use to "customize" the installation process. And by "cusomize" I mean "pre-populate the answer file with data that would otherwise be collected in the GUI portion of the SBS setup." You can run teh Answer File Generator Tool and enter the name of the server, the name of the default administrator, even the location information for the company. The answer file is also the only place you'll be able to customize the internal domain name for the network. By default,all SBS 2008 installs prompt for an internal name, but the name entered is a NetBIOS formatted name, and .local will be added to the end of the name. So if you enter CONTOSO in the field, the internal domain name will be CONTOSO.local. If you want to use .lan or even the public DNS name (and no, I'm not getting into that religious debate here), you'll need to employ the answer file to get a non-.local internal domain name.

As a programming note, some of the "how to" steps for issues described in these posts will be available on the Lessons Learned site. And all of it will be covered in the SBS 2008 Unleashed book, tentatively scheduled for release at the same time as SBS 2008.

On Public Preview

eriq — Thu, 29 May 2008 11:29:00 GMT

i've been waiting with baited breath for the opportunity to talk about the Public Preview of SBS 2008, and it went live yesterday. The SBS Blog carried the announcement from Dean Paron, and you can sign up to download and evaluate the software at the Evaluation Center. If you are going to take a serious look at the software, and by serious, I mean that you are going to run the software through its paces and provide feedback to the development team, make sure that the system you will be testing on meets the minimum system requirements as identified by Microsoft. Running on anything less will not get you the proper experience for the software.

There are a number of changes in SBS 2008 from SBS 2003 and earlier versions. One of the most significant is the change from being able to use the SBS server as an "edge device" by running it with two NICs. SBS 2008 only supports a single NIC (and by single NIC, that means you cannot route private to public traffic through the SBS server - some testers have installed SBS 2008 with two NICs on private networks for physical separation of internal networks) and that's actually a change in the core Windows Server 2008 operating system, not a design decision by the SBS development team. All deployments of SBS 2008 will be of the "single NIC behind a hardware firewall" vaiety, where the "hardware firewall" could be any number of solutions, including a separate server running ISA. The SBS setup wizards will attempt to configure this external firewall if it's a hardware device that supports and has enabled UPnP, but the setup wizards will not configure an external ISA server, so ISA integration has been completely removed from this product.

Over the next few days and weeks, I'll be posting my thoughts and opinions about the product, the successes and failures that I've seen in the time I've been working with the product. These posts will be focused on significant differences in the product from previous versions so that those who are starting to become familiar with the product can see up front some of the implications of those changes and how that might impact the way you deploy SBS 2008 into an existing environment. While some of these changes may not sit well with the community, if you know about them in advance and can plan for them before implementing the system, you may save yourself some headaches down the road. I liken this to the people who were very familiar with SBS 2000 and made assumptions about SBS 2003 when selling it as a solution to customers without knowing some of the significant changes made at that transition. Specifically, consultants who sold SBS 2003 to b used as a Terminal Serve, like SBS 2000 could do, when Terminal Server support was removed from the product. in this case, you won't be selling SBS 2008 with ISA - there is no bundled ISA story with SBS 2008, so if you've been thinkig about selling SBS 2008 Premium and pitchin ISA as one of the benefits of that sale, you need to make alternate plans NOW.

Hopefully you'll find the information coming in the next series of posts useful as you begin to think about how SBS 2008 will fit into your product offerings to your customers. Don't be surprised if you find that, in some cases, SBS 2008 is no longer a fit for customers where SBS 2003 made sense. Times change and tehnology changes, and so has the SBS product. Please make sure that you are familiar with the product and its benefits and limitations before you start deploying it for your customers.

On Community

eriq — Sun, 20 Apr 2008 16:03:00 GMT

Last week, I had the honor and privilege of attending Microsoft's sometimes-annual MVP Summit. This year, there were over 1700 Microsoft Most Valuable Professionals (MVPs) in attendance, which is only a portion of the thousands of individuals who have been recognized by Microsoft for their support and activity in the community. This event is hardly a love-fest, though, because in general, MVPs are not apologists for Microsoft. Benjamin Romano summed up the relationship well in his article covering Stave Ballmer's Keynote speech to the MVP crowd, referring to the MVP community as "friendly but also highly knowledgeable and unabashedly critical." In many of the hallway discussions I had with MVPs from other product groups, there was one theme that was echoed almost unilaterally - MVP interation with the product groups this year was wide open with feedback flowing fully in both directions. For some groups, this was the first time this type of interaction had occurred. Some MVPs finally had an opportunity to interact directly with the people (yes, people) responsible for planning, coding, and marketing the various Microsft products, and give those people their thoughts on product direction, functionality, problems, successes, etc. (I must admit, that as an MVP within the WESS product line, I've almost come to take this level of interaction with the SBS product team for granted, but even our group this year had, I believe, our most open interaction with the product team to date. And that's not something that i ever want to take for granted, because it could very easily be removed.

I have received the MVP award three times now, and I continue to be honored by the recognition. I have an opportunity to interact with some truly amazing people, and I continually wonder why I've been chosen to be a part of this group. These people have a passion forthe Small Business Server product and, if possible, an even stronger passion for working with other IT Pros and end-users who ply their craft while using the product. The wealth of knowledge, experience, and insight that this group collectively possesses is awe-inspiring, and Microsoft is fortunate to have collected this group together and sought their opinions and expertise to help improve the product and their relationships with the community. Not that they get it right all of the time, but that's not the point of this post.

The point of this post is that community exists with or without the presence of Microsoft. Whether I continue to be awarded MVP status or not, I will continue my activites in the community. I'm working harder to get more involved with my local SBS User Group, and after issues with my day job settle down a bit and I get further along with a certain book project, I'm looking forward to getting more involved in the newsgroups and the forums over at smallbizserver.net again. Right now my reality encompasses keeping my customers happy and keeping my publisher off my back for a little longer, not to mention keeping my home life in order, too. Working 70-80 hour weeks since the first of the year has put a strain on a lot of things, both in my personal and professional life. But while it would be easy to walk away from the community altogether, I simply cannot. Community has been an inspiration and resource for me for the last 20+ years, and I plan to continue working with and giving back to the community that has given me so much over time. If Microsoft chooses to continue to recognize that part of my life by awardin me with MVP status, great, but I'm not out to make a minimum number of newsgroup or forum posts, blog posts, user group meetings, conference appearances, etc., I see people who do, and that disappoints me, because I think theyre doing it for the wrong reasons. I'm not active in the community just to get an MVP award. I'm active in the community because I believe I have something to offer back, and that is what motivates me.

I will admit, though, that attending the Summit, despite the stress of travel, etc., was actually a bit of a break for me, and one that I needed to get myself re-energized to tackle the next 3-6 months. I have a book to finish, and when SBS 2008 gets released, I'll have a number of community members to help get adapted to the new product. That's going to take a lot of energy, and honestly I was reminded of the reason for it during my week at Summit last week.

For those who are interested, I've blogged about my week's activities on my personal blog, under the Summit2K8 category.

On Service

eriq — Fri, 21 Mar 2008 01:56:00 GMT

As a service provider (aka "vendor”) to my clients, I'm very cognizant of what constitutes good service and bad service. We strive to provide outstanding service, as I've been endeavoring to do in the 20+ years I've been in this line of work. Choosing to work in the SMB space has given me some new insight into the "service" we often put up with as small businesses or small business advisors. Some enterprise organizations who have entered the SMB space haven't yet figured out how to best provide service to the smaller customer, and it can get very frustrating to be stuck in the middle of the client who needs to have an issue resolved and a large vendor who doesn't pay as much attention to their smaller accounts.

So when I encounter notable service, either good or bad, I make the effort to provide feedback. When the service needs to be improved, I make an effort to reach out to the people behind the service process and share my experiences in a matter-of-fact way, trying to avoid a heated or angry discussion. When the service goes beyond expectations on the positive side, I try to provide feedback about that with the appropriate parties within the company, and sometimes share those positive experiences with the greater community.

Today I encountered service experiences on the extreme opposite ends of the service spectrum and I wanted to share a brief summary of each here.

A vendor I've been working with for almost two years has a great product that I continually recommend to the community, and is pretty much a required component for many of our customer's systems. However, my experience with their support department has not lived up to my expectations. This afternoon, I called my sales contact with this company and asked who was the appropriate person to share feedback with, and my contact gave me the contact information for another person within the organization. I left this person e-mail and voicemail explaining the crux of my concerns and why the level of response I've received was not acceptable. In the last year, I've had reason to contact their support organization three times. All three times I used the "support request" form on their web site, and all three times that request has effectively been ignored. The most recent was the request I put in this past Sunday. I received the auto-response immediately, and haven't heard a peep from them since. Fortunately, this particular issue isn't affecting performance, but four days without a response is simply not acceptable, especially since that's the only way they advertise to reach their support department. Tomorrow I will be calling the technical resources within the company that I've called on before when I had to escalate. I shouldn’t have to do that, and that's the message I'll be passing along to the individual who I attempted to contact earlier today.

On the other side of the coin is Scorpion Software, who provided a status update today on an issue that they've been working on with one of my clients who made a minimum purchase of their AuthAnvil system. This client has a single-purpose need for the AuthAnvil solution, and they've run into two major issues with the implementation. One issue was resolved by a modification to one of the components of the AuthAnvil suite, and that was turned around within a week. The other issue turned out to be a problem with the software they're trying to integrate AuthAnvil with, but Scorpion Software have taken it upon themselves to work directly with the other vendor to get a resolution. And even though it wasn't necessary, they've kept me in the loop through the entire process.

I've also encountered two issues with the AuthAnvil software in our deployment. In both cases, a quick contact with the company, and specifically with Dana, has turned into two very quick resolutions.

It's clear to me that some vendors "get" service while others do not. Dana and the rest of the staff at Scorpion Software get it. They have embraced the SMB market, and even though their product is head and shoulders above the competition, they've not developed an attitude about it. I’ve learned a few things in my interactions with Scorpion, and I'm going to try to incorporate a couple of elements of those experiences into the way we run our operation, so that we can continue to provide outstanding service to the clients we work with.

On Securing RDP

eriq — Fri, 21 Mar 2008 01:26:00 GMT

Last December, I worked out an arrangement to better protect our clients for whom we provide primary support. This involved finding ways to tighten access their severs via RDP (the infamous port 3389). There are a lot of different takes on controlling access to port 3389 out there, from simply not allowing it at all through the firewall (which works for SBS boxes running Remote Web Workplace, provided there's not a problem with IIS on the box at the time you want to access it) to configuring the firewal to allow inbound port 3389 connections only from specific IP addresses. For our purposes, neither of these options, nor the other similar variations, really worked for the way we conduct our business.

Enter Dana Epp and Scorption Software. Dana is a Security MVP from Vancouver whose software development company has been developing security products designed fo the SMB market for a couple of years.

After working with two of his tools, AuthAnvil and RWW Guard, we finally developed an approach that mitigates the risks of opening port 3389 to the internet, yet still allowing our opration a reasonable level of access for support and maintenance. Here's the approach we're taking.

Create a secondary administrative account with the same name across all of our supported servers.
Change the password on the Administrator account to be a really, really secure password.
Modify the local security policy to deny the Administrator account the ability to log in via terminal services, effectively limiting the Administrator account to a local console login only (which also does not affect any services running with that account).
Install the WinLogon Agent component of AuthAnvil on each client system and point it back to the AuthAnvil system running on our servers.
Configure AuthAnvil on our servers to have a grouped account, whose name matches the secondary administrative account we created on our supported servers, and add local users to that grouped account who are allowed to log in to the remote server.
Add the Administrator account to the AuthAnvil Override security group on the local server so that the Administrator account does not require a token to log in to the server.

We have started rolling out this configuration this month, and so far it is working according to plan. The benefits of this arrangement include:

Local access to the sever is still possible with the Administrator account and no security token.
Remote access to the server is limited to the secondary administrative account, which also requires the use of a security token to successfully log in.
The access logging in AuthAnvil gives me an accurate accounting of hich of my staff accessed one of our support servers and when.
When staff turnover occurs, access to remote systems is denied in a single step by disabling the employees token in the main AuthAnvil system.

So for the cost of equipping my staff with the security tokens, we are able to increase the security of our supported systems with two-factor authentication, while blocking remote access to the Administrator account at the same time.

None of this would have been possible without Dana's efforts to bring quality security products to the SMB space at an affordable price. It's a very small price to pay for the enhanced security benefits our client base is receiving.

On Choice

eriq — Thu, 13 Mar 2008 21:36:00 GMT

People who prefer to use Macs and people who prefer to use Windows PCs don't always get along (big surprise). As someone who interacts with both communities, I get to see the good and the bad on both sides. Yes, discussions between the two camps can get heated and polarized (I think "religious war" is a term that gets bandied about occasionally), and so long as the discussion remains good-natured, I don't mind participating in a discussion, as I'm in a position to speak to the benefits and drawbacks of each platform. But when the discussion resorts to name calling or absolutism, I walk away and distance myself from the other parties. There's no value in continuing to participate in a discussion when it gets to that level.

Recently, I observed an interchange in a public forum where someone made a comment about a web post relating to Apple technology. Two posts later in the "discussion," someone threw out an absolutism that Macs are not viable business machines. And the remainder of the thread was jumped on by the "me too" crowd. I get so frustrated by the zealots on both sides (yes, even though the term "zealot" is usually bandied about by Windows folks referring to the Mac community, it does go both ways) who can't settle for expressing their like or dislike for a program/product/platform and instead resort to absolutism.

Those of you who fall into one of the two extremist camps, stop reading now and go elsewhere on the net. You're not going to like what follows.

I run my business on a Mac. Yes, I have an SBS 2003 box in the server closet, and I'm running a Terminal Server with Windows 2003, and I have a test box running Windows 2003 R2 x64. But my main workstation, the tool I use every day, is a Mac. And doing so doesn't make me less productive, less capable, or less efficient than if I was running just a Windows XP or Vista PC. Yes, I am running Windows XP on the Mac using Parallels, and before you Windows zealots (yes, I think there are probably a couple of you that didn't heed the warning above) say "ah HA! You DO have to run Windows so therefore your Mac isn't a good machine for you," there are exactly two tools I use under Windows, and quite honestly, I could run those tools on my TS if that box weren't as underpowered as it is. One is Outlook, which in reality I could opt not to use since I have Entourage on my Mac, but there are some pieces of Outlook 2007 that are nicer to deal with than Entourage 2008. The other is Internet Explorer, but I only use that for two specific web tools that require an ActiveX control to perform correctly.

For everything else, I'm primarily using tools on the Mac. While I have both Office 2007 and Office 2008 available, I regularly use Office 2008 for Word, Excel, etc. 95% of my web browsing is done with Firefox on my Mac. Why? Office 2008 is fully file-compatible with Office 2007, and the interface is solid (not to mention there's no ribbon bar). And I do operate at significantly lower risk of web-based threats by surfing on my Mac than in IE.

Note that I said "lower risk" not "completely free from." No, the Mac platform is not inherently more secure than Windows, per se. But is is targeted far less than Windows, and Windows-specific attacks simply have no impact in my Mac apps. I'm not naive enough to run my Mac without Antivirus protection (Sophos) and hardened settings in the network firewall in OS X. But if there's a suspicious URL I need to investigate, I'm less apprehensive about approaching that site with Firefox on the Mac than I would be, even with Firefox under Windows (which, yes, I have loaded also).

This arrangement works for me. It doesn't work for my current staff, but if I do hire in someone who prefers to work on the Mac platform, we'll make allowances. It's not going to work for every IT pro out there, and I'm not suggesting that it would. Nor am I suggesting that anyone who is not already familiar with the Mac platform would be more productive after taking the time to learn how to navigate the system.

But what I am suggesting is that displays of absolutism don't come across the way that some of the absolutists think it does. In this industry, I don't think you can really take a totally absolutist approach. When I see consultants brag about how they talked a client out of getting a Mac simply because the consultant didn't want to support it, I'm disappointed. Both for the consultant and for the client. Just because the consultant isn't comfortable with the Mac platform doesn't mean that forcing the client to work on a Windows box is going to be the best scenario for the client. Case in point: I dislike the Blackberry devices. Loathe them, specifically. Yet I have several clients who are using Blackberry devices, and we support them. Why? Because after discussing the pros and cons and looking at all the alternatives, in these cases the Blackberry is really the best solution for these clients. Same with the iPhone. Those who choose to stereotype will probably be amazed that I actually work very hard to talk my customers out of getting iPhones (since I'm a Mac-lover, I must want to see the iPhone take over the world, right? Wrong.) But I have two clients who carry them. One who purchased the device before consulting with me, but now he has learned the lesson about discussing technology purchases BEFORE making them, so it wasn't a total loss. The other chose to go with the iPhone after discussing the options with me for several weeks. In his case, it has turned out to be a benefit to him, even with the shortcomings the current iPhone has in the area of Exchange connectivity.

The bottom line is that there is no absolutely right and absolutely wrong technology. When I see my peers in the industry take stands about certain technologies, I cringe. I see consultants who refuse to support Blackberry. I see consultants who refuse to support Apple technology. I see consultants who refuse to support Linux. I see missed opportunities. My potential customer base is larger because we support Apple, because we support Blackberry, because we can work our way through a Linux box. This is one thing that sets us apart from our local competition. When you draw a line in the sand with a customer, you force them to make a decision. While some see the outcome as the customer choosing to go along with the trusted advisor, there will be some who will choose to find another provider.

I choose to run my business on a Mac. I choose to support Blackberry even though I wish they'd all just disappear overnight. I choose to be flexible in what we support as a company, because I choose not to artificially limit my potential customer base.

Customers can choose, too. And often do.