OnQ : SBS

On Foundation

eriq — Thu, 02 Apr 2009 18:36:00 GMT

On April 1 (maybe not the best move), Microsoft introduced Windows Server 2008 Foundation, or at least that's the name of the product on the official product page. Sure, it won't be long before we're referring to it as "Foundation" or "Foundation Server" but I digress. The two important items I want to cover in this post are:

This product is not an April Fool's joke.
There is already a great deal of confusion about this product.

The first point is fairly self-explanatory. As to the second, yes, the official pages at Microsoft are a bit vague about the limitations of the product, and you do need to be aware that there are some specific EULA and product limitations for this system. Those details will be getting hashed out over time in cyberspace, and at least initially I don't think it's critical for the small business IT pro to get in a panic about knowing or not knowing what all of the limitations are. It's still going to be a bit before you can actually get the product from the OEMs (one of the restrictions), so you've got time to get the skinny on the details of the limitations. What is important to know up front, I think, is where this product really fits into the grand scheme of small business computing.

One common theme I've already seen hashed out in a number of forums is that Foundation is a direct competitor to Small Business Server and Windows Home Server. It isn't. In fact, it can be used to augment networks where Home Server or Small Business Server are already in place. One place where Microsoft does see a need to be filled is in the micro business space (if I can use that term, referring to the less than 5 user business or home business) where cash flow just doesn't allow for a business to implement Small Business Server. The micro business may not need all of the bells and whistles of SBS (perhaps they've already got hosted e-mail and/or SharePoint somewhere) but they do want or need a small server to handle a specific task, such as a central file server or print server, or even a LOB app server (especially if the app is not SQL based) or a small Terminal Server. While we haven't seen specific pricing on the software that the OEMs will be charging (as of the moment of this post), the idea is to have a small scale server available for a small business at a low price point. And in some cases, it makes sense. If a business is looking to purchase a small server in the $500 range, are they all that interested in purchasing an operating system that costs more than the hardware? Not according to the research that Microsoft has done.

So how can Foundation be used in a small business? Well, let's hit a few of the product specs and limitations up front to give you some background for this discussion.

Foundation is Windows Server 2008.
Foundation is limited to a single physical processor. That processor can have as many cores as possible, but Foundation will only be sold on single-processor systems.
Foundation is limited to a max of 8GB of RAM.
Foundation is 64-bit only.
Foundation is limited to a maximum of 15 users.
Foundation is only available through the major OEMs (Dell, HP, IBM, etc.) and not through the System Builder channel.
Foundation has no support for virtualization - it cannot be used as a Hyper-V host or guest.
Foundation can be a Domain Controller or a Member Server.

There are many other items not included in this list, but this gives us enough of a basis to discuss what roles Foundation could play as a solution for your clients. I'm going to limit the scope of the rest of this post using examples where the business has no more than 15 users.

If you already have an SBS server in place at a customer site, but you're needing to add a line of business application that you know isn't going to play well with IIS on the SBS server, Foundation might be a good fit. Since it's Windows Server 2008, it supports IIS (along with the other Server 2008 tools) and can be a member server in an SBS network. If the LOB application requires a SQL back end, it might not be a good fit for Foundation, thanks to the 8GB limit (SQL can be very memory-demanding).

Suppose you need to add a Terminal Server that will only be used by a couple of users in the business, and the applications they will be using on the Terminal Server are not memory-intensive. Foundation may make sense as a solution here. You will still need to purchase Terminal Server CALs and configure Foundation with the Terminal Services roles, but it will work.

Suppose you have a customer that has 4 computers in a peer-to-peer network looking for a server to centralize their shared data. They are happy with their current e-mail situation, and they're working on a tight budget. Foundation might make a good solution for them, as they can use it as a DC to use Active Directory for central authentication and file share security on the server.

These are just a few examples of how Foundation could be used to be a first server in a small organization or to augment services in an existing small network. In the new few weeks as the stories become clearer, I'll post some additional scenarios where Foundation could be used. In addition, I'm preparing for a presentation on Foundation server for the upcoming SMB Summit in Dallas in May.

Bottom line, Foundation can be a valuable addition to the small business IT professional's solutions catalog. In cases where the cost of putting in an additional 2008 server into the network has been financially prohibitive for the smaller customer, Foundation may now make that type of solution more fiscally reasonable. Stay tuned for more information.

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 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 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 Protection

eriq — Wed, 20 Feb 2008 16:36:00 GMT

I've already seen several questions floating around following the announcement today about SBS 2008 and some of the product details. SBS 2008 will include a one year trial subscription for both the Forefront Security for Exchange (anti-virus, anti-spam protection for e-mail) and Windows Live One Care for Server. Does that mean you have to use these products to protect your SBS 2008 deployments?

The answer is NO. Just because they're included in a "trial" version does not mean that you're locked into using these products. You will be able to remove both Forefront and One Care if you choose and use your own preferred protection software. For businesses who will be "upgrading" from SBS 2003 to SBS 2008, this will likely be the case.

But for new businesses, or businesses who are deploying SBS 2008 as their first server, the inclusion of both Forefront and One Care gives that business, or the consultant who deploys for that business, the opportunity to have protection right out of the box, either while making the decision about an appropriate product for the client, or while waiting for the preferred vendor to release a version of the protection suite that is compatible with SBS 2008, and those may not be ready at the time the product ships.

Bottom line, if you're not comfortable or familiar with Forefront or One Care and want to use your own protection tools, you will be able to.

