After a few rounds of email with Quest (Dell) support about our somewhat-successful management history migration, I found out that edsvaDeprovisionStatus and its sister edsvaUnDeprovisionStatus are stored in Change History, not Management History, and therefore are not moved by the Management History Migration Wizard. The helpful support engineer, Jose, suggested I try writing edsvaDeprovisionStatus directly. Since I couldn’t write to edsvaDeprovisionReportXml, I assumed that edsvaDeprovisionStatus and edsvaUnDeprovisionStatus were also unwritable. I was wrong.

If we had done this Management History migration in a more timely manner, I could have used Steps 6 and 9 of Matt Hitchcock’s migration process. If I’d paid a bit more attention to those steps, I might have given fiddling with those attributes manually a try earlier.

Since we ran split for over a year, I would do the following to avoid crushing subsequent changes that were made in 6.7 by simply copying over deprovision status from 6.5:

1) Find objects with dubious deprovisioning status in 6.7 and store them in lists.

Get-QADUser -Disabled -SearchAttributes @{DisplayName="Deprovisioned*";edsvaDeprovisionStatus=''} -IncludedProperties edsvaDeprovisionStatus, edsvaUnDeprovisionStatus, edsvaDeprovisionReportXml -SizeLimit 0 | Where { $_.edsvaDeprovisionReportXml -ne $null } | select name, edsvaDeprovisionStatus, edsvaUnDeprovisionStatus | export-csv C:\Temp\Deprovision-Problems.csv -notypeinformation

A lot of objects were “manually” undeprovisioned – enabled, attributes changed, but edsvaDeprovisionStatus was not changed. For reasons unknown to me, the -Enabled flag does not play nice with -SearchAttributes @{edsvaDeprovisionStatus=1}, and the calculated attribute edsaAccountIsDisabled is not searchable server-side. Icky.

Get-QADUser -SearchAttributes @{edsvaDeprovisionStatus=1} -SizeLimit 0 -IncludedProperties edsvaDeprovisionStatus, edsvaUnDeprovisionStatus, edsaAccountIsDisabled | where {$_.edsaAccountIsDisabled -eq $false} | select name, displayName, edsvaDeprovisionStatus, edsvaUnDeprovisionStatus | Export-Csv -NoTypeInformation -Path U:\Temp\UndeprovisionProblems.csv

2) Using those lists, get their edsvaDeprovisionStatus and edsvaUnDeprovisionStatus from 6.5.
3) Write the edsvaDeprovisionStatus and edsvaUnDeprovisionStatus from 6.5 into 6.7, then try deprovisioning/undeprovisioning my test objects.

… but I won’t. Do I care about all the user objects in iffy deprovision status? Not really. Relatively few deprovisioned user objects are ever undeprovisioned. Every user object, in theory, will eventually be deprovisioned, so those stuck in a weird undeprovision status are also a concern, but out of about 50,000 enabled human user accounts, only about 100 in use are showing up as Deprovisioned.

The following cmdlets have the advantage of not relying on data from ARS 6.5, too.

# In our environment, $UserID is unique

function Undeprovision-ProblemQADUser {
Param($UserID)
	$User = Get-QADUser $UserID -IncludedProperties edsvaDeprovisionStatus, edsvaDeprovisionReportXml
	if ($User.edsvaDeprovisionReportXml -ne $null -and $User.edsvaDeprovisionStatus -eq $null) {
		$User | Set-QADUser -ObjectAttributes @{edsvaDeprovisionStatus=1} | Set-QADUser -ObjectAttributes @{edsvaUnDeprovision=1}
	}
}

# Returns an error on Deprovisioning sometimes, even if it ends up working
# Could be prevented if the Start-Sleep period were longer
function Deprovision-ProblemQADUser {
Param($UserID)
	$User = Get-QADUser $UserID -IncludedProperties edsvaDeprovisionStatus
	if ($User.edsvaDeprovisionStatus -eq 1) {
		$User | Set-QADUser -ObjectAttributes @{edsvaDeprovisionStatus=$null}
		Start-Sleep -Seconds 30
	}
	Deprovision-QADUser $UserID
}

If I just wanted to repair the status of these accounts and not really Deprovision/Undeprovision them, here’s a cmdlet that works in all those changes and does a bit of checking:

function Repair-ProblemDeprovisionStatus {
Param(
	$UserID,
	[ValidateSet("Deprovisioned","Undeprovisioned")]
        [String]$DesiredStatus
	)
# User object has already been "manually undeprovisioned" in ARS 6.7,
# or was undeprovisioned in 6.5 after the initial migration

	if ($DesiredStatus -eq "Undeprovisioned") {
		$User = Get-QADUser $UserID -IncludedProperties edsvaDeprovisionStatus
		if ($User.displayName -notlike "Deprovision*" -and $User.edsvaDeprovisionStatus -eq 1) {
		# Divided because trying to set both of those attributes at once gives inconsistent results
			$User | Set-QADUser -ObjectAttributes @{edsvaUndeprovisionStatus=1}
			$User | Set-QADUser -ObjectAttributes @{edsvaDeprovisionStatus=$null}
		} else {
			Write-Error "Undeprovision user in GUI or set edsvaUndeprovision attribute to 1"
		}
	}

# User object was deprovisioned in ARS 6.5

	if ($DesiredStatus -eq "Deprovisioned") {
		$User = Get-QADUser $UserID -IncludedProperties edsvaDeprovisionStatus, edsvaUndeprovisionStatus, edsaAccountIsDisabled
		if ($User.displayName -like "Deprovision*") {
			if ($User.edsvaDeprovisionStatus -eq $null) {
				$User | Set-QADUser -ObjectAttributes @{edsvaDeprovisionStatus=1}
			}
			if ($User.edsvaUndeprovisionStatus -eq 1) {
				$User | Set-QADUser -ObjectAttributes @{edsvaUnDeprovisionStatus=$null}
			}
# Enabling a user object is easy.
# Dealing with the consequences of an enabled object that shouldn't have been might be trickier
			if ($User.edsaAccountIsDisabled -eq $false) {
				$User | Disable-QADUser
			}
		} else {
			Write-Error "Deprovision user with Deprovision-QADUser or in GUI"
		}
	}
}

I could change the policy on the ARS server to examine displayName, edsvaDeprovisionStatus, edsvaUnDeprovisionStatus and edsvaDeprovisionReportXml and then repair the Deprovision/UnDeprovision status whenever a user object is accessed or if Deprovision/Undo Deprovision is selected. If I go that route, I’ll write about it. But for now, I am happy to have sorted out Undeprovision-ProblemQADUser, Deprovision-ProblemQADUser and Repair-ProblemDeprovisionStatus.

After running two parallel ARS systems for over a year, I can finally get rid of ARS 6.5.