canthe's WebLog

So I just finished my presentation on SBS 2003 SP1 and R2 at SMB Nation, and got a lot of great feedback. Fortunately we had a lot of SBS team members there as well to help me out and take feedback from the partners there.

I try to time my presentations so it's 2/3 me, 1/3 questions and comments. That tends to leave things open for both good and bad comments, but I'd prefer to do that than not have time for our customers to tell me what's we're doing right and wrong. I had a great time - one of my favorite things to do as a Microsoft employee is go out and talk with people about SBS. A couple of big things I heard:

• SP1 installation not always super smooth - Most people seemed to have small problems crop up, some were important, some less so, but consistently there seems to be feedback that some small details come up after applying SBS SP1. I got some details from some people and I'll see what I can find out.
• Licensing, licensing, licensing. <sigh> There should be an entire blog dedicated to Microsoft licensing. I'm not qualified to be an expert on this, and in fact I got corrected by some people on some things I thought I knew. But I know it's often confusing/painful.
• Messaging - Because we have to show value to both the business owner and our partners, we have messaging that applies to both markets. Sometimes a message that makes sense to one may confuse the other. We'll need to make sure we're careful about this, and fortunately our marketing team was in the room to hear that as well.
• R2 - Since most of the talk was about R2, a lot of questions about what's in it, what can you do with it, how will it work, etc. I'll spend some time posting more information about R2 over the next few weeks so I can share the same information here that I did at the conference.

Somehow I managed to get home, crawl into bed, get 6 hours of sleep, and then get up to immediately drive back to the business site to be there by 9:30 AM. Fortunately my morning schedule was pretty open, so I felt that I could hang around for a couple of hours to make sure everything was going smoothly.

The main goal of the day was to take the data that was backed up to the portable USD drive that the owner had with him and copy it back to the server, maintaining the same folder structure they had before. While I was waiting for him to come in, I walked around and made sure the anti-virus was working correctly, and set up the automatic updates for the virus signatures and the like. Somehow during this I managed to foul up their Internet connection, and had to figure that out for a little while, but after a while we were ready to go.

The owner came in with his USB drive, and I told him to go ahead and start copying the data back to the server. While working on something else, he came out and said he wasn't able to copy the data off of the USB drive.

