Jan 8 2009 2:18AM GMT
Posted by: Jerry Lees
essential tools,
System Administration,
Web applications,
web sites,
webmaster,
free software,
free tools
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!
Dec 26 2008 2:42PM GMT
Posted by: Jerry Lees
webmaster,
Web applications,
migrating a web server,
rebuilding a webserver,
ODBC,
ODBC entries,
migrate ODBC entries,
registry,
fun with the registry
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:
Nov 3 2008 4:18PM GMT
Posted by: Jerry Lees
HTTP,
web tools,
web sites,
Web applications,
webmaster,
http tools,
Web Pages,
HTTP Status Codes
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.
Oct 10 2008 7:57PM GMT
Posted by: Jerry Lees
SOAP,
WSDL,
web tools,
web sites,
Web Service,
webmaster,
Web Pages
As an IIS Administrator I have spent quite a bit of time administering web sites and web services in my role where I work. Recently, I have been doing some work with Web Services in IIS to actually monitor them since we needed to do more than just simply monitor the Web Service Definition Language (WSDL) page.
For those of you who do this sort of work, you know this is a real challenge sometimes, since the web service can actually be broken– but the WSDL page shows up. So, I had to create something to actually consume the web service so that we could truely test the web service.
Web Services are basically (yes, I’m boiling it down to the bare minimum here…) web sites that accept input via the HTTP protocol, preform work based on those parameters, and return back some value via HTTP. Just like a FUNCTION! This is an exciting technology, becasue it essentially is distributed computing.
This caused me to look for public web services, again, because I was interested in the concept since I first heard about it 4 or 5 years back. I found a decent site that had a list of web services that were available on the internet at Xmethods.net. While they all aren’t free (and they all didn’t appear to be operational) — it did seem like a decent list of sometimes useful stuff to have handy.
Having found this, I can now share the consumption of web services from VBScript with you in another blog posting– Consuming and using a web service from within VBScript to create a WHOIS tool.
Jun 26 2008 1:56PM GMT
Posted by: Jerry Lees
monitoring,
VBScript,
Web applications,
webmaster
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!