We use a lot of redirects in my current environment. I mean ALOT. Currently we have 150. While that doesn't seem like a big number in many ways each of these are loaded into the Web Servers memory each time it starts. Often, every 6 months or so, I like to have these reviewed to see which ones are valid, and this is difficult since we have a tracking system for requests, and we store the files in source control but there is little visibility about which ones are actually in use. Which led to my recent foray into PowerShell and XML.
I was asked recently about getting a list of the updated redirects for review. Nothing new, again I do this every 6 months, mostly because some just get asked to deal with a specific marketing campaign, a scheduled event and we have a few that exist from when we updated our web site in July 2011. Those update ones are there to point people who may have had links to information on the old site, to the locations on the new site. At times even those age and need to be removed at some point. Still getting the information wasn't simple since I needed to collate from multiple sources, until last week when I had some spare multi-task time in the afternoon and thought, "hey, I can do this in powershell!"
So I sat down and pulled the XML into a PowerShell variable so I could look at it:
[xml]$redirectXML = Get-Content $redirectFile
From there I looked at the structure I was getting and looking through many of the nodes noticed that the one that was going to give me trouble was the system.webserver since that . notation typically means that you have another node. Why Microsoft gives it that notation I don't know but this stumped me for awhile. Until coming across an answer for something else I saw that when you have node names like that you use quote marks around them. So while following the nodes down to the Rules section I wanted from the Redirect Map I came up with:
$rules= $redirectXMl.configuration."system.webServer".rewrite.rewriteMaps.rewriteMap.add
This gave me the first part, but then it was a simple matter to then pull out the actual rules:
$redirectUrl= $redirectXMl.configuration."system.webServer".rewrite.globalRules.rule
This helped a lot, so what I ended up doing was pulling these together then outputting them into a table delimited file so I could pull them into Excel. In the end I came up with a fairly good script that pulled out what I wanted, it does need clean up and I would like to actually output into an Excel worksheet, but that is for later. My basic script ended up being:
# Get the values that we will need from the command line
# So far I only need the path and name of the redirect file, the
# ApplicationHost.Config file
Param([string]$redirectFile)
# Constants that will be necessary
[string]$redirListDir = $null
[string]$redirectList = "redirectList.csv"
# Check that we have a file to pull redirects from
if( ($redirectFile -eq $null) -or ($redirectFile -eq "")) {
"Make sure its the path including the name "
"of the applicationHost.config that needs to be checked. Try something like "
".\redirectReview.ps1 C:\filelocation\applicationHost.config"
"Thank you!"
exit
}
# Check that we have a place to put the file at the end
if(($redirListDir -eq $null) -or ($redirListDir -eq "")) {
if (Test-Path -Path "d:\temp") {
$redirListDir = "d:\temp"
"Using D:\Temp"
}
elseif (Test-Path -Path "c:\temp") {
$redirListDir = "c:\temp"
"Using C:\Temp"
}
else {
"Cannot find a directory D:\temp or C:\temp. Create one and try again.`n"
exit
}
}
$redirectListFile = Join-Path -Path $redirListDir -ChildPath($redirectList)
if (Test-Path $redirectListFile) {
Remove-Item $redirectListFile -Force
}
# Open the file and put it in an XML format
[xml]$redirectXML = Get-Content $redirectFile
# Review the XML tags
# One of my old pointers
# $redirectXMl.configuration."system.webServer".rewrite.rewriteMaps
"Getting the Rewrite Maps"
# This gets all the rewrite Map redirects
$rules = $redirectXMl.configuration."system.webServer".rewrite.rewriteMaps.rewriteMap.add
"Now for the Global Rules"
# This gets all the rules that have been added
# Trying some different match formats that did not work
# $inputUrl = $redirectXMl.configuration."system.webServer".rewrite.globalRules.rule | % {$_.match)
# $redirectUrl = $redirectXMl.configuration."system.webServer".rewrite.globalRules.rule | % {$_.action}
$redirectUrl = $redirectXMl.configuration."system.webServer".rewrite.globalRules.rule
"Creating the output file"
# Output the claimed values into a CSV file that can be reviewed somewhere
$rules | % {
$a = $_.key + "`t" + $_.value
$a >> $redirectListFile
}
$redirectUrl | % {
$b1 = ($_.match).OuterXML
$b2 = ($_.action).OuterXML
$b = $b1 + "`t" + $b2
$b >> $redirectListFile
}
So, 2011 was a busy year working with SharePoint. We did a major site
upgrade where the old public site running on IIS was moved over to SharePoint,
that was a major effort and took a lot of coordination with a lot of people. It
came off really well, and has been successful since not many people noticed the
underlying change, only the new look of the site. To me, that is a major
success.
In addition I went through the task of learning SharePoint, as well as it's
Search functionality, we had it going well for awhile then things just stopped.
We still have no idea why, but it's been slightly educational in learning how
things work. A nice environment where people just jump into things, help out
where needed, and take the time to learn. That's what makes this job great.
Testing was a big focus, not only because we added a new person to help test
last year, though she moved on it was good to sort of settle things and document
much more. Teaching is always interesting since everyone comes in with a
different focus and idea, that helps me readjust my thinking when I start to
train someone. From that I have more wiki pages, more places to document what
we have been doing and more documentation on just everything. I also got a
start on automated testing, I now have a Framework with SpecFlow where I am now
using BDD to create automated cases for Functional and Acceptance testing.
First time the Acceptance Test was used after a deploy we found an error, that
is success to me.
I needed to add goals for the year, which I am bad at, for myself I have
overall goals but they get subsumed by whatever is going on at work at the
time. Priorities come up and I need to learn something, say about writing a
PowerShell script here or there, always something new. Though I think I am
better now at focusing more on what I need to do and I will be going through
that as a task for 2012. Should be an interesting year and I hope to do better
about recording things here as well.