The scripting options have gotten better over time, and with IIS7 they got much better yet. You're right it's sure nice for IIS7, but that puts IIS6 behind.
In IIS6, you can use WMI through Powershell, or else you can script using WMI or ADSI over WSH.
I would start here, here and here.
According to the Microsoft support engineer I spoke with... and the Microsoft engineer he escalated me to... and their manager, the short answer is that the only way to rid myself of this cursed object is to do an authoritative restore to before this object's appearance in the LostAndFound
container. I'm convinced I could also rid myself of it by booting all the domain controllers to LiveCDs and manually editing the AD database, but short of those two non-options, I'm stuck with it.
As to how and why this is the case:
We ran a repadmin /showobjmeta
against the object (to peek into its metadata) and were able to determine from the object's isDeleted
version (2
) that it was deleted, then unexpectedly and unsuccessfully/partially restored, which is what is causing the problem. It was suggested, and seems likely to me, that after the object was restored, but before the change had completely replicated, it was deleted again, along with its parent OU, causing the restore to fail, and resulting in it being considered an orphaned object by at least some of our domain controllers, landing it in the LostAndFound
container.
As a result of the partial restore, it cannot be restored. As a result of the object's SAMAccountType
being empty, it cannot be deleted (or modified).
The SAMAccountType
attribute is a value that cannot be changed by any user, and attempting to do so throws the below error:
Operation failed. Error code: 0x209a
Access to the attribute is not permitted because the attribute is owned by the Security Accounts Manager (SAM).
0000209A: SvcErr: DSID-031A1021, problem 5003
(WILL_NOT_PERFORM), data 0
We can't restore the object to get the system (Security Accounts Manager) to set this attribute because of the partially-restored state it's in, and we can't delete it (or modify it) without a valid value for that attribute.
However, since this is too interesting of a case for me to simply walk away from, I'm going to poke around for a while and see if I can't come up with a way around this, or at least expand my knowledge of AD a little bit more in the attempt. Beats troubleshooting printers... and frankly, it turns out that a computer telling me "WILL_NOT_PERFORM" is a challenge I cannot resist.
Oh yes you will perform, dammit!
Best Answer
Let's see:
Get-ChildItem iis:\sites | get-Member | Where name -like p* | Sort-Object Name
Get-IISSite | get-Member
it doesn't have any members starting with P and has far fewer members than Get-ChildItem. You can see they are not the same object either.
When using Get-ChildItem, each provider provides some hints on what should be displayed. I think this is in:
$pshome\Modules\WebAdministration\iisprovider.format.ps1xml
because of this, all the extra information is added.