Of Active Directory, 64-Bit, the dredded -2147221164 error, and type "Object"

[BeyonderLoader]

Good Morning,

Please forgive the title.  I chose that just in case future intrepid souls should find themselves caught in the same infinite loop as me.  You see, for no less than 2 weeks now, because of pride mixed with a determination that I cannot have been the only one to have this problem, I have been mired in this bog of eternal stench.

OK, down to business.  I wrote a script that allows my network people perform some functions easily.  It browses AD, shoots off SMTP emails, and assigns admin rights.  That kind of stuff.  For a few years, this has work flawlessly.  Now enter Windows 7 x64.  Doesn't want to work so much anymore.  I submit the following for your perusal and reading pleasure...

 

Code Clip:

================

        Global    $objConnection = ObjCreate("ADODB.Connection")        ; Create COM object to AD

        $objConnection.ConnectionString = "Provider=ADsDSOObject"

 

What do I get?

================

       COM Error Encountered

       NumberHex = 80040154

       WinDescription = Class not registered

       -2147221164

       Variable must be of type "Object".:
 

 

What have I tried?

================

      - Screaming

      - logging many miles on google and various websites

      - Registering DLLs with both C:WindowsSysWOW64regsvr32 and the other regsvr32

      - Registering random, seemingly related DLLs with both C:WindowsSysWOW64regsvr32 and the other regsvr32

      - Running the script as x86

      - Compiling the script as x86

      - This thing: #AutoIt3Wrapper_UseX64=n

      - Probably something else that I do not remember

 

I am sure that:

================

      - There are DLLs I have missed

      - There is something basic most people know but except me

      - I am dreaming and will wake soon

      - Someone other than me has seen this and has successfully escaped (probably in 5 minutes or less)

      - Humor holds back the tears

Help me AutoIT Forum... You're my only hope, kind of.

Sincerely,

Beyonder Loader

[water]

Maybe something like this?

[water]

How to register missing ADO files is described here.

[BeyonderLoader]

Good Afternoon,

Thank you for your responses, Water!  Unfortunately, neither of those seemed to address the situation.  The error remains.  I don't know what I could be missing.  Obviously, this has to be about registering DLLs in 64-Bit Windows and there seems to be plenty of information out there on this topic but nothing I have seen gets the job done.

The WMI repository is consistent.

Thank you!

-BL

[water]

Could you test your script on another computer?

If it works there maybe a fresh install of your computer solves the problem.

[BeyonderLoader]

Hi,

I have tested the script on no less than 3 different Windows 7 x64 computers all with the same result.  On two of those computers I have done extensive DLL work in terms of registering and trying out different things.  Perhaps this is a novice thought but I find it strange that all of the other programs that interact with AD (AD Users & Computers, DSQuery, DSGet) all work just fine.

The repository from which I derived my code (AD.au3) is a well-written set of tools which functions *perfectly* for me on 32-Bit Windows.  I just cannot figure out what could possibly be so wrong with the configurations of these x64 computers.

I appreciate your help!

-BL

[water]

It looks like the problem is related to ADO.

As there are other ways to access AD this could explain why the other tools you mention work without a problem.

I tested on my W7 64bit computer and everything worked just fine. I tested by running some of the example scripts from the AD UDF.

[BeyonderLoader]

Good Morning,

So I did something... something cheesy, perhaps horrible.  Given I had little control over whatever environmental factors contributed to my problems I had to find a workaround.  As it turns out, I needed several workarounds.

 

Problem #1 – Variable must be of type "Object"

This prevented me from connecting to AD to get data.  However, command line stuff like DSGet worked just fine.  Moreover, PowerShell command line tools worked just fine.  So, and this is exactly the sort of thing I do not like to do, I opened a hidden PowerShell AD Module window and passed commands to it.

$CMDID = Run(@comspec & ' /k C:\Windows\System32\WindowsPowerShellv1.0powershell.exe -noexit -command import-module ActiveDirectory', $FPath, @SW_HIDE)

I hate this because  sending commands is unreliable because user keyboard use could mess this up.  But wait, I uncovered another problem.

 

Problem #2 - WinActivate does not return a handle in 64-bit

Though this scheme worked in 32-Bit, it failed in 64-Bit.  “Send” works but “WinActivate”  does not and I needed this in order to direct the send command to the right window so I had to:

$ADWE = _WinAPI_EnumWindows (FALSE)

$ADWS = _ArraySearch ( $ADWE, "ConsoleWindowClass")

$ADWh = $ADWE[$ADWS][0]

ControlSend($ADWh, '', '', 'Get-ADUser -Filter * -SearchBase "OU=OS,OU=EF,OU=DS,OU=LC,DC=BALT,DC=AA,DC=MO,DC=COM" -Properties StreetAddress, Description, Mail, TelephoneNumber > '& $GPath & @CR)

 

You believe that?  I found that WinActivate does not return  a window handle in 64-Bit.  Believe it or not this works because, with the help of the excellent “AutoIT Window Info” program, I found a window handle.  Because AutoIT Window Info could get a handle, I knew it was possible.  I found that _WinAPI_EnumWindows could get the handle but I needed to browse for an obscure window name to get it (ConsoleWindowClass) – because that made senseL.

Using ControlSend with this handle is a good thing because “BlockInput” does not work in 64-bit either.

So this convoluted thing was necessary to fully close the PowerShell experience.

Local $PSPID = ProcessList ("powershell.exe")

ProcessClose ($PSPID[1][1])

ProcessClose ($CMDID)

But wait you ask, “How in the world did this help you at all, how did you browse the data?”

Oh, my good reader, I did another thing I do not like to do.  I wrote all outputs to temporary text files.  I then read these text files into arrays where I did my searches.  This is not good.

Believe it or not, with all of these kludges, the program actually works quite well in both 32 and 64 bit versions of Win 7.  It is actually pretty fast and I kind of like it.

Don’t get me wrong though, I would like to connect to AD and query it directly but as alternatives go, this seems to work just fine.

 

Thank you for all input and consideration!

-BL

Edited November 24, 2014 by BeyonderLoader

[water]

Maybe I missed it but did you tell us which version of AutoIt you run?

[BeyonderLoader]

Good Afternoon,

I am running version 3.3.12.0

- BL

[water]

That's exactly the same environment I'm running here.

Is there anything special with your WIndows installation (btw. which service pack do you run?).

[BeyonderLoader]

Good Morning,

We use Service Pack 1.  The more I think about this, the more I wonder if they introduced some weird group policy or if the base image is simply corrupt.  I would love to build a fresh x64 machine but this is not allowed in our environment.

- BL

[water]

I once had a problem when a script was run from a non trusted location. After I copied the code to a local drive everything worked again.

[BeyonderLoader]

Hi,

Local or network, compiled or not, run as x86 or x64... same result.

-BL

[water]

What do you get if you run the first script from this site?

[BeyonderLoader]

Hi,

I get this...

- BL

[water]

Doesn't look bad. I nearly get the same result.

I'm soon running out of ideas

[BeyonderLoader]

Hi Water,

I am so sorry; with my cold I am a little foggy.  I ran it on the 32-bit box not the 64-bit.  Here are the relevant results...

Thank you,

BL

 

[water]

Looks good too.

The only difference to my machines is that on your machines there are drivers for Office 2007 and Office 2013.