So I went to his PC and tried to figure out what was going on. The drive was on and working. He had a bunch of files on the drive, but all of his backed up files were in a specific subdirectory. I tried copying the files to the server, and got an error (the exact text I've burned from my memory), but suffice to say it was not the clearest in explaining the problem. So I tried copying from the USB drive to the local machine. Failed. Hmm... now this is not so good.

So maybe it's a permissions issue. I go into the security properties on the USB drive and ah ha! It seems that the permissions have been set for PC\user, which was the settings when the PC was not a member of a domain. Now that the PC is joined to the domain, and he is logging into his domain credentials, obviously the permissions are wrong. So since he's an admin, let's go ahead and take ownership and reset the permissions. So I go to take ownership and set permissions and inheritence, and.... wait. And wait. And wait. Hmm... this is not so quick when setting it on thousands of files. But finally this finishes and I go to copy the file and... still fails.

Hmmm... it's now going on almost 11AM and they still have no data. What the heck is going on? Not a destination permissions issue, as I can't copy anywhere. Dig deeper into the properties of the folder that he's backed up to and what's this? The folder is encrypted? What? AARRRGGGHHHHHHHH! I have no idea how or why this got set, but now I think I'm F*&^#@! What little I do know about EFS is that it is entirely credential based. If the encryption is based on his old PC\user credentials, I have no way to create those back again, as it's based on the original SID. (I may be off here, but what little documentation I could find seemed to back this up.) So now it looks like I have no way to get this data back.

Just to make sure, I try unjoining his PC from the domain, and then logging in back under his old credentials, but I still couldn't copy the files. So now it seems like this data is unrecoverable. Fortunately, I have, as we say in poker, an "out". Since we used new hard drives for the SBS install, I still have the original hard drives (in their static bags, even) sitting on a shelf next to the server. So, while the owner goes out to lunch, I shut down the server, remove the new drives, put the old drives back in, reset the cables back to their original configuration, boot up the server again (to Linux, ugh!), and once the server is back up, I go back to one of the PCs and copy all the server data files to a local folder and make sure I can copy them back somewhere else. Once I have all the folders copied again, I shut down the server, swap the drives and cables again, boot back into SBS, and copy the folders back to the server. Total reconstruction time: 90 minutes. Which given everything else, I didn't think was too bad.

And here's where I get to Epiphany 6.

Epiphany 6: Don't ever trust the end user/customer. If they said they did something, do it again yourself. Better yet, just do it yourself the first time.

If I had actually looked at his backup drive instead of just trusting that it was just a simply copy/move, I probably could have saved myself a lot of hassle.

So now it's close to 1PM, we finally have the data back up on the server, the PCs are joined to the domain, anti-virus is installed and updating. We don't have the server published to the Internet because they have a dynamic IP address, so I purchase No-Ip.com, get that installed on the server so we can keep their DNS records up to date. At the same time, I also need to configure their Cisco 678 DSL Modem to enable port forwarding. Unfortunately, Cisco doesn't really have a web interface, so I'll need to install the Cisco configuration app and learn how to configure port forwarding, but that I'll save for another day.

Long story short, I finally get out of there around 3PM, with the data in place, the server running, and the clients working. And yet there was still so much more to do....

So before I continue my saga on my experience as a partner, I thought I'd post a quick comment about the ongoing SMB Nation conference currently happening on the Microsoft campus at the Microsoft Conference Center. So far it's been great as a Microsoft team member to get out and talk with customers and partners who are using SBS and building their businesses around it. It's incredibly empowering and fun to talk with people about how they use SBS and how we can help make it better. It's also been slightly strange to find the number of people who know me or have heard of me through this blog or other talks/postings I've done.

I'll be presenting a session on SP1 and R2 Saturday morning, but tonight I have to stop by my accountant again and hopefully get his port forwarding working, which will help me not have to visit for every single thing. :-)

When last we left our intrepid SBS Release Manager, he had been humbled at the all mighty task of trying to upgrade a pre-existing server box to be able to run SBS. After much consternation, he had gone off and gotten a BIOS upgrade for the machine, and re-scheduled a time to go back and perform the upgrade. We scheduled it for after work on a Tuesday, I knew this was risky, but my schedule on Wednesday was pretty light so I knew I could come in Wednesday morning to fix any glitches that came up.

I walked in confident; I walked in sure. This was going to fix it, we would be back on track and ready to go. I backed up the old BIOS (safety first), flashed the new BIOS (all went well), rebooted, inserted the new drives, powered the machine on, and.... nothing.

No change. Still not recognizing the drives. At this point I was super frustrated, and feeling bad that this CPA shop still had made no progress despite having purchased new drives and a new BIOS. What the hell was going on? I tried flipping around the cables and jumpers again, but I knew that couldn't be the problem. In desperation, they started pulling out all the hardware manuals for the machine, including the motherboard instruction book. Now who reads an instruction manual, especially for a motherboard?

Well thank God I did, because I happened to notice that this board had two different IDE channels. One regular IDE channel (primary and secondary) and then something called a PROMISE IDE channel (also Primary and Secondary). Who the heck had ever heard of this? Turns out this is some sort of IDE channel that's fairly common on Linux servers, but required a specific driver and blah blah blah, I'm too frustrated with the whole thing to go into it anymore. I reset the cables so the drives were set into the main IDE channels and Presto; everything works fine.

So we're finally able to start the SBS install. I knew this was going to take a while, so after waiting for the OS to install, and then CD1, once we had CD2 inserted, which I knew would take at least 40-45 minutes on this machine (it wasn't the swiftest server), we went out for dinner at a nice Chinese restaurant, where we happened to see our local Congressman, Rep. Jim McDermott, at the table across the room. Quite the coincidence. :-)

We came back, I put in CD3, and waited for the server install to finish. In the meantime, I was downloading AVG and reviewing the install steps. All told, about 3 hours and change after we had started, the server was installed and up and running. Next, of course, I had to immediately install SBS SP1. Fortunately I had copied that onto my laptop, so I copied it over to the server and installed the components. In the meantime, I also installed AVG and started to configure the client PCs to use the AVG client and configured the monitoring and reporting functionality as well.

We were making good progress, although it was getting late in the night. Once all of SP1 was installed, I ran through the wizards, adding users and computer accounts. I also made sure to hit Windows Update for the latest security patches (fortunately SP1 is still fairly up to date).

And it was here that I made my next mistake, leading me to Epiphany #4:

Epiphany #4: Never ever rename the client PCs if you can avoid it.

Example of epiphany #4: After running through the Add User and Computer Wizard, I accepted the defaults, not thinking about the name changes for the PCs (I was getting tired). We ran the connectcomputer wizard on each of the PCs, which worked great with practically no problems. Until Jeff, one of the CPAs who was staying late with me to help me out, pointed out that all of their mapped drives, which pointed to each other's PCs, no longer worked because the PC names were all different.

<sigh>

I couldn't really make them change their whole workflow in the middle of the night, so we went to each PC (only about 6 of them) and reset all of their drive mappings. Of course, each PC had something like 6-8 mapped drives, so that was fun and exciting.

