microsoft.ad.computer fails if computer already exists about microsoft.ad

[BenLangers]

Been able to revisit this. Swapped the deprecated modules out again. The microsoft.ad.computer module works without error if I only use path and name, and leave identity out of it completely. All green again, looking good.

[jborean93]

I cannot replicate this error and we even have integration tests covering this scenario. Do you have a custom path for new computers? The way the module checks if the computer already exists is by combinding the name provided with the default computer path. The following code will produce the DN of the computer object that is checked before it exists.

$GUID_COMPUTERS_CONTAINER_W = 'AA312825768811D1ADED00C04FD8D5CD'
$defaultNamingContext = (Get-ADRootDSE -Properties defaultNamingContext).defaultNamingContext
$defaultPath = Get-ADObject -Identity $defaultNamingContext -Properties wellKnownObjects |
    Select-Object -ExpandProperty wellKnownObjects |
    Where-Object { $_.StartsWith("B:32:$($GUID_COMPUTERS_CONTAINER_W):") } |
    ForEach-Object Substring 38

"CN=Host1,$defaultPath"

If you run that does the computer account exist. If you were to run New-ADComputer manually does it create the computer object in the $defaultPath specified above for you?

Interestingly New-ADComputer seems to be trying to create the object CN=Host1,DC=example,DC=local unless that's just something you've set as an example.

[BenLangers]

If it can help, I have the exact same issue (including the mention of New-ADComputer trying to create a new account. Switched back to community.windows.win_domain_computer with same config except for 'ou' instead of 'path'. Tried microsoft.ad.group with or without identity specified but get the same error when the computer account already exists in AD (either in the actual OU or elsewhere in AD). If there is anything I can look up or supply, let me know?

[jborean93]

At a guess I think it's going to be related to #44 (comment). Essentially the purpose of name used in the microsoft.ad.* modules are not for an accounts sAMAccountName but rather it refers to the cn of the AD object itself. The identity option can be used by the caller to help the module find the account and do operations like a rename or move but due to the current behaviour of path as mentioned in that comment it's less than idal.

If there is anything I can look up or supply, let me know?

I would see what the value is for $defaultPath for you, whether it's the expected default or a custom path set. I would also use New-ADComputer with a dummy account to see where it created the AD computer object and if it's in the $defaultPath from the above path. Finally I would try Get-ADComputer -LDAPFilter '(sAMAccountName=...)' and see if you already have an existing computer account under that name and what path it is under.

[cobbr]

I think I oversimplified my example. In my case, I was doing something strange and incorrect with dns_hostname. Correcting that solved the issue for me. Feel free to close this issue unless @BenLangers wants to take it over.

[BenLangers]

I have tried with 'identity' instead of 'name' after I saw that remark elsewhere, but this fails exactly the same. Had to switch back to the old modules to be able to stay on schedule in my project but will try and test as requested and update.