On Numbers

eriq — Wed, 20 Feb 2008 16:24:00 GMT

50? or 75? Which is it?

In reviewing the product propeganda about SBS 2008 from the Essentials site at Microsoft, there's a pretty consistent theme in the way the SBS 2008 and EBS 2008 products are positioned - 50 users. Specifically, on the Choose Solutions page, SBS 2008 supports "up to 50 users or devices." Same message in the official press release from February 20, 2008: SBS 2008 is "ideal for organizations with up to 50 PCs." However, on the SBS Blog Post announcing the Essential family, the limit is 75 users. Specifically, SBS 2008 is "designed for organizations with up to 50 users, but will support organizations with up to 75 users."

So which is it? In SBS 2003, Microsoft increased the user/device license from 50 users in SBS 2000 to 75 users/devices. Is this a step backwards?

Not really. The likelihood of a 75 user/device organization realistically running everything to do with their operation on a single box with SBS 2003 was pretty slim, but it did depend on the type of activity in the organization. Microsoft marketing is clearly trying to make the differentiation that SBS 2008 is geared for 50 users and fewer, while EBS 2008 is geared for 50 users and greater. In practice, we know that there will be smaller organizations (15-20 users) where EBS will be a better fit than SBS, and there will be larger organizations (50-60 users) where SBS will be a better fit than EBS.

So if you're concerned that MS has reduced the licensing limit with SBS 2008, don't be. You still can have up to 75 users/devices connected to an SBS network. But the reality is that if you have more than 50 users/devices, you really probably should be looking at EBS and not SBS as a solution.

On SBS 2008

eriq — Wed, 20 Feb 2008 12:42:00 GMT

Yep, it's now official. Microsoft has released some additional information about the next version of the Small Business Server product line, and we can finally start sharing some infomation about it.

SBS 2008, what we had lovingly called Cougar up until now, is part of a larger family of products known as the Windows Essential Server Solutions, which includes Cougar (SBS 2008) and Centro (Essential Business Server 2008) as the first two members of the family. The Official SBS Blog has information about the product lines, and Microsoft has posted a page for the product family as well.

The most significant change in SBS 2008 from previous releases of SBS is the inclusion of a second server in the Premium edition, moving SBS from a single-server solution to a two-server solution. SQL 2008 is included in the Premium edition along with a license for Windows Server 2008 to put SQL on the second server.

There are still a number of questions that we don't have answers for yet. The release date has not been announced. Full details about the technologies that will be bundled with SBS have not been published yet. I'm sure some of this information will be made available from Microsoft through the remainder of the development cycle, but I'm also sure that there are a few things we won't know until we get actual shipping media in our hands.

In addition, I'm also glad to officially announce that I'm working with a team of authors to bring you Microsoft Small Business Server 2008 Unleashed, which is expected to hit the bookstores around the same time the product is actually available in the marketplace. The authoring team remains under strict NDA about the product, so we won't be able to share any NDA information until the product, and the book, are finally released.

On Sydney and Security

eriq — Thu, 29 Nov 2007 18:36:00 GMT

I’m finally getting back in the swing of things following the week I spent in Sydney with my wife and friends. We headed down to Australia for the SMB Security Summit put on my Trend Micro and SBSFAQ.com, and a bit of sightseeing as well. It was a long trip, and I have a renewed respect for the efforts our Australian counterparts to come to the US as often as they do. I certainly couldn’t imagine making another trip like that for quite a while, despite my issues with flying in general.

But I gladly went to the conference, not only to help out my friend Wayne Small, who offered me an opportunity to speak and share my expertise in the forum, but also to learn. Every chance I have to participate in an event like this is more than just an opportunity to give back to the community, but it’s a great chance for me to listen to other experts and either get reminded of issues that have slipped to the back of my mind, or to acquire new information that I didn’t have before. Being able to mix and mingle with the likes of Dana Epp, Amy Babinchak, Susan Bradley, Wayne Small, Dean Calvert, and many, many others and pick their brains about issues I’m facing with my company or my clients was a fabulous opportunity.

There were several common themes that prevailed during the myriad of discussions both in and out of conference that week. Two of the key ones were the importance of least privilege and improving authentication. Clearly, Dana’s AuthAnvil offering from Scorpion Software was a big point of discussion for bringing affordable and easy-to-manage two-factor authentication into the micro and small business arena. But more than just a sales pitch, Dana makes a clear case for the importance of two-factor authentication and how implementation of such a system can significantly improve security for even the smallest operations.

The interesting take on least use privilege, however, was not from the user perspective, but from an administration perspective. Amy and I discussed in our session on security and remote support the importance of realizing that as more and more IT shops begin to provide remote support to their widening client base, those shops cannot and should not increase the security risk to their clients in order to make it easier for them to support those clients. There was a lot of good discussion during our session stemming from some very insightful questions, and I think we all came away from the day with a good sense of things to think about within our own firms as we move forward.

One practical point that I’m starting to implement in my operation is the use of AuthAnvil to help protect those servers we support who have port 3389 open to the Internet, even temporarily. With a combination of an additional administrator-equivalent account on the network, installation of the AuthAnvil software, and a requirement that access to the server be protected by two-factor authentication, we can significantly reduce the risk of having port 3389 open to the Internet as well as increase the level of documentation when these sites are accessed. That, and it gives us an “in” to discuss two-factor authentication with our clients and work to really help them reduce their own security vulnerabilities.