So next I just wanted to get their Outlook profiles working. Of course, they had pre-existing mail in old accounts, so I had to go back and import their PST files into their Exchange mailboxes, which didn't take too long (except for one PC, which was strangely slow).

So here I was hopping from PC to PC, resetting mapped drives and importing mail at something like 11PM or midnight. And I came to epiphany #5:

Epiphany #5: Think! Think through the entire process and plan each step carefully before you start.

I thought I had done this, but obviously that was a fallacy. Because it occurred to me that I had been too smart for my own good. If I had really thought through all of the steps I actually needed to go through, I wouldn't have been so optimistic about either a.) the time required or b.) the potential snafus that I would encounter along the way.

Finally we reached the point where the clients were up and running, anti-virus was installed, backup was configured, users could login, the only thing left to do was copy the original server data back onto the SBS server from the backup drive, recreate their shares, and all would be well for the morning. Unfortunately, the owner had carefully backed up all the data that afternoon and then, like every day, took the removable drive home with him. This did lead to another epiphany, but it was superceded the next morning, so I'll save that one for later.

At this point, I had done all the damage I could do. Everything was up and running, even the Win98 machines were configured to the domain as best as they could be, and everything was working (sans data). The owner was going to come in the next morning and copy the data back onto the server himself, so at 1AM I finally headed home, planning on coming back at 9:30 to just make sure the data copy went OK and answer any questions/fix any problems that came up. I figured I'd be out of there by 11:30, 12 at the latest. Oh, the lies we tell ourselves sometimes. But that's for another post...

For the past several years I've been having a personal experience of the movie "Groundhog Day", only it happens every year when I go to visit my accountant. It would go something like this:

Me: So are you still using that Linux file server, which requries you to create your own batch files that copy and zip all your data every night to backup, with every workstation having a different A/V client and no integrated e-mail?

Him: Yup.

Me: We ever going to get you upgraded to Small Business Server?

Him: Yup - we should do that someday. So hey, about those W-4s...

Lather, Rinse, Repeat.

Don't get me wrong, my accountant is a super-nice guy, who got his network setup by a family member who was rather anti-MSFT, and so came up with all these weird configurations that just boggled my mind when he described them. And since no one was really looking after things, it was obvious that they were more at risk from things like unpatched vulnerabilities and viruses than were supposedly "fixed" by not using a Windows Server.

Finally this year I convinced him to let me help him upgrade his server and network. I decided I would use this as a great opportunity to learn how our partners sell, install, and maintain their customer networks, so I'm doing it as if I was my own partner. Man, am I learning a lot. Expect a running commentary here as I describe my experiences.

Step 1: Understand customer needs

We sat down and talked about everything they used on their network, along with his best understanding of their current hardware, software, and network setup. Then we talked about what could be better/easier. Here I came to my first epiphany (which I actually "knew" but grokking it for yourself is very illuminating).

Epiphany 1: The small business does not know how their own technology is limiting them. They won't be able to tell you what they want to do better or different, because they don't even know how good/bad what they have is. You have to understand their business workflow and suggest possible improvements for them, at which point they light up and go "You can do that?".

Example of epiphany 1: My accountant was explaining how they kept a record of customer data in an Excel spreadsheet that everyone edited. But they had to be careful not to reset the ordering of the spreadsheet, since there were thousands of columns of data, so they always made a backup copy before making any edits. But what if the system kept previous versions for you, every several hours (ala ShadowCopy)? He really went "You can do that? Cool."

But if I had asked him, he never would have said "I wish I didn't have to keep a spare copy of my files in case someone goofs and overwrites all the data." He would never say that because he couldn't risk losing that data, and so it wouldn't occur to him to find a different way to protect it, as he had a system that worked.

So after understanding all of their configuration, I went back and wrote up a record of everything we talked about and I saw on my own (mainly just so I could remember) and came up with a list of recommendations. Most of it was pretty standard Susan Bradley 2x4 recommendations:

