Active Directory UDF - Help & Support (III)

[water]

If it doesn't work, grab the name of an Exchange Server - the physical address if it runs as a cluster - and prepend a "$" sign.
Run the following script:

#include <AD.au3>

_AD_Open()
Global $aObjects = _AD_GetObjectproperties("Your Exchange Server name goes here")
_ArrayDisplay($aobjects)
_AD_Close()
Exit

Grab one of the entries of property "memberof" and run the script from post #359.

[davzell13]

it works on a client server.

to find and modify the FQDN after "_AD_GetGroupMember", the easyest way is the macro @LogonDNSDomain and a variable for my domain name ?

Or they are an other way include in the udf ? 

PS: my fqdn is TEST.LOCAL, but it's different according to the client

 

#include <AD.au3>

; Open Connection to the Active Directory
_AD_Open()
If @error Then Exit MsgBox(16, "Active Directory Example Skript", "Function _AD_Open encountered a problem. @error = " & @error & ", @extended = " & @extended)
Global $aObjects = _AD_GetGroupMembers("CN=Exchange Install Domain Servers,CN=Microsoft Exchange System Objects,DC=TEST,DC=LOCAL")
If @error > 0 Then
    MsgBox(64, "Active Directory Functions - Example 1", "No objects found")
Else
    _ArrayDisplay($aObjects, "Exchange Servers")
EndIf

 

Edited November 9, 2015 by davzell13

[water]

Can you please give an example how the FQDN returned by _AD_GetGroupMembers looks like (please replace any sensitive information) and how it should look like at the end?

[davzell13]

i have just replace the two DC at the end of this line

My FQDN is TEST.LOCAL

_AD_GetGroupMembers("CN=Exchange Install Domain Servers,CN=Microsoft Exchange System Objects,DC=TEST,DC=LOCAL")

[water]

Something like this?

#include <StringConstants.au3>
$sAD_DNSDomain = "DC=Unknown,DC=Org" ; Remove this line in your production script. $sAD_DNSDomain is set by _AD_Open
$sFQDN = "CN=Exchange Install Domain Servers,CN=Microsoft Exchange System Objects,DC=TEST,DC=LOCAL"
$iPos = StringInStr($sFQDN, ",", $STR_NOCASESENSE, -2)
$sResult = StringLeft($sFQDN, $iPos) & $sAD_DNSDomain
ConsoleWrite($sResult & @CRLF)

 

[Lucid]

I realize that this isn't probably the ideal environment for this UDF, but... I'm running into an odd issue when running things within 64-bit Windows PE on a brand new Dell OptiPlex machine with an SSD. For some reason, I get an illegal exception error on this line within the AD UDF in my compiled executable:
$aObjectProperties[$iCount3][1] = __AD_LargeInt2Double($vPropertyValue.LargeInteger.LowPart, $vPropertyValue.LargeInteger.HighPart)

If I slap in a few MsgBox statements, I can see that it seems to blow up when returning from the "__AD_LargeInt2Double" function. I just don't understand why. And it doesn't happen all of the time. Maybe 7 out of 10 times.

Oh, and I've snagged the latest version of the AD UDF and am using the latest (non-beta) versions of Autoit and SciTE. Can anyone shed some light on this and maybe point me in a direction to do more research?

Thanks!

[water]

Did you compile the Autoit script for 32 or 64 bit?

[Lucid]

I compiled as x64.

[water]

Could you test with 32 bit?

[Lucid]

