Web applications

Essential tools: Fiddler Web Debugger, Display HTTP packets LIVE without a packet sniffer

You may have been thinking I had forgotten about this series of articles since I haven’t posted to it in a while. Nope! Just haven’t run across anything that was truely aazing enough to be an “Essential Tool”. Well, I recently found just that web I had to troubleshoot a application that was making calls to a web service.

The tool i was lead to is Fiddler, the Web Debugger!!! If you’re like me and you have to trouble shoot web applications that make web service calls– you’re going to LOVE fiddler. No more digging through logs to determine problems real time, especially since IIS caches the log data and writes it in chunks.

Fiddler displays the HTTP (and HTTPS) traffic originated from a machine it is ran on and then shows the cooresponding response from the server you connected with in the request. It’s a real life saver, especially if your not certain the packet is well formed for a SOAP web service on the other end. As an added bonus, Fiddler also allows you to see the raw HTTP (or HTTPS) headers and response headers.

Best of all it’s FREE!!! (We’ll it cost me a $250 call to Microsoft to find out about it… but the application is free and for you the information is free!) Try it out— TODAY!

Fun with the Registry: Saving ODBC Entries from a server (and moving them to a new server)

On occasion you have to rebuild servers, some are worse than others to rebuild. Much like my previous post on moving file and print shares, Web Servers are not that difficult to rebuild, but one of the tedious tasks in moving a web server is setting up all the ODBC entries that have been added over time all at once. you know the drill:

Point. Click. Click. Click. Add. Double check settings. Click OK.  Pray it’s right.

Well, all the ODBC enties on a system are actually in the registry! You can save a TON of time– and be lazy! — by simply exporting the proper key in the registry and importing it to the new server! (Note: This just moves the OBDC entries… you’ll want to be extra careful that all the ODBC Drivers imported are actually installed on the server and probably are the same versions)  The registry key is:

HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBC.INI

Keep in mind… your editing the registry on your fresh new server… so I’ll once again blatantly copy Microsoft’s stereotypical disclaimer: 

Caution, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow the steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, click the following article number to view the article in the Microsoft Knowledge Base:

322756   http://support.microsoft.com/kb/322756/ ) How to back up and restore the registry in Windows

HTTP Status Codes explained for web servers

As a web administrator I encounter quite a few instances where a weird HTTP status is returned to a browser.Even using them often it’s hard to remember the codes 100% and what they all mean. Sure, a 404 means the file doesn’t exist and a 200 is a good response… but what about the harder more obscure ones? Generally the toughest to resolve revolve around permissions and the HTTP 401.x status, here is a good article explaining the HTTP 401 sub status codes for IIS (The general idea will flow over to other web servers like apache as well).

As a  added bonus here is a great article that explains a vast variety of other HTTP Status codes.

How to associate specific WWW w3wp.exe process ID’s with a IIS application

One of the most difficult problems with troubleshooting a web application on a server that has many applications on it is determining which one of the applications is causing an issue. Sometimes that is easy because you see an error message or, in those rare cases where you get an actual screenshot, a URL is given to you to go on. However, often you don’t get such useful information! Most times you just notice a w3wp.exe process either taking up to much memory or using to many CPU cycles (or in some cases none at all), but there’s a vbscript solution for this!

The best part is that you don’t have to write a single line of VBScript code! It’s already been written for you my Microsoft! The only thing you need to do is be sure the applications have a different pool name from one another—which is always a good idea.At a command prompt you can run iisapp.vbs to get application pool information associated with a specific w3wp.exe process, like so:cscript c:\WINDOWS\system32\iisapp.vbsThis will return output similar to the following:

W3WP.exe PID: 17632   AppPoolId: Application-1
W3WP.exe PID: 17532   AppPoolId: Application-2
W3WP.exe PID: 5748   AppPoolId: Application-2
W3WP.exe PID: 14040   AppPoolId: Application-1

That’s it… easy as pie!