Thanks to everyone who participated in the conference and helped make it a real benefit to those who were able to attend. Thanks for the insightful questions that got us all thinking, and thanks for the opportunities to not only help others improve their own operations, but to help me bring my own ship in a little tighter as well.

On Follow-Up

eriq — Tue, 13 Nov 2007 12:25:00 GMT

In yesterday's post, I covered the problems being seen in the community regarding the unexpected behavior on SBS 2003 R2 boxes because of a problem with a WSUS definition update. Given the volume of traffic that post generated (more hits in the first 4 hours of that post than any other single post on this blog, period), there were a lot of people impacted by this issue, and apparently not a lot of information out there. Yes, i found a number of threads in other discussion foums, but most hinted at the behavior an didn't document the full code of the errors, etc. So there was a lot of internet traffic and human effort expended over this issue yesterday.

Late yesterday afternoon (well, my time anyway) the Official WSUS Blog finally put up a post about the issue and detailed the causes behind it. A few hours earlier, the folks at the Official SBS Blog put up a post detailing the resolution, specifically noting that the normal course of updates for the WSUS services on the server would fix the problem so that today everyone's SBS boxes should be back to normal.

I checked on the last of my managed servers this morning, the one I left untouched to test this theory for myself, and sure enough, it updated and WSUS and the Performance Reports are back to "normal" on the servers.

So, all's well that ends well, right? Ah, not exactly.

This event has raised some concern in the community about the WSUS product and the SBS R2 implementation of WSUS. For the remainder of this post, I'm not speaking for the community, but from my own personal concerns about the topic.

Hindsight allows us to look back and see that, in the grand scheme of things, this was not a major catastrophe. In fact, the server that I left completely untouched yesterday to test the automatic update fix had no performance issues at all. The customer who uses this server didn't lose a piece of e-mail, didn't lose access to the server, didn't lose any productivity, in fact, they were never aware that there was even an issue that we were looking at. That's good, because that's one less client I have to explain this to, and that makes my life a little easier today.

