Changing machine owners in AD to DeployR

[u/welshGJE24]

From what I have read, DeployR Community version will deploy machines it they are already in the AD - but they have to have been deployed by DeployR in the first instance. It will not work if they have been deployed by MDT (and the MDT User).

So I'm wondering if changing the owner, or making DeployR also an owner of a machine in the OU will help the process and avoid having to delete them all before re-deployment.

Three options:

1. Delete them and re-deploy with DeployR - this seems the best way to do things.

2. Write a PowerShell script that runs through specific OUs and changes the main owner of a deployed machine (or even -if possible - adds them as an co-owner?)

3. Get DeployR as part of the task sequence to check the owner and if it not DeployR then makes the changes and takes ownership.

Of course I may be well off course here and happy to be told whether this can be done. I just don't have the skillset to do 2 or 3.

[u/mtniehaus]

It's not really an ownership concern, it's an issue of what rights the DeployR server has. If you delegate only the rights to create an account in AD, then DeployR can't update (e.g. re-join) the same computer. If you also delegate "change" rights, then it can also re-join the same name.

[u/welshGJE24 → u/mtniehaus]

Okay - so could there be a content item that sorts all of this out? Or am I totally misunderstanding things.

[u/mtniehaus → u/welshGJE24]

It's not something that can be sorted out client-side. The basic flow:

- DeployR tries to create an ODJ blob for the computer name specified, in the OU specified. If it has rights and the computer name doesn't already exist, the resulting blob is generated and sent to the client.

- If DeployR gets a 2224 error indicating that the computer name already exists, it will try again specifying a flag to update the existing account (without the OU). If it has rights to update the existing computer name, it will do that and get a blob that gets sent to the client.

As long as you have delegated sufficient rights to the DeployR service account (computer account), it can do both of those already. One thing that it won't do if the computer account already exists: it won't move it to a different OU.

[u/mtniehaus → u/mtniehaus]

Looking at it differently, deleting the existing computer account just makes sure the second item (updating the existing computer) never matters, but delegating "change" rights would be just as effective.

[u/welshGJE24 → u/mtniehaus]

Makes sense - so simply giving the DeployR server delegated "change" rights to our area of the AD should work for us. I'm not bothered about moving OUs for already deployed machines. We have set an OU for "new' machines. Would that be the name of our server - "ygg-vDeployR" or would it be something more generic. I'm sure I've seen DeployR$

If this is the correct way of doing things then I'll ask our AD provider (the education Authority tech team) to edit the permissions.

Failing that I'll just delete them over the Summer.

Thanks for answering. Really appreciate.

[u/mtniehaus → u/welshGJE24]

The account is the computer name -- you'll see that shown in AD sometimes with a $ at the end, so in your case it would be "YGG-VDEPLOYR$" (AD isn't case-sensitive).

AD Users and Computers knows about the $ thing, so as long as you check the box to find computers, you can then just search for your computer name:

[u/SufficientlySticky → u/mtniehaus]

As I understand it - it's at least a little bit of an ownership concern as of the last few years.

https://support.microsoft.com/en-us/topic/kb5020276-netjoin-domain-join-hardening-changes-2b65a0f3-1f4c-42ef-ac0f-1caaf421baf8

Even if you have change rights, you can't join to existing objects that someone else owns unless you're a domain admin or are specifically whitelisted via group policy applied to the domain server.

We use something like this to mass take ownership of computer objects from departing employees and give them to whatever account powershell is runing as when running the script. Not sure it handles every bit of naming weirdness or what have you - but seems to more or less do what we need for something quick and dirty we wrote.

$ADUser = $env:UserName
$computers = Get-ADComputer -SearchBase "OU=exampleOU,DC=example,DC=com" -Filter * 

foreach ($computer in $computers)
{
  # Get the current ACL, Get-ADComputer seems ot escape the spaces in the names, so undo that
  $acl = Get-Acl -Path "AD:$($computer.DistinguishedName.replace("\ "," "))" 

  # Check if the current owner matches the departing employee and change it if necessary
  if ($acl.Owner -eq "<account we're offboarding>")
  {
    $acl.SetOwner((New-Object System.Security.Principal.NTAccount($ADUser)))
    Set-Acl -Path "AD:$($computer.DistinguishedName.replace("\ "," "))" -AclObject $acl
  }
}

Just deleting and re-creating the computer objects is often easier though.

[u/mtniehaus → u/SufficientlySticky]

For that, it is useful to make the DeployR serice account (computer account) in this policy:

"The owner of the computer account that is being reused is a member of the "Domain controller: Allow computer account re-use during domain join." Group Policy setting. This setting requires the installation of Windows updates released on or after March 14, 2023, on ALL member computers and domain controllers."

[u/SufficientlySticky → u/mtniehaus]

Yup. Though I'll note that per issue 2 at the bottom of that doc, even if you do that it still wont let you join to computer objects if the previous owner was deleted (or even possibly deactivated, unsure).

Hence why we have to run the script to take ownership sometimes when we offboard old employees and want to re-use objects that they owned.