xComputer fails while joining deleted machine

[avishnyakov]

If VM was added to the domain, then deleted-recreated-rebuilt, and then we try to use xComputer again, then joining fails with the error "can't join machine to domain cause it already exist"

Here is how to reproduce this issue:

• build VM
• join to DC with xComputer and name "my-dev"
• delete VM
• join to DC with xComputer and name "my-dev" <-- fails here

That could be fixed with the following code-check prior joining to the DC:

$machineName =  "my-dev"
$dcIpAddress = "10.0.0.10"

	# removing maching from the AD
	Write-Output  "`tChecking if VM exists in AD:[$machineName] via DC IP address:[$dcIpAddress]"
	try {
		
		$machine = get-adcomputer $machineName -Server $dcIpAddress -ErrorAction SilentlyContinue
	}
	catch {
		
	}
	
	if($machine -ne $null) {
		Write-Output  "`tRemoving VM from AD:[$machineName]"
		remove-adobject $machine  -Recursive -Server $dcIpAddress -Confirm:$false -ErrorAction SilentlyContinue
	}

In that case, if VM isn't inthe DC and it EXISTS in DC (from previous build), all be good.

[daBONDi]

Got the same Problem, suck when you rebuilding multiple vms in vagrant and rejoin them to the domain.

But the Problem is the Active Directory Utilitys are not Installed on the Client Machine on the Domain join so no "Get-ADComputer..." and so need, need to do it with .net AD Objects

[avishnyakov]

Ahahaha, exactly the same.

I put up that script in vagrant provisioned (ps, chef, whatever you've got) you make it happen.
However, the account (and security) to delete VMs from the AD has to be elevated. Make sure you've for some permissions to do that (in staging / prod) that would be kinda point to solve.

[avishnyakov]

Meaning, xComputer should have additional property to indicate the user who actually HAS permissions to delete computer from AD. Just in case anyone would want to enhance xComputer.

[daBONDi]

I realy hate the nda stuff microsoft put on thix xXxX Modules, realy destroys the mood on contributing :D

[avishnyakov]

What'd you mean? What the NDA stuff you are talking about?

[daBONDi]

For some Maintainer: Same as #55

[daBONDi]

https://github.com/PowerShell/DscResources/blob/master/CONTRIBUTING.md#contribution-license-agreement-cla

[iainbrighton]

There's a contributors agreement that needs to be signed before MS will accept a PR. Effectively you have to agree to MS owning any code you contribute.

[avishnyakov]

And then, potentially, sue you as you used their code somewhere else. Open source is such an open source ^_^

[daBONDi]

Why make it open source then? Thats whyi don't will contribute anything marked with this :-) but i'm not a lawyer, maybe i'm overreacting :-)

Croudsourcing at it best!

[iainbrighton]

That's your choice and I'm not judging. It is an MIT license so you can essentially do whatever you like with your copy/fork of the code. If you do want contribute to MS' copy, you shouldn't submit copyrighted code. That's true of any open source project as far as I'm aware. You can't blame MS for protecting themselves!

[daBONDi]

Shouldn't the MIT License protect them in that case? I'm not a laywer, this case running into a chatroom :-)
Need to investigate the web to get some light on it :-)

[PlagueHO]

@daBONDi , @iainbrighton , @avishnyakov - are any of you planning on submitting a fix for this one or shall I keep it open on the backlog (I'll get to it some day if no one else does)?

[iainbrighton]

@PlagueHO I have no immediate plans on fixing it 😢. However, we should avoid taking a dependency on the ActiveDirectory module and may have to resort to WMI Win32_ComputerSystem 🏃.

[PlagueHO]

@iainbrighton - OK I'll try and get to this one some day 😁 Good point about not depending on AD module!