But at the time we were dealing with this yesterday, we didn't have that insight. What initially looked like a Performance monitor issue quicky became a WSUS issue, and in the midst of it, we had no idea if WSUS was completely broken or what it might take to get it back or what other functionality might be affected. To be honest, when something affects a class of devices across the world, I'm a litlte more apt to spend time to figure out how this could be impacting my own client base, who I am ultimately responsible for. The lack of information was frustrating (one of the reasons I put the post up yesterday, so that hopefully someone who was seeing the issue could get concrete evidence that there was a larger problem and someone was looking into it, even if it wasn't an official Microsoft source) and I really, really hate operating in a vacuum. In total, our operation lost 75% of our business day identifying the problem, diagnosing the problem, communicating with others about the problem, and ultimately implementing the workaround for a few of our clients to get them back on track, given that we still didn't know the breadth of the problem. And I know we were not the only business impacted in this way.

Ultimately, I'm concerned that given the nature of the problem and the "fix," the community has absolutely no way to ensure that this issue won't happen again. By the very nature of the way WSUS operates, and specifically the way SBS R2 implements WSUS, the exact type of mistake made by Microsoft yesterday could happen again and bring down thousands of WSUS processes again. This fact is what is giving me serious pause about WSUS in general and the SBS R2 implementation of WSUS.

In the interest of full disclosure, I am NOT a WSUS guru by any stretch of the imagination. The extent of my understanding of the R2 implementation of WSUS is to make sure that I leave the default settings enabled so that I can see the Green Check of Health and not the Blue Check of Misconfiguration, which should help me better identify when my R2 installations are out of compliance. Reports say that those who manually installed WSUS, specifically configuing it to only identify updates that are needed by that particular installation, were not affected by the problem yesterday. In fact, since the problematic update was for a BETA build of a product that I do not have installed at ANY of my client sites since I am not participating in that particular beta, I should not have had any system pull down the dictionary for that particular product. But somehow, an SBS R2 box with a single NIC card (i.e., could never run ISA to begin with, much less one that was not participating in the ISA Nitro beta) got the definition update for this beta program and lived with a crashed WSUS for a full 24 hours. At least, that's the way I understand it, given my relative inexperience with WSUS.

This simply should not have happened.

For the next few days, I now get to spend time learning about WSUS and see how I can modify the configuration of WSUS on the servers I manage to minimize the risk of this happening again. This means I have to reprioritize my workload so that I can try to make sure my clients have a lower risk of being affected by a problem that, quite frankly, may never appear again. But given Murphy's Law, if I take the road that it won't happen again so I don't need to do anything, as soon as I leave the country (which is happening in less than a week) another mistake will happen that will impact these boxes, and the rest of my operation will be left scrambling to deal with the issue while I'm stuck in a plane. Thanks a lot, Microsoft, for recalibrating my work week for me.

Understand, I don't specifically fault Microsoft for making a mistake. Who among us hasn't made mistakes? Though some have said that this type of mistake shoudl never have occured, well, stuff happens, you know. What I do fault Microsoft for is the design of the system which allowed this particular mistake to have such a widespread impact on systems that should never have seen this specific update, ever. How did a server that's not even capable of running ISA get a definition update for a product that's not even a released product? This is what I have to spend time on now, getting a better understanding of how WSUS works so that I better understand the risks I am putting on my clients by using this tool.

Wait, did I just say that running WSUS increases the risk vector for my clients? I thought the entire purpose of WSUS was to help reduce the risk vector for my clients. Ironic.

On Errors

eriq — Mon, 12 Nov 2007 15:18:00 GMT

This morning (November 12, 2007) a rash of reports are floating around the net about problems viewing the Monitoring report on SBS servers. This appears to be an issue with SBS R2 servers with the R2 WSUS installed. Several factors indicate the problem:

The daily monitoring e-mail shows the following instead of the normal performance report:

	The page cannot be displayed
An error occurred on the page you are trying to view.
To work around this problem, perform the following steps. After each step, try again to access the page. Ensure that the MSSQL$SBSMONITORING service is started. Ensure that the server is not low on memory or disk space. Restart the server. Verify that the server is functional and that there are no system-wide problems. Run the Set Up Monitoring Reports and Alerts task in the Server Management Monitoring and Reporting taskpad.

You will see the same verbage when you open the Monitoring node in the Server Management console on the server.
When you look in the event logs, you will see an error similar to:

Event Type: Error
Event Source: ServerStatusReports
Event Category: None
Event ID: 1
Date:  11/12/2007
Time:  6:00:15 AM
User:  N/A
Computer: SERVER
Description:
Server Status Report:
URL:  http://localhost/monitoring/perf.aspx?reportMode=1&allHours=1
Error Message: The specified string is invalid.
Parameter name: Title
Stack Trace:    at Microsoft.UpdateServices.Internal.BaseApi.UpdateContainer..ctor(GenericReadableRow row)
   at Microsoft.UpdateServices.Internal.BaseApi.UpdateCategory..ctor(GenericReadableRow row)
   at Microsoft.UpdateServices.Internal.BaseApi.UpdateCategory.BuildUpdateCategoryCollection(GenericReadableRow[] categoryRows)
   at Microsoft.UpdateServices.Internal.BaseApi.UpdateCategory.GetAll(DateTime fromSyncDate, DateTime toSyncDate)
   at Microsoft.UpdateServices.Internal.BaseApi.UpdateServer.GetUpdateCategories(DateTime fromSyncDate, DateTime toSyncDate)
   at Microsoft.UpdateServices.Internal.BaseApi.UpdateServer.GetUpdateCategories()
   at Microsoft.SBS.UpdateServices.DataProvider.GetScheduledUpdates()
   at Microsoft.SBS.UpdateServices.StatusPage.Utility.GetStatusItems()
   at usage.frmPerf.PopulateStatusItems()
   at usage.frmPerf.renderReportWorker()
   at usage.frmPerf.renderReport()

http://go.microsoft.com/fwlink/events.asp

When you try to open the Update Services node in the Server Management console, you will see a page similar to the following:
Server Error in '/UpdateServices' Application.
--------------------------------------------------------------------------------

The specified string is invalid. Parameter name: Title
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

Exception Details: System.ArgumentException: The specified string is invalid. Parameter name: Title

Source Error:

Line 194:  </div>
Line 195:  <%Response.Flush();
Line 196:    RenderPage();%>
Line 197:  <div id="divForm" style="display: none">
Line 198:  <form id="formMain" method="post" runat="server">

Source File: c:\inetpub\UpdateServices\Home.aspx    Line: 196

Stack Trace:

[ArgumentException: The specified string is invalid.
Parameter name: Title]
   Microsoft.UpdateServices.Internal.StringValidation.ValidateUpdateContainerTitleString(String paramName, String value) +256
   Microsoft.UpdateServices.Internal.BaseApi.UpdateContainer.set_Title(String value) +19
   Microsoft.UpdateServices.Internal.BaseApi.UpdateContainer..ctor(GenericReadableRow row) +182

[WsusInvalidDataException: The specified string is invalid.
Parameter name: Title]
   Microsoft.UpdateServices.Internal.BaseApi.UpdateContainer..ctor(GenericReadableRow row) +397
   Microsoft.UpdateServices.Internal.BaseApi.UpdateCategory..ctor(GenericReadableRow row) +24
   Microsoft.UpdateServices.Internal.BaseApi.UpdateCategory.BuildUpdateCategoryCollection(GenericReadableRow[] categoryRows) +418
   Microsoft.UpdateServices.Internal.BaseApi.UpdateCategory.GetAll(DateTime fromSyncDate, DateTime toSyncDate) +134
   Microsoft.UpdateServices.Internal.BaseApi.UpdateServer.GetUpdateCategories(DateTime fromSyncDate, DateTime toSyncDate) +23
   Microsoft.UpdateServices.Internal.BaseApi.UpdateServer.GetUpdateCategories() +52
   Microsoft.SBS.UpdateServices.DataProvider.GetScheduledUpdates() +140
   Microsoft.SBS.UpdateServices.StatusPage.Utility.GetStatusItems(Boolean waitingForSyncStart) +3199
   Microsoft.SBS.UpdateServices.StatusPage.formHome.RenderPage() +23
   ASP.Home_aspx.__Render__control1(HtmlTextWriter __output, Control parameterContainer) in c:\inetpub\UpdateServices\Home.aspx:196
   System.Web.UI.Control.RenderChildren(HtmlTextWriter writer) +27
   System.Web.UI.Control.Render(HtmlTextWriter writer) +7
   System.Web.UI.Control.RenderControl(HtmlTextWriter writer) +243
   System.Web.UI.Page.ProcessRequestMain() +1926

--------------------------------------------------------------------------------
Version Information: Microsoft .NET Framework Version:1.1.4322.2407; ASP.NET Version:1.1.4322.2407

[Edited at 3:00pm CST]
I think there's a workable resolution for this now. I've done this on a couple of my sites, and it's resolved the issue. Here are the step-by-step instructions that got this working:

Open a command prompt.
Type the following at the prompt and hit Enter:
osql -E -S %COMPUTERNAME%\WSUS
Type the following lines at the prompt and press Enter after each one:
use SUSDB
Update tbPrecomputedCategoryLocalizedProperty
Set Title = Replace(Title, '"', '')
Where Title like '%"%'
go
[note that in the Set Title line, the characters are single-quote, double-quote, single-quote following Title and two single-quotes before the close parenthesis; also, in the Where Title line, the characters are single-quote, percent, double-quote, percent, single-quote]
After you enter the "go" line, you should get a response that tells you how many rows were affected.
Type the following lines at the prompt and press Enter after each one:
Update tbPreComputedLocalizedProperty
Set Title = Replace(Title, '"', '')
Where Title like '%"%'
go
[note that the Set Title and Where Title lines are exactly the same as the first set of commands you entered]
After you enter the "go" line, you should get a response that tells you how many rows were affected. It may take a little longer for this one to process.
Type "quit" and press Enter to get out of OSQL.

Once you finish this, you should be able to go back into the Update Services node of Server Management and click Refresh to bring up the WSUS status again. Please note that I personally have only done this work for a couple of systems, and it resolved the issue (for the time being) on those boxes. This is NOT a permanent fix and could well break again if Microsoft issues another update that includes doulbe-quotes in the update title.

More information about the behind-the-scenes reasons for these issues were found in a thread at forums.techarena.in and another at SANS. At the time of this edit, there has been no info posted at the WSUS team blog.

[Edited at 3:40pm CST]
I have been informed that the faulty information that was pushed into WSUS yesterday has been updated and *should* automatically get pulled in during the next scheduled WSUS update. WSUS 3.0 can do a manual sync to get the update now, and WSUS 2.0 should get it at 10pm local time tonight. A post is expected from the Official SBS Blog later today. I plan to leave one of my servers in this state to confirm that this operation works as expected tonight, but will manually run the osql steps tomorrow if it does not.

On Leopard, Part 4

eriq — Sun, 28 Oct 2007 21:48:00 GMT

OK, the first of the Leopard How-To's is now posted: Connecting a Macintosh running Mac OS 10.5 to an SBS 2003 Server is now online. There are some key differences between this version of the Mac OS and previous versions, but nothing really earth-shattering. In fact, it's quite a bit easier to get the Mac connected. In fact, if it weren't for SMB signing, it would really be a piece of cake. Oh well.

I've run into a couple of other interesting hiccups related to Leopard installation, and I'll be posting about those as well when I get more concrete information about the issues.

In the meantime, as I did when Vista came out, I'm recommending that people hold off from installing Leopard on their exsting systems, especially on a business-critical machine. Give the bleeding edge folks a little time to ferret out some of the issues that didn't come up in beta testing and get fixes or workarounds before trying to install. I'm probably going to stick with my recommendation that a clean install is a good install for Leopard as well. More on that as information becomes available.

On Leopard, Part 1

eriq — Fri, 26 Oct 2007 16:16:00 GMT

Today is a big day for the Mac community - Apple is releasing Leopard, otherwise known as Mac OS X 10.5, at 6pm local time around the globe. Apple Stores around the world are putting on large showcases and thousands and thousands, if not millions, will be flocking in to pick up their very own copy of the OS. Unless you pre-ordered, that is.

Those who went to the Apple Store on-line on October 16, 2007, could pre-order Leopard (in the single-serving or family pack packages) to be delivered on October 26. So if you didn't want to wait in line with the mobs who will be converging on the Apple Stores (and other places that sell Mac stuff, let's not forget them) to get their copies, you could order on-line and get it shipped to your very own address, wherever that is.

