I consider AnnArbor.com my primary source of local news, but find its user comments to be uninformative and distracting. So, I assembled a method to hide all traces of user comments while browsing their site. This requires Firefox and a Greasemonkey script. This is by no means perfect, but it works. Take it as you will and read in peace!

The script:

// ==UserScript==
// @name           hide annarbor.com comments
// @namespace      aadotcomcblock
// @include        http://www.annarbor.com/*
// ==/UserScript==

var all_li, specific_li;
all_li = document.evaluate(
“//li[@class=’comments’]”,
document,
null,
XPathResult.UNORDERED_NODE_SNAPSHOT_TYPE,
null);
for (var i = 0; i < all_li.snapshotLength; i++) {
specific_li = all_li.snapshotItem(i);
specific_li.parentNode.removeChild(specific_li);
}

var all_p, this_p;
all_p = document.evaluate(
“//p[@class=’post_comment_now’]”,
document,
null,
XPathResult.UNORDERED_NODE_SNAPSHOT_TYPE,
null);
for (var i = 0; i < all_p.snapshotLength; i++) {
this_p = all_p.snapshotItem(i);
this_p.parentNode.removeChild(this_p);
}

var all_div, one_div;
all_div = document.evaluate(
“//div[@class=’news_comments clearfix’]”,
document,
null,
XPathResult.UNORDERED_NODE_SNAPSHOT_TYPE,
null);
for (var i = 0; i < all_div.snapshotLength; i++) {
one_div = all_div.snapshotItem(i);
one_div.parentNode.removeChild(one_div);
}

var all_urlcomments, single_urlcomments;
all_urlcomments = document.evaluate(
“//a[@class=’comments’]”,
document,
null,
XPathResult.UNORDERED_NODE_SNAPSHOT_TYPE,
null);
for (var i = 0; i < all_urlcomments.snapshotLength; i++) {
single_urlcomments = all_urlcomments.snapshotItem(i);
single_urlcomments.parentNode.removeChild(single_urlcomments);
}

var removeComments = document.getElementById(‘comments’);
if (removeComments) {
removeComments.parentNode.removeChild(removeComments);
}

Thanks to E. Clarke for help on this.

Recently, I had to enable ACS Forwarding on a percentage of the systems reporting to my SCOM Management Group. All of the examples that I found on the Internet were for enabling ALL of the systems in a management group. For me, that was about 5,500 systems too many. So, I made a quick PowerShell script that did the job for me. There are 2 parts to this script. 1.) Input File - This file containts the list of hostnames that you wish to enable ACS Forwarding on. 2.) PowerShell Script. Here is an example of the script:

ACS_Enable.ps1

#### FUNCTION DECLARATION BEGIN

Function enableACSForwarder
{

param ($targetHostname)

Write-Host “Enabling Audit Collection for:” $targetHostname
cd <mgmtserver>\Microsoft.SystemCenter.AllComputersGroup\$targetHostname\Microsoft.SystemCenter.HealthService
Start-Task -task:$enableAcsTask -overrides:$overrides -credential:$credentials

}

#### FUNCTION DECLARATION END

$collectorServerName = “<your collector server name here>”

$enableAcsTask = get-task -path \ | where {$_.Name -eq ‘Microsoft.SystemCenter.EnableAuditCollectionService’}
$overrides = new-object Hashtable
$overrides.Add(“CollectorServer”,$collectorServerName)
$credentials = Get-Credential

get-content C:\acs_enable_input.txt | ForEach-Object { enableACSForwarder $_ }

Ever find yourself sifting through specific event logs after debugging a script or application? Do you do the old “hurry up and switch to Event Viewer so I can catch new events” technique? With wevtutil, put this command in front of your script and enjoy event logs that are relevant from the time of execution forward:

wevtutil cl log_name /bu:backup_location_before_clear

wevtutil cl Security /bu:C:\security_backup.evt