• Upgrade all the PCs to XP with SP2
• Standardize on a single A/V solution that auto-updates (I recommend AVG, but that's a personal preference)
• Upgrade server from Linux to SBS

Note that the server was actually my 3rd recommendation, I felt the critical items was getting the workstations secured before we went about adding functionality with a new server.

We went over the recommendations, and his only concern was some ancient application they were using that might not run on XP. We did a trial run with it, and we hit a snag that was probably not XP related, but rather the app stops working if you try to copy it from one PC to another, forcing you to call them and pay them support for a new "activation" code. (And you thought Microsoft activation was bad....?) But since most of the PCs were already XP, we decided to leave the one 98 machine while he investigates possible replacement applications that were XP-compliant.

So we proceeded to Step 2: Upgrade server

We decided to upgrade the server so we could get the benefit of a networked AVG solution (rather than just at the workstation level). He decided to upgrade his hard drives at the same time - his current config was 2 60 GB hard drives striped together. (I won't even tell you what he paid for those 2 drives several years ago, just that there were 4 digits before the decimal, whereas 120 GB hard drives were $80 at Fry's.)

So we got 2 new 120 GB Maxtor HDs, came in on a Sunday afternoon (made sure that all of their data was backed up to a Zip drive overnight) and started the upgrade. Here I came to Epiphany #2:

Epiphany 2: Home-made servers are crap. Not that they don't work well, not that they don't save you money, but if you ever walk into a room with a custom-made server, run away screaming. The money saved at manufacturing time will only come back to bite you when you don't know/remember some config item or requires some upgrade that will take you hours to figure out.

First off, this thing was a beast - a full tower. Second, it had at least 4 fans running it. Yup 4: 1 by the power supply, 1 attached to the hard drives, 1 on the CPU, and one just sitting in the middle blowing air. You'd think it was computing cryptograhic codes for the NSA, rather than literally just being a dumb file server. It made more noise than my college friend's 15 year old Pontiac Sunbird missing its muffler. Third, I had to unscrew at least 10 screws to remove the HDs. Ugh.

Anyway, removed the old hard drives, (being careful to store them in the original electrostatic bags - good move later), added in the new drives, attached the IDE and power cables, rebooted, and watched the BIOS.

System boots, the striping driver sees the drives, so I create a new stripe array, reboot to the SBS CD1, and I'm ready to install when... No drives found? Very weird.

At this point, I spend at least 45 minutes rebooting and trying every BIOS change I can find, resetting cables, changing cables, changing jumpers, even <gasp!> reading the HD manual. Everything is identical to the old config, why the hell isn't this working?

Finally, I submit to the ultimate savior: I search Google. There I quickly realize that this machine is so old, it probably doesn't recognize the new HDs, meaning I need a new BIOS upgrade. So reboot again, get the BIOS manufacturer, another quick Google search takes me to Esupport.com, where they have a very friendly webpage that asks for a few pieces of information, and it implies that an answer is just past the "Submit" button. Enter my info, and I get a page saying "Someone will contact you within 24 hours to help you upgrade your system." This leads us to Epiphany 3:

Epiphany 3: Be prepared. Be really prepared. No really, you think you're prepared, but you're not. Because it'll be a Sunday and if you don't have it there, you're uck-fayed.

I thought I was thinking ahead with extra CDs, network cables, screwdrivers, etc. Hahahahahaha. Silly rabbit, upgrades are for professionals. I realize if I have actually read the threads in discussion groups like microsoft.public.windows.server.sbs or the Yahoo sbs-list group, I would have realized that everyone says to make sure to upgrade your BIOS before changing hardware. Sigh.

So that pretty much ended that endeavor. We pulled out the new drives, put back the old ones, watched it reboot into Linux (man, that hurt), and then made sure the workstations were still able to work. Whereupon we realized that they could not connect to the server, now making me trying to remember my Unix config work from college. Fortunately there was a small admin manual next to the machine, and along with some diagnostic work on my own, managed to figure out I had somehow set the BIOS to not allow Linux to enable the network card, another reboot, and all was well. (Except if anyone can tell me why the shutdown command in Linux doesn't actually shut down the machine - I'd really appreciate an explanation. Apparently it logged me out to single user mode in BASH, but for the life of me I couldn't figure out how to do a safe shutdown without using reboot, and then just powering the machine off once the BIOS screen came up. Very strange.)

So next week we'll be trying the upgrade again, after which I'll be installing AVG and showing them the wonders of ShadowCopy (later we'll get them using Exchange). Along with WSUS, I'm very excited for the future.

I'll have more thoughts on other aspects of the upgrade soon, but now I need to check traffic before heading home.

To help us pinpoint the root issue with reports of Dell servers getting a BSOD when installing Windows Server 2003 SP1, if you do have a machine in this state, please call SBS PSS and report this issue. We will ask for a dump file (which may take some time to copy) and then help you get your server up and running.

Some other info we will ask:

• What date did you order your SBS 2003 OEM system?
• What 3rd party S/W is installed on the server?
• When did the BSOD occur? What was the STOP error code?
• Did you install SBS on top of a Windows Server 2003 OS only image?

Thanks!

When last we left our intrepid release manager, we had a Bill of Materials for all of our SKUs. Now the development team has finished writing and testing the code - what else is there to do, you ask?

Plenty! First, in order to get the software team to the point where they even can sign off, there are new checkpoints we have to make sure we address.

The first is Security - it's no secret that Microsoft has laser-like focus on Security in our products and for our customers right now. Of course, sometimes that laser like focus means running around with a big hammer.

There is now a mandatory start-to-finish security process called the Security Development Lifecycle (SDL). It's a process all teams at Microsoft have to follow for all products we release. It includes making sure we run a variety of security tools on our code and on our installs, doing threat models of potential exploits, and reviewing all of our bugs to make sure we haven't missed anything that has a potential security impact. During this entire process we have a security "buddy" whose basic job is to make my life a living hell - constantly asking questions and pushing back - it's a good role to have if you like being a constant pain... :-)

Nothing can ship without sign off from the Security team that they are satisfied with the process and decisions we've followed.

In addition to the security sign-off, there are several other required compliance issues we need to check off on. For example, insuring that we are in compliance with the US DOJ consent decree, that we have the proper regulatory steps taken care of, etc. etc.

OK, so now we've made sure that we're not doing anything bad or wrong. How on earth do you actually get this thing to customers?

Well, once we have a final build that the development team has signed off on, we burn a set of "master media". These CDs are marked with the SKU, part #, language, build, and other info to make sure they don't get mixed up. The media are handed to our Build Verification Test team, who runs through an install from the master CDs and runs a set of tests on them to make sure nothing obvious is wrong with the CD or build or any last minute problems haven't cropped up.

Once the BVT team has completed their install, the CDs are then handed off to our media verification team. This team runs a separate install while also noting the CRC value of each CD and other verification tests.

While this testing is going on, the build team has already had all of the binaries signed by the Microsoft corporate certificate (so they are authentic Microsoft bits) and submits the build to a virus-scan test and also a check to make sure we are in compliance with the Sun MSJVM settlement.

Once all that is done, the master CDs are submitted back to the release management team with the sign-offs. The CDs are now ready to be released.

If a DVD is included, there is an additional process. A DVD ISO is released to a share, and a DLT tape creation request is submitted to our MS Studios team. They create a DLT tape which we pick up within 24 hours.

In the old days, this meant taking each CD to our Release Services Lab and submitting each one by hand physically. For a product like SBS, where for each language we might be submitting 20+ CDs, that would be something like over an hour to stand in the hallway and turn them in one at a time.

Now we can utilize electronic ISO handoff for CDs (DVDs still require a physical DLT tape to be submitted). The Build team, when creating the master media, created identical ISOs and put them in a separate share. My team checks that the ISO CRC matches the master media CRC, and then can copy the ISO to our Release Services Lab. Once those are submitted, a sign-off request mail goes to our Release Manager (me) and our Test Manager to sign-off that these CDs are OK to go to customers world-wide.

Once the sign-off is done, the Release Services lab performs a set of their own processing checks, and occasionally an ISO gets dumped out for some error (usually a file copy error). Once they sign off, the part goes into a "Released" state and can be picked up by anyone with access to the Microsoft Release database.

Since usually the software is the last thing to be released, once all of the CDs for a BOM are released, the BOM for that SKU goes "live", meaning production can start. Our operations team notifies our manufacturing team, and once the SKU is released they can begin the manufacturing process that starts churning out boxes.

For web downloads, the process is similar but slightly different. The download bits are posted to our Downloads Management Tool, where again we have to sign-off on compliance (it has a EULA, we're not shipping MSJVM, we ran a virus-scan, etc.). Once submitted, again a sign-off is required, and the bits are then propogated worldwide and released.

So, that's first why the download bits are always available prior to the physical media. Once the CDs are released, we have to manufacture the parts and ship them to our distribution centers around the world. We have operations centers in North America, Europe, and Asia which handle the SKUs for the languages in that area (English is utilized worldwide). The whole process usually takes 6-8 weeks to make it out to you, the customer.

This is also why the release management team usually engages in some heavy celebration after the big party. :-)

So now if anyone asks what the heck RTM means or why it takes so long to get a piece of software even after Microsoft "releases" it, you can help them understand.

Hope people found this useful/interesting. I've certainly learned a lot going through this in the last few years.

On Thursday I sent mail to the entire SBS development team announcing that we have now officially released SBS SP1 in all of our 18 languages!

The Redmond SBS team is now focused on the next releases of SBS - and taking a well deserved holiday break. :-)

Since I've become a Release Manager at Microsoft, I've learned a lot about what it actually takes to "ship" software. From the development team's point of view, the big celebration is when our software is "released" (often abbrievated as RTM or RTW). RTM = Release to Manufacturing, or the process of making CDs, putting them in a box, and then getting them out to customers. RTW = Release to Web, which is making something available for download.

SBS SP1 was a little unique in that we did both an RTM and RTW. But I thought it might be fun to explain what happens after the team signs off on the software (besides partying, getting drunk, making a mess, and forcing the carpet to get replaced in the hallway...) Part of this is because a lot of people on the development team couldn't tell you what happens after RTM, but it's pretty interesting and also helps explain why CDs aren't just magically available the day after we ship.

For physical media (like CDs or DVDs) the shipping process has to start about 6-9 months ahead of time. I sit down with our operations team, who coordinates with our manufacturing team and guide techy folks like me through all the steps of manufacturing something. I'll tell you right now - I have a lot more respect for anyone involved in manufacturing than I ever imagined. It's the most incredibly detailed, minute, and honestly, anal process I've had to walk through, but considering the number of parts and steps they have to walk through in order to manufacture a box, it has to be.

So, we sit down with our operations folks and walk through what we want to do. For SBS SP1, this was fairly simple in that we weren't doing something entirely new, just modifying the existing SBS 2003 kits, so we had a pretty good baseline to start with. None of the artwork on the box changed, really all we were doing was changing the CDs and the book inside, and then putting a sticker on the front that says "Includes Service Pack 1". You'd think that would be pretty simple. :-)

Well first, you have to determine which CDs are changing. Are any staying the same? You wouldn't want to re-create a CD if you didn't have to. Each new CD then gets a part number, which is a unique identifier of that software CD that can be re-used in different kits or boxes (something like X09-12345). If you look closely at anything shipped from Microsoft, in fine print you'll probably find the part number.

For a single CD offering, like MS Money, that's not too big a deal - you have maybe 4-5 CDs for all of your different offerings. But if you think through something like SBS, the numbers start to get really big. Think of it this way:

SBS Standard Edition = 5 CDs
SBS Premium Edition = Standard + 2 = 7 CDs
Then multiple that by the number of different offerings we have: Evaluation Kit, OEM, Retail (7*3 = 21)
Now add in Windows for Small Business Server (1), the Transition Pack (Std and Pre - 2), the OEM PreInstallation Kit CD (1) and you're up to 25 CDs just to re-create what we shipped in SBS 2003. Notice we haven't created any CDs for the Service Pack itself.

So, add in 3 CDs for SP1, and you're up to 28 CDs. Oops, forgot the DVD, didn't you? 30 (2 parts for the DVD, one for the DVD itself and the other for the DLT that is used to make the DVD).

So we have 30 different piece of software that we need to make sure our accounted for, and this is just for English! Now multiple this number by 18 languages, and you have (30*18 = 540) different software pieces to release!

Fortunately, it gets a little better from here. SBS doesn't ship the Outlook or Frontpage CDs, we simply re-use the ones from Office, so subtract 2. Also, DVD is only provided in 6 languages, so for the other 12 we don't have to worry about that either.

Then, you start to optimize - for example, CDs 3 and 4 are identical between our retail and evaluation edition. So rather then re-create the wheel, you just use the same CD. All told, you get it down to between 17-20 parts, depending on language.

OK, so now we have CDs. But all that covers is the actual software (or ISO) image of the CD. What about that fancy artwork on the CD that tells you what it is (with the hologram and etching and everything?).

Ah ha! Yet another part required! This time, you have to have a different one for each CD. If you look closely at the hologram on your SBS CDs, you'll find a part number on the right hand side, underneath the Disc #. That's the artwork part #. The actual software part # is etched on the inner ring of the CD. This is because some channels (like volume licensing) get different CD artwork than what comes in a retail box, for example. And eval kits and DVDs are also different.

So now we have software parts, artwork parts, doc kit parts (for the new Getting Started Guide), sticker parts, etc. What's next?

Much to our chagrin, we realized that we needed to add a CD to our slipstreamed kits because of the size of new components such as Exchange Server SP1 and XP SP2 (which was way bigger than XP SP1). You'd think that adding a CD would be as simple as just adding a new CD part, right?

Except what happens when the CD container can't hold anymore CDs? We spent about 6 weeks trying to figure out how to shuffle CDs around in the box so we could maintain the best customer experience (where you open up the box and the CDs go in order 1.2.3.4.5) but still protect them during shipping from breaking or cracking. This required us to create some custom manufacturing instructions for how CDs should be placed (which is why the Frontpage CD is now in the same clip as the Getting Started Poster in Premium retail boxes).

OK, so now you have all your parts, languages, and manufacturing instructions? You've got tons of spreadsheets and artwork printouts. How do you make sure you're actually putting this stuff all together right (so you're not putting the artwork for CD4 on CD3 software, or the product key sticker on the right CD sleeve?)

That's right, you get everyone together in a room, with a stack of printouts about 3 inches high, and you have a "BOM review". BOM = Bill of Materials, or the set of instructions for how to assemble something. If you thought dealing with just the CD parts was painful, a BOM review will make you want to consider hari kari.

This is an incredibly tedious exercise of going through a BOM (which may include 40+ parts) and making sure that the parts that our team was responsible for was correct, and in the right order. Caffeeine is a definite requirement for making it out these alive, as is a morbid sense of humor.

OK, so you've got your BOM, you've got your parts, you've got everything ready to go. Now all you need is your software - but we're just getting started.

When we continue, what happens after the ship party.....

While I'm here I just thought I would mention that we've now released SBS SP1 in 16 of the 18 languages. Today Czech, Polish, and Hungarian SP1 were released to the web (although I just got back an error through our web publishing tool on the Czech one, so don't quote me on that).

Next week the last two languages for SP1, Russian and Turkish, will be posted to the web, and SP1 will be officially done! (whew)

I realize most of the world has passed this issue by, but it's been getting a lot of discussion around Microsoft the last several days, so I thought I'd put in my 2 cents along with everyone else.

In case anyone has been living under a rock the past few weeks, Microsoft has gotten a lot of press around its decision to switch from active support to a "neutral" stance of a pending bill in the Washington State legislature that would expand the state's anti-discrimination law to include people of homosexual or bisexual preference. The law forbids discrimination in housing, legal services, etc. Microsoft has in previous years actively supported the bill by sending a letter of support, but this year took no action.

A seemingly minor issue, until local weekly rag The Stanger reported that Microsoft changed its position after a meeting with a conservative Christian pastor on the Eastside (aka the suburbs, also where MSFT is located in Redmond). Supposedly the pastor threatened Microsoft with a national boycott of Microsoft products unless Microsoft took a variety of actions, including a.) withdrawing its support b.) firing employees who testified in Olympia in support of the bill (as individuals) and c.) God only knows what else.

