Whilst driving back from our 4th of July celebrations in San Antonio, I got alerted to a server running low on disk space. As it hadn’t hit critical, and there was still a fair bit of space left, I decided to wait until I got home. When I looked at the server, I pulled up my trusted space analyzer, TreeSize.
Read more…
Since IIS6, or there abouts, IIS will not host a file that it does not understand, or doesn’t have a MIME handler for. This is a security feature, but can cause some unknown issues…
Read more…
Whilst working away this morning, I received a very pitiful look. It’s that look that we all know. The “I did something terribly wrong” kind of look. This look came with the hands of a digital camera, a small compact point and shoot. A story followed the look, as the camera was handed over to me…
Read more…
Every now and again, we have issues where a developer will have their laptop rebuilt, and forget they have files checked out in Team Foundation Server (TFS). This isn’t very helpful as sometimes they cannot undo their check outs. Visual Studio doesn’t give you access to undo a checkout in another workspace if it’s not your workspace, however the TF.exe command does. Here’s how:
tf /undo /workspace:workspacename;username $/project/path/to/file
This will happily undo the change on that particular file. If you have a whole directory to revert the changes on, that’s easy too…
tf /undo /workspace:workspacename;username /recursive $/project/path/to/directory
You must remember when reverting somebody else’s change to use the project URL, not the physical path on your local machine, otherwise you’ll get an error like this:
No pending changes were found
for <localpathname>\file.aspx
For more details on the tf.exe undo command, see the Microsoft documentation here. Full details on arguments for the tf.exe command can be found here too.
This one is a quick and easy one. We have multiple IIS boxes, which each generate large usage logs on a daily basis. To save space, and for analytics off-server, we compress the log files. Having found Rar is one of the better compression algorithms, we simply shell out to rar, compress the logs, and cleanup older logs.
Read more…
We’ve had a stubborn Windows 2003 server that we’ve been trying to get Office 2007 installed for a while. It has a couple of things wrong with it which have made the install substantially harder.
Read more…
The Networker Blog has an excellent post on support contracts, coining the term Icarus Support Contract. Preston warns on the dangers of using a using minimal support agreements when covering equipment, and software in an environment that is covered by an SLA.
Read more…
For the last day or so, we’ve been working on rolling out the next release of our code to our QA environment. When it came time to build a new set of solutions I stumbled across a weird validation error.
An error occurred while validating. HRESULT=80004005
This error popped up on the setup applications for several new programs. Doing some searching I stumbled across a couple of posts that hinted on removing the project output from the setup, and trying again. This stopped the errors on the setup application, but not the actual application itself.
Then I saw a hint in the errors list…
Application Configuration file "App.config" is invalid. '-' is an unexpected token.
Checking into the app.config file, I stumbled across the cause. It looks like somebody had pasted code that had been “fixed” up by Outlook, or word, and broken a comment. Fixing this, resolved both the app compilation, and the setup validation error.
Part of our move was including the building of the new DR environment. Like most people, we cheated, and cloned the production servers to the new environment. One issue was host naming changes. In our DR environment, the host names change due to the location, and roll of the servers. This means that various IIS config options are now incorrect. This is easily fixed with the new AppCmd in IIS7.
appcmd set vdir /vdir.name:"SiteName/virtual_dir" /physicalPath:"\\NewServer\Images"
The command is relatively easy to understand. /vdir.name is the path to the site, and virtual directory, and /physicalPath is the new path. Easy huh?
I’m obviously playing catch up with a number of posts I’ve been meaning to do. This was something from something I read back in November by Tom Limoncelli, but was something I had planned on writing about anyway. The post, titled “Run, run, run, dead“, brings a nice analogy of things breaking in the analog/digital eras, and points out that as system administrators, we should be using the analog method of monitoring.
Read more…