So yours truly placed his order on October 16 and arranged his work days for October 26 and 27 to focus on Leopard. The plan is to have an updated "Connecting your Macintosh to SBS 2003 via SMB" document ready for publication by Monday so those who find themselves in that situation can get the Leopard Mac connected with minimal effort and hair pulling.

Only there's one small flaw with that plan: the Store shows that my order has not shipped yet. Kind of hard to received something today that hasn't been shipped yet.

Well, I've worked with a number of other vendors who have had issues getting shipping information updated in their on-line order systems. I can recall a number of times when tracking information was not available on the vendor web site until after the package arrived at its destination. So, I'm thinking (hoping) that's the case with Apple. Still, it warrants a phone call.

Oops. Maybe I shouldn't have called. Not only does Apple's tracking system show that the product hasn't shipped yet, it shows that it hasn't even been prepped for shipment. So unless there's a large quantity of Leopard boxes in a warehouse in the DFWD area (which wouldn't surprise me, honestly) and they're arranging for a same-day shipping process, I'm not hopeful that I'll actually be removing the shrink wrap on Leopard today.

Still, this could be all of Apple's plan for keeping control of when Leopard actually gets in the hands of the public. It wouldn't surprise me a bit if the shipping information hasn't been updated deliberately to keep the information under wraps. I think that's giving Apple a little too much credit, though. I think I'm set up for a bit of a disappointment today and will have to wait until Monday (Lord, I hope it's not later than that) to crack the case and start working on the docs.

In the meantime, I updated the "Connecting a Macintosh to SBS 2003 via SMB" document to address some of the user interface changes that both Apple and Microsoft have introduced into the various software pieces since the original posts were made almost three years ago. Hopefully that will be useful for someone...

