I don't ask permission, I notify the users and I take ownership and grant Administrators permissions, and make sure permissions are inherited.
Once that's done, I offer to work with them to get the permissions rational. Normally that means moving subdirectories up the tree so that breaking inheritance isn't required. Kurt On Wed, Jan 31, 2018 at 7:00 AM, Charles F Sullivan <charles.sulliva...@bc.edu> wrote: > This happens almost every time. Someone who doesn't know what they're doing > has the right to change permissions and they don't include Administrators. > Usually the next issue I find is that when I try to take ownership and reset > perms, there are stragglers, sometimes lots of them. It's good that you have > the log from the run using /create so you have that as a list of failures. > Put the onus on the data owners to decide who should have access or if the > data is even needed. Usually that's the next issue...finding someone who > will take that responsibility. > > On Wed, Jan 31, 2018 at 9:36 AM, Michael Leone <oozerd...@gmail.com> wrote: >> >> <SIGH> >> >> Oh, the joys of special permissions on sub-folders ... >> >> Good thing I did an initial run using the /CREATE switch (thanks for >> that!). Found a number of errors, couldn't access destination folder. >> Checking the source folder permissions, I see that these have been set >> manually - not inherited, limited to only certain AD accounts (which now >> don't exist, as those users left, and have been deleted from AD), etc. >> >> So I'm wondering if it's better to run Robocopy as the local system >> account, to avoid issues like this? >> >> (I can probably fix the source permissions on a couple, after consulting >> with that department, and seeing who to re-set the security to) >> >> How do others get around this type of problem? Or are your folders set >> with sane NTFS security on all of them? LOL >> >> >> >> On Tue, Jan 30, 2018 at 8:23 AM, Michael Leone <oozerd...@gmail.com> >> wrote: >>> >>> On Mon, Jan 29, 2018 at 5:07 PM, Charles F Sullivan >>> <charles.sulliva...@bc.edu> wrote: >>>> >>>> By default it only copies changed files, no /a switch needed. >>> >>> >>> >>> AH HA. Vital information/confirmation. Thanks. So if I do a /MIR this >>> weekend, I should (theoretically) be able to do the same command, say every >>> 3-4 days, until the move (17 days until the move). That should make the >>> final command, on the weekend of the move, relatively quick. >>> >>> I will start testing the /MIR on some temp and test folders ... >>> >>> Thanks! >>> >>> >>>> >>>> On Mon, Jan 29, 2018 at 3:15 PM, Michael Leone <oozerd...@gmail.com> >>>> wrote: >>>>> >>>>> On Mon, Jan 29, 2018 at 2:57 PM, Charles F Sullivan >>>>> <charles.sulliva...@bc.edu> wrote: >>>>>> >>>>>> 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.) >>>>> >>>>> >>>>> >>>>> Hmmm ... well, this would be done after hours on a Friday, so I doubt >>>>> there would be any access.The idea is that the users go home Friday, and >>>>> come back Monday, and it's all done behind the scenes. >>>>> >>>>> >>>>>> >>>>>> 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. >>>>> >>>>> >>>>> >>>>> I may test that this weekend, do a /MIR. Then I would need to only copy >>>>> things that have changed since then. Is that the /A option? >>>>> >>>>>> >>>>>> 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 >>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> >>>> Charlie Sullivan >>>> >>>> Sr. Windows Systems Administrator >>>> >>>> Boston College >>>> >>>> 197 Foster St. Room 367 >>>> >>>> Brighton, MA 02135 >>>> >>>> 617-552-4318 >>> >>> >> > > > > -- > > Charlie Sullivan > > Sr. Windows Systems Administrator > > Boston College > > 197 Foster St. Room 367 > > Brighton, MA 02135 > > 617-552-4318