The issue got national attention, with an article in the New York Times and, more importantly, a satirical mention on The Daily Show with Jon Stewart (which had me laughing on the floor - click on "Gaywatch").

MSFT CEO Steve Ballmer (SteveB to us) sent a company wide e-mail last week explaining Microsoft's versions of events (very different) and saying that while he personally supports the bill, as a company MSFT made a decision to focus our lobbying efforts on other issues, but if you look at our company policies against discrimination on this very issue, we've led the industry for years.

The Stranger has followed up its stellar reporting this week with the pastor saying that Steve's version is bull, and taking credit for scaring the big, bad Microsoft into changing its position.

OK, so why am I repeating all this? Because however you feel about the bill/issue, (and I personally support it 100%), the whole idea that some local podunk pastor could scare Microsoft with a boycott is the most ridiculous, inane argument ever. The fact that people take it seriously is even worse.

Hello, people - we're a friggin monopoly. Put aside all of the negative aspects of that business model, one positive is that you don't really get scared at the idea of a Christian "boycott". How can people take this seriously? The pastor said he forced a change? Or course he did! This is his 14:59 of fame, you think he's going to say "Oh right, I actually have no influence. I don't want any free publicity and getting my name in national papers, getting more donations."

And exactly what impact would a US "boycott" have? A very large portion of MSFT sales comes from OEMs (such as Dell, HP) with software pre-loaded. And the US is only one part of MSFT's worldwide sales. (Detailed breakdowns in MSFT's quarterly filing.) You think people are going to suddenly stop buying PCs from Dell? Switch to Macs? It's the most ridiculous waste of ink I've ever heard.

