Win Domain File Services


Service Components

Architecture

The UD central Win Domain File Services consists of two virtual servers (one in Chapel St. and one in DR) that are managed by IT-NSS. Virtual disks are attached to these servers and are then shared. Each share is using Distributed File System Replication (DFSR), meaning that the data is continuously replicated between the two machines and, therefore, users do not need to be concerned about which server they are attached to. The "active" machine for a particular share is dictated on a shared basis depending on which root the DFSR uses.

Details on DFSR can be found online:

Price Comparison (as of April 2013)

Service

Price

Free

$/(GB*month)

1 year of 100GB

IT-NSS

0.0600

$72.00

Dropbox

100GB 9.99 month

2GB

0.0999

$117.48

Google Drive

25GB 2.49

5GB

0.0996

$113.54

SkyDrive

20GB 10

7GB

0.041666667

$46.50

Amazon

100GB 50'year

5GB

0.041666667

$47.50

Information about pricing from:
https://www.dropbox.com/pricing
https://support.google.com/drive/bin/answer.py?hl=en&answer=2375123&p=mktg_pricing
http://windows.microsoft.com/en-US/skydrive/compare
http://www.amazon.com/gp/feature.html?ie=UTF8&docId=1000796931

Two major differencse between these services and the IT-NSS service are backups and shadow copies. None of the services listed will recover a file for you. Although they have a trash bin, they do not keep previous versions.

Information Security and Assurance

Shadow copies

Shadow copies allow end users to recover data themselves. Shadow copies are enabled (shadow copy space as specified by the IT Pro when a share is requested) and copies are taken at 8 a.m., 12:30 p.m., and 6 p.m., Monday-Friday; 12 noon and 6 p.m. on Saturday and Sunday. Copies of files that change are taken every 4 hours. The amount counts against your total quota. So, if you request a 200GB share with 10GB of shadow copies, you will end up with 190GB of usable space.

Microsoft estimates a change rate of 10% per day. IT-NSS typically sees a 1% change rate. These values are reported on data for each drive and the size of the volume shadow copy allotment can be adjusted by request. Typically, on a share that has historic data on it (i.e., items are added but rarely removed), IT-NSS has seen about a 1% change rate. In that case, a 10% shadow copy size would yield approximately 10 days worth of retention.

If, on the other hand, the share contains mainly active research data that is culled at the end of each 6-month project, you may want to adjust the shadow copy storage accordingly. IT-NSS provides a Web page that lists the age of the oldest volume shadow file, so the length of retention can easily be determined by the IT Pro at any time. There is also a limit on the number of shadow copies that can be retained. Only 64 copies can be shown to end users. Therefore, there are approximately 4 weeks of shadow copies.

As an example, with a 1TB share, and every day 100GB of data is being added, deleted, or changed, then a 10% shadow copy size will only yield one day's retention. That amount may be acceptable if the data is then being processed and new data generated the next day.

Backup and recovery

IT-NSS retains 90 days of backups on site. No offsite backups are kept and nothing is archived. (DR system will be used for disaster recovery.) A first step for recovery should be done using shadow copy recover. If that does not work, then contact consult@udel.edu and provide the path of where the file was (e.g., \\win.udel.edu\NSS\Personal\Files\Deleted.docx) and a date for when the file should be recovered from (e.g., 3 weeks ago or 6/8/2013).

Permissions

The IT Pro who requests the share will have full control over NTFS permissions on their share. Share-level permissions will be set automatically to "EVERYONE: Full Control," and NTFS permissions will be used to secure the share. When a share is created, these permissions will be assigned:

Group Name Permission Level
<OU PREFIX>FS<SHARE NAME> Modify Modify
<OU PREFIX>FS<SHARE NAME> Access Read Only
<OU PREFIX>_Admins Full Control
Administrators Full Control
NSS_Admins Full Control
System Full Control

