Category Archives: ActiveRoles

Standard

Posted by

Posted on

April 6, 2016

Posted under

ActiveRoles, PowerShell

Comments

1 Comment

ActiveRoles Performance Tip: Use Distinguished Name instead of Canonical Name in OrganizationalUnit Parameters

When making over 100 accounts today for some hard core Skype for Business monitoring, I (re-)discovered that the form of New-QADUser‘s -ParentContainer parameter makes a huge performance difference. I didn’t time it, but noticed that it took about as long to make five accounts using the Canonical Name (mandie.net/Region/State/City/Purpose) as it did to make the rest of the batch using DN, or Distinguished Name (OU=Purpose,OU=City,OU=State,OU=Region,DC=mandie,DC=net).

This was with Quest ActiveRoles Management Shell for AD 1.7, which goes with ARS 6.9. It was an issue back in the QARMS 1.6/ARS 6.8 days, so hopefully Dell has fixed it for recently-released ARS 7.0. I say “hopefully,” because I can’t find QARMS 1.8(?) anywhere in the ARS 7.0 installation download, much less the Release Notes. Anyhow, it is something to do with how ActiveRoles checks your permissions on the Organizational Unit you are attempting to write to.

You might leave the team responsible for ActiveRoles Server at your company, but ActiveRoles Server never really leaves you…

Advertisement
Standard

Posted by

Posted on

June 2, 2014

Posted under

Active Directory, ActiveRoles

Comments

Leave a comment

Get-QADUser -ProxyAddress needs the address type or a wildcard

The wonderful colleague who has succeeded me as the main ActiveRoles Server admin here at Awesome German Auto Parts Manufacturer (awesome.com) ran into trouble last week while trying to find out which user had a proxy address that she was trying to assign. firstname.lastname@awesome.com is not quite as unique as one might think, even in a country with loads of rather long family names, and when a holder of a firstname.lastname@awesome.com leaves, there’s possibly another who would like to have it, and who outsiders are trying to reach at that address.

So my successor cleverly noticed that Get-QADUser has a -ProxyAddress parameter, so tried this on the stubborn address:

Get-QADUser -ProxyAddress "firstname.lastname@awesome.com"

Nothing.

She tried it on her own address, as she was quite sure that one was in there.

Nothing.

Resourceful lady that she is, she started Googling.

Nothing beyond this old Dmitry Sotnikov post: http://dmitrysotnikov.wordpress.com/2010/08/13/manage-email-addresses-without-exchange-cmdlets/

His example shows the address type (in this case, x400) prefix on the searched-for address, but doesn’t state that this is necessary for this parameter to work properly.

Because I’d hit my own wall on Lync emergency calling configuration, I experimentally tried:

Get-QADUser -ProxAddress "smtp:myfirst.mylast@awesome.com"

Result!

Just to check, I tried it without whispering “smtp:“, and…

Nothing.

Continue reading →

Standard

Posted by

Posted on

April 23, 2013

Posted under

ActiveRoles

Comments

Leave a comment

Why would I want to deprovision an Active Directory Group?

Most of my posts are about issues I’ve run into on the job. However, I occasionally look at the search terms that brought people here, and saw the question, “why would I want to deprovision a group?”

Deprovisioning in ActiveRoles Server is mostly focused around user accounts, because those are what most visibly consume resources: mailboxes (Exchange CAL), space on a file server, an ARS license (ARS licensing is completely based on the number of enabled User objects) and are most subject to abuse if there’s no legitimate need for them anymore. You can copy and then modify the sample “Built-in Policy – Default Deprovisioning” that ships with ARS. I recommend that you copy any Built-In Policy and change your copy.

However, groups can also be deprovisioned. Deprovisioning lets you take a group out of action without deleting it. What “out of action” means depends on exactly what groups do in your environment, and what information you need to retain. Do you need to keep the membership list of the group? Do you want to be able to “undeprovision” it, bringing it quickly back into use? Is there any data in the Description or Info (Notes) attributes that other systems use for accounting? Do you need a record of who the secondary owners were? Should a group that granted read privileges on a departmental folder be deprovisioned differently from one that was used to give administrator access to the file server that was at an office that has just been closed?

Deprovisioning policy for groups, just like deprovisioning policy for users, can be configured in both the Policy Object wizard, which is a good idea if it’s a simple attribute change based on a pattern or another attribute in the same object, or a script that you then attach to the Policy Object.

You can configure different deprovisioning policies for different OUs, which you then attach to the container you want to apply them to with Policy Object Links, similar to Access Template Links, except for the lack of a snazzy AD Management Shell cmdlet that will let you do them in bulk, like you can with New-QARSAccessTemplateLink.

If you create your Group Deprovisioning policy actions in a script, you put them in the onPreDeprovision(), onDeprovision() and onPostDeprovision() event handlers. Make sure you put your group-related code inside an if ($Request.class -eq “Group”) {  } black to distinguish it from what you want to do when $Request.class -eq “User”. You should do that object class check even if you have separate Policy Objects for deprovisioning user and deprovisioning groups.

