mhenry1384's questions

We occasionally have configurations in web.config(s) being changed by the IT team on live production servers. I would like to create an audit trail, e.g., "On October 11 the property "foo" in file "bar" was changed to "banana".

My first thought was to create a PowerShell script that would run every hour, and if one of the .config files changed, save it off in a time stamped folder. My second thought was that this must be a problem that has already been solved.

Ideally, config file changes would not be allowed and any change would require a new deployment, but it's unlikely I could push that through.

I say "web.config" but I have a few different xml config files: web.config, app.config, nant.configs.

I need to know exactly what in these config files changed (approximately) when and (ideally) by whom.

Is there some kind of standard way or open source tool to do file change logging?

We have a number of sites in a number of environments. Many of the environments are load balanced with two web servers (and in some cases two app servers). Twice in the past two months we've run into a situation in which a server was inadvertently taken out of the load balancer. This bit us a few days later when the second server was taken out and the site went down completely. In both cases the problem was discovered and corrected quickly, but it leads me to believe that we need an alert when a server is out of the load balancer. Our normal alerts don't work here because in both cases the website on the server was up and responding, it just wasn't in the LB.

It might be possible to set up alerts on the load balancer itself, but they are managed by our hosting provider and dealing with them can be a pain.

My thought is to have an app that scans the server logs every 15 minutes and sends an email when the number of unique visitors per hour drops below a certain threshold. Doesn't sound terribly difficult to write, but seems like there may already be a standard 3rd party tool that already does something along these lines.

We use Windows, ASP.NET, IIS, if that matters.

Recommendation for a tool that alerts when a website is not getting hits?

I have some URL Rewrite rules at the root of IIS (i.e. not in a specific site). They are at the root because they Route to Server Farm, and apparently that has to be done at the root (I don't see the option for "Route to a Server Farm" when I create a URL Rewrite rule on a site.)

I would like to enable Failed Request Tracing so I can see what's going on with this particular rule, but I don't see a way to enable it at the root, only on a site-by site basis. How do I enable Failed Request Tracing at the root?

I have two users who only see the following options in the Team Explorer tab in Visual Studio: Changes, Branches, Sync and Settings

Another user, correctly sees all of them: Changes, Branches, Pull Requests, Sync, Work Items, Builds, Reports, Settings

The users who cannot see all the options appear to be members of the same relevant groups as the user who can. The only difference I can see is the user who CAN see all the options is on Visual Studio 2015 Update 1. The ones who can't are on Update 2. Possibly a red herring? I don't want to have the one who can see the options update, for fear he will lose the ability to access these options.

I am an admin, and on Visual Studio Update 2, and I see all the options.

TFS server 2015 Version 14.95.25122.0

From the web interface, all users are able to access pull requests and work items and see the builds. So it doesn't seem to be a permission problem? Possibly something they need to set in Visual Studio? How can this be fixed?

Related to What does Virtual Bytes mean in Worker Processes pane in IIS7.5 Manager?

I have a server running a few different sites. We're seeing some performance and memory issues.

When I go to Worker Processes I see one of the sites with a Virtual Bytes count of 5 GB. The private bytes is a more reasonable 800 MB. The server is x64 with 8GB of memory and IIS 7.

Is it a problem that the virtual bytes count is so high, or is that a red herring? If the virtual bytes count is high, does that mean it's storing memory in the paging file which could be causing thrashing? Or does the application pool simply create a big chunk of virtual memory on Windows x64 and it doesn't affect other processes or get written to the paging file?