Office Live Testing

• semi-flush front turn signals (the lights protrude about 1" from the side of the fairings, but are the flush style of lights, not the stockers)
• integrated rear turn signals
• silver to black Micron slip-on exhaust (http://www.csquaredcomputing.com/blogimages/slipon.jpg)
• removed rear fender
• flush license plate lights (bright white led)
• hard wired garage door opener (currently wired for Genie doors, easily changed for other doors)

Are you frustrated by not having a desktop client (like Outlook) to use with your free hotmail account?

Are you tired of dealing with Outlook Express 6, which was released three eons ago?

Do you wish you had a current, flashy little mail client, which integrated with your hotmail account, and your messenger account?

I've got the solution!

Check out this post, where the Windows Live Mail team announces the beta release of Windows Live Mail Desktop (it's basically the next version of Outlook Express).

I have been reading a blog about Excel 2007 for about a year now. There was a bunch of really good stuff in the blog, but very little of it was useful on a daily basis; it was mostly stuff that I am interested in because I totally dig the new UI.

Yesterday, the author started a new series of posts about how to use Excel 2007 on a daily basis. Those of you that have the beta should check it out. Those that don't, go download the beta, and then check it out. Or, I guess you could check out the blog first, and see why you should go download the beta.

It's the Excel 2007 blog.

So, it's official. We're now Big Time™! Office Live has hit the home page of Channel 9. If you're reading this real time, check out http://channel9.msdn.com/.

If you aren't reading this entry on July 17^th, 2006, then here is the direct link to the Channel9 interview: http://channel9.msdn.com/showpost.aspx?postid=216654

In our environment, we have a machine that is dedicated as a load test controller.  I share that machine with two other SDETs, on a sister team.  Since there are three of us using the machine, we try to only use it for running tests, not creating or debugging them.

To support this, we have multiple Run Settings in each load test, and multiple .testrunconfig files.  We have one of each for a local run, and one for a run on the controller, using the agents.

The other day, I was starting a test run, and I set the Run Settings to use the controller.  I forgot, however to set the active test run configuration.

If you are set up in a similar environment, be sure to select the correct test run config settings, by going to Test->Select Active Test Run Configuration, in addition to choosing the correct Run Settings in the load test you are running.

My boss, Matt Rolak, used to work on Visual Studio (mostly on 2005). He knows a lot about the program, so he’s my go-to guy when I need to know how to do something, or have a gripe about the product.

Here’s what I learned today:

    You can, in fact, add an existing folder to a project. If that folder is in your project tree (i.e. under your project root). To add it, just click on the “Show All Files” button. You will see a shadow-y folder icon show up. Right click on the folder, and select “Include in Project”. Done. It will also add any files in the folder to your project.

I realize this is a little thing, but there have been a lot of times when I needed to do this. My solution was to rename my folder, then create a new folder, with the original folder’s name, and copy the contents of the original folder into the folder that VS created.

Hope that helps someone.

Beyond the published benefits, there are some really cool perks that come with working at Microsoft. You get some good insider information (even if you can’t share it with the public). Plus, you get the opportunity to work on projects that you may have used as an application developer out in the world.

For instance, I have always been fascinated with Windows Installer packages. I don’t know why, but MSI construction is really interesting to me. I also think that the setup options that ship with Visual Studio leave a lot to be desired. I’m not the only one who thinks so. Rob Mensching also thought the setup support in VS was lacking. He went and did something about it. He created the Wix project. Wix stands for Windows Installer XML. Basically, he wrapped the entire functionality of MSI into a single xml file. There is a ton of information about Wix on the internet, here’s a link to get you started: http://wix.sourceforge.net/.

I’ve always loved the idea of Wix, and always wanted to support the project. Here’s where the perk comes in: the other day, I emailed Rob, and asked what I could do to contribute. I was able to email him because he is in the same Active Directory domain as I am, so I have a little better access to him than the average joe (even though any of you can contact him through his blog).

He made a couple of suggestions, and now I get about 50-75 emails every day dealing with Wix; I am learning the ins and outs at an amazing rate. I love that I am now in a position to contribute directly to the project (assuming I ever get smart enough about it to know what to contribute).

James Iredale asked a question as a response to my last post. I have held off on answering him, so that I could check some details regarding NDAs and such. Here is his original question:

I was interested in your redundancy log. We're pretty redundant on NT and NI, but back in Feb has a SQL db go suspect; took us 13 hours to recover. We now backup to disk on the SAN and then to tape so our recovery time is two hours. We had our SQL rep for MSFT on site (coincidence) when this happened. If you're not giving away any secrets, it would be interesting to know how you guys handle this.

I held off on answering right away, so I could ask exactly how much I can share, and also to find a reference that would be able to explain everything in greater technical detail than I could alone. The MSN team built an amazing (to me) Sql server cluster, which provides both redundancy and data protection. This approach is not suitable for all teams and all locations, since it requires a substantial investment, both in hardware and in development time.

MSN wrote a whitepaper on the subject, and it can be found at http://www.microsoft.com/technet/prodtechnol/sql/2005/scddrtng.mspx. The whitepaper is really interesting, and definitely a good read. If your application is data-driven, and requires high availability and data protection, this might be a solution you should look into.

The dev who built our solution was on the MSN team that built this solution, so our architecture is extremely similar to the MSN architecture, but at a smaller scale, and only for the really critical part of our system. The rest of our data is protected in more mundane ways (transaction log shipping to redundant Sql servers).

Today, I found Josh Christie’s blog. He is one of the members of the ‘Ocracoke’ team. For those of you outside Microsoft, Ocracoke is the name of the set of load testing features in VSTS 2005.

Josh has a lot of great information about load testing, and has even published a white paper (Web Test Authoring and Debugging Techniques).

Josh also provided a bunch of links to other members of the Ocracoke team. Here are the links:

• Ed Glas
• Sean Lumley
• Bill Barnett

They seem to have some really good content posted. If you are interested in the field of stress and load testing (and why else would you be reading this blog?), I’d suggest checking them out.

When you are building high-availability, high-traffic systems, it’s all about redundancy.

This afternoon, I met with Matt M, in our Ops department. The Ops group is responsible for making sure that our software gets deployed properly, and for maintaining our server farms. Since I am going to be handling our stress and performance testing, Matt and I focused on our performance cluster of machines.

I noticed something that I thought would be of interest to developers and system admins everywhere. Redundancy is built into our system at every level. At the machine level, we have many hard drives in our servers, organized into RAID arrays. The ‘R’ in RAID stands for redundant. If one hard drive fails, no problem. In addition, each machine has redundant power supplies. If a power supply fails, the user doesn’t even notice it. So far, this is all very standard, and somewhat basic.

Let’s zoom out one level. Our system is built of multiple subsystems. One subsystem is our public sites cluster. This cluster consists of two subsystems, the front end (IIS/ASP.Net), and the backend (Sql Server).

Within the Sql Server subsystem, there are two physical servers. Each one of these servers has the redundancy we spoke about in the previous chapter. If one of the Sql servers crashes in such a way that it is gone forever, the user can still perform any and all actions in the application, although some operations may be slower than usual. In order to achieve this, we have a piece of hardware in place that writes all database changes to two servers, simultaneously. This same hardware detects the failure of a single server, and redirects all traffic to the other server. This setup ensures that the loss of one server will not cause the loss of any customer data, and provides a much better

Within the front end subsystem, we have several web servers, which all have the same image of our code base on them. If any one of these servers goes offline, we once again recover without any human interaction, gracefully. The only data that is lost is encapsulated in whichever responses are being created by the server, which haven’t been sent back to the client yet. For those of you who aren’t web developers, a single response does not normally contain very much data. So, in the usual case, a set of users will only have to repeat the single step that they just performed (usually just clicking on the submit button again).

So far, we have redundancy within the servers, and we have redundant servers. This is all fairly standard stuff, and any medium sized web application will probably be architected similarly.

Let’s get on to the more interesting bits. Given our public site cluster, consisting of a front-end subsystem and a paired back-end subsystem, we also have redundancy at the level of the public site cluster. So, we have multiple sets of paired front-end and back-end subsystems. These clusters are load-balanced through a piece of hardware. Now, if we somehow lose all of our front-end servers and/or all of our back-end servers in a given cluster, the user still doesn’t notice anything during use of the application. The catch here is that there will be loss of data, or at least loss of the ability to get at the data, until our Ops guys get the cluster back up. However, the application continues to function, and the affected users will be provided with a (presumably) friendly error message detailing the problem.

Why do we need four levels of redundancy in our application, you ask? Good question. Here are some stats, to hopefully help you understand the answer. Our application has been in beta for 3½ months. In that time, we have had almost 80,000 domains registered through our service. So, on any given day, we have nearly 80,000 public websites being hosted on our servers. That is a lot of websites. So, if we didn’t have this level of redundancy, a single machine failing could prevent around 80,000 sites from being accessible to our customers. That translates directly into lost revenue for each one of our customers. Clearly, we have to have a very robust architecture, to prevent this from happening.

One of my responsibilities is making sure that our systems can handle failures. We call this fault tolerance, and I think this is going to be the most enjoyable part of testing this application. There’s nothing better than breaking something on purpose, just to see what happens next.

My name is Cullen Waters, and I am a newly hired SDET, working on the Office Live team.  I have learned that my primary responsibilities will start with performance and stress testing our service, and grow to include fault tolerance testing and security testing.

This experience will be a huge learning opportunity for me, since I have never worked in performance and stress testing.  Hopefully, through this blog, it will also become a learning experience for the other developers who find themselves thrust into this problem space.

In addition to posting about stress and performance testing, I will be sharing some of my experiences as a new Microsoft employee.  I am going to skip describing the interview process, since the process went for me pretty much the way every other blogger has already described.  I'll pick up my narrative after my interview, probably starting with the day I accepted the offer.  Not many people share their experiences in relocating and orienting to MSFT.

Hopefully, this information will be of use to at least one prospective or new MSFT employee.