The Surly Admin

Custom Employee Directory Update

The other day Richard Hipkin over at Spiceworks requested a custom version of the Employee Directory that I blogged about last week.  The irony, and isn’t this always the case, is that he wanted something I had removed from the original vbScript that had been there!  Richard wanted to add Location as well as the employee’s manager into the mix.  Normally this would have been pretty simple and I would have just sent it over to him without comment but I ran into an interesting problem that I wanted to write about here.

Adding Location

Not only did he want to add location, but he wanted to change the button row from using departments to using location–again what the original script used to do!  This involved making 4 small changes to the script.  Two of the scripting changes went into the $HeaderHTML here-string as they involved adding an extra column in the header for Location, no big deal there.  The other involved changing the button search Javascript.  The Javascript is hardcoded to only key off of the department column, here:

function filtbutton(phrase){
var tableMain = document.getElementById('TableMain');
for(i=1;i<tableMain.rows.length;i++){
ele = tableMain.rows[i].innerHTML.replace(/<[^>]+>/g,"");
tableMain.rows[i].style.display = '';}
for(i=1;i<tableMain.rows.length;i++){
ele = tableMain.rows[i].cells[4].innerHTML.replace(/<[^>]+>/g,"");
if (ele != phrase && phrase != '') {
tableMain.rows[i].style.display = 'none';
} else {
}
}
}

Note line number 7, I’m assigning the variable ele to tableMain (the primary table where employee information is held), row “i” which is a variable for the current line and cell “4” which happens to be the department row.  We just have to change that cell to match the new column where location will be located, which happens to be column “6”.

ele = tableMain.rows[i].cells[6].innerHTML.replace(/<[^>]+>/g,"");

Next up, we have to modify the ADSI searcher to include the location.  This field is called physicalDeliveryOfficeName in Active Directory.  Then we just need to include that field in our custom PSObject and in the $DetailHTML lines.  Not too bad.

Employee Manager

This is a little trickier and while working on the problem I discovered an interesting “quirk” when using ADSI searcher.  The first problem is the manager field stores the employee’s manager as an FQDN, which is good for a computer but makes for a horrible looking display on the Employee Directory.  What we need to do is take that field, then query Active Directory for that user and build a display name from their first name and last name, but I hate refering back to Active Directory because it just slows things down.  Why not just simply search the variable I have that has all the users in it?  That should have the manager in there too.  This meant I had to add distinguishedName to the ADSI searcher so I could look at it.  Here’s what I came up with:

$Manager = $Users | Where { $_.Properties.distinguishedname -eq $User.Properties.manager }
$Manager = "$($Manager.Properties.givenname) $($Manager.Properties.sn)"

$Users is the variable I store the ADSI search results and I was doing a ForEach {$User in $Users} loop, so $User has the employee information in it.  And it worked, kinda.  I definitely got the correct manager information on the Employee Directory.  I also only got 1 employee!  What the?  So I broke the code out to just the searcher part and ran that as a seperate script and took out the $Manager part and it worked fine.  Put the $Manager part back in and only got one employee.  Turns out when I use $Users it somehow transforms the variable to a $null when it’s done, so it works the one time (I called it throwing itself on it’s sword) but then the loop ended because $Users doesn’t mean anything anymore.

OK, this is a bit of a setback.  Luckily, I’m loading all of the data into a custom PSObject instead of creating the HTML straight off of the $Users variable and this was my way out of the problem.  Why do I use a custom PSObject you ask?  It was so I could use the Powershell Select statement with the -unique parameter to find out all of the unique departments and create my button row.  Of course in this custom version it’s actually finding the unique locations instead.  The solution is to just dump the FQDN data for the manager into the PSObject and deal with it later.

So we have a custom PSObject with the information we need in it, but the Manager property still has the FQDN of the employee’s manager in it.  This just means we have to modify the code above to work the the PSObject instead of the $Users variable.  I’m in another ForEach {$User in $Data} loop so $User means the same thing (even though it’s a different loop from the original).

$Manager = $Data | Where { $_.distinguishedName -eq $User.Manager }
$Manager = "$($Manager.'First Name') $($Manager.'Last Name')"
$DetailHTML += "  <TD>$Manager</TD>`n"

$Data is the custom PSObject I’ve been referring to, by the way.  So here we go, query all the users for where the FQDN of the user that matches the FQDN of the manager field for the current employee, $User.  Build a pretty little string and then put it in the $DetailHTML variable.

And that’s it.  We added location, modified the button row and added the employee’s manager into the full printout.  If anyone would rather have this version just email me and I’ll send it to you.

October 25, 2012 - Posted by Martin9700 | PowerShell | adsi, employee directory