On Partner Event Kits

eriq — Fri, 28 Sep 2007 21:43:00 GMT

This past week, I had an opportunity to use the SBS Partner Event Kit that Microsoft is making available for promoting Small Business Server at events. Our Chamber of Commerce has a Mega Mixer once or twice a year, which is basically a "vendor expo" for area Chambers and Chamber members to promote their goods and services to other area Chambers and Chamber members. This time, I knew I wanted to have a booth (not only to support the Chamber but also for promotion and name recognition, etc.) and about the time I signed up for the booth, I got notification about the Partner Event Kit and followed the simple instructions to request the kit. The rest of this post covers my experience with the kit and the entire kit process, so feel free to skip if you've got no interest in the kit or my experiences.

As per Eric's post, I e-mailed the group requesting the kit on the date of my event, and got an e-mail response asking for some additional information. I e-mailed back the response, and the next day I got confirmation that I'd been approved to use the kit and they collected other information, including shipping address. They made it very clear that they'd ship the kit two days before the event, I'd get it the day before the event, and I'd have to return it the day after the event. I also took them up on the offer to have my company logo printed on a 6'x3' banner for a fee. I had a banner made up a couple of years ago, but information changed and it's no longer usable, so being able to get another banner was a real plus. We went back and forth a bit making sure they got the image file for the banner in the right format, and they even asked to get a couple of additional updates because the first print on the banner didn't quite match up with the logo colors they were expecting, so rather than get a banner whose primary colors were purple and dark green, I got one that had the proper shade of blue and light green. Big plus on customer service on that point.

Two days before the event, I got the e-mail that the kit had shipped and I'd have it the next day. This is unfortunately where things began to get a bit interesting. Towards the end of the day I should have received the kit, I called and asked if they had a tracking number for the package. They sent me the number, and showed that the kit was still scheduled for delivery, but if I didn't get it soon, that I should call the shipper and ask. When it hadn't shown up by 4:30 local time (building closes at 5:30) I called. The shipping company (well, the specific agent I spoke with) wasn't very friendly or helpful, but told me that there was no way that a package of that size (it weighed in at 138lbs apparently) would get sent overnight. I asked when I could expect it, and was told that they should get it to me by noon on the day of the event. Since I had to start setting up no later than 2pm for the event, that was going to cut it close. I communicated this information back to the folks who shipped the kit to bring it to their attention and went home.

The next morning, I got into the office at 7:30 and checked the tracking. At least now the on-line tracking showed that it had left the original facility. It also said that it had left the facility in Ohio at 4:35 that morning. I'm guessing that was EDT, which meant it was only 3:35 my time, but I was curious to see if it really was going to get from Ohio at 3:35am CDT to Denton, Texas, by noon. I called the carrier to see if they could give me an ETA on arrival so I could make sure that someone was at the office to receive the kit, and was pretty much told "no." I had a 10am meeting that I couldn't reschedule, so I left my associate at the office to wait for the package. Not so big brownie points to the shipping company, and I've already submitted that feedback to the appropriate parties.

I got back from the meeting in time to start packing to head over to the event, and sure enough, there was the kit, in all its massively large crate glory. Yeah, I can see why it might weigh 138lbs. The case alone looked pretty heavy, but there's no doubt that the contents of the crate were well-protected.

So we cracked open the crate to look at the contents. As advertised, there was a 19" LCD flat panel display (which hadn't been used before, so the next guys that get it, we left it in really, really good condition for you), table banners for SBS 2003 and Server 2008, an SBS 2003 standing banner, and three clear holders of propaganda (propaganda included). Also present was an extra banner with the company logo.

Rather than try to manhandle the shipping crate to the event, we packed the individual components, along with a computer, extension cord, power strip, keyboards and mice, and our own marketing materials, and headed over to the event. Our booth was near the front of the setup, and we hung the company banner first thing.

Then we set up the standing banner and hung the SBS 2003 banner on the main table. We set up the LCD display on that half of the table to help hold the SBS banner in place. I opted not to use the Server 2008 banner as I didn't want to cause any confusion as to what we were hawking. Then we put up the marketing collateral and finished out the rest of the table.

Even once we put the people in the booth, it still didn't look too bad.

As for the demo, the Kit was supposed to come with a DVD of SBS demos, but didn't (I confirmed with the folks that put the kit together that the DVD wasn't missing, even though it was in the list of items that should have been in the Kit), so we improvised. We built a Vista workstation running Office 2007, and had Outlook via the Internet connected back to a test SBS box at the home office. We also had an RWW session up connected to a test workstation hung off the test network. We also had a shortcut ready to go to connect to the RWW login page on my production box to demo AuthAnvil. And all this was done with a Verizon USB wireless broadband adapter (no networking available at the facility). No huge surprise, but folks not familiar with SBS were surprised at all it could do.

Overall, the event was a success, and having the kit really polished off our appearance at the event. I for one am thrilled that MS has made this kit available, and I hope that this post about the kit and how we used it can answer some questions that others may have had about whether using the kit would be a good idea. I can say for certain that the next opportunity I have for an event like this I'll definitely check to see if I can get the kit again.

On iPhone, Secure E-mail, and other things

eriq — Fri, 14 Sep 2007 11:23:00 GMT

