Self-Service User Can’t Add Member to Group, or Error (0x800403fb) Unknown to Anyone

The first thing you should do when you get a weird error code is plug it into your favorite search engine or, with ARS, the ActiveRoles Knowledge Base. This time, there was nothing even vaguely related to ActiveRoles Server when I tried searching for 0x800403fb, so here’s something for the next person who runs into this: the group in question has a member that ActiveRoles Server cannot directly access, and that is likely what is causing your user to have problems maintaining that group.

A Secondary Owner was getting a weird error when he tried adding a new user to one of his groups via the ActiveRoles Server Self-Service web interface. A tech at the Help Desk was getting it, too, so it got referred to me. I took a look at the group in the MMC, and it stopped listing users when it got to 1150 of them. We have some groups with over 5,000 users (I do NOT recommend this), so too many users could not have been the problem. I tried

Get-QADGroupMember ProblemGroupName -SizeLimit 0

and got after about the 1150th result:

Get-QADGroupMember : Unknown error (0x800403fb)
At line:1 char:19
+ Get-QADGroupMember <<<< ProblemGroupName -SizeLimit 0
+ CategoryInfo : NotSpecified: (:) [Get-QADGroupMember], COMException
+ FullyQualifiedErrorId : System.Runtime.InteropServices.COMException,Quest.ActiveRoles.ArsPowerShellSnapIn.Powershel
l.Cmdlets.GetGroupMemberCmdlet

So, time to look at the members list as plain strings:

$group = Get-QADGroup ProblemGroupName

$group.members
(listed a whole bunch of distinguished names without complaint)

$group.members.count

1165

Ok, so a few more than were being displayed in the GUI.

I skimmed the list until this jumped out:

CN={17656956-4661-41ad-b4dd-0a1d4ff4fccf},CN=Application Contacts,CN=RTC Service,CN=Services,CN=Configuration,DC=root,DC=hld

root.hld is our infrastructure domain, and regular users should not have anything to do with it.

RTC Service is put in the Configuration container when you first install Lync Server, and the creation date of this object aligned pretty well with when we started our Lync deployment.

So, I removed the offending object from the group:

Remove-QADGroupMember -Member 'CN={17656956-4661-41ad-b4dd-0a1d4ff4fccf},CN=Application Contacts,CN=RTC Service,CN=Services,CN=Configuration,DC=root,DC=hld' -Identity ProblemGroupName

And when I redid Get-QADGroupMember ProblemGroupName … no problem 🙂

To make sure the problem object was no longer a group member:

(Get-QADGroup ProblemGroupName).members.count

1164

The help desk tech who referred the problem to me was able to add and remove users without issues, and will be calling the user to close the ticket.

How to Change the Attributes Get-QADUser Returns

Get-QADUser | where {$_.edsaAccountIsDisabled -eq $false} will usually result in disappointment. Why? edsaAccountIsDisabled is a calculated ActiveRoles Server attribute derived from userAccountControl and is not part of the default return set, along with most of the other AD and ARS attributes.

FatBeard wrote a great explanation of this a few years ago in his article, “Where’s my attribute?” He then shows you how to add a single attribute to the default return set. FatBeard’s blog is full of all sorts of PowerShell goodness; unfortunately, he’s not updated it in quite awhile. Go there and tell him to write more posts 🙂

If you want to add more than one attribute, here’s how:


# please note that employeeNumber and homeMDB
# might not be present in your environment.
# edsaAccountIsDisabled is ARS-only.

$attributes = Get-QADPSSnapinSettings -DefaultOutputPropertiesForUserObject
$attributes += @("edsaAccountIsDisabled","employeeNumber","homeMDB","homeDirectory","homeDrive","msRTCSIP-PrimaryUserAddress")
Set-QADPSSnapinSettings -DefaultOutputPropertiesForUserObject $attributes

As FatBeard mentions, this change will only be in effect for the rest of your current session, and if this is an attribute set you want to usually have around, you need to add those limes to your PowerShell profile, after Get-PSSnapIn quest.activeroles.admanagement.

So why not add a whole ton of attributes to the default return set, just so they’re handy? Each attribute you want to pull increases the amount of time it takes AD or ARS to return your results and increases the size of the result set.

Another caveat: once you change the default return set within a session, you cannot go back to the original default return set without opening up a new PowerShell session – unless you saved the “default” default return set before changing it.

