Migrate to DFS from UNC file shares? Complications..
-
@ntoxicator said:
Having 2 SAN's configured (sync storage). Would just help if one of them failed, I could quickly swap out the iSCSI pool and SR pointers within XenServer Control Panel and get us back online.
Yeah.... that's insanely silly. Just drop the original Synology and you'll save money, go faster and be safer. All wins. The only rational answer is to remove the Synology completely. Anything is, I'd have to say, insane. Why would any money be spent to do something that isn't any good?
-
@scottalanmiller said:
@ntoxicator said:
We actually have 2 Synology rack-mounts. The idea was to pool them together using the Synology HA / sync and its heartbeat setup.
One of the places where NAS and SAN isn't something that you can fudge. I believe that the HA is for the NAS functionality only. But in both cases, it doesn't apply to use for VMs, so does not exist for you at all.
Gotcha - and i completely understand that now :). The HA would apply to the storage units themselves, and not to the running VM's. As latency and time it takes... we would still have downtime while I would have to re-associate storage pool / SR's and virtual disks to the VM's on xenserver node.
I see the bigger picture on that aspect now after it all being laid out to me.
-
@ntoxicator said:
I'm thinking of just a NAS unit. Probably a 2-disk unit in RAID-1. Again, I see a synology product here? I can create SMB2 shares on this, however I'm sure I will have to tie into AD using LDAP connector for it to work properly (because SMB share).
SMB has no relationship to AD. AD is authentication, SMB is a network file protocol. AD will be needed because you are dealing with AD users, I assume, but is not a factor due to SMB in any way.
-
@scottalanmiller said:
@ntoxicator said:
Having 2 SAN's configured (sync storage). Would just help if one of them failed, I could quickly swap out the iSCSI pool and SR pointers within XenServer Control Panel and get us back online.
Yeah.... that's insanely silly. Just drop the original Synology and you'll save money, go faster and be safer. All wins. The only rational answer is to remove the Synology completely. Anything is, I'd have to say, insane. Why would any money be spent to do something that isn't any good?
It was a bad decision on that. Full circle then (1-year ago), when I was asking for new servers to create a Xenserver HA setup.
-
@ntoxicator said:
Unless I can create SMB share and present this network path \\location\share to the Domain Controller (net use). And then configure the seperate GPO policy for this sub-set of users @ satellite office. to which will make their folder redirection and roaming profile save to that new network location? Let windows server handle the file permissions on that SMB drive?
Why would you not be able to do that?
-
@scottalanmiller said:
@ntoxicator said:
Unless I can create SMB share and present this network path \\location\share to the Domain Controller (net use). And then configure the seperate GPO policy for this sub-set of users @ satellite office. to which will make their folder redirection and roaming profile save to that new network location? Let windows server handle the file permissions on that SMB drive?
Why would you not be able to do that?
For some reason, I was under impression. When there is a SMB share, you have to use AD to be able to properly setup file folder permissions on the SMB folder. As this would not be a local disk on the Windows server and it would be considered a network location and windows server would have a hard time applying file/folder permissions for users/groups?
-
@ntoxicator said:
I'm thinking of just a NAS unit. Probably a 2-disk unit in RAID-1. Again, I see a synology product here? I can create SMB2 shares on this, however I'm sure I will have to tie into AD using LDAP connector for it to work properly (because SMB share).
If possible, buy a NAS that supports AD integration. This will allow you to set permissions on the SMB shares based on AD users.
Unless I can create SMB share and present this network path \\location\share to the Domain Controller (net use).
You don't need to present anything to the DC. in your GPO you'll create a mapping for \\name or IP of NAS\sharename, that's all. You need to do nothing more on the DC.
And then configure the separate GPO policy for this sub-set of users @ satellite office to which will make their folder
redirection and roaming profile save to that new network location?Correct
Let windows server handle the file permissions on that SMB drive?
The server doesn't really handle the permissions on the files, only the share itself. After you get below the share, for example \\NAS IP\sharename, once you go to \\NAS IP\sharename\filename - once you reach filename, you are now dealing with permissions at the file/folder level, which the Windows Server or DCs don't care about. Of course they are used to verify who has permission, but the servers themselves aren't watching what's happening at that level. And really the DC isn't watching at the NAS device either, the NAS is watching itself, but again, only at the share level.
-
@ntoxicator said:
When there is a SMB share, you have to use AD to be able to properly setup file folder permissions on the SMB folder.
I'm guessing you read some posts on Spiceworks. There is an epidemic there of people not knowing what AD is and associating all kinds of things with it. AD is nothing but a database of users and passwords (and some info about those users, like first name, phone number, etc.) That's it. It's used to look up authentication, nothing more.
SMB does share permissions. SMB itself cannot with or without AD being in use, do anything with folder and file permissions.
Folder and file permissions are always from the ACLs of the file system. What you want to mimic a Windows machine are called NTFS ACLs.
Go on SW and you'll see people buying things with AD integration all of the time thinking that AD does file permissions and then being upset that they have no permissions. AD has no association with permissions.
AD: Authentication
FS ACLs: Permissions
SMB: Share Permissions on the network -
@ntoxicator said:
As this would not be a local disk on the Windows server and it would be considered a network location and windows server would have a hard time applying file/folder permissions for users/groups?
Huh? It would be a local disk. The AD system has nothing to do with "applying" permissions.
-
@scottalanmiller said:
AD: Authentication
FS ACLs: Permissions
SMB: Share Permissions on the networkYou want something with all three.
-
@scottalanmiller said:
@ntoxicator said:
As this would not be a local disk on the Windows server and it would be considered a network location and windows server would have a hard time applying file/folder permissions for users/groups?
Huh? It would be a local disk. The AD system has nothing to do with "applying" permissions.
I understand.
In reference to AD, I was meaning the windows server in itself. This would be the file folder share permissions and the NTFS read/write permissions. Now, these are typically applied to local disks on the actual server.
The NAS setup with SMB share would be new to me. But, yes I understand it
I would need NAS with AD integration, so I can streamline and secure the SMB share over the network (Set of users who can access this share).
Then I would need FS (file system) permissions on the SMB share (on the NAS). Which would also rely on AD user/group
So in my logic and what I was trying to explain before. Is that I would 100% need a device with AD integration for an SMB setup, since this SMB share is NOT local disk on the actual windows server. Since I would not be able to to the NTFS & share permissions directly on that server....
Yes -- I read some information awhile back on Spiceworks.
-
For DFS, your GPO looks like this. The same as with a basic SMB share. jsut you use the namespace instead of server. Nothing new or special.
-
@ntoxicator said:
@scottalanmiller said:
@ntoxicator said:
As this would not be a local disk on the Windows server and it would be considered a network location and windows server would have a hard time applying file/folder permissions for users/groups?
Huh? It would be a local disk. The AD system has nothing to do with "applying" permissions.
I understand.
In reference to AD, I was meaning the windows server in itself. This would be the file folder share permissions and the NTFS read/write permissions. Now, these are typically applied to local disks on the actual server.
The NAS setup with SMB share would be new to me. But, yes I understand it
I would need NAS with AD integration, so I can streamline and secure the SMB share over the network (Set of users who can access this share).
Then I would need FS (file system) permissions on the SMB share (on the NAS). Which would also rely on AD user/group
So in my logic and what I was trying to explain before. Is that I would 100% need a device with AD integration for an SMB setup, since this SMB share is NOT local disk on the actual windows server. Since I would not be able to to the NTFS & share permissions directly on that server....
Yes -- I read some information awhile back on Spiceworks.
You got it all correct there!
-
@ntoxicator said:
So in my logic and what I was trying to explain before. Is that I would 100% need a device with AD integration for an SMB setup, since this SMB share is NOT local disk on the actual windows server. Since I would not be able to to the NTFS & share permissions directly on that server....
It's not on "the" Windows server, but to everything on the network, it's on a server. I'm not sure why you keep mentioning the Windows server... what does that have to do with anything.
Your resulting information seems to be correct, but you keep mention that things are "because this isn't local disks on the Windows server" but that has nothing to do with the situation that I can see. It would be identical if this was a Windows server - nothing on the network knows that this isn't a Windows server. All the same tools, functions, processes, etc. apply.
It's still local disks. Still SMB. Still NTFS ACLs. Still AD Integration.
-
@scottalanmiller said:
@ntoxicator said:
So in my logic and what I was trying to explain before. Is that I would 100% need a device with AD integration for an SMB setup, since this SMB share is NOT local disk on the actual windows server. Since I would not be able to to the NTFS & share permissions directly on that server....
It's not on "the" Windows server, but to everything on the network, it's on a server. I'm not sure why you keep mentioning the Windows server... what does that have to do with anything.
Your resulting information seems to be correct, but you keep mention that things are "because this isn't local disks on the Windows server" but that has nothing to do with the situation that I can see. It would be identical if this was a Windows server - nothing on the network knows that this isn't a Windows server. All the same tools, functions, processes, etc. apply.
It's still local disks. Still SMB. Still NTFS ACLs. Still AD Integration.
Ok --
"On the windows server". I meant if I create the SMB shares on the actual Windows Server VM on those disks.
now, if I create SMB shares on a NAS / network device.. That would be different and ofcourse this is not 'on the windows server'.
It has all come together for me.
-
@scottalanmiller said:
@ntoxicator said:
So in my logic and what I was trying to explain before. Is that I would 100% need a device with AD integration for an SMB setup, since this SMB share is NOT local disk on the actual windows server. Since I would not be able to to the NTFS & share permissions directly on that server....
It's not on "the" Windows server, but to everything on the network, it's on a server. I'm not sure why you keep mentioning the Windows server... what does that have to do with anything.
Your resulting information seems to be correct, but you keep mention that things are "because this isn't local disks on the Windows server" but that has nothing to do with the situation that I can see. It would be identical if this was a Windows server - nothing on the network knows that this isn't a Windows server. All the same tools, functions, processes, etc. apply.
It's still local disks. Still SMB. Still NTFS ACLs. Still AD Integration.
well, his issue of needing to be concerned if NTFS permissions was supported or not wouldn't be there if this was a Windows Server instead of a NAS appliance.
-
@Dashrender said:
well, his issue of needing to be concerned if NTFS permissions was supported or not wouldn't be there if this was a Windows Server instead of a NAS appliance.
-Correct
-
@ntoxicator said:
@scottalanmiller said:
@ntoxicator said:
So in my logic and what I was trying to explain before. Is that I would 100% need a device with AD integration for an SMB setup, since this SMB share is NOT local disk on the actual windows server. Since I would not be able to to the NTFS & share permissions directly on that server....
It's not on "the" Windows server, but to everything on the network, it's on a server. I'm not sure why you keep mentioning the Windows server... what does that have to do with anything.
Your resulting information seems to be correct, but you keep mention that things are "because this isn't local disks on the Windows server" but that has nothing to do with the situation that I can see. It would be identical if this was a Windows server - nothing on the network knows that this isn't a Windows server. All the same tools, functions, processes, etc. apply.
It's still local disks. Still SMB. Still NTFS ACLs. Still AD Integration.
Ok --
"On the windows server". I meant if I create the SMB shares on the actual Windows Server VM on those disks.
The fact that the Windows Sever is a VM also doesn't matter. As long as Windows sees and considers the disks local to itself, SMB and NTFS file permissions work the same as any physically install server on bare metal. You just don't need to worry about the fact that it's a VM. i.e. if you are mounting vis iSCSI or Fiberchannel or DAS using SAS through an external adapter - none of these things matter. Windows considers all of these local, and work as normally expected.
-
@Dashrender said:
@scottalanmiller said:
@ntoxicator said:
So in my logic and what I was trying to explain before. Is that I would 100% need a device with AD integration for an SMB setup, since this SMB share is NOT local disk on the actual windows server. Since I would not be able to to the NTFS & share permissions directly on that server....
It's not on "the" Windows server, but to everything on the network, it's on a server. I'm not sure why you keep mentioning the Windows server... what does that have to do with anything.
Your resulting information seems to be correct, but you keep mention that things are "because this isn't local disks on the Windows server" but that has nothing to do with the situation that I can see. It would be identical if this was a Windows server - nothing on the network knows that this isn't a Windows server. All the same tools, functions, processes, etc. apply.
It's still local disks. Still SMB. Still NTFS ACLs. Still AD Integration.
well, his issue of needing to be concerned if NTFS permissions was supported or not wouldn't be there if this was a Windows Server instead of a NAS appliance.
None of that was covered, though. No amount of Windows, AD or SMB covers that. Only NTFS ACLs provide that. You can do with with actual NTFS or you can do it with Linux VFS and an NTFS ACL layer. Either way, works the same. But the only device that can give you ACLs is the device providing SMB. So the Synology NAS in the example.
-
@scottalanmiller
None of that was covered, though. No amount of Windows, AD or SMB covers that. Only NTFS ACLs provide that. You can do with with actual NTFS or you can do it with Linux VFS and an NTFS ACL layer. Either way, works the same. But the only device that can give you ACLs is the device providing SMB. So the Synology NAS in the example.Understood! Thank you sir.
