there are two tabs on the User Property page in AD which I can't get access to from powershell: Session and Remote Control.
I figured out that the settings are kept in the userParameters property but I can’t decode the string it returns:

$k = Get-QADUser -lastname abc
$k.userParameters
P☺CtxCfgPresent????☺CtxCfgFlags1????☺CtxShadow????☺CtxMaxDisco
nnectionTime???☺CtxMaxIdleTime????*☻☺CtxMinEncryptionLevel?

Much less I can think of a way of setting these properties.
Any ideas?

Case in the above point:

 If I get the list of users into an array:
>$u = Get-QADUser

 I can get properties like:
>$u[10].name

But can’t call a method:
>$u[10].DirectoryEntry.PSBase.InvokeGet('EnableRemoteControl')

returns:

The same thing happens in a foreach loop.

Kirk,
great work but the sheer look of it raised the hair on my back and I let my spell checker have its way with Powers Hell…

Andrey’s suggestion looked much easier and I came to the following interpretation of it:

Still not sure if Andrey  meant something else or made a typo.
Either way, I would never solved this without the two of you.

Wow, Kirk I finally got your idea!
I'll try to add this as a function to my profile and call it get-KirkADUser, set-KirkADUser.

Seriously, you should write this up as a real cmdlet and create somecompetition to Quest. Kirk AD cmdlets sounds good!

The only reason I’ve been complaining is that I would neverbe able to come up with this on my own. I’m excited about Powershell because ithides the complexity and inconsistency of AD and many other things in theWindows environment. I’m thinking in terms of Users, OUs, Groups etc. not DirectoryEntry.PSBase.InvokeGet.

Nonetheless, this was fun and I’ll try to learn a littlemore of your craft while making this into a function over the weekend.

George, I'm really glad to hear that you're starting to understand what I was trying to accomplish in the script.  But I still wasn't happy with having to use such a large script every time you wanted to access the extended properties (perfectionism can be a blessing and a curse ), and I wanted to try something that I hadn't tried with PowerShell before, so I decided to take this a little further.  Well am I ever glad that I did!  I am *so* happy with the results of this that I'll be posting about it on my blog very soon.

Attached to this message is a file called QAD.types.ps1xml.  This file contains instructions on how PowerShell should extend objects of type "Quest.ActiveRoles.ArsPowerShellSnapIn.UserAdsiConnection".  This is the type of the objects returned by Get-QADUser.  It is also the type of the user objects returned by Get-QADObject.  The purpose of the extension is basically to make the extended attributes available as native members of the user object whenever they are retrieved from Get-QADUser or Get-QADObject.  This is nicer than creating a Get-KirkADUser function because as long as you have configured your profile appropriately, you can always call the Get-QADUser cmdlet and you'll get the information you want without having to do anything extra at all.  You never have to worry about modifying scripts to call one cmdlet or the other.  Also, this type extension makes the DirectoryEntry member properly return the appropriate object all the time, even when a set of users is returned by the Get-QADUser cmdlet (no more need to call Get-QADUser twice because of that member being null!).

For example, once you have the QAD.types.ps1xml type data loaded into PowerShell, you could simply do this:

[Edit: I originally was using $this instead of $_. This has been corrected]
Get-QADUser | Where-Object { $_.EnableRemoteControl -eq 2 }  | ForEach-Object {
    # Internal processing of users
    $_. EnableRemoteControl = 1
    Write-Host "Remote control for user" $_.Name "was reset to" $_.EnableRemoteControl "." 
}

All you have to do to set up PowerShell to support this is:

1. Download the attached QAD.types.ps1xml file onto your local machine.
2. Add the following line of script to your profile:
    Update-TypeData fullPathToPs1XmlFileYouDownloaded

For example, on my local machine I placed the file in C:\Program Files\Quest Software\ActiveRoles Server\PowerShell, so I needed to add this to my profile:

[Edit: I forgot to append this path with QAD.types.ps1xml in the original post]
Update-TypeData "C:\Program Files\Quest Software\ActiveRoles Server\PowerShell\QAD.types.ps1xml"

That's it!  Once you have the file downloaded and your profile configured to load the type data, your user objects returned from the Get-QADUser and Get-QADObject cmdlets will have the native members you were looking for!  How cool is that?

I should note that I haven't spent a lot of time testing this, but in the tests that I did run it worked perfectly.  Also note that the ps1xml file I have attached to this post isn't signed, so depending on your execution policy you may have issues loading the type data in it.  That aside, I think you'll be really happy with this solution.

Please let me know if you have any problems with this.  I'd like to work them out before posting this on my blog.

-
Kirk Munro
Poshoholic
http://poshoholic.com

P.S. I just loved your suggestion for me to create Kirk AD cmdlets as competition to Quest!  I work for Quest, but not on the PowerShell projects yet although it is something I have been heading towards.  At the time of this writing, I'm on the MessageStats team.  PowerShell has been my obsession outside of the office for most of this year, and it is likely only a matter of time until I make the switch to work with PowerShell full time.