Idea: have several return sets available in your profile, oriented around various tasks. For mail, pull more of the Exchange attributes, both msExch-* and edsva-MsExch*. For Lync, the msrtcsip-* attributes. For tracking down a Deprovision/Undeprovision issue, the edsvadepro* and edsvaundepro* sets.

Because I don’t like having to restart PowerGUI in the middle of things, here are the Set-QADPSSnapInSettings related lines from my PowerShell profile:


# Making sure the PSSnapIn for QADMS is loaded

if ( (Get-PSSnapin -Name quest.activeroles.admanagement -ErrorAction SilentlyContinue) -eq $null )
{
    Add-PsSnapin quest.activeroles.admanagement
}

# Connect to ARS; if connecting to native AD domain,
# Connect-QADService -Service my.domain.com

Connect-QADService -Proxy

$defaultQADuserattributes = Get-QADPSSnapInSettings -DefaultOutputPropertiesForUserObject

#Extra attributes I ALWAYS want to load -
#please note that employeeNumber and homeMDB
# might not be present in your environment.
# edsaAccountIsDisabled is ARS-only.
$defaultQADuserattributes += @("edsaAccountIsDisabled","employeeNumber","homeMDB","homeDirectory","homeDrive")
Set-QADPSSnapinSettings -DefaultOutputPropertiesForUserObject $defaultQADuserattributes

# edsva = ARS-only
function Use-QADExchangeUserAttributes {
$attributes = Get-QADPSSnapinSettings -DefaultOutputPropertiesForUserObject
$attributes += @("edsva-msexch-mailboxtypedescription","edsva-msexch-mailboxtypedescription","edsva-msexch-protocolsettings-activesync-enable")
Set-QADPSSnapinSettings -DefaultOutputPropertiesForUserObject $attributes
}

function Use-QADLyncUserAttributes {
$attributes = Get-QADPSSnapinSettings -DefaultOutputPropertiesForUserObject
$attributes += @("msrtcsip-line","msrtcsip-internetaccessenabled","msrtcsip-federationenabled","msRTCSIP-UserPolicy")
Set-QADPSSnapinSettings -DefaultOutputPropertiesForUserObject $attributes
}

# ARS-only
function Use-QADDeprovisionUserAttributes {
$attributes = Get-QADPSSnapinSettings -DefaultOutputPropertiesForUserObject
$attributes += @("edsvaDeprovisionCommands","edsvaDeprovisionDeletionDate","edsvaDeprovisionReportXML","edsvaDeprovisionStatus","edsvaUnDeprovisionCommand","edsvaUnDeprovisionReportXML","edsvaUnDeprovisionStatus")
Set-QADPSSnapinSettings -DefaultOutputPropertiesForUserObject $attributes
}

function Use-QADDefaultUserAttributes {
Set-QADPSSnapInSettings -DefaultOutputPropertiesForUserObject $defaultQADuserattributes
}

Note that if I do Use-QADExchangeUserAttributes and then Use-QADLyncUserAttributes without a Use-QADDefaultUserAttributes in between, I’ll get both extra sets of attributes added to the return set.

Have a nice attribute set you’d like to share? Done something clever for working with groups? Post it, or a link to your blog, in the comments!

Set-CalendarProcessing -ResourceDelegates (and Friends) Without Tears

(Get-CalendarProcessing -Identity “MyAwesomeRoom”).ResourceDelegates is equal to (Get-Mailbox -Identity “MyAwesomeRoom”).GrantSendOnBehalfTo. This is good to know, because while you can do Set-Mailbox -GrantSendOnBehalfTo @{add=”user3@awesome.com”} and not kick out user1 and user2, Set-CalendarProcessing does not do this. If you try it, you get back this mess:

Cannot process argument transformation on parameter ‘ResourceDelegates’. Cannot convert the “System.Collections.Hashtable”
value of type “System.Collections.Hashtable” to type “Microsoft.Exchange.Configuration.Tasks.RecipientIdParameter[]”.

Unfortunately, I have yet to find a similar, more friendly route for adding BookInPolicy, RequestInPolicy or RequestOutOfPolicy.

All of these parameters will take an array, so you need to read in what’s there, append your new delegate(s), then write the new list to Set-CalendarProcessing:

function Add-CalendarResourceDelegate {
Param(
$roomName
, $newDelegate
)
$resourceDelegates = (Get-CalendarProcessing -Identity $roomName).ResourceDelegates
$resourceDelegates += $newDelegate
Set-CalendarProcessing -Identity $roomName -ResourceDelegates $resourceDelegates
}
function Add-CalendarBookInPolicy {
Param(
$roomName
, $newDelegate
)
$bookInPolicy = (Get-CalendarProcessing -Identity $roomName).BookInPolicy
$bookInPolicy += $newDelegate
Set-CalendarProcessing -Identity $roomName -BookInPolicy $bookInPolicy
}

Add-CalendarResourceDelegate -roomName “MyAwesomeRoom” -newDelegate user3

Removing delegates is a bit trickier; they are stored in the array as canonical names (awesome.com/Site1/Users/user1), not email or UserPrincipalName (User.One@awesome.com or user1@awesome.com). However, you just need to do (Get-Mailbox user1).Identity to get this.

function Remove-CalendarResourceDelegate {
Param(
$roomName
, $delegateToRemove
)
$resourceDelegates = (Get-CalendarProcessing -Identity $roomName).ResourceDelegates
$delegateToRemoveIdentity = (Get-Mailbox $delegateToRemove).Identity
$resourceDelegates.Remove($delegateToRemoveIdentity)
Set-CalendarProcessing -Identity $roomName -ResourceDelegates $resourceDelegates
}

And so on for BookInPolicy, RequestInPolicy and RequestOutOfPolicy.

A step closer to extending ActiveRoles Server to handle all the Set-CalendarProcessing attributes…

The publicDelegates AD Attribute: Change GrantSendOnBehalfTo the ARS Way

While the Active Directory object’s publicDelegates attribute matched the contents of (Get-Mailbox “aliasGoesHere”).GrantSendOnBehalfTo for all the resource mailboxes and distribution groups I checked, I hesitated to give the way of modifying publicDelegates directly with ARS instead of using Set-Mailbox -GrantSendOnBehalfTo with Exchange Management Shell in my previous post on this topic. A little more research (and trial and error) shows that indeed, publicDelegates really is what Exchange uses to decide who gets to send stuff on behalf of another mailbox.

Here is a thread from the [ActiveDir] listserv archive in which Joe Richards, an author of the classic O’Reilly Active Directory reference, states that “[t]he stuff in AD is strictly how Send On Behalf is controlled” and goes on to explain how an update bug in Exchange 2003 might prevent a recent change from being propogated to a user in a different domain from the delegated object. Since the conversation took place before Exchange 2007 was on the scene, I was a bit skeptical about its applicability to Exchange 2010.

To see which one of several dozen edsva-MsExch-blahblahblah attributes does this for the ARS connector to Exchange 2010, I used the ARS web interface to add and remove delegates from the “Send on Behalf” list of one of the test room mailboxes (Exchange Properties -> Delivery Options -> (Send on behalf) “Add”), then looked at the Change History for that room mailbox. The publicDelegates attribute was the only item changed. Still, I was concerned: the publicDelegatesBL for the delegates outside the domain of the room mailbox weren’t getting updated.

For comparison, I added some delegates the Exchange way:

Set-Mailbox “Room Name” -GrandSendOnBehalfTo @{add=”username”}

Then the Quest AD Management Shell way:

Set-QADUser -ObjectAttributes @{publicDelegates=@{append=(Get-QADUser username).DN}}

(trying to append the username directly didn’t work; it wants the distinguishedName)

After some more experimentation, I discovered that when a user in an different domain is added to the publicDelegates attribute, the delegated object will not show up in the user’s publicDelegatesBL, whether you use Exchange, Quest AD Management Shell or the ARS web interface, while the change to publicDelegatesBL occurs immediately for delegates within the domain of the delegated object. Cross-domain delegated objects will only show up in a user’s publicDelegatesBL once that user has connected to the object for the first time.

If anyone knows why this is, what trouble it might cause, or better yet, how to fix it, please post a comment. More importantly, if anyone knows of a reason NOT to use publicDelegates instead of GrandSendOnBehalfTo, please let me know. And let the ActiveRoles Server dev team know 🙂

Fun fact about the CalendarProcessing ResourceDelegates attribute: it is equal to a resource mailbox’s GrantSendOnBehalfTo, which is controlled by the AD attribute publicDelegates.

Next step: figuring out how to control the other CalendarProcessing attributes via ARS.

Goal: Complete management of resource mailboxes via ARS.

Post-Migration Deprovision and UnDeprovision Inconsistencies – Solved!

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.

Continue reading