PXE Powershell FindAll() ComException

Article
2014-08-05

Question

_{Tuesday, August 5, 2014 2:40 PM}

I have a powershell script that we use during a Microsoft SCCM PXE task sequence for naming a PC. It worked flawlessly until a recent upgrade to SCCM 2012 R2 by the primary server admin.

Now when the code runs search if a user is in a specified AD group needed to complete the PXE build it gives this COM error

Exception calling "FindAll" with "0" argument(s): "Unknown error (0x80005000)"
At X:\Windows\System32\OSD\x86_PXE.ps1:202 char:1
+ $colResults = $objSearcher.FindAll()    # Finds all items that match search and put ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
    + FullyQualifiedErrorId : COMException

I have searched far and wide to try and solve this. It seems like a .Net error but I have been unsuccessful in resolving it.

Below is the relevant code. Note that this is being ran in Windows PE that is included with SCCM 2012 R2 as well as the current Windows ADK. It is most likely going to work just fine on a normal PC as it does on mine.

Things to note, you will need to change to match you environments

- $Domain
- $strFilter - specifically "Memberof=cn=<AD_group>"
- $objOU - server path

function get-humadcreds {
    $global:creds = get-credential -message "Please authenticate to Domain"
    $global:UserName = $creds.username
    $global:encPassword = $creds.password
    $password = [System.Runtime.InteropServices.Marshal]::PtrToStringAuto([System.Runtime.InteropServices.Marshal]::SecureStringToBSTR($encpassword))   # Converts secure string to plain text
    $Domain = #Domain

Add-Type -AssemblyName System.DirectoryServices.AccountManagement
$ct = [System.DirectoryServices.AccountManagement.ContextType]::Domain
$pc = New-Object System.DirectoryServices.AccountManagement.PrincipalContext $ct,$Domain
$authed = $pc.ValidateCredentials($UserName,$Password)

# Recursively requests credentials if authorization fails
if ($authed -eq $false) 
    {
        [System.Reflection.Assembly]::LoadWithPartialName("System.Windows.Forms")
        [System.Windows.Forms.MessageBox]::Show("Authentication failed - please retry!")
        get-humadcreds
    }
}

get-humadcreds # Gets AD credentials from user

###Provisioning Authentication
$strFilter = "(&(objectCategory=user)(SAMACCOUNTNAME=$global:UserName)(|(Memberof=cn=,OU=Delegation,OU=HQ,dc=,dc=,dc=)))"     # Filter for searching
$decodedpassword = [System.Runtime.InteropServices.Marshal]::PtrToStringAuto([System.Runtime.InteropServices.Marshal]::SecureStringToBSTR($encpassword))        # Decoded password from AD Auth
$objOU = New-Object System.DirectoryServices.DirectoryEntry("LDAP://server/OU=HQ,dc=,dc=,dc=",$global:username,$decodedpassword)          # Authentication must specify domain controller
$objDomain = New-Object System.DirectoryServices.DirectoryEntry
$objSearcher = New-Object System.DirectoryServices.DirectorySearcher
$objSearcher.SearchRoot = $objOU        # Starts search in this OU
$objSearcher.PageSize = 1000
$objSearcher.Filter = $strFilter        # Applies filter to search
$objSearcher.SearchScope = "Subtree"
$colProplist = "name"
$isInProvGroup = $False                 # Defaults value to false.
echo $objSearcher >> C:\Windows\System32\OSD\results.txt  
$colResults = $objSearcher.FindAll() # Finds all items that match search and puts them in array $colResults
echo $colResults
foreach ($objResult in $colResults)
    {
        $isInProvGroup=$True                #If user is in D_HQ_AddComputers (if $colResults is not empty), result will be true
            
    
    }
echo $isInProvGroup

PE OS Verson 6.3.9600.16384

All replies (4)

_{Monday, August 11, 2014 9:47 PM ✅Answered | 1 vote}

I found my solution.

Previously in SCCM 2012 prior to R2 the boot image was a Windows 8 PE4 image in which we had to integrated ADSI back into to using a version of it written by Johan Arwidmark. This can be found here for reference.

This time around after the R2 update and subsequently the forced upgrade of the boot images to 8.1 PE5 since no prior boot images would boot from PXE we had to add ADSI back in again this time from here. Previously and this time it was done through the configuration manager under drivers, its added as a driver with its required files and is added as a driver component into the boot.wim but in reality after digging for quite some time I found that it wasn't actually adding the needed dll files into the image even though the operation returned successful.

What I ended up doing was manually mounting the wim file on my PC with DISM, adding the driver from a folder, allowing unsigned ones to be installed. then manually verified the dlls were put into place in <boot.wim_windir>\System32. After I did that I was able to unmount the wim committing changes, replace the boot wim used by the server, distribute content and test it. Which was successful.

Just as a reference, the required files are listed below. In my case they had to come from a Windows 8.1 32bit install. If going for 64bit they have to come from a computer or image with Windows 8.1 64bit

adsldp.dll
adsmsext.dll
adsnt.dll
mscoree.dll
mscorier.dll
mscories.dll

_{Friday, August 8, 2014 10:15 AM | 1 vote}

Hi,

You could have a look on the comments in following blog.

Quote:"Adding $colOfMembersExpanded=@() to the function getMemberExpanded is a requirement. This sets the $colOfMembersExpanded variable to an array, which then correctly adds each user. Without this, each user is still added, but it becomes one long non-delimited string, so when multiple members are found you get the "Exception calling "FindAll" with "0" argument(s):" error under PowerShell v3, but not v2. I traced this error and found that the $uniqueMembers is one long string, so when processed and passed to the getUserAccountAttribs function, the DirectorySearcher was always going to fail. Mendel's change addresses this and is actually something that should be there to set the correct variable type regardless of a v2 or v3 issue."

http://blogs.technet.com/b/askpfeplat/archive/2013/05/01/3564000.aspx

Best Regards,

Joyce

We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time.
Thanks for helping make community forums a great place.

_{Friday, August 8, 2014 3:18 PM}

Thank you for your reply to this.

I have found that this method has successfully casted my search into an array but my find all method is still missing for some reason even though I have my NetFX packages added.

I may just end up building my own method to call.

_{Friday, August 29, 2014 4:14 PM}

Glad you were able to restore functionality to your custom solution, but ADSI in WinPE is not supported by Microsoft.

I looked at this hack and decided against it, because I want to move away from unsupported modifications to WinPE in our production environment.

V/R, Darrick West - Senior Systems Engineer, ConfigMgr: OSD

Share via

PXE Powershell FindAll() ComException

Question

All replies (4)

Additional resources