In this scenario, our team will be migrating users, ~50 at a time, from one child domain to another within the same forest. The View implementation is in the destination domain and is 4.0.1 on vSphere 4 Update 1. We are currently using a persistent desktop pool, which will be changed down the road once all migrations are complete to non-persistent.
We are using a user data disk, and this is where I'm asking for suggestions/ideas.
What is the best practice for re-mapping these users' data disks to their new desktops?
The scenario I see playing out is that we will increase the pool by x number of desktops. X being the number of users we are going to migrate. When the users login, then out, we will need to re-map their pre-existing data disks to their new desktops, then delete their old desktops tied to their old domain accounts.
Since overall, there are several hundred migrations, obviously scripting would be preferred, but all ideas are welcome.
If you can wait until the next version of View gets out then do that, it will be signifcantly more easy to do this then.
(Can't comment on any releasedate at this time)
If you find this information useful, please award points for "correct" or "helpful".
Thanks for your response. I'm not exactly sure what feature in 4.5 your referencing. We are in the beta program, and IMHO, it will be sometime before it is GA, and that's longer than we can wait.
That in mind, what would be the best approach in 4.0.1?
It's a simple process to reassign the existing VM to the new user account (vdmadmin -L -d desktop-name -m machine-name -r/-u username on the broker) but as far as I know salvaging the existing user profile into a new AD account isn't doable in Windows. I'm pretty sure that the user SID is used for the ownership/reference for a lot of stuff in the registry and moving the account into a different domain will by definition require a new SID.
We allow SID history on migrations, so as long as we have the correct user disk attached to the new account's VM, they should get their profile data.
I'm just trying to find an alternative to users having to login/logout once, then us run a script that will have to be touched hundreds of times to update the user and machine names. Finally, have the users login again and verify their profile integrity....
Would the users have to login for this...since the user data disks are tied to the VM, it doesn't seem so....
Doesn't seem to be any alternative to the above flow....will the commands you mention take a CSV file for arguements?
If the existing user profile will automatically be reused (I didn't think that was possible, good to know) then it sounds like you just have to handle the user assignment in the pool. Sounds like the users won't have to do an additional login for this to take effect, though you'll need to make sure they're not logged in while you change the assignment as an active session for the "old" user will block the new one from logging in through View. vdmadmin won't take a csv file as input so you'd have to run it for each (un)assignmnet, manually finding each user assignment might be a pain, as you say. If you're comfortable scripting and using ldap then the simplest method would be this:
backup your configuration by running vdmexport
ldap connection to localhost, dc=vdi,dc=vmware,dc=int
get all entries under ou=servers (they'll all have GUIDs as names, don't be alarmed), filter by string value of the original user SID on the pae-sidstring attribute
replace pae-sidstring attribute value with a string containing the new user SID for any matching entries