On Service

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

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.

1. Create a secondary administrative account with the same name across all of our supported servers.
2. Change the password on the Administrator account to be a really, really secure password.
3. 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).
4. Install the WinLogon Agent component of AuthAnvil on each client system and point it back to the AuthAnvil system running on our servers.
5. 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.
6. 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

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.

On iPhone and Exchange

It's official! Apple will support connections to Exchange server in the next version of the iPhone, according to Apple's web site. No date has been made publicly available for the release of the next version of the iPhone software, nor does Apple indicate if the company will make the iPhone available through carriers other than AT&T. But for those who have been asking about if Apple will support Exchange Active Sync, the answer is apparently yes.

And yes, I have applied to be in the Enterprise Beta for the iPhone 2.0 software.