Windows Server 2008 R2 DFS provides a number of built-in replication topologies to choose from when an administrator is configuring replication between DFS folder targets or replication group members; they’re described next. As a general guideline, it might be prudent to configure DFS Replication connections and a schedule to follow current Active Directory site replication topology connections or the existing network topology when the organization wants true multimaster replication.
Hub and Spoke
A hub-and-spoke topology is somewhat self-descriptive. A single target is designated as the replication hub server, and every other target (spoke target) replicates exclusively with it. The hub target has two replication connections with each spoke target: sending and receiving. A hub-and-spoke topology requires three or more servers, and when the hub target is unavailable, replication updates stop between all replication members. Windows Server 2008 R2 introduces the ability to specify more than one hub when creating a hub-and spoke replication topology. In previous releases, this required creating a custom topology.
Full Mesh
Using a full mesh topology, each target has a connection to every other target in the replication group. This enables replication to continue among available replication members when any member becomes unavailable. Because each member has a connection to every other member, replication can continue with as few as two replication members. Using this topology with read/write replication sets can lead to data conflicts if data is being changed in multiple sites so this topology should be used with caution.
No Topology and Custom Topology
During the creation of a replication group, one of the topology options is the No Topology option. Selecting this option enables an administrator to create a custom replication topology after the replication group is created. A custom topology allows an administrator to define specific replication connections for each target. This option can be useful if an organization wants to define one-way replication for centralized backup or to optimize read-only replicated folders. Also, this can be most useful when creating a topology for a network that is connected using different speed WAN links or each connection needs to have a specific schedule and bandwidth setting.
Replication Schedule and Bandwidth Throttling
Windows Server 2003 R2, Windows Server 2008, and Windows Server 2008 R2 DFS
Replication support scheduling replication, as well as restricting the amount of bandwidth a replication connection can utilize. In the original version of DFS that came with Windows 2000 and the initial release of Windows 2003, administrators were limited in their replication scheduling options and forced to limit replication to after hours for large data sets as opposed to trickling data replication all day long using only a portion of the wide area network (WAN) link between sites. For large data sets that will initially replicate across the WAN, the initial replication connections can be configured to run limited bandwidth during business hours and full bandwidth after hours until replication has completed and restrictions can be removed if desired.
Source of Information : Sams - Windows Server 2008 R2 Unleashed (2010)
Saturday, April 30, 2011
Monday, April 25, 2011
Distributed File System Replication Terminology
DFS uses either the File Replication Service or the Distributed File System Replication service to automatically replicate data contained in DFS folder targets. To understand the replication concepts, you must understand some key DFS replication terminology. Here are some important terms:
. Replication—The process of copying data from a source server folder to a destination server folder.
. Replication connection—The directory object that defines and manages the replication between a sending and receiving replication member server. The replication connection defines the replication schedule, which service will replicate the data, the sending and receiving members, and any bandwidth restrictions for the connection. Each replication connection has only a single sending and receiving replication member.
. Replication member—A server that shares a common replication connection. The receiving replication server receives data from a sending member server specified in the replication connection. The sending replication partner sends data to the receiving member specified in the replication connections.
. Read-only replication folders—Windows Server 2008 R2 introduces support for read-only replicas. This can be useful for auditing, centralized backup, or managing data sets. Only the replication members that are not defined as the primary source can host read-only replication folders. Read-Only Domain Controllers host the SYSVOL as a read-only replication folder. When read-only replication folders exist, it is a best practice to ensure that replication is only one-way to the read-only replication folder.
. Replication group—All the servers, folders, and connections that define a replication set of data.
. Multimaster replication— This defines two-way replication between multiple servers in a replication group. With multimaster replication, data changed on any server in the group will be replicated to every other server in the group.
Source of Information : Sams - Windows Server 2008 R2 Unleashed (2010)
. Replication—The process of copying data from a source server folder to a destination server folder.
. Replication connection—The directory object that defines and manages the replication between a sending and receiving replication member server. The replication connection defines the replication schedule, which service will replicate the data, the sending and receiving members, and any bandwidth restrictions for the connection. Each replication connection has only a single sending and receiving replication member.
. Replication member—A server that shares a common replication connection. The receiving replication server receives data from a sending member server specified in the replication connection. The sending replication partner sends data to the receiving member specified in the replication connections.
. Read-only replication folders—Windows Server 2008 R2 introduces support for read-only replicas. This can be useful for auditing, centralized backup, or managing data sets. Only the replication members that are not defined as the primary source can host read-only replication folders. Read-Only Domain Controllers host the SYSVOL as a read-only replication folder. When read-only replication folders exist, it is a best practice to ensure that replication is only one-way to the read-only replication folder.
. Replication group—All the servers, folders, and connections that define a replication set of data.
. Multimaster replication— This defines two-way replication between multiple servers in a replication group. With multimaster replication, data changed on any server in the group will be replicated to every other server in the group.
Source of Information : Sams - Windows Server 2008 R2 Unleashed (2010)
Friday, April 22, 2011
Distributed File System Terminology
To properly understand DFS, a number of technical terms are used when deploying, configuring, and referencing DFS. Although the DFS namespace and DFS Replication have already been described, the remaining terms should also be understood before reading the remainder of this chapter or deploying a new DFS infrastructure:
. DFS namespace—A unified namespace that presents a centralized view of shared folder data in an organization.
. DFS namespace server—A Windows server that hosts a DFS namespace.
. DFS namespace root—The top level of the DFS tree that defines the namespace for DFS and the functionality available. The namespace root is also the name of the DFS namespace. A domain-based root adds fault-tolerant capabilities to DFS by allowing several servers to host the same DFS namespace root.
. DFS folder—A folder that will be presented under the root when a DFS client connects. When a root is created, folders can be created within the file system, but DFS folders allow the system to redirect clients to different systems other than the namespace server hosting the root.
. Folder target—A shared folder hosted on a Windows server. The DFS folder name and the share name do not need to be the same but for troubleshooting purposes it is highly recommended. Multiple folder targets can be assigned to a single DFS folder to provide fault tolerance. If a single folder target is unavailable, clients will be connected to another available target. When DFS folders are created with multiple folder targets, replication can also be configured using DFS replication groups to keep the data across the targets in sync. Folder targets can be a share name or a folder beneath a share. For example, \\server1\userdata or \\server1\userdata\Finance are both valid folder targets.
. DFS tree—The hierarchy of the namespace. For example, the DFS tree begins with the DFS root namespace and contains all the defined folders below the root.
. Referrals—A configuration setting of a DFS namespace and/or folder that defines how DFS clients will connect to the namespace server, a folder in the namespace, or a particular folder target server. Referral properties include limiting client connections to servers in the local Active Directory site and how often to check the availability of a DFS server. Disabling a target’s referral keeps it from being used by clients. Target referral can be disabled when maintenance will be performed on a server.
Depending on which Server version, service pack, and edition of Window Server 2003 or 2008 is used will determine how many namespaces are supported on a single server. Please refer to online Microsoft documentation to determine which edition is right for your organization’s implementation of DFS.
Source of Information : Sams - Windows Server 2008 R2 Unleashed (2010)
. DFS namespace—A unified namespace that presents a centralized view of shared folder data in an organization.
. DFS namespace server—A Windows server that hosts a DFS namespace.
. DFS namespace root—The top level of the DFS tree that defines the namespace for DFS and the functionality available. The namespace root is also the name of the DFS namespace. A domain-based root adds fault-tolerant capabilities to DFS by allowing several servers to host the same DFS namespace root.
. DFS folder—A folder that will be presented under the root when a DFS client connects. When a root is created, folders can be created within the file system, but DFS folders allow the system to redirect clients to different systems other than the namespace server hosting the root.
. Folder target—A shared folder hosted on a Windows server. The DFS folder name and the share name do not need to be the same but for troubleshooting purposes it is highly recommended. Multiple folder targets can be assigned to a single DFS folder to provide fault tolerance. If a single folder target is unavailable, clients will be connected to another available target. When DFS folders are created with multiple folder targets, replication can also be configured using DFS replication groups to keep the data across the targets in sync. Folder targets can be a share name or a folder beneath a share. For example, \\server1\userdata or \\server1\userdata\Finance are both valid folder targets.
. DFS tree—The hierarchy of the namespace. For example, the DFS tree begins with the DFS root namespace and contains all the defined folders below the root.
. Referrals—A configuration setting of a DFS namespace and/or folder that defines how DFS clients will connect to the namespace server, a folder in the namespace, or a particular folder target server. Referral properties include limiting client connections to servers in the local Active Directory site and how often to check the availability of a DFS server. Disabling a target’s referral keeps it from being used by clients. Target referral can be disabled when maintenance will be performed on a server.
Depending on which Server version, service pack, and edition of Window Server 2003 or 2008 is used will determine how many namespaces are supported on a single server. Please refer to online Microsoft documentation to determine which edition is right for your organization’s implementation of DFS.
Source of Information : Sams - Windows Server 2008 R2 Unleashed (2010)
Tuesday, April 19, 2011
Distributed File System Replication
When an Active Directory domain exists, standalone and domain-based DFS namespaces support the replication of DFS data stored on multiple servers. This can be a valuable tool used to distribute company applications to each site or to provide centralized storage of remote office data for redundancy, centralized backup, and to support users who travel and work in different offices.
With the release of Windows Server 2003 R2 and further improved in Window Server 2008 R2, a service to extend the functionality and optimize DFS Replication has been created. This service is called the Distributed File System Replication (DFSR) service, which utilizes the new Remote Differential Compression (RDC) protocol. DFSR replaces the legacy File Replication Service (FRS) that was previously used to replicate DFS data. As long as all of the DFS servers defined in a DFS replication group are running Windows Server 2003 R2 or later, the DFSR service will be used to replicate the data. If any of the systems are running a previous version operating system, DFS data will be replicated using the File Replication Service. There is one exception to this rule: The Domain System Volume (SYSVOL) will be replicated between domain controllers using the File Replication Service, even if all the domain controllers are running Windows Server 2008 R2, until the domain functional level is raised to the Windows Server 2008 level and the SYSVOL is migrated from FRS to DFSR.
DFS Replication and DFS namespaces are independent of one another, but they can be used together, as they are commonly deployed in this fashion. Replication of folders can be set up between servers that do not host any DFS namespaces or namespace folders but the DFS Replication service must be installed on all systems participating in the replication. Windows Server 2008 R2 increases DFS Replication security and performance because all DFS Replication is compressed and encrypted. Note that the data stream cannot be set to run unencrypted.
Source of Information : Sams - Windows Server 2008 R2 Unleashed (2010)
With the release of Windows Server 2003 R2 and further improved in Window Server 2008 R2, a service to extend the functionality and optimize DFS Replication has been created. This service is called the Distributed File System Replication (DFSR) service, which utilizes the new Remote Differential Compression (RDC) protocol. DFSR replaces the legacy File Replication Service (FRS) that was previously used to replicate DFS data. As long as all of the DFS servers defined in a DFS replication group are running Windows Server 2003 R2 or later, the DFSR service will be used to replicate the data. If any of the systems are running a previous version operating system, DFS data will be replicated using the File Replication Service. There is one exception to this rule: The Domain System Volume (SYSVOL) will be replicated between domain controllers using the File Replication Service, even if all the domain controllers are running Windows Server 2008 R2, until the domain functional level is raised to the Windows Server 2008 level and the SYSVOL is migrated from FRS to DFSR.
DFS Replication and DFS namespaces are independent of one another, but they can be used together, as they are commonly deployed in this fashion. Replication of folders can be set up between servers that do not host any DFS namespaces or namespace folders but the DFS Replication service must be installed on all systems participating in the replication. Windows Server 2008 R2 increases DFS Replication security and performance because all DFS Replication is compressed and encrypted. Note that the data stream cannot be set to run unencrypted.
Source of Information : Sams - Windows Server 2008 R2 Unleashed (2010)
Monday, April 18, 2011
EVOLUTION OF VIRTUALIZATION
In the 1970s, mainframes ruled the datacenter. Partitioning ensured both optimum use and efficient sharing of resources. This was a great way to get the most for the many, many dollars organizations spent to acquire, implement, and manage these behemoths.
All processing was performed on a single computer with data retrieved from and stored to storage located in the datacenter. Access to the datacenter was tightly controlled. In many cases, users received reports from the computer operators through a window or slot. They accessed electronic information with dumb terminals with no local processing capabilities. The terminals were simple devices which collected keystrokes and presented data in green-screen text.
Distributed processing began in the 1980s, with personal computers finding their way to the desktop. These were fat clients which participated in client/server configurations and connected to the mainframe’s smaller cousin, the minicomputer. Although many companies still performed the bulk of their business processing in a centralized environment, both applications and data began to drift out to endpoint devices.
During the 1990s, another shift in business processing architecture took place with the advent of layered system technology. This included building applications with presentation and data access logic layers. Data resided in database servers in the datacenter. Still, fat client endpoint devices continued to run applications, and more data than ever before found its way to local hard drives. This was also a time when malware writers began perfecting their art. Attacks that eventually spread across entire enterprises often started on an unprotected—or weakly protected— personal computer.
In the twenty-first century, IT managers began to realize that traditional methods of managing desktop and laptop systems were no longer effective in dealing with changes in business requirements, user demands regarding technology implementations, and black hat hackers transitioning from fun and games to an organized crime business model. Demands for the rapid turnaround of application installation or upgrade requests, the need to quickly apply security patches to operating systems and applications, and many other management headaches are driving a new approach to endpoint and server processing and management— virtualization.
Source of Information : Elsevier-Microsoft Virtualization Master Microsoft Server Desktop Application and Presentation
All processing was performed on a single computer with data retrieved from and stored to storage located in the datacenter. Access to the datacenter was tightly controlled. In many cases, users received reports from the computer operators through a window or slot. They accessed electronic information with dumb terminals with no local processing capabilities. The terminals were simple devices which collected keystrokes and presented data in green-screen text.
Distributed processing began in the 1980s, with personal computers finding their way to the desktop. These were fat clients which participated in client/server configurations and connected to the mainframe’s smaller cousin, the minicomputer. Although many companies still performed the bulk of their business processing in a centralized environment, both applications and data began to drift out to endpoint devices.
During the 1990s, another shift in business processing architecture took place with the advent of layered system technology. This included building applications with presentation and data access logic layers. Data resided in database servers in the datacenter. Still, fat client endpoint devices continued to run applications, and more data than ever before found its way to local hard drives. This was also a time when malware writers began perfecting their art. Attacks that eventually spread across entire enterprises often started on an unprotected—or weakly protected— personal computer.
In the twenty-first century, IT managers began to realize that traditional methods of managing desktop and laptop systems were no longer effective in dealing with changes in business requirements, user demands regarding technology implementations, and black hat hackers transitioning from fun and games to an organized crime business model. Demands for the rapid turnaround of application installation or upgrade requests, the need to quickly apply security patches to operating systems and applications, and many other management headaches are driving a new approach to endpoint and server processing and management— virtualization.
Source of Information : Elsevier-Microsoft Virtualization Master Microsoft Server Desktop Application and Presentation
Thursday, April 14, 2011
Distributed File System Namespaces
DFS can be used in a few different ways, but it will usually require the creation of a DFS namespace. A DFS namespace can be the name of a single server and share folder or the DNS and NetBIOS name of an Active Directory domain and share folder. The DFS namespace is also referred to as the namespace root. The namespace allows connections to automatically be redirected to different servers without user knowledge. When a client connects to the domain DFS namespace named \\Companyabc.com\Apps, the client will be redirected to \\Server10\Apps, and the client will be unaware of this redirection.
For DFS to function properly with regard to client redirection and just basic connectivity, a compatible DFS client is required. In a network that supports different versions of Windows, Apple Mac, and UNIX clients, DFS should be tested on all clients before it is released to production. DFS-compatible clients are currently available for the following Microsoft Windows operating systems:
. Windows 2000 Professional and Server.
. Windows XP Professional.
. Windows Server 2003 and Windows Server 2003 R2.
. Windows Vista Business, Ultimate, and Enterprise.
. Windows 7 Professional, Ultimate, and Enterprise.
. Windows Server 2008 and Windows Server 2008 R2.
. Windows NT Server and Workstation 4.0 with Service Pack 6a and the Active Directory Client Extension found on the Windows 2000 Server CD.
. Windows 98 can support DFS domain namespaces with the installation of the Active Directory Client Extension found on the Windows 2000 Server CD.
Because DFS clients do not connect to the actual server by name, administrators can move shared folders to new servers and user logon scripts and mapped drive designations never need to be changed. In fact, DFS data presented in a single namespace can be hosted on multiple servers to provide redundancy and distribution of large amounts of data.
Standalone DFS Namespace
A standalone DFS namespace utilizes the name of the server hosting the DFS namespace.
Standalone DFS namespaces should be used when file system access needs to be simplified and the amount of data exceeds the capacity of a single server. Also, if no Active Directory domain exists, a standalone DFS namespace is still supported. When a standalone DFS namespace is created on a Windows Server 2008 R2 server that is a member of an Active Directory domain, DFS replication can be configured.
Domain-Based DFS Namespace
A domain-based DFS namespace utilizes the name of the Active Directory domain the DFS namespace server is a member of. A domain-based DFS namespace is created upon deployment of an Active Directory domain at the location of \\domain\SYSVOL to replicate the domain group policies and logon script folders. Domain-based DFS namespaces support replication using either the File Replication Service or the new Distributed File System Replication service.
Domain-Based DFS Namespace Windows 2008 Mode
When a new domain-based DFS namespace is created on a Windows Server 2008 R2 system, an option to enable Windows Server 2008 mode is presented. This option is available on Windows Server 2008 and Windows Server 2008 R2 systems when the namespace is hosted on either operating system, and the domain the system is a member of must be running in Windows Server 2008 domain functional level and at least Window Server 2003 forest functional level. This means that the domain must have only Windows Server 2008 domain controllers and the entire forest must have only Windows 2003 and/or Windows 2008 domain controllers.
Windows Server 2008 mode enables the namespace to contain more than 5,000 DFS folders and it also enables access-based enumeration within the DFS namespace. Historically, many organizations ran into issues when deploying DFS because over time, the number of folders beneath a namespace grew too large and they had to create multiple namespaces and segregate the data, which in some cases defeated the purpose for deploying DFS. Windows Server 2008 namespace mode surpasses this previous limitation and with the added bonus of access-based enumeration, it allows for users to locate the data that is relevant to them much easier.
It is important to note that the same functionality enabled for a Windows 2008 mode domain-based namespace exists on standalone DFS namespaces when the namespace server is hosted on a Windows Server 2008 R2 server, so this functionality can be leveraged immediately, even in organizations that are far from meeting the requirements for Windows 2008 mode domain-based namespaces.
Source of Information : Sams - Windows Server 2008 R2 Unleashed (2010)
For DFS to function properly with regard to client redirection and just basic connectivity, a compatible DFS client is required. In a network that supports different versions of Windows, Apple Mac, and UNIX clients, DFS should be tested on all clients before it is released to production. DFS-compatible clients are currently available for the following Microsoft Windows operating systems:
. Windows 2000 Professional and Server.
. Windows XP Professional.
. Windows Server 2003 and Windows Server 2003 R2.
. Windows Vista Business, Ultimate, and Enterprise.
. Windows 7 Professional, Ultimate, and Enterprise.
. Windows Server 2008 and Windows Server 2008 R2.
. Windows NT Server and Workstation 4.0 with Service Pack 6a and the Active Directory Client Extension found on the Windows 2000 Server CD.
. Windows 98 can support DFS domain namespaces with the installation of the Active Directory Client Extension found on the Windows 2000 Server CD.
Because DFS clients do not connect to the actual server by name, administrators can move shared folders to new servers and user logon scripts and mapped drive designations never need to be changed. In fact, DFS data presented in a single namespace can be hosted on multiple servers to provide redundancy and distribution of large amounts of data.
Standalone DFS Namespace
A standalone DFS namespace utilizes the name of the server hosting the DFS namespace.
Standalone DFS namespaces should be used when file system access needs to be simplified and the amount of data exceeds the capacity of a single server. Also, if no Active Directory domain exists, a standalone DFS namespace is still supported. When a standalone DFS namespace is created on a Windows Server 2008 R2 server that is a member of an Active Directory domain, DFS replication can be configured.
Domain-Based DFS Namespace
A domain-based DFS namespace utilizes the name of the Active Directory domain the DFS namespace server is a member of. A domain-based DFS namespace is created upon deployment of an Active Directory domain at the location of \\domain\SYSVOL to replicate the domain group policies and logon script folders. Domain-based DFS namespaces support replication using either the File Replication Service or the new Distributed File System Replication service.
Domain-Based DFS Namespace Windows 2008 Mode
When a new domain-based DFS namespace is created on a Windows Server 2008 R2 system, an option to enable Windows Server 2008 mode is presented. This option is available on Windows Server 2008 and Windows Server 2008 R2 systems when the namespace is hosted on either operating system, and the domain the system is a member of must be running in Windows Server 2008 domain functional level and at least Window Server 2003 forest functional level. This means that the domain must have only Windows Server 2008 domain controllers and the entire forest must have only Windows 2003 and/or Windows 2008 domain controllers.
Windows Server 2008 mode enables the namespace to contain more than 5,000 DFS folders and it also enables access-based enumeration within the DFS namespace. Historically, many organizations ran into issues when deploying DFS because over time, the number of folders beneath a namespace grew too large and they had to create multiple namespaces and segregate the data, which in some cases defeated the purpose for deploying DFS. Windows Server 2008 namespace mode surpasses this previous limitation and with the added bonus of access-based enumeration, it allows for users to locate the data that is relevant to them much easier.
It is important to note that the same functionality enabled for a Windows 2008 mode domain-based namespace exists on standalone DFS namespaces when the namespace server is hosted on a Windows Server 2008 R2 server, so this functionality can be leveraged immediately, even in organizations that are far from meeting the requirements for Windows 2008 mode domain-based namespaces.
Source of Information : Sams - Windows Server 2008 R2 Unleashed (2010)
Monday, April 11, 2011
Windows Server 2008 - The Distributed File System
To improve the reliability and availability of file shares in an enterprise network, Microsoft has developed the Distributed File System (DFS). DFS improves file share availability by providing a single, unified namespace to access shared folders hosted across one or more servers. A user needs to only remember a single server or domain name and share name to connect to a DFS shared folder. DFS has many benefits and features that can simplify data access and management from both the administrator and end-user perspective. DFS provides three main functions, as follows:
. Data redundancy—DFS can provide access to a single share that is hosted on multiple servers. This allows clients to get referred to or fail over to a different server if the primary server cannot be contacted.
. Automated data replication—DFS can be configured to utilize the Distributed File System Replication (DFSR) service, and can be configured to automatically synchronize folders between DFS servers to provide data redundancy or centralized storage of branch office data.
. Distributed data consolidation—DFS can be used to provide a single namespace that can contain several distinct or unique data sets, which can be hosted on separate servers. This enables administrators to provide access to existing file shares hosted on many different file servers, from the single namespace, without adding replication or redundant data sets.
Source of Information : Sams - Windows Server 2008 R2 Unleashed (2010)
. Data redundancy—DFS can provide access to a single share that is hosted on multiple servers. This allows clients to get referred to or fail over to a different server if the primary server cannot be contacted.
. Automated data replication—DFS can be configured to utilize the Distributed File System Replication (DFSR) service, and can be configured to automatically synchronize folders between DFS servers to provide data redundancy or centralized storage of branch office data.
. Distributed data consolidation—DFS can be used to provide a single namespace that can contain several distinct or unique data sets, which can be hosted on separate servers. This enables administrators to provide access to existing file shares hosted on many different file servers, from the single namespace, without adding replication or redundant data sets.
Source of Information : Sams - Windows Server 2008 R2 Unleashed (2010)
Thursday, April 7, 2011
Windows Server 2008 File Management Tasks
File Management tasks is a new feature within the FSRM console. File Management tasks can be run out of the box on a Windows Server 2008 R2 system, to either expire classified files that meet a certain criteria, by moving these files to a designated folder location, or to perform a custom task. This can be a handy tool to automatically move files that have not been accessed in an extended period of time. Or, in the case of sensitive data, such as files that might contain passwords, this tool can be used to create a custom script to move the classified files to a designated, secured folder, and leave a link or note in the original location to instruct any users on how to regain access to that file. Of course, this logic would need to be created by an administrator because this functionality is not included out of the box. As an example, to create a new File Management Task to move files that have not been accessed in over a year, perform the following steps on a Windows Server 2008 R2 system with the FSRM service and tool installed:
1. Log on to a Windows Server 2008 R2 system with the FSRM service and tool installed, with an account with administrative rights.
2. Click Start, click All Programs, click Administrative Tools, and select Server Manager.
3. Expand Roles, expand File Services, expand Share and Storage Management, and double-click on the File Server Resource Manager node beneath it.
4. Double-click File Management Tasks node beneath the File Server Resource Manager node.
5. In the Actions pane, click the Create File Management Task link to start the process.
6. In the Create File Management Task window, on the General tab, type in a task name of Move Data not accessed in 1 year and enter a description as desired.
7. In the Scope section, click the Add button to locate and add the folder, folders, or volumes to this task.
8. Click on the Action tab and for action type, choose File Expiration, and in the expiration directory, type or browse to a volume and folder location to where the files that meet this criteria should be moved.
9. Click on the Notification tab and click the Add button to add notifications to users and administrators so they can be notified of when particular files will be considered expired and moved to the expiration directory.
10. Back in the Create File Management Task window, click on the Condition tab and check the Day Since File Was Last Accessed check box and enter a value of 365.
11. In the Effective Starting section, enter the date that files will actually begin expiration; this date should be more than the amount of days included in any notification.
12. Click on the Schedule tab, click the Create button and create a new schedule. Click OK until the windows are closed to complete the creation of the file management task. Depending on the date chosen for the effective date, a pop-up might open stating that the effective date must be pushed forward to ensure that users are notified in advance before their data is moved.
Once the task is completed, it will run on the designated schedule and will begin notifying administrators and users when files will be moved. One important point to consider is that once a file is expired and moved, there will be no indication of where or when that file was moved when users go to the original location of the expired file. Much more can be done with file management tasks, including performing custom actions on files that have been previously classified, and it is recommend that any organization wanting to leverage this new File Classification Infrastructure test it thoroughly on copied data in an isolated lab network.
Source of Information : Sams - Windows Server 2008 R2 Unleashed (2010)
1. Log on to a Windows Server 2008 R2 system with the FSRM service and tool installed, with an account with administrative rights.
2. Click Start, click All Programs, click Administrative Tools, and select Server Manager.
3. Expand Roles, expand File Services, expand Share and Storage Management, and double-click on the File Server Resource Manager node beneath it.
4. Double-click File Management Tasks node beneath the File Server Resource Manager node.
5. In the Actions pane, click the Create File Management Task link to start the process.
6. In the Create File Management Task window, on the General tab, type in a task name of Move Data not accessed in 1 year and enter a description as desired.
7. In the Scope section, click the Add button to locate and add the folder, folders, or volumes to this task.
8. Click on the Action tab and for action type, choose File Expiration, and in the expiration directory, type or browse to a volume and folder location to where the files that meet this criteria should be moved.
9. Click on the Notification tab and click the Add button to add notifications to users and administrators so they can be notified of when particular files will be considered expired and moved to the expiration directory.
10. Back in the Create File Management Task window, click on the Condition tab and check the Day Since File Was Last Accessed check box and enter a value of 365.
11. In the Effective Starting section, enter the date that files will actually begin expiration; this date should be more than the amount of days included in any notification.
12. Click on the Schedule tab, click the Create button and create a new schedule. Click OK until the windows are closed to complete the creation of the file management task. Depending on the date chosen for the effective date, a pop-up might open stating that the effective date must be pushed forward to ensure that users are notified in advance before their data is moved.
Once the task is completed, it will run on the designated schedule and will begin notifying administrators and users when files will be moved. One important point to consider is that once a file is expired and moved, there will be no indication of where or when that file was moved when users go to the original location of the expired file. Much more can be done with file management tasks, including performing custom actions on files that have been previously classified, and it is recommend that any organization wanting to leverage this new File Classification Infrastructure test it thoroughly on copied data in an isolated lab network.
Source of Information : Sams - Windows Server 2008 R2 Unleashed (2010)
Monday, April 4, 2011
Windows Server 2008 File Classification Rules
Once the file administrator has created the necessary file classification properties, they can proceed in creating classification rules that will actually process and classify the files that meet the rule criteria, by applying the necessary classification property values to the file collections. To create a new classification rule, perform the following steps:
1. Log on to the same Windows Server 2008 R2 system that the Files with Passwords classification property was previously defined on, with an account with administrative rights.
2. Click Start, click All Programs, click Administrative Tools, and select Server Manager.
3. Expand Roles, expand File Services, expand Share and Storage Management, and double-click on the File Server Resource Manager node beneath it.
4. Double-click Classification Management and select the Classification Rules node.
5. In the Actions pane, click on the Create a New Rule link to start the creation of a new classification rule.
6. In the Classifications Rule Definitions window, type in the name of the rule as Classify files with passwords and enter a description.
7. In the Scope section of the page, click the Add button to define the volumes and or folders that this classification rule will be applied to. For our example, we will apply this rule to E:\ITDept. When the location is specified, all subfolders will be included.
8. Once the name, description, and file locations are defined, click on the Classification tab and select Content Classifier from the Classification mechanism drop-down menu.
9. In the Property Name section, select the Files with Passwords property and set the property value to be assigned as Yes.
10. Click the Advanced button to set the additional parameters that will actually be used to determine if the files match the criteria and should be classified with the property defined in this rule.
11. In the Additional Rule Parameters window, select the Additional Classification Parameters tab. On this tab, administrators can define three different types of criteria used to search with a files content. These three types are as follows:
» RegularExpression—The RegularExpression is the same as is used with .NET programming and can be used to find complex or multiple types of data formats, for more complex searches.
» String—The String type is used to find a very specific string, such as password that will not be dependent on the case of the string, although the string must be an exact match. For example, the string password will not match passwords, as that is a different string.
» StringCaseSensitive—The StringCaseSensitive is the same as the string, in that the entire string must be an exact match, but the case must match. For example, the StringCaseSensitive string of Password will not match the string password.
12. For our example, we will specifically look for the word password and will not care about the case. In the Name section, type in String and in the value type in password. Click OK when completed.
13. Back on the Classification Rule Definitions page, click OK to complete the rule creation.
Once the rule is created, it can be scheduled or run manually. To run all of the rules manually, in the tasks pane, right-click on the Classification Rules node and select Run Classification with All Rules Now. Follow the steps to select the type of report that will be generated and whether the administrator will wait for the classification to complete and display the window or to have the process run in the background. If a schedule or a manual run is performed, any files that meet the properties of any enabled classification rules will be classified, unless these files have been previously classified.
Source of Information : Sams - Windows Server 2008 R2 Unleashed (2010)
1. Log on to the same Windows Server 2008 R2 system that the Files with Passwords classification property was previously defined on, with an account with administrative rights.
2. Click Start, click All Programs, click Administrative Tools, and select Server Manager.
3. Expand Roles, expand File Services, expand Share and Storage Management, and double-click on the File Server Resource Manager node beneath it.
4. Double-click Classification Management and select the Classification Rules node.
5. In the Actions pane, click on the Create a New Rule link to start the creation of a new classification rule.
6. In the Classifications Rule Definitions window, type in the name of the rule as Classify files with passwords and enter a description.
7. In the Scope section of the page, click the Add button to define the volumes and or folders that this classification rule will be applied to. For our example, we will apply this rule to E:\ITDept. When the location is specified, all subfolders will be included.
8. Once the name, description, and file locations are defined, click on the Classification tab and select Content Classifier from the Classification mechanism drop-down menu.
9. In the Property Name section, select the Files with Passwords property and set the property value to be assigned as Yes.
10. Click the Advanced button to set the additional parameters that will actually be used to determine if the files match the criteria and should be classified with the property defined in this rule.
11. In the Additional Rule Parameters window, select the Additional Classification Parameters tab. On this tab, administrators can define three different types of criteria used to search with a files content. These three types are as follows:
» RegularExpression—The RegularExpression is the same as is used with .NET programming and can be used to find complex or multiple types of data formats, for more complex searches.
» String—The String type is used to find a very specific string, such as password that will not be dependent on the case of the string, although the string must be an exact match. For example, the string password will not match passwords, as that is a different string.
» StringCaseSensitive—The StringCaseSensitive is the same as the string, in that the entire string must be an exact match, but the case must match. For example, the StringCaseSensitive string of Password will not match the string password.
12. For our example, we will specifically look for the word password and will not care about the case. In the Name section, type in String and in the value type in password. Click OK when completed.
13. Back on the Classification Rule Definitions page, click OK to complete the rule creation.
Once the rule is created, it can be scheduled or run manually. To run all of the rules manually, in the tasks pane, right-click on the Classification Rules node and select Run Classification with All Rules Now. Follow the steps to select the type of report that will be generated and whether the administrator will wait for the classification to complete and display the window or to have the process run in the background. If a schedule or a manual run is performed, any files that meet the properties of any enabled classification rules will be classified, unless these files have been previously classified.
Source of Information : Sams - Windows Server 2008 R2 Unleashed (2010)
Friday, April 1, 2011
Windows Server 2008 File Classification Management Properties
Classification properties are used to categorize files to be used later for file management tasks or reporting. A classification property, as included with Windows Server 2008 R2, includes the following classification property types:
. Yes/No
. Date-time
. Number
. Ordered List
. String
. Multichoice
. Multistring
To get a good understanding of how classification can be used, this section provide an example of how classification can be used to classify files based on content that includes the word password. To do this, we will create a file property type of Yes/No and create a classification rule to search the E:\ITDept folder for any files containing the word and to classify these files as necessary. To perform this task, we must first create the classification property. Perform the following steps to create the classification property:
1. Log on to a Windows Server 2008 R2 system with the FSRM service and tool installed, with an account with administrative rights.
2. Click Start, click All Programs, click Administrative Tools, and select Server Manager.
3. Expand Roles, expand File Services, expand Share and Storage Management, and double-click on the File Server Resource Manager node beneath it.
4. Double-click Classification Management and select the Classification Properties node.
5. In the Actions pane, click on the Create Property link to start the creation of the classification property.
6. In the Create Classification Property Definition window, type Files with Passwords in the Property name section, enter a description, and choose the Property type of Yes/No.
7. In the Value section, enter a description as desired and click OK to create the classification property.
Once the new classification property is created, we can create a classification rule that will use this property to classify files that the rule determines to meet the criteria.
Source of Information : Sams - Windows Server 2008 R2 Unleashed (2010)
. Yes/No
. Date-time
. Number
. Ordered List
. String
. Multichoice
. Multistring
To get a good understanding of how classification can be used, this section provide an example of how classification can be used to classify files based on content that includes the word password. To do this, we will create a file property type of Yes/No and create a classification rule to search the E:\ITDept folder for any files containing the word and to classify these files as necessary. To perform this task, we must first create the classification property. Perform the following steps to create the classification property:
1. Log on to a Windows Server 2008 R2 system with the FSRM service and tool installed, with an account with administrative rights.
2. Click Start, click All Programs, click Administrative Tools, and select Server Manager.
3. Expand Roles, expand File Services, expand Share and Storage Management, and double-click on the File Server Resource Manager node beneath it.
4. Double-click Classification Management and select the Classification Properties node.
5. In the Actions pane, click on the Create Property link to start the creation of the classification property.
6. In the Create Classification Property Definition window, type Files with Passwords in the Property name section, enter a description, and choose the Property type of Yes/No.
7. In the Value section, enter a description as desired and click OK to create the classification property.
Once the new classification property is created, we can create a classification rule that will use this property to classify files that the rule determines to meet the criteria.
Source of Information : Sams - Windows Server 2008 R2 Unleashed (2010)
Subscribe to:
Posts (Atom)