We can have a valid argument about whether Microsoft should have removed thier support (and I've been in several over the past several weeks), but I can't stand this guy getting way, way way more credit than he deserves. Given this, you'd have to believe either:

a.) Microsoft is a heartless monopoly bent on destroying our competition through whatever means, and utilizing our market position to ignore the needs or concerns of competitors

OR

b.) Microsoft is a cowering scared animal, running away with our tail between our legs whenever some local nobody stands up and "demands" we change our value structure under thread of some hypothetical "boycott".

I'm not saying either is right, but the concept of MSFT running scared is just ridiculous.

When you've been up and working late for several weeks, late at night is a dangerous time to be posting to the web. But it's late, I'm playing poker (in ahem... Canada) and so I figured the thome of silence should end.

Susan Bradley, in her Mountain Dew caffeine enhanced awareness state she's always in, has presicently noticed that we've started posting SBS SP1 documentation to the web. This is one of those great decisions that come to me as release manager: Charlie, should we hold off on posting content and gum up an entire publishing process or just let it go live and let people like Susan go crazy? I chose option B, if only for the entertainment value. :-)

So what does this mean about the upcoming release of SBS SP1? Not much. Our documentation is completed, but then it has to be finished weeks ahead of time in order for us to localize (translate) it into all of our languages. How then do we handle changes in the documentation after we lock it down if something changes later on, you ask? Good question. Ever notice those links in the docs that say "Go to this web site for the latest version"? We can update them constantly on the web (and in the future pretty much all of our documentation will be web based. You see this with Office Online today in Office 2003).

