@DustinB3403 said in SMB vs Enterprise:

In regards to ?

I assume he's talking about from a career standpoint since this is posted in the IT Careers area, but I've been wrong before lots of times.

@scottalanmiller said in DFW SpiceCorps - 6/29/2017:

Week from tonight. Very close to my place for those that know the area.

Hopefully we'll have a good turnout. The Makerspace is a nice facility.

@Dashrender said in When Robocopy Fails because of Folder Permissions...:

@NetworkNerd said in When Robocopy Fails because of Folder Permissions...:

@Dashrender said in When Robocopy Fails because of Folder Permissions...:

@NetworkNerd said in When Robocopy Fails because of Folder Permissions...:

f our projects after moving servers will be to clean up permissions and remove the full control.

I used robocopy a year or so ago to do just this. There is an option in robocopy that allows robocopy to run as the backup service to copy the data to the new location. This solve any issues I had with my admin account not having access to files on the volume I was moving.

robocopy /b = backup mode (if you don't have permissions, restart the copy of that file using the backup account)

This may be the missing link. Not that we shouldn't fix permissions, but we really do need to get the data transferred. I will give it a try over the weekend and let you know how things go. Thanks!

Why do you assume permissions are broken?

My boss has files on the server that I have no business touching. She can (and does) use Windows file permissions to prevent my casual looking at those files. I don't see a problem with this.

There's not a problem with using permissions to keep people out of folders as you mention, and it goes right along with the JITJEA principle. Our real issue is that the folks who setup permissions on the server set individual user permissions instead of assigning the permissions to groups. That's where it seems messy and broken to me. But I completely agree with you that there are things I don't need to stumble upon and see, and that's a good thing.

@Dashrender said in When Robocopy Fails because of Folder Permissions...:

@NetworkNerd said in When Robocopy Fails because of Folder Permissions...:

f our projects after moving servers will be to clean up permissions and remove the full control.

I used robocopy a year or so ago to do just this. There is an option in robocopy that allows robocopy to run as the backup service to copy the data to the new location. This solve any issues I had with my admin account not having access to files on the volume I was moving.

robocopy /b = backup mode (if you don't have permissions, restart the copy of that file using the backup account)

This may be the missing link. Not that we shouldn't fix permissions, but we really do need to get the data transferred. I will give it a try over the weekend and let you know how things go. Thanks!

@Grey said in When Robocopy Fails because of Folder Permissions...:

@Mike-Davis said in When Robocopy Fails because of Folder Permissions...:

If that's the case I would fix all the folder permissions before trying to move stuff. The problem will keep coming back to bite you.

Exactly this. Check out icacls on the 2003 server, fix the permissions, then do your move and adjust on the new server.

If this were a pair of VMs, you could disconnect the drive from one VM to another and call it done (mostly).

Unfortunately the Server 2003 machine is physical and uber low on storage space. The new file server is a VM, however. I'd not heard of icacls but will definitely check it out. Thanks.

@Mike-Davis said in When Robocopy Fails because of Folder Permissions...:

I would think taking ownership of the files makes the most sense. Does your backup account have access? If not, those files aren't getting backed up. How did files get created that an admin doesn't have permissions to? Were permission set on the drive where a user has full control?

Administrators of the server have full control from the root volume, but it looks like inheritance was broken at some point before the folders to which we do not have access. There are users will full control of folders set in many areas. One of our projects after moving servers will be to clean up permissions and remove the full control.

The backup agent is running under a local system account, which I believe have access to all folders on the system (did not see any errors about file / folder access in backup job logs).

@scottalanmiller said in When Robocopy Fails because of Folder Permissions...:

@NetworkNerd said in When Robocopy Fails because of Folder Permissions...:

We're in the process of moving all files on a specific volume from one server (old Server 2003 machine) to a volume on a new file server (Server 2012 R2). We tried robocopy on the source server but actually found the admin accounts we were using to run the robocopy do not have access to all subfolders of the volume.

What kind of admin account doesn't have file access?

That would be the kind that some consulting firm setup before you got here.

We're in the process of moving all files on a specific volume from one server (old Server 2003 machine) to a volume on a new file server (Server 2012 R2). We tried robocopy on the source server but actually found the admin accounts we were using to run the robocopy do not have access to all subfolders of the volume.

Here are my thoughts on ways we could get around this issue (choose only one but leaning toward the second option):

• Use Powershell on the old server to force ownership of the folders to which we do not have access so the robocopy will succeed.

• Since we're running agent-based backups on the old server and the new (runs under local system account and will create image-based backups with file-level restore capabilities), I was thinking of just doing a restore of the entire data volume on the old server (separate from the OS volume) to a volume on the new server. This should propagate all NTFS permissions as they were when the backup was taken.

We would, of course, have to re-create shares with proper permissions on the new server (export registry keys for shares on old server and import on new server) for things to work the way we want as well as modify user drive mappings to reflect the move to the new server to officially cutover.

Am I thinking about this the right way to get around the file permission issues? Let me know if there is something that has been missed.

If you didn't make it to VeeamOn, you may want to check out these recordings from the conference - https://www.veeam.com/veeamon/free-sessions. I'm sure these can be helpful to just about any Veeam customer and wanted to share.

I don't see any mention of internet bandwidth at the site or if this will be PRI / analog. I only saw mention of the gateway to allow use of the intercom. Internet bandwidth is something you need to consider when using a hosted PBX (on Vultr, for example) since in that scenario both internal and external calls would take internet bandwidth. If you had the FreePBX instance on site and brought your own SIP trunks, you're only spending internet bandwidth for inbound / outbound calls (not internal extension calls). With G711u, you can estimate 100Kbps per concurrent call on the high side. It isn't a ton of bandwidth if everyone is on the phone at the same time with 25 phones, but if you were trying to run all this on DSL or a T1 (which I hope not), you may not like the results.

Be sure to keep QoS in mind on the upload side for voice traffic as well.