MWCC's WebLog

Technology Adoption Programs (under the hood) - 1

2005-01-04T23:39:00Z

What is TAP?

The Technology Adoption Program (TAP) at Microsoft® is designed to provide a consistent experience for customers partnering with Microsoft in obtaining real world customer feedback on Microsoft pre-release products. Participating customers find that some of the most powerful benefits include:

§ Product team engineering

§ help in deploying their Microsoft solutions.

§ Early product education.

§ An opportunity to influence product through their feedback.

§ The strategic edge all this can give them in their line of business.

TAP (Technology Adoption Program) is a framework that has been created to rationalize, simplify and centralize the former JDP (Joint Development Program), EAP (Early Adopter Program, RDP (Rapid Deployment Program) and related programs under a single umbrella. The goal is to improve customer/partner experiences in evaluating and adopting our technologies and improve our ability to track and manage customer/partner relationships across programs. TAP is not an additional program. There are currently four different types of TAPs (Product Validation, Product Evaluation, Rapid Deployment and Solutions Implementation) in the framework.

TAP Benefits for Customers (businesses)

§ Agreement

o Single legal agreement for all programs under TAP

o Only 7 pages, clear language

o Governing law aligned with major geographical regions: e.g. Ireland, if your principal place of business is in Europe

§ Program Description

o Same format for all programs

o Flexible to accommodate your requirements

o Like MOU (Memorandum Of Understanding), no legal process necessary

§ Web Site

o Information about all programs available under TAP

o More information about all programs you are participating in

o Work with MS contact if you are interested in participation

o Easy access to pre-release software

§ Plus …

o Consistent / Clear taxonomy for Microsoft wide, cross product consistency:
the customer knows what to expect

o TAP programs part of your strategic IT planning

Deploying Pre-release Products Internally at Microsoft

2004-12-13T23:57:00Z

One of the fun aspects of my job is the opportunity to manage the team that partners with MSIT (Microsoft's IT department) to deploy Microsoft products internally prior to release. I say fun because of the fast-paced challenge pre-release deployment presents. Several weeks prior to releasing a milestone build, whether a Beta (feature complete milestone), Release Candidate (milestone built for testing to validate readiness and quality for release to manufacturing), or a product that is complete and ready for manufacturing, we prepare a build for internal deployment to validate the quality. Once the build gets into the hands of our engineers at MSIT, they start building deployment images, and testing their configurations.

Then, we begin a ramped server operating system deployment by putting the build on 2 or 3 machines in a domain called Windeploy. Most of the Windows division has their user accounts in the Windeploy forest. We do this so that if a problem occurs, people are really motivated to get it fixed since it impacts their ability to do work and access the tools required to do their jobs. We have found that the development team responds quickly in this scenario -- nothing like feeling your own pain.

After the initial server deployments, we wait for 24 to 48 hours and then start deployment servers more rapidly. At the end of 10 days, we will have up to 180 to 190 servers running the pre-release (or escrow) build. Sometimes the deployment goes completely smooth and other times, we hit hiccups that cause us to stop and take fixes. When we hit the hiccups, all hands come on deck to keep the service running and to solve the problems as quickly as possible.

A few weeks ago I talked about providing performance information about 64-bit in MSIT. So far, the data we have is anecdotal. Here it is:

Roles where we have 64-bit server deployed with the 64-bit OS: Domain controllers, SQL database applications (both clustered and non-clustered), file servers such as our large bug database in Windows, and Web servers
For our large database applications, we are seeing the 64-bit box handle twice as many production queries than the next fastest 32-bit box (mix of 1740g28x2.8GHz w/8GB memory)

And plans are in the work for more. I'm curious what you think about the emerging 64-bit marketing. Is it going to come faster or slower than expected in business and government IT departments?

Releasing Operating Systems

2004-12-01T04:50:00Z

I've been working at Microsoft for upwards of seven years now, and I never quite get over the awe I feel when we get close to releasing a milestone build. It's amazing to see how teams of engineers come together totally focused on resolving issues quickly to get to a stable build for our customers. The process begins weeks before we get to the final build.

The actual process starts with an idea that turns into a spec for a new feature or scenario. This is repeated multiple times across a product a complex as Windows. Then, as each team completes coding milestones, they check the code into the main build and we start building a new version of the OS. As we get close to a major release milestone like a beta or a release candidate, we go through a lockdown period where each fix or code change has to be pre-approved by a group called the Ship Room before it can be checked into the core code.

At the same time, we start releasing internal only milestone builds that are ready for deployment. These builds have been tested to the point where each engineering team is confident enough to have other employees use the builds on their work machines. Employees in Windows pick up these builds and start having interesting experiences. For example, when I loaded the latest server build today, I logged onto the machine and to my surprise, saw a desktop background picture of my children in their Halloween costumes from three years ago that I haven't seen for a couple of years. Apparently, there was an old version of my profile stored on the back-up server to the one that holds my roaming profile. When I logged onto the new build, it picked up the old profile that included the desktop picture. While it was fun to see the picture again, I was surprised to see it. Further investigation showed that there is a glitch in the code that accesses the servers holding profiles that can cause the computer machine to pick up an old profile on log-in.

This is the time when releasing software can be fun. What a cool thing to be able to find issues and get them fixed. We are in a race now to see how many issues we can find and fix so that customers will have a great experience. It's amazing how test teams can mobilize to reproduce issues and developers can come in quickly behind to code a fix that then gets checked into the build. This process occurs multiple times across multiple teams until we release a build that can run the Microsoft business in our Microsoft IT department and all before we've released the build to customers.

I haven't forgotten the performance data I promised in the last blog. I'll have the detailed information for you soon.

64-bit Domain Controllers in MSIT

2004-11-18T05:10:00Z

Two years ago, we decided that it was time to start doing some serious deployments of 64-bit hardware in Microsoft's internal IT organization -- MSIT. We looked around for a scenario that would justify the cost of the 64-bit hardware. When we decide to deploy technology in MSIT, even though the software is Microsoft engineered, we require each deployment to meet a business need. This helps us ensure that we are not only building the right products for the enterprise space, but also that we spend our money and resources wisely.

After some discussion, we realized that an area where we could find good value would be to move some of our domain controllers to 64-bit hardware running the 64-bit OS. Our internal .dit file (the flat file that stores Active Directory data) was larger than 14 GIG. The 4 GIG memory limit on our 32-bit boxes made it so that domain controllers were spending valuable time using paging files during database access. So, after checking with the Directory Services developers, who agreed that the theory should work, we purchased a system and put it into production. Sure enough, we saw performance gains. MSIT engineers have promised to have more detailed information on the performance gains by this early next week. I'll update the site when I get the details.

Move forward two years. Now, we're in an engineering march to release the Windows 64-bit edition client and server next year. We've revisited our scenarios and are now in the process of upgrading print servers, file servers, and our internal Human Resources website to 64-bit.

If you have some feedback or questions about the 64-bit deployments, I'd love to hear them and respond.

Introducing the Windows Technology Adoption Team

2004-11-10T05:03:00Z

The Windows Technology Adoption Program (TAP) team exists to drive greater and higher quality customer, ISV, and OEM input into the product development process for Windows. Our goal is to understand the entire customer eco-system where the operating system runs and then drive success for each customer set by providing early builds and giving customers an opportunity to tell us what works and what doesn't.

We run both breadth and depth customer programs. Breadth programs provide build access to customers through Tech Betas. Depth programs provide pre-release product support and dedicated resources to drive critical technical issues raised by ISVs, OEMs, and customers into product changes.

My team is where the rubber hits the road between developing the operating system and companies using it to run their businesses. It's an exciting place to be.

Every week someone from my team will be posting a new entry talking about our experiences. We welcome any and all feedback, ideas, and suggestions.

Next week, look for a summary of the 64-bit scenarios we have in deployment within Microsoft today along with information about the type of performance we are seeing.

New website in the works - tools for SMB IT Pros

2004-10-14T01:25:00Z

I’ve been throwing around some ideas within my team on how to reach our SMB (Small and Medium Business) IT Pros in the same way that sites like gotdotnet.com reach our developer community. More specifically, what types of tools can I provide from the windows team that IT Pros can really use and build on?

Some background: IMHO, the beauty of gotdotnet and other developer sites are the samples. Samples that are well documented that don’t over complicate a task by overloading the code with error checking and performance enhancements that obscure the readability of the code.

Does that mean error checking and perf aren’t important? Of course not but error checking might better be handled in a separate sample where I can digest the topics in bite size chunks.

My idea is to publish a site. Yes! Another site but with a different paradigm; one that doesn’t strive to provide everything to everyone. More simply, a site with samples that SMB IT Pros can consume with instant gratification. The key to being successful would hinge on NOT providing everything that everyone needs. I want to be the local grocer; not that super-value-outlet-mart that I can never find the soup isle in. By keeping it reasonable I would be able to keep content discoverable.

What type of information would I keep on it?

Here are a couple ideas I have:

1.) Script Samples: Boiling down useful WMI and command line scripts to their basic elements for IT Pro that aren’t scripting gurus.

2.) Solution guides: Simple, practical, and applicable guides for implementing windows client and server technologies like DNS 101, DHCP for Beginners, How to move from NT Domains to Active Directory in 10 easy steps.

3.) Partner workspaces or forums where the SMB communities can answer questions about documentation on the site in real time. I can’t stay up as late as I used to anymore.

I’m probably going to make this my holiday vacation project this year to see if I can’t reduce some of the frustration I saw and felt in a previous life as an IT Pro for a university where I didn’t have a supporting staff that already had figured this stuff out.

Any ideas are appreciated.

Mike Langowski

Welcome

2004-10-13T20:22:00Z

Welcome to the Windows Customer Connection Blog!