Free e-book: Windows 7 troubleshooting tips

Originally found on the Microsoft Press blog…

Free e-book: Windows 7 troubleshooting tips

Mitch Tulloch, a Microsoft Most Valuable Professional and lead author of the just-published (and hot-selling) Windows 7 Resource Kit (Microsoft Press, 2010; ISBN: 9780735627000; 1760 pages), has created a short e-book called “What You Can Do Before You Call Tech Support.” Here are the opening paragraphs:

Your sound card has stopped working, your computer seems sluggish, the network is down, your hard drive is clicking, you can’t view a website, your monitor is hard to read, your new webcam isn’t working, your favorite program won’t run, and a funny burning smell is coming from your computer. What can you do on your own to try to troubleshoot the issue before you pick up the phone to call tech support?

If you’re running Windows 7, quite a lot. Microsoft has included a lot of self-support tools in Windows 7 that you can try using before you seek the help of others, and we’ll examine these in a moment. Then there are the tools you were born with—your five senses (see, hear, smell, taste, touch) and most importantly your brain. And by brain I’m including your memory, experience, and capacity for logical reasoning. Finally, there is ancient and sacred lore passed on in secret from Master to Disciple over the millennia. We’ll see shortly how your brain, your senses, and the secrets of the Wise Ones can be very helpful for troubleshooting computer problems. But first let’s look at what troubleshooting tools are built into Windows 7.

You can download the e-book in XPS format here and in PDF format here. Enjoy!

ASP.NET Application Deployment Best Practices – Part 2

In my previous post I started a list of best practices that should be followed for deploying applications to production systems.  This is continuation of that post.

  • Create new Virtual Application in IIS

Right-click [website app will live in] > Create Application

Creating a new application provides each ASP.NET application its own sandbox environment. The benefit to this is that site resources do not get shared between applications. It is a requirement for all new web applications written in ASP.NET.

  • Create a new application pool for Virtual App
    • Right click on Application Pools and select Add Application Pool
    • Define name: “apAppName” - ‘ap’ followed by the Application Name
    • Set Framework version to 2.0
    • Set the Managed Pipeline mode: Most applications should use the default setting

An application pool is a distinct process running on the web server. It segregates processes and system resources in an attempt to prevent errant web applications from allocating all system resources. It also prevents any nasty application crashes from taking the entire website down. It is also necessary for creating distinct security contexts for applications. Setting this up is essential for high availability.

  • Set the memory limit for application pool

There is a finite amount of available resources on the web servers. We do not want any one application to allocate them all. Setting a reasonable max per application lets the core website run comfortably and allows for many applications to run at any given time. If it is a small lightweight application, the max limit could be set lower.

  • Create and appropriately use an app_Offline.htm file

Friendlier than an ASP.NET exception screen (aka the Yellow Screen of Death)

If this file exists it will automatically stop all traffic into a web application. Aptly named, it is best used when server updates occur that might take the application down for an extended period of time. It should be stylized to conform to the application style. Best practice is to keep the file in the root directory of the application renamed to app_Online.htm, that way it can easily be found if an emergency update were to occur.

  • Don’t use the Default Website instance
    • This should be disabled by default
    • Either create a new website instance or create a Virtual Application under existing website instance

Numerous vulnerabilities in the wild make certain assumptions that the default website instance is used, which creates reasonably predictable attack vectors given that default properties exist. If we disable this instance and create new instances it will mitigate a number of attacks immediately.

  • Create two Build Profiles
    • One for development/testing
    • One for production

Using two build profiles is very handy for managing configuration settings such as connection strings and application keys. It lessens the manageability issues associated with developing web applications remotely. This is not a necessity, though it does make development easier.

  • Don’t use the wwwroot folder to host web apps

Define a root folder for all web applications other than wwwroot

As with the previous comment, there are vulnerabilities that use the default wwwroot folder as an attack vector. A simple mitigation to this is to move the root folders for websites to another location, preferably on a different disk than the Operating System.

These two lists sum up what I believe to be a substantial set of best practices for application deployments.  The intent was not to create a list of best development best practices, or which development model to follow, but as an aid in strictly deployment.  It should be left to you or your department to define development models.

Make it Right: Revisited

In the previous post Make it Right I asked the question

Why aren’t more people making it right?

I was curious why people don’t take the time to write software properly.  There are lots of jokes about bad software development:

If houses were built the same way programmers build programs, we’d all be living on the street.

Unfortunately it’s a fair statement.  Most programs out there suck*.  I used to come back with the argument that people have been building houses for thousands of years, but software for only a few decades.  There are bound to be issues.  But then it occurred to me.

Mike Holmes is all about making it right, as I said in the previous post.  His TV show was about fixing the problems that professionals made.  Professionals who have been building the same thing people have built for thousands of years.  Wait a minute.  I just flawed my own argument.

Houses are built the same way programmers build programs.

Why?

I see three very apparent reasons.

  1. Cheapness – People want software built quickly, as cheap as possible.
  2. Laziness – Why strain your mental processing or follow best practices when you can just do whatever first comes to mind?
  3. Uneducated – Sometimes (a lot of times) the person doing the building/development just doesn’t know what they are doing.

There are numerous other reasons why, but these three are by far the biggest across all aspects of building stuff.  I think they answer the basic question asked earlier, but now I have another question.

Why do we let people who are lazy or uneducated build applications for us, just so we can save a few bucks?  We will end up paying loads more in support after the fact…

*I said programs, not programmers.