As far as whether something should be in onPreDeprovision(), onDeprovision() or onPostDeprovision(), think about what needs to happen before the group goes offline, what attributes you want to be able to restore, and what needs to happen after everything else is finished.

onPreDeprovision() might do checks to see if it is in the local Administrators group for a specific sensitive server, and this has to happen in onPreDeprovision() if converting the group from a Security Group to a Distribution List is part of your deprovisioning process (Distribution Lists do not have SIDs.)

onPostDeprovision() is for clean-up activity: perhaps dynamically determining who the recipients for the notification email should be.

If it is a property change you wish to revert, however, it should be in the onDeprovision() event handler, because that is what is recorded in the data retrieved by that group’s edsvaDeprovisionRecordXML, which is used if you ever tell ARS to undo the deprovisioning.

Once you’ve got your group deprovisioning the way you want it, you might want to use PowerShell to deprovision them the same way you can deprovision users with Deprovision-QADUser. There’s no native Deprovision-QADGroup cmdlet, but I’ve written one, along with UnDeprovision-QADUser and UnDeprovision-QADGroup: Deprovision and UnDeprovision Users and Groups with PowerShell

Standard

Posted by

Posted on

March 27, 2013

Posted under

ActiveRoles

Comments

Leave a comment

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.

Standard

Posted by

Posted on

March 26, 2013

Posted under

ActiveRoles

Comments

Leave a comment

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!

Standard

Posted by

Posted on

March 18, 2013

Posted under

ActiveRoles, Exchange

Comments

1 Comment

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.

Standard

Posted by

Posted on

March 5, 2013

Posted under

ActiveRoles

Comments

2 Comments

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 →

Standard

Posted by

Posted on

February 12, 2013

Posted under

ActiveRoles, PowerShell

Comments

1 Comment

Deprovision and UnDeprovision Users and Groups with PowerShell

Since I’ve got deprovisioning problems on the brain for some reason, here are a few little things that do work as expected.

Using Quest’s Active Directory Management Shell, connected to ARS (Connect-QADService -Proxy) as a user allowed to deprovision objects, Deprovision-QADUser works like a champ on any user who could be deprovisioned via the ARS MMC or the web interface. However, there is no UnDeprovision-QADUser or UndoDeprovision-QADUser or even Deprovision-QADUser -Undo.

There are also no cmdlets that parallel the Deprovision/Undo Deprovision functions available for groups in the ARS MMC and web interface.

The edsvaDeprovisionType and edsvaUnDeprovision attributes are accessible via the -ObjectSettings parameter of the Set-QADUser and Set-QADGroup cmdlets. So, here’s what I’ve added to my profile to remedy these slight shortcomings of the otherwise amazing QADMS:


# Makes deprovisioning groups by script similar to deprovisioning users.

function Deprovision-QADGroup {
Param($Group)

Get-QADGroup -Identity $Group | Set-QADGroup -ObjectAttributes @{edsvaDeprovisionType=1}

}

# For undeprovisioning groups. Would work the same for undeprovisioning users.

function Undeprovision-QADGroup {
Param($Group)

Get-QADGroup -Identity $Group | Set-QADGroup -ObjectAttributes @{edsvaUnDeprovision=1}

}

# Undeprovision user.

function Undeprovision-QADUser {
Param($User)

Get-QADUser -Identity $User | Set-QADUser -ObjectAttributes @{edsvaUnDeprovision=1}

}

Before you get carried away, remember that what Deprovision-QADGroup actually does is as much up to you or your ARS developer/consultant as the effects of Deprovision-QADUser are; likewise, you have to do a bit of work for what Undo Deprovision does.

Standard

Posted by

Posted on

February 12, 2013

Posted under

ActiveRoles

Comments

2 Comments

ActiveRoles Server Management History Migration Wizard – A Personal Experience

We’re off to see the wizard – the Management History Migration Wizard, that is. As discussed in this previous post, we did not migrate our management history from ARS 6.5 at the same time we started having our admins start managing user accounts with ARS 6.7, and that caused no small amount of annoyance.

Today (Friday) is the day. The test accounts have been created, deprovisioned and in some cases, undeprovisioned. The SQL Server DBA has handed me scripts to back up the ARS databases. I have created Access Template Links so that the admins whose normal write privileges I am suspending this weekend can still unlock accounts and reset passwords. Access Template Links for normal privileges have been disabled. Admins have gotten spammed. Self Service users have seen the bulletin. IIS (w3svc) has been stopped on all the ARS servers.

It is time to do the Management History migration that did not happen earlier, as discussed in a previous post, ……

Quest’s own Knowledge Base gives the vague statement that this could take “in excess of 25 hours”, and I have not found anything more concrete. Therefore, I have allocated 60 hours for ARS to be unavailable.

Our stats:

ARS 6.5 DB: 94 GB, 3.75 million records to import
ARS 6.7 DB: 6 GB
SQL Server 2005, running on Windows Server 2003 (both DBs are in the same instance)

The local backup of the 6.7 DB took less than two minutes; the enormous 6.5 DB took about 20 minutes.

18:32 – And we’re off!

