Digging up an old post today, I helped my wife figure out why her office A/C system couldn’t be managed properly. Apparently their system connects on a specific IP address, and it wasn’t responding. It was surmised that it was caused by some work I had done fixing one of the other machines a few months ago. But after some quick digging, turns out it wasn’t. Apparently their “consultant” had a device on the network for VPN, firewall, etc, which had the same address on it. How it got the same, we don’t know, but here is how we figured it out…

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.

The Nubby Admin has an interesting post, and lesson learnt on the importance of monitoring. The post, titled The Wisdom of Specificity in Monitoring and Alerting. After an outage was caused due to his service provider making some DNS changes due to disk usage issues, Wesley found himself with a broken site, but monitoring didn’t report it as such.

In a case of what I’d call security through obscurity, the Linux Poison blog has a posting up on how to hide the PHP information in your web server. The idea is that the less a potential hacker knows about a system, the better. Here, I’m going to take it one step further, and show you the impact of some other options, and what data gets hidden.

In a follow up to @ScriptingGuys post about restarting services using VBScript, here is the same using PowerShell. I’ll probably be dragging the same onto some server monitoring stuff to get a service back up and running we’ve been having a weird issue with¹.

$names = Get-Content c:\temp\computers.txt
foreach($name in $names) {
	$svc = Get-WmiObject Win32_Service -ComputerName $name `
	    -Filter "name='wuauserv'"
	if ($svc.started -eq $true) {
		$svc.StopService()
	}
	$svc.StartService()
}

This takes a file “computers.txt”, loops through the data, and uses WMI to connect to the remote machines to get the wuauserv service (or in plain English Windows Automatic Update). Easy as pie.

I frequently comment on people not making backups, and there are always plenty of examples of corporations missing the mark too (here, here, here, and here for example). The Social Networking Weblog has a post up with an offer code for Carbonite¹. Not quite sure on the angle for social networking in specific, but it’s good to see somebody else commenting on backups. I’ve been using BackBlaze myself for a while, used it to restore files, and it’s pretty fast too².

Backups are critical, businesses have a financial responsibility for them, whilst home backups have both financial and sentimental value. Get your backups done, get them tested regularly. There are plenty of options for both.

The Last In - First Out blog has an interesting post on on software patching, or more specifically the complexities behind maintaining updated systems. The post brings attention to the numerous security issues, and how hard it is to build a secure patched system, even for the tech savvy folks. He doesn’t call out just one vendor…

This is a quick and handy one for server monitoring, and tracking down that process that is using all your CPU. It makes use of WMI counters.

Curious about how long your script took to execute? How about just that cmdlet? Powershell has a built in function for you.

• Open Powershell command prompt
• Use the command Measure-Command like so:

Measure-Command {c:\scripts\yourscript.ps1}

Enjoy the output broken down by days, hours, minutes, seconds, milliseconds, and ticks.

Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 34
Milliseconds      : 287
Ticks             : 342873445
TotalDays         : 0.000396844265046296
TotalHours        : 0.00952426236111111
TotalMinutes      : 0.571455741666667
TotalSeconds      : 34.2873445
TotalMilliseconds : 34287.3445

The same works for cmdlets too…

PS C:\scripts> Measure-Command {Get-Process}

Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 0
Milliseconds      : 6
Ticks             : 65919
TotalDays         : 7.62951388888889E-08
TotalHours        : 1.83108333333333E-06
TotalMinutes      : 0.000109865
TotalSeconds      : 0.0065919
TotalMilliseconds : 6.5919

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.