Legacy applications and websites remain in place for longer than they should, often because there is a suspicion that they are still being used. Meanwhile, the application is hanging around consuming IT resources that could be put towards a more useful purpose.

To safely decommission a web site or service, you need to be sure that you are not going to cut off an important business process.  You may even have to prove this at some point to get your decommission change approved and implemented.

I employed some simple log file analysis using WebSpy Vantage to find and address the machines that were still using a legacy application before decommissioning it. Here’s how.

Real World Example

My real world example site involves an internal PKI certificate revocation list distribution point. It gets called by the client browser every time it is presented with a certificate to ensure that the certificate is still valid.  This is a perfect example of a site that will never be seen by a user, but can cause issues if it is decommissioned prematurely.

Start at the destination – Analyzing Microsoft IIS Log Files

I knew the application was hosted by IIS (Internet Information Services), which is pretty good at logging traffic. So my first step was to check that  logging was turned on, and make a note of the log file location.  Since it was Windows Server 2003, I had to actually look it up.

The next step was to import these log files into WebSpy Vantage. This is simply done by going to the Storages tab and clicking Import logs. In the Import Wizard, just create a new storage, select Microsoft IIS as the format, and select your log folder.

Once the logs have been imported, I went to the Summaries tab and ran a new analysis on the storage. This lets me interrogate the log and interactively drill down for more detail.

In this case I had logs going all the way back to 2010, notice how I drill down just to the latest year and month.

This gave me a list of the very few connection attempts being received by the application.  Just to make sure that these are indeed requests intended for this application, I checked the User Agent field and confirmed it was all traffic from the Microsoft-Crypto API user agent.

I now had an actual list of devices still connecting to the site and could now remediate any issues on those machines.

The Gotcha

There was one snag though. Some of the IP addresses that showed up belonged to the perimeter Forefront TMG Array.  That does not really help me since the connections could either be VPN or reverse proxy. The Forefront TMG array replaces the originating IP with its own IP address thanks to NAT.  To track down the source of those conversations, I would also have to analyze the Forefront TMG logs.

The Vantage Advantage

WebSpy Vantage’s ability to process and analyze multiple log formats means that I can use the same tool and methodology, despite the two systems being completely different technology stacks. IIS is a web server and Forefront TMG is a reverse proxy and VPN (among other things).

Analyzing Forefront TMG Log Files

Therefore, the process to analyze the Forefront TMG log files is essentially the same:

1. Create a new storage and import the Forefront TMG array’s log files for the corresponding date(s)
2. Create a new analysis
3. Since we already know where the relevant traffic is going, we can simply filter by the destination IP.  In this case, using the IP address for the old PKI site.
4. From here we can look at the source IP addresses and this will confirm if they are external or VPN.
5. Also, by looking at the Rule field you can also see if there is a potential TMG access rule you need to clean up as part of the decommissioning process.

Conclusion

Being able to safely decommission web sites, applications and services is an essential business process, whether it is to release old hardware hogging the data center, or freeing up expensive Windows licenses. It is also something that needs to be done completely and safely.

In this example we analyzed the Microsoft IIS log files to identify the last few scraggly machines using the application and confirmed the historic and current usage of the site.

We also analyzed the perimeter Forefront TMG logs to identify external connections to the site from the Internet, and established the access rules that allowed it.

Without WebSpy Vantage it would have been much harder, and far easier to overlook that one last important machine.

See also:

• Dedicated WebSpy and Forefront TMG pages – Everything you need to know about TMG Log Reporting
• Increase Report Speed : Reduce What You Import
• Making Sensible Employee Internet Reports for the Modern Web (Part 2)
• Making Sensible Employee Internet Reports for the Modern Web (Part 3)
• A Complete Guide to Useful Reverse Proxy Reporting