If I compile for x86 and run under 32-bit Windows PE, it works just fine. I have to use 64-bit executables in 64-bit Windows PE (no 32-bit subsystem on the PE version I'm using).

I did some more quick testing, and if I tweak the __AD_LargeInt2Double function to this:

Func __AD_LargeInt2Double($iLow, $iHigh)
    Local $iResultLow, $iResultHigh

    If $iLow < 0 Then
        $iResultLow = 2 ^ 32 + $iLow

    Else
        MsgBox(64, "test", $iLow)
        $iResultLow = $iLow

    EndIf

    If $iHigh < 0 Then
        $iResultHigh = 2 ^ 32 + $iHigh

    Else
        MsgBox(64, "test", $iHigh)
        $iResultHigh = $iHigh

    EndIf

    MsgBox(64, "test", "returning")
    Return $iResultLow + $iResultHigh * 2 ^ 32
EndFunc   ;==>__AD_LargeInt2Double

it spits out "669650608" and "0", and then crashes when it returns to the _AD_GetObjectProperties function - when running as a compiled x64 executable. My grasp of converting integers isn't that great, so not sure if that helps or not. Ideas? Suggestions?

[water]

Do you mean it crashes on the Return statement of function __AD_LargeInt2Double or at line

$aObjectProperties[$iCount3][1] = __AD_LargeInt2Double($vPropertyValue.LargeInteger.LowPart, $vPropertyValue.LargeInteger.HighPart)

in function _AD_GetObjectProperties?

[Lucid]

Hmm good question. Don't know why I didn't tweak the function to test the final math in the first place. Soooo.. In the __AD_LargeInt2Double function I changed the last few lines to this:

....
    EndIf
    MsgBox(64, "test", "test the final math")
    $iValue_Test = $iResultLow + $iResultHigh * 2 ^ 32
    MsgBox(64, "test", "returning")
    Return $iValue_Test

and it causes an illegal instruction error on this line:
$iValue_Test = $iResultLow + $iResultHigh * 2 ^ 32
(my MsgBox about "returning" doesn't display)

So it doesn't like something about that equation. Suggestions?

[water]

Which version of AutoIt do you run?

[Lucid]

I'm running Autoit 3.3.14.2 and SciTE 3.6.0

[Lucid]

While my grasp on higher math and the variety of integers is weak, it seems that my current problem with the __AD_LargeInt2Double function is when the $iHigh value is zero. So would it make sense to add this code snippet to the first part of that function?

If $iHigh = 0 Then
    Return $iLow
EndIf

Would that still return the desired result for the calls made to this function?

[water]

So

Global $iHigh = 0 * 2 ^ 32
ConsoleWrite($iHigh & @CRLF)

crashes on Windows PE instead of displaying "0"?

Edited November 11, 2015 by water

[Lucid]

No, if I compile that code as:

Global $iHigh = 0 * 2 ^ 32
MsgBox(64, "testing", $iHigh)

in a standalone x64 executable, it works just fine in my 64-bit Windows PE environment and spits out "0".

BUT if I edit the __AD_LargeInt2Double function and plop in this bit of code at the top, it blows up:

Local $iResultLow, $iResultHigh

MsgBox(64, "testing", "testing next line...")
Local $iHighTest = 0 * 2 ^ 32
MsgBox(64, "testing", $iHighTest)

And I tried adding that code to another area of my main script (so it wasn't in your "AD.au3" script file) and it blew up there too.

So I'm totally confused now as to what may be going wrong. Any ideas?

[Lucid]

Man, this is driving me nuts... So if I compile the following code as x64, it blows up in my 64-bit Windows PE environment:

#Region ;**** Directives created by AutoIt3Wrapper_GUI ****
#AutoIt3Wrapper_Outfile_x64=Test.exe
#AutoIt3Wrapper_UseX64=y
#EndRegion ;**** Directives created by AutoIt3Wrapper_GUI ****
Global $iHigh = 669650608 * 2 ^ 32
MsgBox(64, "testing", $iHigh)

I basically, snagged the numbers from my main script when it was blowing up and just plopped that number down: $iResultLow + $iResultHigh = 669650608

Any idea what this means? Or how I can maybe get around whatever is causing this?

[water]

I have absolutely no idea what goes wrong. But as your proposal solves the problem I suggest to implement it

If $iHigh = 0 Then
    Return $iLow
EndIf

 

[Lucid]

After doing more tests, it seems that the AD UDF is fine, but there's a bug or something when using Autoit 3.3.14.2 with SciTE 3.6.0 that only shows up in a specific scenarios/machines. I went back and compiled my test code with an older version of Autoit and SciTE and it worked just fine: https://www.autoitscript.com/forum/topic/178622-odd-math-results/

So thanks Water for helping me at least get to the bottom of the weirdness! Guess I'll just stick with compiling with older AutoIt for the time being...