I will say we're very close, although I've already had to move our party a couple of times (another one of my job requirements :-). I could bore you with all of the hard work and pressure we go through to ship software to our customers that's high quality, but it's probably not that interesting to you. But I do want to say that our team does an awesome job across the board - people working until 2AM or later to get things done so we can get this out to our customers soon. It's been a rough couple of weeks, but I'm very proud of where we're at.

On a separate note, expect a post from me soon on this whole Microsoft/anti-discrimination bill. I'm so annoyed I can't describe it, but I didn't want to mix that note in with an SBS related one.

The feature is enabled by default in SBS SP1 (coming really soon)

Dan asked (a long time ago, sorry Dan) that he was getting notifications of accounts being locked out due to invalid password attempts. Dan's assuming this is because someone is trying to hack into an account and wanted to know how to stop SBS usernames from being "broadcast".

Unfortunately, the question makes a fundamental assumption, that SBS somehow is broadcasting usernames. This is not the case, but it probably doesn't take someone long to figure out a username for your users.

For example, if your user's e-mail addresses and logon names are identical, then once they get an e-mail address for a user they can simply use that as their username for their attempt and start a dictionary attack.

How does one get a valid e-mail address? Simple: start at a@foo.com, end at zzzzzzzz@foo.com, and try every combination in between. Run a script to send to your SBS server a piece of spam that will just get deleted by your ordinary user. Wait for NDRs to return for the non-valid addresses, subtract the rest, and you have a user list.