At 21:30, 55% of the first step was finished. At that pace, that part should be over about 00:30.

Saturday:

08:00 – it’s gotten through steps 1-3, and is now 23% through the actual data transfer.
08:05 – 887000
08:10 – 897500 – 10500 record per 5 minutes – 126000 per hour

estimated finish time for data transfer: Sunday, 6:00. Might as well go skiing at this lovely little place in the Bavarian Forest while the Wizard works its magic.

19:00 – Back from skiing; the snow was pretty good, and the Wizard is at 61%. A bit slower than hoped, but still on track for a Sunday morning finish.

Sunday:

10:20 – 81%. Oh, dear – this won’t be done by start of business Monday! My test accounts had their depro history available, but did not offer undo depro. What a disaster. Hmmm…. synthetic undepro using the xml history?
16:00 – 93% (whew), 250000 records to go – might be done around 19:00.
19:37 – DONE, 49 hours after I kicked off the Wizard, and 50 hours after I restricted everyone’s access to ARS and took SQL Server backups. This is exactly twice as long as the “sometimes in excess of 25 hours”, which is the only estimate I could find. So here is a real datapoint: it took 50 hours to import 2 years’ worth of management history for an ARS installation with about 50,000 enabled user accounts and 3.75 million changes.

New ARServer67 DB size: 80 GB. The ARServer65 DB was unchanged.
Just about everything looks to be in order – the deprovision information itself (edsvaDeprovisionReportXML) was brought over and looks right for my test objects, as does the surrounding Change History.

There is still that one fly in the ointment: the edsvaDeprovisionStatus attribute was not changed to 1, and Undo Deprovision is not available in the context menu; Deprovision is. This is disappointing, as this was the main goal of the import (aside from being able to dump the old database and 6.5 server). I’m seriously considering a sort of scripted Undeprovisioning, available for disabled objects with existing edsvaDeprovisionReportXML data.

But before I get into all that, I’ll restart the arssvc on both the 6.7 servers and hope for the best.

21:20 – Doh! No difference.

Monday:
6:00 – Enabled the Access Template Links I disabled Friday at 18:00, restarted w3svc so that the ARS web interface would be available to admins and data owners. Did NOT do the same on ARS 6.5 🙂

So far, no one has reported any funny business, so I’ll count the whole exercise as mostly harmless, even slightly helpful. At least I have the data from 6.5 in the same place as the current stuff.

So now what?

edsvaDeprovisionReportXML contains the changes to the following attributes:

description
displayname
edsaAccountIsDisabled
msExchHideFromAddressLists
altRecipient
showInAddressBook
edsaMailboxSecurityDescriptor

but not

authOrig
manager
homeDirectory
accountExpires

These last four are under the username of the ARS service account; the depro itself takes place under the username of the admin who initiated the depro request.

The four attributes not included in edsvaDeprovisionReportXML are changed a few seconds before the ones in the the Depro Report; they could be picked up by Get-QARSOperation -ChangedBefore [5 minutes after depro request] -changedAfter [5 minutes before depro request]

Could change depro policy to keep the attributes the same if “Deprovisioned” is in the homeDirectory or the DisplayName, then change undepro to truncate the depro+date info.

Any ideas would be GREATLY appreciated!

Link to my discussion on the Quest Communities ActiveRoles Server board: http://communities.quest.com/thread/21170

Standard

Posted by

Posted on

October 9, 2012

Posted under

ActiveRoles, PowerShell

Comments

Leave a comment

$Request vs. $DirObj vs. QADObject, or, The Article I Wish I’d Read Before I Started Messing with ARS Policy Scripts

Quest publishes a guide to ActiveRoles Server script development in the form of a CHM (Microsoft compiled HTML help file), the ActiveRoles Server SDK (Software Development Kit). It comes with the ARS installation package, or you can download it separately from here: http://communities.quest.com/docs/DOC-10017/. Make sure you get the one for your version of ARS, but even if you’re using an earlier version, I recommend also getting the 6.7 one – more PowerShell examples. Even so, get ready to comprehend some VBScript, because that’s what most of the examples are in. It is a reference, not a step-by-step tutorial, and as a newbie to ARS development, I had a hard time getting started with it.

Fortunately, Greg Montoya has distilled the bits about $Request and $DirObj, along with how they stack up to the QAD cmdlets in the article that I insist you read before you do anything to an ARS Policy Script: Working with Data Sets in ARS Policy Scripts – $Request vs. $DirObj vs. QAD Cmdlets

There’s plenty of other wonderful ARS and PowerShell stuff on his site, but this is the article I keep coming back to. Greg explains not only what the intrinsic differences are between $Request, $DirObj and what Get-QADObject (or Get-QADUser or Get-QADGroup or …) each give back to you, but he also discusses performance reasons for choosing one or the other.

“Why won’t it read that attribute? Why isn’t it changing that attribute? I said ‘$Request.edsvaMySpecialAttribute = ($Request.City + $Request.St)‘ – isn’t that clear enough?”

No, it’s not, for several reasons I’ll discuss in my next few posts covering what the beginning ARS scripter needs to know about $Request and $DirObj.