RE: DFSR
That can be mitigated with setting referral ordering on the namespace for common shares. I don't DFSR to load balance, I do it for uptime. All of the shares are referral ordered to just one server. To date, we have not had any double edit issues. Although I probably just jinxed myself. From: Michael B. Smith [mailto:mich...@smithcons.com] Sent: Monday, April 29, 2013 5:18 PM To: NT System Admin Issues Subject: RE: DFSR The big deal with DFS (IMO) is the double-edit issue. Two people can edit the same file at the same time and the last one that saves the file wins. From: David Lum [mailto:david@nwea.org] Sent: Monday, April 29, 2013 5:03 PM To: NT System Admin Issues Subject: DFSR I resolved my DFS issue from last week (pilot error :)). My question is this: Is there a reason not to leverage DFS for most file shares? It seems to me like it's a good way to be able to down a server (read: patch and reboot) and keep the file shares available, but I also know with something that's new to me makes it easy to overlook something simple. I'd guess it's not a good idea to DFS *every* file share, just mission-critical ones? In the scenario I care about the sites are all connected at 10Mbit or better and there's no more than 40 users connected to any one server at a time and 55 is the total user count. All storage is local, no SAN /iSCSI, etc. I did find this too: http://blogs.technet.com/b/askds/archive/2010/11/01/common-dfsr-configuration-mistakes-and-oversights.aspx Seems like the only downside - as long as you're paying attention to things listed in the link above - is using 2x/3x+ of the overall disk space as without DFSR, and possible traffic if you are a huge environment with very slow connections. David Lum Sr. Systems Engineer // NWEATM Office 503.548.5229 // Cell (voice/text) 503.267.9764 ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/ ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to listmana...@lyris.sunbeltsoftware.commailto:listmana...@lyris.sunbeltsoftware.com with the body: unsubscribe ntsysadmin ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/ ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to listmana...@lyris.sunbeltsoftware.commailto:listmana...@lyris.sunbeltsoftware.com with the body: unsubscribe ntsysadmin ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/ ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to listmana...@lyris.sunbeltsoftware.com with the body: unsubscribe ntsysadmin
RE: DFSR
What happens when the WAN sh*ts itself, and your environment is cut in half? Cheers Ken From: Kennedy, Jim [mailto:kennedy...@elyriaschools.org] Sent: Tuesday, 30 April 2013 10:04 PM To: NT System Admin Issues Subject: RE: DFSR That can be mitigated with setting referral ordering on the namespace for common shares. I don't DFSR to load balance, I do it for uptime. All of the shares are referral ordered to just one server. To date, we have not had any double edit issues. Although I probably just jinxed myself. From: Michael B. Smith [mailto:mich...@smithcons.com] Sent: Monday, April 29, 2013 5:18 PM To: NT System Admin Issues Subject: RE: DFSR The big deal with DFS (IMO) is the double-edit issue. Two people can edit the same file at the same time and the last one that saves the file wins. From: David Lum [mailto:david@nwea.org] Sent: Monday, April 29, 2013 5:03 PM To: NT System Admin Issues Subject: DFSR I resolved my DFS issue from last week (pilot error :)). My question is this: Is there a reason not to leverage DFS for most file shares? It seems to me like it's a good way to be able to down a server (read: patch and reboot) and keep the file shares available, but I also know with something that's new to me makes it easy to overlook something simple. I'd guess it's not a good idea to DFS *every* file share, just mission-critical ones? In the scenario I care about the sites are all connected at 10Mbit or better and there's no more than 40 users connected to any one server at a time and 55 is the total user count. All storage is local, no SAN /iSCSI, etc. I did find this too: http://blogs.technet.com/b/askds/archive/2010/11/01/common-dfsr-configuration-mistakes-and-oversights.aspx Seems like the only downside - as long as you're paying attention to things listed in the link above - is using 2x/3x+ of the overall disk space as without DFSR, and possible traffic if you are a huge environment with very slow connections. David Lum Sr. Systems Engineer // NWEATM Office 503.548.5229 // Cell (voice/text) 503.267.9764 ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/ ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to listmana...@lyris.sunbeltsoftware.com with the body: unsubscribe ntsysadmin
RE: DFSR
When my WAN sh*ts itself it is cut into 13ths and it is all over anyway. Full mesh redundancy is not on our radar. The ROI isn't there for us. We pay for 4 hour from Cisco and 24 hour from our fiber provider. But if I was meshed and had distributed servers my referral ordering would still work. The top priority server dies or that part of the network dies peeps would go to the second ordered referral. .com] Sent: Tuesday, April 30, 2013 8:50 AM To: NT System Admin Issues Subject: RE: DFSR What happens when the WAN sh*ts itself, and your environment is cut in half? Cheers Ken From: Kennedy, Jim [mailto:kennedy...@elyriaschools.org] Sent: Tuesday, 30 April 2013 10:04 PM To: NT System Admin Issues Subject: RE: DFSR That can be mitigated with setting referral ordering on the namespace for common shares. I don't DFSR to load balance, I do it for uptime. All of the shares are referral ordered to just one server. To date, we have not had any double edit issues. Although I probably just jinxed myself. From: Michael B. Smith [mailto:mich...@smithcons.com] Sent: Monday, April 29, 2013 5:18 PM To: NT System Admin Issues Subject: RE: DFSR The big deal with DFS (IMO) is the double-edit issue. Two people can edit the same file at the same time and the last one that saves the file wins. From: David Lum [mailto:david@nwea.org] Sent: Monday, April 29, 2013 5:03 PM To: NT System Admin Issues Subject: DFSR I resolved my DFS issue from last week (pilot error :)). My question is this: Is there a reason not to leverage DFS for most file shares? It seems to me like it's a good way to be able to down a server (read: patch and reboot) and keep the file shares available, but I also know with something that's new to me makes it easy to overlook something simple. I'd guess it's not a good idea to DFS *every* file share, just mission-critical ones? In the scenario I care about the sites are all connected at 10Mbit or better and there's no more than 40 users connected to any one server at a time and 55 is the total user count. All storage is local, no SAN /iSCSI, etc. I did find this too: http://blogs.technet.com/b/askds/archive/2010/11/01/common-dfsr-configuration-mistakes-and-oversights.aspx Seems like the only downside - as long as you're paying attention to things listed in the link above - is using 2x/3x+ of the overall disk space as without DFSR, and possible traffic if you are a huge environment with very slow connections. David Lum Sr. Systems Engineer // NWEATM Office 503.548.5229 // Cell (voice/text) 503.267.9764 ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/ ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to listmana...@lyris.sunbeltsoftware.commailto:listmana...@lyris.sunbeltsoftware.com with the body: unsubscribe ntsysadmin ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/ ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to listmana...@lyris.sunbeltsoftware.com with the body: unsubscribe ntsysadmin
RE: DFSR
FWIW Even full-mesh redundancy doesn't help you if your telco pushes some incorrect config to their core routers, or pushes some bad firmware to devices etc. You still end up with split network. Referral ordering relies on all users being able to access the current top target simultaneously. Once some users are accessing one top target, and other users think that a different target is the current top target, you run the risk of double edit issues. Main way to avoid that is to have a highly redundant #1 target (or individual site-specific targets which are backed by the highly redundant target as #2). You can replicate the content to additional servers (e.g. in another DC), but don't publish these as targets unless your highly redundant target (and any protocol-aware load balancers you have) go down. Cheers Ken From: Kennedy, Jim [mailto:kennedy...@elyriaschools.org] Sent: Tuesday, 30 April 2013 10:57 PM To: NT System Admin Issues Subject: RE: DFSR When my WAN sh*ts itself it is cut into 13ths and it is all over anyway. Full mesh redundancy is not on our radar. The ROI isn't there for us. We pay for 4 hour from Cisco and 24 hour from our fiber provider. But if I was meshed and had distributed servers my referral ordering would still work. The top priority server dies or that part of the network dies peeps would go to the second ordered referral. .com] Sent: Tuesday, April 30, 2013 8:50 AM To: NT System Admin Issues Subject: RE: DFSR What happens when the WAN sh*ts itself, and your environment is cut in half? Cheers Ken From: Kennedy, Jim [mailto:kennedy...@elyriaschools.org] Sent: Tuesday, 30 April 2013 10:04 PM To: NT System Admin Issues Subject: RE: DFSR That can be mitigated with setting referral ordering on the namespace for common shares. I don't DFSR to load balance, I do it for uptime. All of the shares are referral ordered to just one server. To date, we have not had any double edit issues. Although I probably just jinxed myself. From: Michael B. Smith [mailto:mich...@smithcons.com] Sent: Monday, April 29, 2013 5:18 PM To: NT System Admin Issues Subject: RE: DFSR The big deal with DFS (IMO) is the double-edit issue. Two people can edit the same file at the same time and the last one that saves the file wins. From: David Lum [mailto:david@nwea.org] Sent: Monday, April 29, 2013 5:03 PM To: NT System Admin Issues Subject: DFSR I resolved my DFS issue from last week (pilot error :)). My question is this: Is there a reason not to leverage DFS for most file shares? It seems to me like it's a good way to be able to down a server (read: patch and reboot) and keep the file shares available, but I also know with something that's new to me makes it easy to overlook something simple. I'd guess it's not a good idea to DFS *every* file share, just mission-critical ones? In the scenario I care about the sites are all connected at 10Mbit or better and there's no more than 40 users connected to any one server at a time and 55 is the total user count. All storage is local, no SAN /iSCSI, etc. I did find this too: http://blogs.technet.com/b/askds/archive/2010/11/01/common-dfsr-configuration-mistakes-and-oversights.aspx Seems like the only downside - as long as you're paying attention to things listed in the link above - is using 2x/3x+ of the overall disk space as without DFSR, and possible traffic if you are a huge environment with very slow connections. David Lum Sr. Systems Engineer // NWEATM Office 503.548.5229 // Cell (voice/text) 503.267.9764 ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/ ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to listmana...@lyris.sunbeltsoftware.com with the body: unsubscribe ntsysadmin
RE: DFSR
Ah. I'm recommending SMB 3.0 scale-out for that now. From: Kennedy, Jim [mailto:kennedy...@elyriaschools.org] Sent: Tuesday, April 30, 2013 8:04 AM To: NT System Admin Issues Subject: RE: DFSR That can be mitigated with setting referral ordering on the namespace for common shares. I don't DFSR to load balance, I do it for uptime. All of the shares are referral ordered to just one server. To date, we have not had any double edit issues. Although I probably just jinxed myself. From: Michael B. Smith [mailto:mich...@smithcons.com] Sent: Monday, April 29, 2013 5:18 PM To: NT System Admin Issues Subject: RE: DFSR The big deal with DFS (IMO) is the double-edit issue. Two people can edit the same file at the same time and the last one that saves the file wins. From: David Lum [mailto:david@nwea.org] Sent: Monday, April 29, 2013 5:03 PM To: NT System Admin Issues Subject: DFSR I resolved my DFS issue from last week (pilot error :)). My question is this: Is there a reason not to leverage DFS for most file shares? It seems to me like it's a good way to be able to down a server (read: patch and reboot) and keep the file shares available, but I also know with something that's new to me makes it easy to overlook something simple. I'd guess it's not a good idea to DFS *every* file share, just mission-critical ones? In the scenario I care about the sites are all connected at 10Mbit or better and there's no more than 40 users connected to any one server at a time and 55 is the total user count. All storage is local, no SAN /iSCSI, etc. I did find this too: http://blogs.technet.com/b/askds/archive/2010/11/01/common-dfsr-configuration-mistakes-and-oversights.aspx Seems like the only downside - as long as you're paying attention to things listed in the link above - is using 2x/3x+ of the overall disk space as without DFSR, and possible traffic if you are a huge environment with very slow connections. David Lum Sr. Systems Engineer // NWEATM Office 503.548.5229 // Cell (voice/text) 503.267.9764 ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/ ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to listmana...@lyris.sunbeltsoftware.commailto:listmana...@lyris.sunbeltsoftware.com with the body: unsubscribe ntsysadmin ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/ ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to listmana...@lyris.sunbeltsoftware.commailto:listmana...@lyris.sunbeltsoftware.com with the body: unsubscribe ntsysadmin ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/ ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to listmana...@lyris.sunbeltsoftware.commailto:listmana...@lyris.sunbeltsoftware.com with the body: unsubscribe ntsysadmin ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/ ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to listmana...@lyris.sunbeltsoftware.com with the body: unsubscribe ntsysadmin
RE: DFSR
The big deal with DFS (IMO) is the double-edit issue. Two people can edit the same file at the same time and the last one that saves the file wins. From: David Lum [mailto:david@nwea.org] Sent: Monday, April 29, 2013 5:03 PM To: NT System Admin Issues Subject: DFSR I resolved my DFS issue from last week (pilot error :)). My question is this: Is there a reason not to leverage DFS for most file shares? It seems to me like it's a good way to be able to down a server (read: patch and reboot) and keep the file shares available, but I also know with something that's new to me makes it easy to overlook something simple. I'd guess it's not a good idea to DFS *every* file share, just mission-critical ones? In the scenario I care about the sites are all connected at 10Mbit or better and there's no more than 40 users connected to any one server at a time and 55 is the total user count. All storage is local, no SAN /iSCSI, etc. I did find this too: http://blogs.technet.com/b/askds/archive/2010/11/01/common-dfsr-configuration-mistakes-and-oversights.aspx Seems like the only downside - as long as you're paying attention to things listed in the link above - is using 2x/3x+ of the overall disk space as without DFSR, and possible traffic if you are a huge environment with very slow connections. David Lum Sr. Systems Engineer // NWEATM Office 503.548.5229 // Cell (voice/text) 503.267.9764 ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/ ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to listmana...@lyris.sunbeltsoftware.commailto:listmana...@lyris.sunbeltsoftware.com with the body: unsubscribe ntsysadmin ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/ ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to listmana...@lyris.sunbeltsoftware.com with the body: unsubscribe ntsysadmin
RE: DFSR
It depends. There are 2 parts to DFS- the DFS namespace and DHS Replication. You can use the namespace without doing replication, but you can do replication without the namespace. I use the DFS namespace on all shares so that when I replace a file server, all of the links to it will still work. I.e. DFS namespace domain.com\dfs\share points to \\server\mysharefile:///\\server\myshare. I can plug in \\newserver\newsharefile:///\\newserver\newshare and people can till access it using the same DFS path. DFS replication doesn't do you any good unless you have multiple locations involved, so I don't use it there. The other thing to keep in mind with DFSR is that it doesn't do distributed file locking, so even though you have the data in multiple locations, you can't let people edit the same files from different locations. I use it mainly for backup and RO data for my users. ...Tim From: David Lum [mailto:david@nwea.org] Sent: Monday, April 29, 2013 2:03 PM To: NT System Admin Issues Subject: DFSR I resolved my DFS issue from last week (pilot error :)). My question is this: Is there a reason not to leverage DFS for most file shares? It seems to me like it's a good way to be able to down a server (read: patch and reboot) and keep the file shares available, but I also know with something that's new to me makes it easy to overlook something simple. I'd guess it's not a good idea to DFS *every* file share, just mission-critical ones? In the scenario I care about the sites are all connected at 10Mbit or better and there's no more than 40 users connected to any one server at a time and 55 is the total user count. All storage is local, no SAN /iSCSI, etc. I did find this too: http://blogs.technet.com/b/askds/archive/2010/11/01/common-dfsr-configuration-mistakes-and-oversights.aspx Seems like the only downside - as long as you're paying attention to things listed in the link above - is using 2x/3x+ of the overall disk space as without DFSR, and possible traffic if you are a huge environment with very slow connections. David Lum Sr. Systems Engineer // NWEATM Office 503.548.5229 // Cell (voice/text) 503.267.9764 ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/ ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to listmana...@lyris.sunbeltsoftware.commailto:listmana...@lyris.sunbeltsoftware.com with the body: unsubscribe ntsysadmin ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/ ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to listmana...@lyris.sunbeltsoftware.com with the body: unsubscribe ntsysadmin
Re: DFSR
+1 to the namespace usage. I did this ages ago on Server 2003 and it makes life much easier. -Jeff On Mon, Apr 29, 2013 at 5:19 PM, Tim Evans tev...@sparling.com wrote: It depends. ** ** There are 2 parts to DFS- the DFS namespace and DHS Replication. You can use the namespace without doing replication, but you can do replication without the namespace. ** ** I use the DFS namespace on all shares so that when I replace a file server, all of the links to it will still work. I.e. DFS namespace domain.com\dfs\share points to \\server\myshare. I can plug in \\newserver\newshare and people can till access it using the same DFS path. ** ** DFS replication doesn't do you any good unless you have multiple locations involved, so I don't use it there. The other thing to keep in mind with DFSR is that it doesn't do distributed file locking, so even though you have the data in multiple locations, you can't let people edit the same files from different locations. I use it mainly for backup and RO data for my users. ** ** …Tim ** ** *From:* David Lum [mailto:david@nwea.org] *Sent:* Monday, April 29, 2013 2:03 PM *To:* NT System Admin Issues *Subject:* DFSR ** ** I resolved my DFS issue from last week (pilot error J). My question is this: Is there a reason not to leverage DFS for most file shares? It seems to me like it’s a good way to be able to down a server (read: patch and reboot) and keep the file shares available, but I also know with something that’s new to me makes it easy to overlook something simple. ** ** I’d guess it’s not a good idea to DFS **every** file share, just mission-critical ones? In the scenario I care about the sites are all connected at 10Mbit or better and there’s no more than 40 users connected to any one server at a time and 55 is the total user count. All storage is local, no SAN /iSCSI, etc. ** ** I did find this too: http://blogs.technet.com/b/askds/archive/2010/11/01/common-dfsr-configuration-mistakes-and-oversights.aspx ** ** Seems like the only downside – as long as you’re paying attention to things listed in the link above – is using 2x/3x+ of the overall disk space as without DFSR, and possible traffic if you are a huge environment with very slow connections. *David Lum* Sr. Systems Engineer // NWEATM Office 503.548.5229 //* *Cell (voice/text) 503.267.9764 ** ** ** ** ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/ ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to listmana...@lyris.sunbeltsoftware.com with the body: unsubscribe ntsysadmin ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/ ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to listmana...@lyris.sunbeltsoftware.com with the body: unsubscribe ntsysadmin ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/ ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to listmana...@lyris.sunbeltsoftware.com with the body: unsubscribe ntsysadmin
RE: DFSR question regarding RDC
Yes it's block level. IIRC down to like 64KB blocks that it does the diff at. Once you put the first image out there, you should only expect to replicate the diffs in all the other images. Thanks, Brian Desmond br...@briandesmond.commailto:br...@briandesmond.com w - 312.625.1438 | c - 312.731.3132 From: Christopher Bodnar [mailto:christopher_bod...@glic.com] Sent: Wednesday, February 6, 2013 10:41 AM To: NT System Admin Issues Subject: DFSR question regarding RDC Got a question about this: http://msdn.microsoft.com/en-us/library/windows/desktop/bb540025(v=vs.85).aspx Replicating data to multiple servers increases data availability and gives users in remote sites fast, reliable access to files. DFSR uses a new compression algorithm called Remote Differential Compression (RDC). RDC is a diff over the wire protocol that can be used to efficiently update files over a limited-bandwidth network. RDC detects insertions, removals, and rearrangements of data in files, enabling DFSR to replicate only the deltas (changes) when files are updated. Just curious if anyone has really looked at this in regards to the RDC feature in larger files. Got a replication set we are going to setup. These will be larger files (17-25G), they will be images for Citrix Provisioning server. Wanted to know if it's really doing delta's in larger images files as they change, or replicating the whole thing. Thanks Christopher Bodnar Enterprise Architect I, Corporate Office of Technology:Enterprise Architecture and Engineering Services Tel 610-807-6459 3900 Burgess Place, Bethlehem, PA 18017 christopher_bod...@glic.commailto: [cid:image001.jpg@01CE0475.2B21E750] The Guardian Life Insurance Company of America www.guardianlife.comhttp://www.guardianlife.com/ - This message, and any attachments to it, may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are notified that any use, dissemination, distribution, copying, or communication of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately by return e-mail and delete the message and any attachments. Thank you. ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/ ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to listmana...@lyris.sunbeltsoftware.commailto:listmana...@lyris.sunbeltsoftware.com with the body: unsubscribe ntsysadmin ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/ ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to listmana...@lyris.sunbeltsoftware.com with the body: unsubscribe ntsysadmininline: image001.jpg
RE: DFSR question regarding RDC
Using DFS-R for PVS 6.x is really nice. PVS 5.x doesn't support DFS-R so don't call Citrix or MS for support when it screws up your PVS system (provided you can even get DFS-R and PVS to even start looking at each other). Thanks Webster From: Brian Desmond [mailto:br...@briandesmond.com] Sent: Wednesday, February 06, 2013 2:21 PM To: NT System Admin Issues Subject: RE: DFSR question regarding RDC Yes it's block level. IIRC down to like 64KB blocks that it does the diff at. Once you put the first image out there, you should only expect to replicate the diffs in all the other images. Thanks, Brian Desmond br...@briandesmond.commailto:br...@briandesmond.com w - 312.625.1438 | c - 312.731.3132 From: Christopher Bodnar [mailto:christopher_bod...@glic.com] Sent: Wednesday, February 6, 2013 10:41 AM To: NT System Admin Issues Subject: DFSR question regarding RDC Got a question about this: http://msdn.microsoft.com/en-us/library/windows/desktop/bb540025(v=vs.85).aspx Replicating data to multiple servers increases data availability and gives users in remote sites fast, reliable access to files. DFSR uses a new compression algorithm called Remote Differential Compression (RDC). RDC is a diff over the wire protocol that can be used to efficiently update files over a limited-bandwidth network. RDC detects insertions, removals, and rearrangements of data in files, enabling DFSR to replicate only the deltas (changes) when files are updated. Just curious if anyone has really looked at this in regards to the RDC feature in larger files. Got a replication set we are going to setup. These will be larger files (17-25G), they will be images for Citrix Provisioning server. Wanted to know if it's really doing delta's in larger images files as they change, or replicating the whole thing. ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/ ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to listmana...@lyris.sunbeltsoftware.com with the body: unsubscribe ntsysadmin
RE: DFSR question regarding RDC
You just need to be aware of things like encrypted files, where changing the file and re-encrypting will typically change the entire file. Also, for very large data sets, be aware of the need to size your DFS-R cache on each server. Cheers Ken From: Brian Desmond [mailto:br...@briandesmond.com] Sent: Thursday, 7 February 2013 7:21 AM To: NT System Admin Issues Subject: RE: DFSR question regarding RDC Yes it's block level. IIRC down to like 64KB blocks that it does the diff at. Once you put the first image out there, you should only expect to replicate the diffs in all the other images. Thanks, Brian Desmond br...@briandesmond.commailto:br...@briandesmond.com w - 312.625.1438 | c - 312.731.3132 From: Christopher Bodnar [mailto:christopher_bod...@glic.com] Sent: Wednesday, February 6, 2013 10:41 AM To: NT System Admin Issues Subject: DFSR question regarding RDC Got a question about this: http://msdn.microsoft.com/en-us/library/windows/desktop/bb540025(v=vs.85).aspx Replicating data to multiple servers increases data availability and gives users in remote sites fast, reliable access to files. DFSR uses a new compression algorithm called Remote Differential Compression (RDC). RDC is a diff over the wire protocol that can be used to efficiently update files over a limited-bandwidth network. RDC detects insertions, removals, and rearrangements of data in files, enabling DFSR to replicate only the deltas (changes) when files are updated. Just curious if anyone has really looked at this in regards to the RDC feature in larger files. Got a replication set we are going to setup. These will be larger files (17-25G), they will be images for Citrix Provisioning server. Wanted to know if it's really doing delta's in larger images files as they change, or replicating the whole thing. Thanks Christopher Bodnar Enterprise Architect I, Corporate Office of Technology:Enterprise Architecture and Engineering Services Tel 610-807-6459 3900 Burgess Place, Bethlehem, PA 18017 christopher_bod...@glic.commailto: [cid:image001.jpg@01CE051B.D520DE40] The Guardian Life Insurance Company of America www.guardianlife.comhttp://www.guardianlife.com/ ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/ ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to listmana...@lyris.sunbeltsoftware.com with the body: unsubscribe ntsysadmininline: image001.jpg