2 ways to obscure this information:

1. Make your user's logon name and e-mail address different (can be done in the Add User Wizard at user creation time or afterwards by modifying the e-mail address or logon name in the user properties)
2. Disable external deliveries of NDRs (840158 You cannot restrict certain automatic responses to the Internet based on http://support.microsoft.com/?id=840158) Note that I don't typically recommend this as it is technically a violation of the SMTP RFC and won't help your customers who accidentally mis-type an e-mail address and wonder why they never got a response

Your most effective way of making sure that no one cracks your accounts is to enforce strong password policy. In Dan's case, though, it doesn't help his users who are getting locked out of their account legitamately. In that case, your best effort is to take some time and try to determine the IP address of the offending attempts and then block these at your router or higher up.

I often get the complaint that I don't post to my blog often enough. (Somehow Eugene even mentioned he got comments about this too - I'm not sure when my blog posting frequency became something that popped on his radar, but oK.....)

Well, today is question answering day! I'll go back through questions asked so long ago no one remembers asking them and try to come up with a response...

(FYI - this is what happens when you ship your Beta and you spend the rest of the afternoon cleaning out your e-mail inbox of all the e-mails you'd get to "later")

D. Lewis asked about how easy it is to change the company name or domain name on your SBS server after install.

The Company Name, which is specified during the server setup, is easy to change. It's stored by the OS in a regkey that is subsequently read by tools such as RWW when it loads the homepage (for the customization). You can change this by modifying the regkey at HKEY_LOCAL_MACHINE_\SOFTWARE\Microsoft\Windows NT\CurrentVersion\RegisteredOrganization

As for the domain name, that's tougher. After installing SBS, it is not possible to change the Active Directory or NETBIOS domain name used on the server. On the bright side, this should have no impact to you as an SBS user. We do a lot of work in SBS to not require the AD or Netbios domain name to be used anywhere. (It's not required in OWA, or to login, or anywhere else)

Given that, you should be able to change the org name fairly easily and keep on using your SBS server! Hope this helped.

 William asked if there are any limitations to using SBS as a web hosting server.

There are no specific licensing restrictions per se. The only issue is if people visiting your web site would need to authenticate to view specific pages. Each authenticated user would be considered a client according to the terms of the SBS license, and so would require an SBS CAL. Therefore, you would have a maximum limitation of 75 authenticated users to your website (assuming no one else needed to read e-mail or anything).

That aside, given the workload demands of an SBS server (DC, e-mail, DNS, internal web site, file sharing, backup, etc.) I'd recommend against using SBS as a web server strictly from a performance standpoint. If you want to put up a small "business card" website that has some static pages and basic company info, you should be fine. Anything more robust, or anything with high traffic, and I'd recommend off-loading that work to another server or hosting it at a web service company.

Well, that does it for today's blog mailbag! Hope to post again sometime soon... :-)