This message was deleted.

I'm thinking its a case of clone > rename > rejoin to the domain (Not sure if sysprep would be required?)

I did this way back for 7.6 . I just DM’d you a doc. Let me know if you got it. I did it from my cell.

Legend!

On the doc ignore the tcp offload stuff as it was for 2012R2 back in the day lol

Roger that, sir 🙂

Cool

Are they domain joined. Youll have issues w the machine password

@John Gallacher I saw your message right when I got out of bed, and needed to wake up a bit. What I sent you originally will work, but this is more detailed below. I’ve done this before, and from what I recall, I had to create a temporary local admin account. The reason I had to make a local admin account was that the original admin account that was built in with the password that we had at the time seemed to get disabled after the sys-prep. Long story behind this, and I’ll never forget it as it gave me PSTD(LOL). It was Christmas Eve at 6 PM, and I got a call that I had 30 users who couldn’t connect to their MCS persistent machines, and from what I found out, the Datastore had gone offline. Basically, the LUN dropped its backing. So, long story short, I lost a golden image and the 30 machines. To make matters even worse, the folks who did the admin side didn’t back the data up. In my mind, I said OKAY, let's spin up a new image and install the software really fast. They explained that the software was installed by a previous person, and it was super complex, and they did not have a clue about what went into the main app that the title agency needed. Basically, they(users) could not close house loans that they promised their customers. Their customer the ones who applied for the house loans, had to have them approved by the 24th of December. I had to think fast and my customer was in a panic mode big time; I used the following to get them out of a pinch. • Create a local Admin account (temporary) • Then, could you clone it in your hypervisor! This also assumes that you have an on-premises hypervisor. You can go into the VM object and detach the Nic. • Snapshot the clone, so if something happens, you can start back at the snapshot. • Power it on and log in with the temporary local admin you created. • Remove the VDA. Reboot and do any cleanup that you need to do on the clone. • Run system prep out-of-the-box experience. • Set the machine back up as if it were a brand-new image out of the box. • If needed, add to the domain (but not needed ideally) • Reinstall the VDA and do any optimizations or whatever task you need to do it, such as removing any Ghost Nics. • Seal it and shut it down. • Depending on how you manually provision. • If you use MCS with thick clones, MCS will handle all the parts for you. • If you’re using the old-fashioned, traditional manual catalog way. You need to manually create the VMs from the clone. Create a Template if you can or have the option to do so. • Either way, spend up the MCS device from the clone, which should register with the DDCs. • Handoff to the customer • Have some beers

Thanks, lads. The issue that is driving this chat is the fact there is no MCS/PVS. Im working with a subset of persistent/manually created VMs/VDAs (Running on VMware). Some of the LOB software installed is no longer available/supported (another issue on its own), We just need them cloned, genralsied and registered with the new site (in the same domain) while we test without affecting production. The problem software/machines will go away but thats a year plus out...

Okay, that makes sense. The above I broke down should work and get you over the hump.

Nice one, cheers 🙂

No worries, I know that feeling at to well 🙂

Shudder

@Ray Davis “I did it from my cell” sounds like you’re working from jail. Hope they’re treating you ok ;)

haha, Funny. I should have said Cell Phone

I just want to say that we don't remove the VDA software when we do clones on our persistent VMs. It's basically: • Clone • Remove clone from Network • Power up clone - login with local admin password (LAPS of old server) • Put clone in workgroup • Fix IP addressing • Give server new name • Shutdown • Enable networking and HyperV replication • Powerup with clone on the network now - Login with local admin • Add server to the domain • Move server object in domain to proper OU to get policies • Reboot to get policies applied We have a custom tool that monitors for computers that are cloned that resets GUIDs on things we have identified as needing new GUIDs, like KACE and WSUS and a couple other things I can't remember off the top of my head. We make clones a lot, and this saves a ton of time and missed steps.

Right on man, good to know.