Youngsters these days... If I change the DVD/CD drive letter, I change it to Y:, because long ago, under some really old version of windows (3.1? wfwg 3.1x? I'm getting old - get off my lawn) logon scripts used Z:.
You can find a vague reference to it here: http://www.oreilly.com/openbook/samba/book/ch06_06.html Heh. Kurt On Mon, Jan 29, 2018 at 2:42 PM, Dave Lum <l...@ochin.org> wrote: > My typical buildout: > > Anything with a user share (other than a domain controller) gets a separate > volume than the OS and the files live there. Database servers get at least > two additional (logs for one, DB for the other). Server hosting applications > with a lot of read/writes and or file growth get an additional volume as this > allows easy movement/growth/reallocation of data volumes without impacting > the host OS. Doing a file recovery can be simplified with this setup as > there's lower risk of restoring the wrong applicaiotn file/setting* > > Single volume systems are infrastructure stuff like domain controllers, DHCP > servers, and print server (depending on its load and if it's not also a file > server). > > My OCD also sets the DVD drive to Z: so adding other drive letters is > contiguous. > > Dave > * This is probably legacy thinking as I haven't run into this in many, many > years. > > > -----Original Message----- > From: listsad...@lists.myitforum.com [mailto:listsad...@lists.myitforum.com] > On Behalf Of Kurt Buff > Sent: Monday, January 29, 2018 2:10 PM > To: ntsysadm <ntsysadm@lists.myitforum.com> > Subject: Re: [NTSysADM] Advice: migrate to new file server > > Don't know about everybody, but I do it - because I hate it when someone > copies a ton of big files to the driver that data shares with the OS, and the > machine chokes. Makes for a very unpleasant time for the users. > > I've also had to do this on machines with hyperactive print queues. > Now, if I'm building a print server, the spool directory goes on a separate > partition - doesn't really matter how big the partition is, even just a few > gigs, as long as it doesn't share the OS partition. > > Kurt > > On Mon, Jan 29, 2018 at 1:40 PM, Gantry Zettler <gan...@gmail.com> wrote: >> "I'm hoping that the data is on a separate partition from the OS. >> That's pretty critical. " >> >> Is this what everyone else does? Even on VMs? >> >> >> >> On Mon, Jan 29, 2018 at 3:16 PM, Melvin Backus >> <melvin.bac...@byers.com> >> wrote: >>> >>> Ditto. I usually do this over a span of days or weeks. Big initial >>> copy, then incrementals periodically depending on normal usage, etc. >>> Last pass as I’m ready to make the move. By that time we’re talking >>> about a few minutes because everything should be the same anyway, >>> just the time to scan the file systems. >>> >>> >>> >>> -- >>> There are 10 kinds of people in the world... >>> those who understand binary and those who don't. >>> >>> >>> >>> ¯\_(ツ)_/¯ >>> >>> >>> >>> From: listsad...@lists.myitforum.com >>> [mailto:listsad...@lists.myitforum.com] On Behalf Of Charles F >>> Sullivan >>> Sent: Monday, January 29, 2018 2:58 PM >>> To: ntsysadm@lists.myitforum.com >>> Subject: Re: [NTSysADM] Advice: migrate to new file server >>> >>> >>> >>> I always use the /mir option when doing a migration like that. The >>> reason is I have to do a "big" initial copy and then at least one >>> delta copy. (I usually do the final copy after removing access by >>> changing share perms or removing the share entirely so no further >>> changes are made.) If I don't use the /mir option, users will likely >>> end up with data that is no longer supposed to be present. (This >>> assumes they will continue to have access to the old server while >>> copy job is running.) >>> >>> >>> >>> It's completely safe despite the warning in the help, at least in >>> this scenario. Unless I'm missing something, the new server will not >>> be accessible to users until you finish the migration, thus there >>> should be no extra data which could get deleted. >>> >>> >>> >>> On Mon, Jan 29, 2018 at 2:27 PM, Michael Leone <oozerd...@gmail.com> >>> wrote: >>> >>> I'd like to impose once more for some advice and opinions. I have a >>> Win >>> 2008 R2 file server; I need to migrate everything (shares and user >>> home >>> folders) to a Win 2012 R2 Storage Server, and then retire the old server. >>> Everything is one 1 drive, with 3 main folders (Shares,Users,Scans), >>> total size in the neighborhood of 2TB. Both have 4 teamed 1G NICs, so >>> a total bandwidth of 4G. >>> >>> >>> >>> I'm thinking of use robocopy. I would make a full copy over the weekend: >>> >>> >>> >>> Source=OldFS\F$ >>> >>> Destination=NewFs\d$ >>> >>> >>> >>> RoboCopy <Source> <Destination> /S /E /ZB /COPYALL /R:1 /W:1 /V /NP >>> /NFL /NDL /LOG+:<LogFile> >>> >>> >>> >>> That should get everything, NTFS security and all sub-folders. I >>> thought about the /MIR option, but I've never used it, and so am just >>> a touch leery (perhaps illogically). >>> >>> >>> >>> The end goal is to: >>> >>> copy all the files and shares to the new FS; >>> >>> re-name and re-IP the old FS; >>> >>> power off the old FS; >>> >>> re-name and re-IP the new FS to the old name. >>> >>> >>> >>> (this way I can power up the old FS, just in case I need it for >>> something I've missed) >>> >>> >>> >>> That *should* make things transparent to the end users. >>> >>> >>> >>> (ordinarily, I would think about doing a restore from my backup >>> program Networker. But this is a remote site, and I believe that >>> doing a local robocopy will probably be faster than trying to restore >>> 2TB of what is probably a lot of small user files and folders across >>> a 1G link) >>> >>> >>> >>> What have I missed? What would make it better? >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> -- >>> >>> Charlie Sullivan >>> >>> Sr. Windows Systems Administrator >>> >>> Boston College >>> >>> 197 Foster St. Room 367 >>> >>> Brighton, MA 02135 >>> >>> 617-552-4318 >> >> > > > Attention: Information contained in this message and or attachments is > intended only for the recipient(s) named above and may contain confidential > and or privileged material that is protected under State or Federal law. If > you are not the intended recipient, any disclosure, copying, distribution or > action taken on it is prohibited. If you believe you have received this email > in error, please contact the sender with a copy to complia...@ochin.org, > delete this email and destroy all copies.
