Name Conflict Detection and Resolution During Rename/AD Join

We tend to use the $ClientSlug-#### naming format for computer names. It allows the user to memorize a simple 2-4 digit number to identify their computer, and for us to remember the computer for the same reason.

Currently we use a CWA script that does a simple index counter with no safety checks at all, but generally it works. With Immy.Bot, I noticed an issue, it goes to the next highest number, which is smart, but during testing I had a TEST-0001 computer, which I let Immy domain join. Then I wiped it and removed the computer from Immy and ran it again, which resulted in a domain join error because the name was taken. I reran onboarding with a manually set name and it was fine, but against the spirit of automation. So I think whatever system that picks the name, that is smart enough to read the Immy.Bot list of computers, should also scan the client’s domain controller too.

What you’re missing here is that there is an option on the deployment to overwrite the chosen computer account in the domain.

If you have all of your windows endpoints in Immy, either via Immy Agent or another integration, you won’t ever have a conflict and can safely overwrite the existing domain accounts. Additionally, there is no guarantee that in everyone’s environment that certain machines are to be on-prem domain joined–many of our client’s laptops and such are either standalone, or azure joined.

You are right, I did miss that when I first ran it. I still think it would be powerful. You are right though, if all PCs are in Immy, the overriding isn’t much of a risk.