Powershell - Get bitlocker keys from AD

Today I was aksed to help write a script to get a list of all the computers in our domain and show which ones had their bitlocker keys backed up to AD.

I googled around to find where in AD the information was stored, and proceeded to write this beauty of a script.  Feel free to modify as you see fit and let me know if you found it useful.

# Load AD tools
import-module ActiveDirectory
## Initialize Variables
$searchBase = "ou=Workstations,dc=mycompany,dc=com"
$RecoveryInfoPresent = 0
$MyCount = 0
$MaxCount = 5000
##Inform the user what is about to take place
Write-Host "Searching " $searchBase " for computer accounts with bitlocker keys.........."
Write-Host ""

##Create Table - ResultsTable
$ResultsTable = New-Object system.Data.DataTable "ResultsTable"
$col1 = New-Object system.Data.DataColumn ("HostName", [string])
$col2 = New-Object system.Data.DataColumn ("CanonicalName", [string])
$col3 = New-Object system.Data.DataColumn ("RecoveryPassword", [string])
$ResultsTable.columns.add($col1)
$ResultsTable.columns.add($col2)
$ResultsTable.columns.add($col3)
$computers = Get-ADComputer -Searchbase $searchBase -filter *
foreach ($computer in $computers)
{
    $RecoveryInformation = get-ADObject -ldapfilter "(msFVE-Recoverypassword=*)" -Searchbase $computer.distinguishedname -properties canonicalname,msfve-recoverypassword

 ##Loop through as their may be multiple saved
 foreach ($RecoveryInfo in $RecoveryInformation)
 {
  $output = $ResultsTable.Rows.Add($computer.name, $RecoveryInfo.canonicalname, $RecoveryInfo."msfve-recoverypassword")
  $RecoveryInfoPresent = 1
 }

 if($RecoveryInfoPresent -eq 0)
 {
  $output = $ResultsTable.Rows.Add($computer.name, "", "")
 }
 else
 {
  $RecoveryInfoPresent = 0
 }

 #Loop protection
 $MyCount = $MyCount + 1
 if ($MyCount -ge $MaxCount)
 {
  break
 }
}
##Write txt/csv file
#$ResultsTable | Out-File bitlockerinfo.txt
$ResultsTable | Export-Csv bitlockerinfo.csv -notype

##Inform the user that processing is complete
Write-Host "processing complete"

Going back to WSS 3.0 from MOSS 2007

Back in 2009 I switch departments at the company i work for and was placed in charge of the sharepoint farms.  i had been getting a lot of people complaining about an inability to edit user information within site collections on our WSS farm.  Normally, you would just click a users name in the top right of the screen, click My Settings, and then edit the information about yourself in the text boxes that would appear.  Intead, only the readonly account field was displayed in edit mode.  If I created a new site collection, the issue was not reproducable, but on most existing sites i was able to reproduce.  This cause me to scratch my head and I started googling...  a lot!  Try as i might, i couldnt find anyone else having this issue.

Read on to find out why and how I fixed it.....

Right before I was in charge of our SharePoint farms a coworker of mine decided to attach a WSS 3.0 content database to a MOSS 2007 instance in order to gain some backup capabilities of some third party software.  Problem was, the DB was still attached to WSS 3.0, and the organization never had any interest in using the paid version of SharePoint for that particular farm....  I quickly proceeded to detach the database from the MOSS farm, but the damage was already done and too much time had passed to make restoring from backups a viable option.

Any site collection that was in the database at the time the DB was attatched to MOSS was upgraded to a new schema that affected the user information for each site collection.  Newly created site collections functioned normally, but all the old site collections were broken: meaning that all user information on the site was read only.  This did not go over well with some of our users (some external to our company).

I literally tried everything i could think of to fix the broken sites, including a support case to Microsoft.  It made its way really far up the chain until months into the case the senior engineering staff i worked with gave me two solutions:  live with it, or manually edit the DB each time a user wanted to change a property.  Wow.  Really?  MS has no db scripts to reverse the changes made?

Backing up and restoring the site still left the site in a bad condition.  Attempts at a fresh new farm did nothing to help the cause either, as the site collections were themselves to blame.  I worked this problem for months and the best solution i could come up with was to rebuild the problem sites by hand or just leave them broken.

We have a LOT of site collections, and have lived with this issue on the old sites for years now.  Our solution has been to migrate by hand all the content on the site to a new site (losing all versioning, last modified by, created by, etc data) in order to fix the problem when the userbase of that site complaned loudly enough.



Fast forward a few years, and well last week one of the last few sites (there are only about 26 bad sites left) needed to be upgraded.....  but it was HUGE!  I deceded to try my hand at hacking the backup files to see what i could manually change in order to get the backup/restore to succeed.  I'll spare you the details of everything i tried, but i wasnt able to get that to work either....

Cue the best solution i have come up with thus far:  In all my attempts I tried something i never tried before: export/import.  If i performed a basic export, and a basic import, all the files and site structure moved over, and the user information list worked again, but the metadata on who touched each file didnt persist.  After a bunch more attempts, this is the best i was able to do:

stsadm -o export -url https://site.mycompany.com/sites/brokensitecollection -filename d:\brokenSiteCollection.bak -quiet -versions 4
stsadm -o import -url https://site.mycompany.com/sites/fixedsitecollection -filename d:\brokenSiteCollection.bak -quiet -includeusersecurity -updateversions 2

by exporting with versions and NOT including user security, the brokenness of the site was not carried over.  by importing WITH security the user information of who last edited a file and all ther version information still transfered over.  The only thing missing was the actual permissions to the site, which given how much work i used to have to do, this is not a big deal to finish out by hand.


So, moral of the story:  If you find yourself in this unique situation (I hope you dont), use the export/import command with the switches indicated above to get the site in a proper state again.