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?

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.

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