I've mentioned the iPhone in previous posts and how I don't think it's really ready for prime time in the business community. Again, don't get me wrong, I think it's an amazing device, but for the folks that I consult with on a regular basis,it's just not going to be "all that" for them as a business communication tool. I do have a couple of clients running the iPhone, and one of them even tried to return it because it wasn't really doing what he wanted (I should also note that he purchased his iPhone prior to consulting with me about it).

Still, there are ways to get some level of e-mail communication set up with a Small Business Server or other Exchange server, but it requires some configuration changes on the back end of the mail server, and I've put up a couple of posts about doing just that (one for SBS Standard, one for SBS Premium with ISA 2004 to be precise).

I really should have put together something like this a long time ago, because as much as I like IMAP, it has the same core problem that POP3 e-mail does - the entire transaction is done over the Internet in clear text. No only are your username and password clearly visible to anyone who happens to be sniffing your network transaction, but all your e-mail contents are transmitted in the clear as well. By setting up IMAP communications over SSL, the entire transaction is encrypted, thereby protecting your account credentials. Unfortunately, the body of the message, unless it was an internal to internal communication, has already been sent in clear text across the internet when it was sent to you in the first place.

And I guess that's really my core point here - e-mail is NOT a secure communication medium. If you have confidential information you need to transmit to someone else, sending that information via e-mail is not going to get it there securely. Sure you can take steps to secure e-mail communications. You can read and compose your e-mail using Outlook Web Access over SSL (note that not all Outlook Web Access servers communicate via SSL). You can set up your remote e-mail client to use IMAP over SSL, or Outlook over SSL, if your back end mail server supports it. You can get an e-mail certificate that can be used to encrypt individual e-mail messages. But these are all extra steps an will not guarantee secure communications every time. If you mail server does not support IMAP over SSL, Outlook Web Access over SSL, Outlook over SSL, or another secure communications interface (how many web-based mail services actually have you both log in and compose/read e-mail over a secure web interface) then at least one portion of your e-mail communications will be sent across the wire in clear text. If you have an e-mail certificate, but the person you want to send to does not, you will not be able to encrypt an e-mail message to that person.

Yes, there are ways to secure e-mail. It will take some effort. Last year, I had reason to have secure communications with a local vendor that I worked with. My side was secure (Outlook over SSL, Outlook Web Access over SSL, etc.) and we both had e-mail certificates so that I could encrypt messages to him, and he to me. I feel fairly certain that those encrypted messages we exchanged were as secure as reasonably possible. But one he received and decrypted the message, Ihave no idea if or how it stayed secure afterward.

So if you've been thinking that e-mail is a nice, convenient, and SECURE way to communicate with business or other associates, please clear this myth from your mind. If you haven't had to jump through a few hoops to set up secure e-mail, you don't have it.

This sounds like a good topic for a radio show. I'll probably work that in for next week's eOnCall episode.

On Mac

eriq — Mon, 20 Aug 2007 15:39:00 GMT

I had an opportunity last week to present my "Connecting a Mac to your SBS Network" presentation to the Fresno chapter of SMBTN. Through the magic of LiveMeeting, we were able to record the presentation, and it's now available for viewing to anyone who wants to see it.

The program is 90 minutes and since I was in Texas, not in Fresno, you don't have to put up with seeing my mug in the presentation. There is some Fresno-specific content in the recording, but the rest of the material should be of interest to anyone who's been struggling with how to get a Mac connected into an SBS network.

On Feedback

eriq — Tue, 10 Apr 2007 16:05:00 GMT

In previous posts, I’ve lamented about the issues I’ve had with the PERC 5/i controller in Dell servers that I have rolled out to clients and put in my own office. Today, I had a conference call with Dell support and someone from the NOS group about the design of the card. The bottom line at the end of the call is that right now, Dell has no solution for being able to provide any automated notification for an array problem or failure, either through software or hardware. They have heard my feedback and are escalating the issue through the engineering group, but they have no answer for me at this time.

I don’t have a problem with this. In the three weeks I’ve been working with Dell on this problem, they’ve been very responsive and proactive about communicating with me when they have updates on the issue. Personally, I think that the argument I’ve presented is solid enough, and while everyone I have spoken with agrees with me, I’m just not sure that it’s a case of one person really making a difference.

So, at the recommendation of the Dell folks, I have posted the issue to their feedback site, Ideastorm. This is a site Dell has set up to accept direct feedback from their customers, and the engineering group, among others, takes the feedback given on the site seriously.

Well, as seriously as they can. Honestly, after looking through a few posts, there are some garbage posts up there, just like you’d expect from any unmoderated public-facing site that asks for thoughts and opinions. Still, they asked, and I complied.

This is where I want to get assistance from the community, and this request is two-fold. I have spoken with several VARs in the small business space who were totally unaware that there was not audible alarm on the PERC 5/i controller, and most were really quite surprised. So, first, if you interact with other VARs who you know sell or support Dell equipment, please let them know that the PERC 5/i has no audible alarm on it. They may not care, but they should at least know. Second, if you want to see this design changed back to having an audible alarm, or at the very least some automated notification tools running on the server directly (no, IT Assistant will not run on an SBS server, nor will it run on a 64-bit OS), check out my post at Ideastorm and comment or vote on it. If engineering sees a large number of VARs are not happy with the state of the hardware, there will likely be more impetus to take action quickly. The squeaky wheel getting the grease and all that. You will have to register on the site to make a comment and vote, but if you are concerned about this situation, please take the time to do so. Alternately, contact your Dell support or account rep and discuss the situation with them.

On SP2 and Avoidance

