In the interest of not giving you something else to learn... What I essentially did was: Create a volume on the SAN. Attached volume to file server robocopy with /mir /sec /r:1 /w:10 (mirror changes, apply security retry once, wait 10 seconds if the file is busy) Repeated daily until my scheduled downtime Disabled all the shares on the local volumes P2V'd the server Attached the iSCSI volumes (I don't remember doing this, but I think I might've had to) recreated all the shares on the SAN volumes.
That process didn't extend my downtime signifcantly longer than the time it took to P2V the server. I scripted the shares, I only have about 10 shares, so it wasn't a big deal. On Tue, Feb 9, 2010 at 10:06 AM, N Parr <npar...@mortonind.com> wrote: > I will look it to DFS some more. But I only have two file servers, I > don't plan on consolidating them and don't plan on any more for a long time. > ------------------------------ > *From:* Ken Schaefer [mailto:k...@adopenstatic.com] > *Sent:* Tuesday, February 09, 2010 9:00 AM > > *To:* NT System Admin Issues > *Subject:* RE: File Server Migration to VM > > You really need to learn DFS. It’s not complex, but will make your life > much easier. > > > > If you have no legacy problems with your current setup, I’d consider > P2V-ing your current setup (to preserve all the current settings) and then > transition to DFS. That would enable you to add in Win2k8 R2 servers at your > leisure down the track. If you do it all in one big-bang, you need to have > all the security migration nailed-down on migration day. > > > Cheers > > Ken > > > > *From:* N Parr [mailto:npar...@mortonind.com] > *Sent:* Tuesday, 9 February 2010 10:03 PM > *To:* NT System Admin Issues > *Subject:* File Server Migration to VM > > > > Getting ready to P2V a couple file servers. OS is C: and all file shares > are on D:, E:, etc. Our plan is to end up with the file share drives on > their own Volumes on our ISCSI SAN and use the ISCSI connector on the VM > guest over it's own VNIC. This is the way we do it now with Virtual SQL > servers and it works great. The only virtual disks will be the OS boot > drive. My reasoning for this is because it's a whole lot easier/quicker for > me to mount a snap shot of the volume via ISCSI to recover data than it > would be to attach a snapshot of a virtual disk to a VM to recover. That's > my reasoning unless someone would like to shoot holes it for me, and yes if > I had NFS I would use it but I don't. > > My question is the procedure for migrating the file share data. There's > about a dozen different ways I could do it. But no matter if I set up a new > server and migrate the data with FSMT or P2V the entire server I still have > to get all the file shares and files and folders with their security in tact > from what the server would consider one physical drive to another. I would > prefer to set up a new server so I could go from a 2003 to 2008R2 at the > same time. I thinking the easiest way would be to set up the new VM server, > move the data and shares with the file server migration toolkit and then > just rename the servers. And probably swap IP's just for the heck of it. I > know DFS would take care of not having to rename the servers but I'm just > trying to keep it simple and my knowledge of DFS is very lacking. > > > > > > > > > > > > > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