Do not remove the Full Control groups above (System, Administrators, and NSS_Admins) because this will prevent backups and shadow copies. We recommend being very careful about how you use NTFS permissions, and that you ask for assistance if needed. You should always use AD Security Groups to assign permissions: avoid granting permissions at the user level whenever possible. Setting up complicated permissions on a file-by-file basis will lead to serious problems. If problems arise, the only option will be to reset the entire share to the initial setup.

Antivirus protection

Forefront Endpoint Protection is being used. If a virus is uploaded, the file will exist for 10 minutes. The server will not allow anybody to access it nor will it replicate.  After 10 minutes, the file will be deleted automatically.

Firewall

The system will have a firewall that will be set to allow in: all wired campus IPs, any VPN address, and wireless addresses on UDel Secure. Connections through UDel (non-secure) will be unable to access shares.

Blocked files

Currently only a few types of files are blocked: .mdf, *.ldf (sql server files), vmdk (virtual machine files), *.pst, and *.ost. Running these files off a DFSR share can cause system problems.

.pst files should not be accessed on the file server as it can often lead to corrupted .pst files and has the potential to cause the file server to freeze up. This is why .pst files are blocked on the server by extension. It is possible to back up to a local copy of .pst files on the server by compressing them into a .zip or other archive file.

See the following Microsoft articles:

Multi-user file access databases

Using the share for multi-user (e.g., Access) databases is unadvisable due to the risk of loss of data integrity. All files accessed by multiple concurrent users have the same integrity risk. If a file is opened from different homed servers--intentionally or inadvertently--then changes made to the file closed first will be lost when the second file is closed. Furthermore, changes to a file will not get replicated across the servers until everyone has closed the file. We have see instances where users do not close Access files for long periods of time, which could impact recoverability and disaster recovery because scheduled mirroring and replication routines are not occurring.

Macs

Mac OS X Lion and Mountain Lion have been tested and work well with Win DFS.               

Redirected personal directories

Home folder redirection is allowable. Offline files are recommended (see below). .pst files must be kept out of the network shared area. (See note above about blocked files.)

Offline files

Offline files can be used. If redirected folders are used, this should happen automatically. Under Windows on a different system, you can right-click on a folder and select "always available offline." You will then have a local cached copy that will be synchronized with the server. In general, last writer wins conflicts though users should be made aware that file conflict warnings are cryptic at best, so care should be taken in cases where files could be edited on the server while a machine is offline (i.e., laptops). See troubleshooting for known issues.

Quotas

At the moment, quotas have not been implemented. The space a share is allowed is controlled by the size of the vmdk file attached. For the time being, it is a manual process until it is determined if and how departments wish to implement. The following link provides details on what can be done: http://technet.microsoft.com/en-us/library/cc755917(v=ws.10).aspx.

DFS tab removal

The DFS tab should be removed from users' computers if using this service. This tab allows end users to change which server they are connected to. By default, all users of a particular share are directed to the same server. Users can change this behavior using this tab, which can be problematic in a scenario such as the following: User A connects to share and is directed to nss-fs01. User B then connects, but thinks, “Hey, I bet nss-fs02 is faster,” and makes the change. User A edits file X. User B, because they are connected to a different server, opens file X. User B makes changes and saves them. User A then saves his changes. User A’s changes will be replicated to nss-fs02 and overwrite the changes User B made. To avoid this scenario, one of the following methods can be used:

Registry edit

  1. Open regedit.exe
  2. Navigate to: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\PoliciesExplorer
  3. Create a new DWORD value named NoDFSTab and set the value to 1.

Group policy

  1. Add a new setting in a group policy.
  2. Enable the setting \User Configuration\Policies\Administrative Templates\Windows Components\Windows Explorer\Remove DFS Tab.
  3. Make sure your users are using that group policy.
IT-NSS feels that the IT Pros should handle this setting so that IT-NSS does not accidently change a setting you are relying on.

Reporting on Request page

On the central NTFS request page, IT Pros can view all the shares they are responsible for along with current usage and Volume Shadow age. Statistics on usage over time are also available on that page.