I recently ran into a problem where a single Guest virtual machine on a VMWare ESX host was consuming too much bandwidth (70megabits/second!). When I configure a basic ESX host, I usually am working with a server that has two Ethernet Interfaces. I end up using one interface for management and the other as a virtual switch in which one VM Port Group is created that all the guests utilize. Luckily, VMWare has some cool policies that can be applied to Virtual Machine Port Groups. One of these policies: Traffic Shaping. Now, you could very well apply this policy to your standard VM Port Group, but that means all of the guests on that port group would then be impacted by this policy. In my case, I only want to apply Traffic Shaping to one virtual machine. Note that the same steps can be adapted for a single port group.

In vShpere, select the ESX host that you wish to configure. Select the Configuration tab on the top and Networking from the hardware selection on the left hand side. When in the Networking pane, make sure Virtual Switch is selected.

In this view, select Add Networking on the right hand side of the screen.

Choose Virtual Machine

Select the virtual switch that you use for your guest VMs

Give it a cool name. Something like “Shapped_Traffic” (an obvious typo).

Here is a preview of what is about to happen: You are adding an additional VM Port Group to your existing virtual switch/physical adapter.

Cool. So now that we have this VM Port Group created, we need to edit the Traffic Shaping policy for it. Select Properties on the virtual switch that your new Port Group resides on.

Choose your newly created port group and Edit it.

Choose the Traffic Shaping tab, enable the policy, and set your desired bandwidth settings. *NOTE that Average and Peak bandwidth are measured in Kbits/sec VERSUS Kbytes for your Burst size.

When your policy is created and ready to rock, edit the Network Adapter settings on the virtual machine in question and choose your newly created VM Port Group as its Network Connection.

Enjoy your total control!

DFSR is an extremely important piece of my daily environment. I primarily use it as it was intended - to efficiently replicate files from one location to another over a slow to average link. But, my situation is slightly unique in the fact that files always originate on the far end of the link (remote site) and replicate to a datacenter. Once DFSR replicates this data to the datacenter, a “data monster” moves the data from the near end DFSR server into some giant information warehouse in the sky. So, let me recap this process from start to finish and with a little more detail. 1.) Data is generated on the far end. 2.) DFSR replicates this data to our datacenter DFSR servers. 3.) The “data monster” moves the data from the datacenter DFSR server to it’s final resting place. 4.) The datacenter DFSR server tells its far end replication partner, “Hey there, this file is gone, so please tombstone (delete) this file on your end. 5.) The far end DFSR server deletes the data as instructed and life goes on. Let’s call this the “transfer lifecycle.”

Once this data is generated at the far end and moves to it’s final resting place in some data warehouse, we no longer have a need for it to exist on the far end DFSR replication partner. That’s why it’s not a big deal that when that data is moved off of the near end DFSR partner, it’s also removed from the far end replication partner.

Initially, my team developed this relatively efficient PowerShell script in which its only job was moving data from the near end DFSR partner to the data warehouse. This script never really gave us much grief. I must admit that it seemed a bit sluggish at times, but it wasn’t so insanely fast that we would go around giving high fives about it either. Up until this point, both the script and the DFSR process itself was running smooth and we didn’t experience any bottlenecks. One day my team decided to write an application that would run as a service on the near end DFSR replication partner, replacing the PowerShell script.

When this application was implemented, we stared to notice two things. 1.) We were randomly receiving TONS of duplicate files and 2.) it would take 5 times as long for a large group of files to fully complete it’s “transfer lifecycle”. Again, this only happened for a large group of files being transferred.

After lots of trial and error, here is what I discovered. Our near end file moving application was too efficient! Before DFSR could complete the entire transaction of a large group of files, our application would have already moved it off of the server! DFSR would then say, “Hey! The file was here and now it’s not - let me try again.” This explained the large number of duplicate files. Even though it would retransmit over and over again, DFSR was intelligent enough to slowly catch up. This explained the increase in time to complete the “transfer lifecycle.” I attribute these results to the increased efficiency of using the Windows API for file movement and WAN link performance (or lack there of).

In the end, we determined that increased gaps of time in which the process would look for new file arrivals would take care of this issue. Lesson learned. Don’t try to beat something at it’s own game unless you are fully informed and fully prepared!

Sorry that I’ve been distant. Been on a long smoke break in the Datacenter.

MMS 2009 Begins..

XenServer Vitals

Campus Wide Nortel to Cisco Swap

dalas verdugo - “buying some of IT”

So awesome.