Active Directory UDF - Help & Support (II)

[Speleologist]

Thanks for the update and for all your efforts. I'll try it on a newly built test machine. if it still doesn't work I'll go through with our AD guys and see if there's anything on our environment that could be causing it.

[water]

I had to modify the hosts file so the PC in the workgroup was able to find DNS and AD (both running on the same Resara server).

[Speleologist]

Here we should have DNS and AD from DHCP. No problem finding them when using System Properties to join the domain, but I'll add that to my list of tests. I may not get a test done until next week as we have a major IDM test lab to build tonight!

[water]

I have 30 days left to test before Windows XP expires, so no need to hurry.

[Speleologist]

Line 3606 is

Local $oAD_Computer = ObjGet("winmgmts:{impersonationLevel=Impersonate}!\\" & $sAD_Computer & "\root\cimv2:Win32_ComputerSystem.Name='" & $sAD_Computer & "'")

I don't understand why you get a "permission denied" with this.

I can see why this is, and it is not relevant. It is the error I get if I am running from my own workstation, and trying to join a remote workstation. Because $sAD_Computer is not in the domain, the $ADUserParam account has no rights to it. I think that is why my _AD_CreateComputer succeeds from my own workstation, but then the _AD_JoinDomain fails. The only solution I can see in this scenario is to be able to specify different credentials for the Active Directory and for the Workstation. But that's an aside, as it's not directly relevant to the problem I am trying to solve, where the script will be running on the workstation that is joining the domain.

Just one thought, when it worked on your test, did your XP workstation have a local account with the same name and password as the domain account. That's one of the things I'm going to try now.

[water]

Just one thought, when it worked on your test, did your XP workstation have a local account with the same name and password as the domain account. That's one of the things I'm going to try now.

Correct. The user to log on to the workgroup and the domain are the same with the same password. But for _AD_Open and the parameters to _AD_JoinDomain I used another domain user which is domain admin.

[Speleologist]

Hi Water,

Embarrassingly I've found that there was an underlying problem of a typing error in the variable for the domain. I've corrected this and it's now near to working. Apologies if my mistake has led to extra work. I did, however, need your modifications above as well.

Running it on the local machine, the login is fine, the computer account is created and the join domain no longer throws a COM error. However it does throw error 5 with @extended set to 1355, which is ERROR_NO_SUCH_DOMAIN. it seems a bit odd when the same credentials have just created a computer in the domain! I will be looking at this next week and hopefully will be able to solve it. I'll let you know how I get on.

Thanks for a really useful UDF and for all your help.

[water]

If you have a look at function _AD_JoinDomain you will see that it uses a different provider: WinNT.

I'm no specialist in this area, so I'm not sure I'm doing it the best possible way but as soon as I added 3 lines to the hosts file the problem went away. The DNS and AD server are at 10.0.0.3. Domain name is home.

10.0.0.3 Resara.home.lan

10.0.0.3 home.lan

10.0.0.3 lan

[Speleologist]

I'll give that a try in the morning.My test PC is currently reimaging to give me a clean platform as it's been messed around a bit.

[water]

A few people had problems in the past joining/unjoining a computer using this UDF. Our discussion will be useful is a reference for future users. Where necessary I will modify the UDF and enhance the wiki.

Thanks for being patient and helping to improve the UDF!

[Speleologist]

Hi Water,

I've just run a quick test on a cleanly built machine. I get the same error. I shan't have a chance to look t it in detail until Monday, but I'll keep you posted with what I find.

[water]

Thanks for the info.

[ParrotMan]

I'm trying to find a way this UDF would allow me to modify the "Log On To" under the Accounts tab so that I can modify a user's attributes so that they can login to a list of computers I specify. See the picture attached. I would like to script it and add many computers to the list or clear the list if necessary

[water]

Looks like you need to modify property "LogonWorkstations".

Set multiple workstations for a user using ADUC, then retrieve the property using _AD_ObjectAttribute to get the stored format.

[ScriptingNewbie]

I am trying to use AutoIt to edit the thumbnailPhoto attribute on a users account. However I think I need to make the image into a byte array, but I am not sure.

Can anyone help?

#include <AD.au3>
_AD_Open()
_AD_ModifyAttribute("test.account","thumbnailPhoto","D:\testaccount.JPG")
_AD_Close()

[water]

and the following posts show how to do it.

[CrazyCarlton]

Hi,

i have some Problems on different OS' in same Domain:

on WinXP / 2003 everything is fine, but on Win7 (Same Domain, same script) im getting @extendet error -2147023541 when trying to _AD_Open()

Do i have to give any other options for _AD_Open()?

[water]

If you call _AD_ErrorNotify(2) at the top of your script what do you get then?

[water]

-2147023541 (decimal) is 0x8007054B (hex).

Searching Google I found the following:

Problems occur when the Autoenrollment feature cannot reach an Active Directory domain controller

[CrazyCarlton]

Im getting

COM Error Encountered in CreatePW.exe

AD UDF version = 1.3.0

@AutoItVersion = 3.3.8.1

@AutoItX64 = 0

@Compiled = 1

@OSArch = X86

@OSVersion = WIN_7

Scriptline = -1

NumberHex = 80070035

Number = -2147024843

WinDescription = Der Netzwerkpfad wurde nicht gefunden.

Description =

Source =

HelpFile =

HelpContext = 6881350

LastDllError = 0