eriq — Sun, 01 Apr 2007 13:52:00 GMT

For what it's worth, I now have an official stance on Windows Server 2003 SP2:

Don't install it. At least not yet.

I keep running into folks who have issues with their servers following the installation of SP2. the majority of issues seem to be cause by the enabling of Receive Side Scaling in SP2. This is more than just my experience, too. The Official SBS Blog also notes that RSS may be at the core of a number of problems seen in the SBS community following the installation of SP2. MS has posted KB927695 which gives a registry hack to disable RSS on the server, but the description of the problem in the KB doesn't correlate to the behaviors we're seeing in the field, so the average bloke trying to figure out why he suddenly can't get to external FTP sites or the iTunes Music Store isn't going to find this KB directly.

Though the KB tells the reader to disable RSS in the registry, I've been able to get resolution in all cases I've handled thus far by going into the Configuration properties of the NICs on the server and setting Recive Side Scaling to Disabled. This is a far more palatable resolution for most people than going in and modifying the registry.

Another common thread we've seen in blogs and newsgroup posts is that ISA is also a factor in the mix. My recent experiences have not had ISA involved, which is why I'm looking at RSS as the core culprit. It's the common thread that leads to the core resolution - disabling RSS seems to take care of a vast majority of issues.

Plus, I have yet to see a real business case for pushing ahead with the installation of SP2, especially in the small business arena. In fact, of the Top Ten Reasons to install SP2 listed at the TechNet site, I see exactly one reason, ironically listed as #1 in the list, that I might want to install SP2, but that's only for sites that I haven't been keeping up to date with Microsoft Updates - SP2 does offer a single rollup for all the updates that have been released since SP1, and if a bunch haven't been installed, then yeah, it could be easier to install SP2 than to singly install all the updates. But given that reason #3 is causing a lot of grief out in the community and that the other "reason" just really seem more like marketing spin than actual technical/business benefits, I cannot in good conscience install this product on my client's servers, nor can I recommend that anyone take the plunge right now and see what's happening. That stance will change once we get a better grip on the breadth of the problems that are being caused by SP2 and quick access to the resolutions for them, but I'm nowehere near that point yet.

One request from you, the gentle reader. If you have encountered a problem followin the install of SP2 that was resolved by disabling Receive Side Scaling, please take a moment and either drop me a note with a brief description of what the problem was, or just leave a comment here on the blog. I'd really like to get an idea of what's out there that's really getting hit, because I don't think all of the possible scenarios have bubbled up to the top just yet.

On SBS SP1 Fulfillment (again)

eriq — Tue, 27 Mar 2007 02:01:00 GMT

Just last week I posted (among others) that the official SBS blog had a post about the problems with the availability of the SBS SP1 media for those needing ISA 2004. Well, the ordering page at Microsoft has been udpated with the following informationn:

"For existing Windows Small Business Server 2003 Standard Edition customers, Service Pack 1 is available as a free download. For Premium Edition customers, the Standard Edition Service Pack 1 is also available as a free download; however, you will also need the Service Pack 1 Premium CD3 which is temporarily unavailable. Please check back after April 30, 2007, for an update on when you can order the CD from this page. We appreciate your business and apologize for any inconvenience this may cause you."

Implication: you will be able to order a CD set with the SP1 media that includes ISA 2004 (for those that have SBS 2003 Premium edition). I guess we'll know in about a month...

On SBS SP1 Fulfillment

eriq — Mon, 19 Mar 2007 18:25:00 GMT

There has been an issue for a while with getting the SBS SP1 installation media from Microsoft for those who have SBS 2003 Premium and wanted to get ISA 2004 as part of the SP1 package. The issue is being worked on, but there is no ETA for a solution at this point. People who are not yet running SBS 2003 SP1 should definitely download and install the non-ISA updates, but those who are wanting to get the ISA 2004 update for their Premium install will have to wait a bit longer.

The Official SBS Blog has a post about this issue and will be the official communications channel when the solution is ready.

On SP2

eriq — Sat, 17 Mar 2007 23:10:00 GMT

OK, after the initial flurry of activity related to the release of Windows Server 2003 SP2, which I've tried to keep updated in the original post, it seems some things have settled down, and some others have come up. Here's what we "know" right now:

1. The bit about having to uninstall IE7 is NOT for all cases. There are some cases involving a reinstall of the core OS that would put IE6 back on top of IE7 that could cause problems, but the initial documentation noted that IE7 had to be uninstalled before SP2 could be installed. That document was wrong, and should have been corrected by now.

2. There are a couple of cases noted where IIS has not started the web sites after a restart of the box immediately following the install. This has not been the case on many boxes, and I haven't seen it on the boxes I've loaded the update on, but it has been reported more than once. Hopefully the common underlying cause will be identified quickly so we can avoid that in the future.

3. There are also reports that machines running the ISA Firewall client are unable to find the ISA server following a reboot of the box that just had SP2 installed. Again, not on every server, and I haven't seen that on the one ISA box I've installed SP2 on, but it has been reported.

4. Some reports about DHCP problems have also been noted, but it's not yet clear if those are related to SP2 or another factor.

All in all, the vast majority of folks who have installed this on SBS seem to have no issues at all, so if you want to move forward, you should probably be OK, but you might want to take the stance of holding off for a bit and see what else happens to the early adopters.

There are also some new GPO settings related to SMB signing (joy) so I'll be researching and documenting that aspect of SP2 and will post updates to existing and new documents that deal with SMB signing and GP in general.