Microsoft released the File Server Migration Toolkit version 1.2 (FSMT 1.2), which will help you migrate file shares from computers running Windows NT 4.0 Server, Windows 2000 Server, Windows 2003 Server, Windows Server 2008 and Windows Storage Server 2008 to computers running Windows 2003 Server, Windows Server 2008 and Windows Storage Server 2008. You can use it to consolidate multiple file servers or simply to migrate files between servers.
This is an update to the previous FSMT 1.1 that fixes an issue with Windows Server 2003 clusters. This version has also been tested with the Windows Server 2008 R2 Release Candidate (full support for Windows Server 2008 R2 is expected and will become official after tests with the final release, which should be out later this year).
Here are the main benefits of FSMT:
- Simplifies the complex and error-prone migration process of SMB shares and data
- Maintains UNC paths and eliminates broken shortcuts and links
- Maintains security settings after the migration
- Consolidates shared folders with the same names from different servers
- Supports server clusters as source and target file servers
- Provides roll-back functionality
- Support for Windows Server 2008 and Windows Storage Server 2008
- Includes both the DFS Consolidation Root Wizard and the Dfsconsolidate.exe command-line tool
- Available in 5 languages (English, French, German, Japanese and Spanish)
Here’s a screenshot:
Download and test it today from
http://www.microsoft.com/downloads/details.aspx?FamilyID=d00e3eae-930a-42b0-b595-66f462f5d87b&DisplayLang=en
Also, be sure to also visit the FSMT Web Site at
http://go.microsoft.com/fwlink/?LinkId=128527
The previous posts in this series explained how to create a Windows Failover cluster and how to configure DFS Replication for high availability on that cluster respectively. Now, it is time to add the failover cluster as a member of a replication group.
Pre-deployment notes
-
The other non-clustered replication member servers in the replication group can be running Windows Server 2003 R2, Windows Server 2008 or Windows Server 2008 R2. It is not a requirement to have all members of that replication group on Windows Server 2008 R2 in order to deploy a clustered replication member in that replication group.
-
After adding a failover cluster to a replication group, the replication group can be administered only using the DFS Management MMC snap-in that ships on Windows Server 2008 R2. The DFS Management MMC snap-in on member servers which are running Windows Server 2003 R2 or Windows Server 2008 will not be able to configure/manage a replication group that has a failover cluster as a replication member.
The steps to create a new replication group are listed below. Before proceeding, please make sure that the DFS Replication service is installed and started on all the nodes of the failover cluster. Additionally, you will also need to have the Remote Server Administration Tools feature installed on the cluster nodes for configuring and administering replication. The DFS Management MMC snap-in that ships on Windows Server 2008 R2 is also available for download via the ‘Remote Server Administration Tools package for Windows 7’. This package enables IT administrators to manage roles and features that are installed on computers that are running Windows Server 2008 R2, Windows Server 2008, or Windows Server 2003, from a remote computer that is running Windows 7 RC.
Step-by-step instructions for installing the DFS Replication service and the DFS Management console are available in a previous blog post. The below Server Manager screenshot illustrates a server on which DFS Replication has been installed.
Adding a Failover cluster to a replication group
Now, let’s take a look at how to configure a folder for replication between a couple of member servers, one of which will be clustered. Note that any/all members of a replication group can be clustered using the exact same instructions available in this series of blog posts – there are no restrictions on the number of clustered member servers in a replication group. We will configure a folder containing reports to be replicated to Contoso’s clustered hub server from the server in the branch office, so it can be backed up centrally at the hub server using backup software such as Microsoft’s System Center Data Protection Manager. For a quick recap, the replication topology we are going to configure looks similar to the below illustration.
Step 1: Launch the DFS Management Console (on the cluster node ‘PrimaryNode’).
The DFS Management console (dfsmgmt.msc) is an MMC snap-in that can be used to configure and manage DFS Namespaces as well as DFS Replication. The MMC snap-in is launched on the primary/active node of the failover cluster (called ‘PrimaryNode’ in this example).
 Note: | Please note that the new Windows Server 2008 R2 features (read-only replicated folders and clustered DFS Replication) can be configured only using the DFS Management snap-in that ships on Windows Server 2008 R2. The DFS Management console on Windows Server 2003 R2 or Windows Server 2008 servers cannot be used to configure read-only replicated folders or to configure DFS Replication on a failover cluster. |
Select ‘Replication’ in the left hand side pane in order to configure and manage DFS Replication. The ‘Actions’ pane on the right can be used to configure replication groups and folders that need to be replicated using DFS Replication.
Step 2: Click on the ‘New Replication Group…’ action.
In the ‘Actions’ pane on the right, click on ‘New Replication Group…’. This launches the ‘New Replication Group Wizard’, which is illustrated in the below screenshot. The wizard walks through a set of operations that need to be performed while configuring the new replication group.
Step 3: Select the type of replication group.
First of all, select the type of replication group to be created. The ‘Multipurpose replication group’ can be used to configure custom replication topologies. This type of replication group can be used to create replication topologies such as ‘hub and spoke’ and ‘full mesh’. It is also possible to create a custom replication topology by first adding a set of servers to the replication group and then configuring custom connections between them to achieve the desired custom replication topology.
The second type of replication group (‘Replication group for data collection’) is a special type of replication topology and is used to add two servers to a replication group in such a way that a hub (destination) server can be configured to collect data from another branch server. The steps are slightly different for these two types of replication group, but the wizard provides helpful information along the way.
Let’s select ‘Replication group for data collection’ for this configuration since we would like to replicate data from the branch office server to the clustered hub server for centralized backup using backup software running on the hub server. In order to configure multiple such branch office file servers for centralized backup in this manner, create multiple replication groups such as this one. Thereafter, configure backup software such as Microsoft’s System Center Data Protection Manager to centrally backup the data consolidated (using DFS Replication) on the hub server from multiple branch office file servers.
Step 4: Select the name and domain for the replication group.
In the ‘Name and Domain’ wizard page that follows, enter a name for the replication group as well as the domain in which to create the replication group. We’re creating a replication group called ‘ContosoBackup’ in this example.
In practice, you may want to name each replication group such that you can easily identify the branch office from which data is consolidated by virtue of the replicated folders configured in that group. For example, the ‘ContosoSales’ replication group is configured to consolidate data from the sales branch office, while ‘ContosoDesign’ is used to consolidate data from the design office etc.
Step 5: Specify the branch office file server (replication member)
In the ‘Branch Server’ wizard page that follows, enter the hostname of the branch office file server. In this case, we’re adding Contoso’s branch office file server. Data from this server will be replicated over the WAN to the central clustered file server we have just set up, for centralized backup using backup software.
Conceptually, to deploy such a solution for centralized branch office backup of multiple branch offices, you would need to create one such replication group for each branch office, with the clustered hub server as a replication partner (Branch Server) for all these replication groups.
Step 6: Select the folders to replicate from the branch office server.
In the ‘Replicated Folders’ wizard page that follows, click the ‘Add…’ button and enter the names of the replicated folders which are to be replicated from this branch office file server to the hub server. Multiple replicated folders can be added on this wizard page. In this example, we have selected to replicate the folder ‘D:\Reports’ from the branch office file server.
Step 7: Specify the hub server (other replication member)
In the ‘Hub Server’ wizard page that follows, the name of the hub server for this replication group needs to be specified. In this example, we want to consolidate data from the branch office file server to the clustered hub server at the datacenter. Therefore, we will enter the failover cluster’s client access point here.
IMPORTANT: This is the most important step to be taken while configuring DFS Replication on a Windows Failover cluster. Here, instead of hostname of the individual server, enter the Client Access Point for the failover cluster you wish to add as a replication member.
In the previous blog post, we took a look at how configure a highly available file server on the cluster we created. This highly available file server was configured to be accessed through a Client Access Point called ‘ContosoFileSrv’. This Client Access Point name needs to be entered here.
|
Note: | If you are creating a multi-purpose replication group, the only difference between adding a regular member server and a clustered member server is that you would need to specify the Client Access Point for a clustered member server. For a regular member server, specify the hostname of the server. Generically speaking: |
Step 8: Specify the path to the replicated folder on the hub server.
In the ‘Target Folder on Hub Server’ wizard page, specify the path on the clustered hub server where you would like to store the data replicated from the branch office file server.
This can be done by clicking on the ‘Browse…’ button and selecting a path from the ‘Browse For Folder’ dialog box. Note that this dialog box only displays shared volumes. This is because on a failover cluster, the replicated folder should be hosted only on shared storage. This enables replication responsibilities to be failed over between the nodes in the cluster.
Note how the below ‘Browse For Folder’ dialog box only displays shared volumes (cluster volumes). In this example, we have selected to consolidate the data replicated in from the branch office file server to a directory called ‘Contoso-Branch’ on the clustered hub server. Note that this directory is located on the shared/clustered volume ‘G:’. This ensures that replication responsibilities can be failover between the cluster nodes.
Step 9: Configure the replication schedule and bandwidth utilization.
Using the ‘Replication Group Schedule and Bandwidth’ wizard page, a custom replication schedule and custom bandwidth throttling settings can be configured. The default option configures the DFS Replication service to replicate continuously without any bandwidth restrictions.
It is possible to configure replication to take place during specific time windows (such as, after office hours to ensure reduced consumption of available WAN bandwidth). This can be done by selecting the option ‘Replicate during the specified days and times’ and then selecting the replication schedule in the wizard page that is launched. For example, the below screenshot illustrates how replication has been configured using all available bandwidth between 6pm and 6am (after office hours).
That’s it! The replication group can now be created. The confirmation dialog box displays the status of this configuration task.
Remember that replication does not begin until the configuration settings for this new replication group have replicated to the domain controller that is polled for configuration information by the DFS Replication service on the replication group members. Therefore, there will be a delay corresponding to the time it takes for the new configuration settings to replicate between domain controllers in the domain and the time taken for all replication member servers to receive these configuration changes from Active Directory.
Once the replication group has been configured, it will show up in the DFS Management MMC snap-in. For example, the below screenshot shows that a replication group called ‘ContosoBackup’ has been created with two replication member servers – the branch office file server (‘CONTOSO-BRANCH’) and the 2-node clustered file server at the datacenter (‘CONTOSOFILESRV’). These two servers replicate a folder called ‘Reports’ between themselves. The configuration is such that the data generated on the branch office file server (CONTOSO-BRANCH) is replicated over WAN links to the central datacenter file server cluster (CONTOSOFILESRV) for centralized backup.
In order to consolidate data from multiple branch office file servers to this file server cluster, create more such replication groups.
|
Note: | Active Directory replication ensures that changes in configuration are replicated amongst all domain controllers so that any domain controller polled by the DFS Replication service has up to date configuration information. Therefore, the rate at which the DFS Replication service notices changes in configuration information is dependent on AD replication latencies as well as the frequency with which it polls Active Directory for configuration information. Hence, it will take a while before the DFS Replication service on the replication member servers notices this change and sets up replication. |
… Now, over to Failover Cluster Manager
Now that we have created a replication group and added the failover cluster as a member server, let us take a look at the Failover Cluster Manager MMC snap-in to see if something has changed there. After the DFS Replication service on the cluster node polls Active Directory and notices that a new replication group has been created with it as a replication member, it will automatically create a cluster resource for every replicated folder in that group. This will be done by the DFS Replication service running on the node that currently owns the client access point/cluster group against which replication has been configured.
Note that the DFS Replication service maintains one cluster resource per replicated folder.
The above screenshot shows that a new cluster resource of type ‘DFS Replicated Folders’ has been created. Notice how the resource name is a combination of the replicated folder name and the path to the replicated folder. This resource is online and the cluster node ‘PrimaryNode’ is currently responsible for replicating data with the CONTOSO-BRANCH server (replication partner).
This cluster resource can now be taken offline or moved to the other node of the failover cluster (‘SecondaryNode’) in case of planned failovers for maintenance of the primary node. Also, if the primary node of the failover cluster were to suffer outages, the Failover Clustering service will automatically move this resource over to the secondary node of the failover cluster. Correspondingly, the secondary node of the failover cluster will now take over replication responsibilities. The DFS Replication service on other replication partners will notice a minor glitch while the failover process is taking place, but will then continue to replicate with the failover cluster as usual (with the secondary node having taken over responsibilities for replication).
Some notes on administering replication on the failover cluster
The DFS Replication service automatically creates and deletes its cluster resources. There is no need for administrators to manually create or configure cluster resources for the DFS Replication service. Regular administrative tasks for the DFS Replication service can be performed using the DFS Management console (including creating new replicated folders, deleting/disabling replicated folders, changing staging areas and quotas, modifying connections, configuring bandwidth throttling and replication schedules etc.). The DFS Replication service will automatically configure and update its cluster resources when it notices these configuration changes after polling Active Directory.
For instance, if a replicated folder is disabled using the DFS Management Console, the corresponding cluster resource will be deleted and will disappear from the Failover Cluster Manager MMC snap-in, as soon as the DFS Replication service polls Active Directory. Subsequently, if the replicated folder is re-enabled using the DFS Management snap-in, a corresponding cluster resource appears in the Failover Cluster Manager MMC snap-in. This happens as soon as the DFS Replication service polls Active Directory and notices the change to ‘Enabled’.
Each replicated folder configured with the cluster as a member server will have one such cluster resource. The resource status can be toggled between ‘Online’ and ‘Offline’ states using the Failover Cluster Manager snap-in, similar to any other cluster resource.
Right clicking the resource brings up its properties, which provides a quick way to view the configuration information for the replicated folder, such as the folder name, path, staging path and whether the folder has been configured to be read-only.
Using the Failover Cluster Manager MMC snap-in, the ownership of a particular cluster group can be moved between the nodes of the cluster group if required. All replicated folders belonging to a particular replication group will be part of a single cluster group and therefore only a single node in the cluster can assume ownership and replication responsibilities for those replicated folders at any given point in time.
The regular administration primitives exposed by the Failover Cluster Manager MMC snap-in can be used to move a cluster group containing replicated folders between the cluster nodes that can be potential owners of that cluster group.
Using these steps it is possible to configure a replication member server on a Windows Failover Cluster for highly available replication services.
All posts in this series:
-
-
-
-------
Mahesh Unnikrishnan
In the previous blog post we examined how to create a Windows Failover Cluster for Contoso. Now, let’s examine the steps involved in configuring a highly available file server on this new failover cluster. It is highly recommended to read the previous post first to gain valuable context about the sample deployment scenario that is referenced in the steps below.
By virtue of configuring a high available file server on this cluster, the DFS Replication service also gets configured automatically for high availability. A detailed step-by-step procedure follows.
Configuring high availability for the DFS Replication service
In this section, we take a look at the steps required for configuring a highly available file server on this newly created failover cluster. As a result of these steps, the DFS Replication service also gets configured automatically for high availability. Thereafter, this failover cluster can be added to a DFS replication group.
To begin, select ‘Configure a Service or Application…’ either from the ‘Configure’ section or from the ‘Actions’ pane on the right side of the Failover Cluster Manager (cluadmin.msc) MMC snap-in.
This brings up the ‘High Availability Wizard’. The wizard is used to configure high availability for a particular application or service.
In the next page, a list of applications or services that can be configured for high availability using Windows Failover Clustering is displayed. Here, select ‘File Server’ from the list.
NOTE: Selecting ‘File Server’ from the list below also automatically configures the DFS Replication service for high availability.
In the ‘Client Access Point’ wizard page that follows, select a Client Access Point for this service. This is the name that clients of the newly clustered file server will use when connecting to it. Remember that this also becomes the name of the replication member server that will be configured on this failover cluster.
In this example, we have selected ‘ContosoFileSrv’ as the client access point through which the file server will be exposed by this cluster. Remember this name since we will later use it when adding the failover cluster to the replication group.
In the ‘Select Storage’ wizard page that follows, select the shared storage which is available to the clustered file server from the pool of available volumes. In this example, we have chosen to make ‘volume G’ (residing on cluster disk 1) and ‘volume I’ (residing on cluster disk 3) available to the clustered file server instance we’re creating. The data hosted on this clustered file server (or replication member server) will need to be located on these shared disks in order for it to be failed over amongst the nodes of the failover cluster.
Thereafter, click ‘Next’ at the ‘Confirmation’ screen that follows and the failover cluster gets configured to provide a highly available file server. A ‘Summary’ page at the end of the wizard displays the status of this task.
That’s it! We now have a two-node Windows Failover cluster that has been configured to provide a highly available file server for Contoso. Notice that a new instance called ‘ContosoFileSrv’ has appeared under the ‘Services and applications’ node in the left side pane of the Failover Cluster Manager. On selecting this instance, the central pane shows a summary. This clustered file server instance is now online on the cluster node called ‘PrimaryNode’ and has two shared disks available to it.
At this point, the Windows Failover cluster is ready to be added to a replication group as a member server. The next blog post in this series covers the steps that need to be taken in order to add this cluster to a replication group.
All posts in this series:
-
-
-
-------
Mahesh Unnikrishnan
On Windows Server 2008 R2, a Windows Failover cluster can be configured to be a member of a DFSR replication group. This feature can be used to configure highly available replication services. In this three part blog series, let us examine how to configure a Windows Failover cluster as a DFS Replication member server. For a quick recap of the new features in DFS Replication on Windows Server 2008 R2, head here.
The first step is to validate the available hardware that will be used for clustering and to create a Windows Failover Cluster. The next post in this series covers the steps required to configure high availability for the DFS Replication service. The third and final post in this series covers the steps required to add the failover cluster to a replication group.
Deployment Scenario
Before we start, let us examine the deployment scenario for which we are creating this failover cluster. In order to implement a highly available replication infrastructure, Contoso plans to deploy a 2-node failover cluster at it's datacenter site/main office. This failover cluster is part of a DFSR replication group. DFS Replication is used to consolidate data to the datacenter server from multiple branch office file servers for centralized backup using backup software such as Microsoft System Center Data Protection Manager. 
As shown in the above figure, the failover cluster to be setup at the datacenter location consists of two nodes – servers named ‘PrimaryNode’ and ‘SecondaryNode’ respectively. The servers are both connected to shared storage. If the PrimaryNode were to encounter hardware failures, the Windows Failover Clustering service should automatically failover replication responsibilities to the SecondaryNode without having to reconfigure the DFS Replication service on any of the branch office file servers (replication partners).
In this series of blog posts, let’s explore the steps required to configure and set up such a failover cluster, configure DFS Replication for high availability on that cluster and then finally add the failover cluster to a replication group.
Creating a Windows Failover cluster for Contoso
Before we begin, make sure that Windows Failover Clustering is installed on all nodes of the failover cluster. This can be done by adding the ‘Failover Clustering’ feature in Server Manager. Also, add the ‘Remote Server Administration Tools’ feature. This feature provides administration tools such as ‘Failover Cluster Manager’ MMC snap-in as well as the DFS Management MMC snap-in which are useful in configuring Failover Clustering and DFS Replication respectively. The below screenshot shows a server with both ‘Failover Clustering’ and ‘Remote Server Administration Tools’ features installed. It is also recommended at this stage to install the ‘File Server Role’ along with the ‘DFS Replication’ role service – details are provided in the third blog post in this series.
On one of the nodes that will be part of the failover cluster (say ‘PrimaryNode’ in this example), launch the ‘Failover Cluster Manager’ MMC snap-in either from the ‘Administrative Tools’ menu or by typing ‘cluadmin.msc’ at the command prompt. This MMC snap-in is used for configuring and managing Windows Failover clusters.
The below screenshot illustrates the look and feel of the MMC snap-in on a server running Windows Server 2008 R2. The start page contains a list of helpful documentation links as well as a list of common cluster management tasks. Note that since this machine is not yet part of a Windows Failover cluster, the left hand side pane is pretty much empty.
NOTE: Before configuring a fresh Windows Failover cluster, it is recommended to validate the configuration. Please review your hardware configuration and check to see that it meets Microsoft’s recommendations in order to get the most out of your Windows Failover cluster.
More information about this process is available in the Failover Cluster step-by-step guide on TechNet.
Clicking on the ‘Validate a Configuration…’ link in Failover Cluster Manager snap-in brings up the ‘Validate a Configuration Wizard’.
Follow the instructions in this wizard and enter the names of all the servers which will be members of this Windows Failover cluster in the wizard. Note that we’ve selected both servers which we intend to be nodes of the new failover cluster (‘PrimaryNode’ as well as ‘SecondaryNode’). These are the servers which will be validated by the wizard.
The ‘Testing Options’ wizard page that follows enable an administrator to select what tests are to be run in order to validate the configuration. It is recommended to run all the available tests. Once the tests have completed running, a report is generated. Check the report to ensure that the hardware configuration is suitable for clustering.
After the cluster’s hardware configuration has been validated, it is now time to create a new Windows Failover cluster to host Contoso’s datacenter file server. The following steps describe how to create a Windows Failover Cluster.
To begin, in the Failover Cluster Manager MMC snap-in, select ‘Create a Cluster…’ from the ‘Actions’ pane on the right.
This launches the ‘Create Cluster Wizard’. This wizard can be used to create a Windows Failover Cluster.
In the ‘Select Servers’ wizard page that follows, select the servers which will be part of this failover cluster. As discussed above, we are going to create a new failover cluster for Contoso. This failover cluster will be a 2-node cluster consisting of the servers ‘PrimaryNode’ and ‘SecondaryNode’ and shared storage.
In the ‘Access Point for Administering the Cluster’ wizard page that follows, provide a name for the failover cluster. This name is used when administering the failover cluster. We’ve provided the name ‘ContosoCluster’ for this failover cluster.
Thereafter, click ‘Next’ at the Confirmation screen that follows and the new failover cluster is created. A ‘Summary’ page at the end of the wizard displays the status of the cluster creation task.
That’s it! We have now configured a two-node Windows Failover cluster. We can now proceed to configure this as a highly available file server and thereafter set it up as a DFS Replication member server. Notice that a new cluster called ‘ContosoCluster’ is now visible in the Failover Cluster Manager MMC snap-in on the left hand side column. This cluster has not yet been configured to run any highly available application workload as yet, which is what we will do next.
The next blog post in this series explains how to configure DFS Replication for high availability. Once that step is complete, the failover cluster can be added to a replication group.
All posts in this series:
-
-
-
-------
Mahesh Unnikrishnan
Whenever you’re deploying Windows Server DFS-Namespaces, you will need to figure out how many servers will be required.
Although we never really had any problems with performance of the namespace server themselves, the question of where to place them is quite common.
A single namespace server can typically handle thousands of referrals per second (the exact number will depend on details like the number of targets per link, the server configuration, the network bandwidth).
Since DFS-N clients will cache those referrals, you will be hard-pressed to find a scenario where a single dedicated namespace server would become a significant performance bottleneck.
However, there’s a lot more to this than raw referral performance, like fault tolerance or site awareness.
So, how many namespace servers do you really need? Jose Barreto has a new blog post to help answer that question at
http://blogs.technet.com/josebda/archive/2009/06/26/how-many-dfs-n-namespaces-servers-do-you-need.aspx
This article answers following questions related to Windows Server Backup in Windows Server 2008 and Windows Server 2008 R2:
Q1. How does Windows Server Backup store backups and maintain backup versions?
Q2. How do I query backup stored versions on a backup storage location?
Q3. How do I delete non system state backups created using Windows Server Backup?
Q4. How do I delete system state backups created using Windows Server Backup?
Overview
· Windows Server Backup is the built-in backup solution in Windows Server 2008 and Windows Server 2008 R2. Using Windows Server Backup, an administrator can schedule periodic backups of a server and also create backups on demand. For details on using Windows Server Backup, please see the Installed Help for Windows Server 2008 (http://technet.microsoft.com/en-us/library/cc770757(WS.10).aspx) and for Windows Server 2008 R2 (http://technet.microsoft.com/en-us/library/cc770757.aspx).
· Windows Server Backup in Windows Server 2008 allows administrators to back up entire volumes. More flexibility is available in Windows Server 2008 R2 where administrators can pick and choose individual files and folders to be included in a backup. The technology used by Windows Server Backup to perform a backup differs based on the nature of the backup:
o If you back up an entire volume, Windows Server Backup creates a block-level backup that reads directly from the volume by passing the file system.
o If you back up just specific files and folders, Windows Server Backup reads individual files going through the file system.
· Windows Server Backup stores backups at the following path: <BackupStorageLocation>\WindowsImageBackup\<ComputerName>\. A back up operation performs following steps:
1. Windows Server Backup reads data from source volumes and then creates a .vhd file per source volume on the backup storage location and writes the backup metadata.
2. Windows Server Backup stores backup versions in volume shadow copies. After the data write is complete, Windows Server Backup creates a shadow copy of the volume where the backup is stored using Volume Shadow Copy Service (VSS). This shadow copy retains the state of the storage volume as a “backup version” or “point-in-time” of the backup and must restore using this backup version. VSS is the underlying Microsoft technology required for maintaining backup versions. (For more information about VSS, see http://technet.microsoft.com/en-us/library/cc785914.aspx.)
3. After creating the shadow copy, Windows Server Backup updates the backup catalog which is stored on both the system volume of the server that is being backed up and the backup storage folder with the following information:
§ The backup time − The local system time of the server when the backup operation started.
§ The shadow copy identifier (Shadow Copy ID) − Used by Windows Server Backup to associate the backup version to the correct shadow copy.
§ Version identifier − Used by Windows Server Backup to uniquely identify a backup version. Users using command line tools (Wbadmin and the Windows PowerShell cmdlets for Windows Server Backup) will specify the version identifier as a parameter to the command to work with a backup version.
· If the backup storage location is full, Windows Server Backup automatically deletes the oldest backup version to make space for the current backup. Since each backup is stored inside a shadow copy, deleting a backup version is accomplished by simply deleting the corresponding shadow copy. However, space for a system state backup in Windows Server 2008 is not automatically managed by Windows Server Backup. See the section “How to Delete System State Backups” below for managing system state backups in Windows Server 2008.
· Windows Server Backup can store only one backup version on a network share (remote shared folder). You can store backups from multiple computers to a network share. A backup from a computer to a network share will be saved at: \\<RemoteServer>\<SharedFolderPath>\WindowsImageBackup\<ComputerBackedUp>. To delete the backup on network share, you need to delete the <ComputerBackedUp> directory from network share.
· Windows Server Backup uses the .vhd format for writing backups. The current virtual hard disk specification limits the size of a virtual hard disk to be 2040 GB, which can fit a volume of size 2040 GB – 2 MB, (i.e., 2088958 MB). Windows Server Backup in Windows Server 2008 also limits the maximum source volume size to be 2088958 MB. In Windows Server 2008 R2, if you are not backing up a full volume and, instead, creating a backup of selected files/folders, your source volume size can be more than 2088958 MB, provided your actual data size is less than equal to 2088958 MB. If you are creating a full volume backup, the maximum source volume size limit continues to be 2088958 MB.
How to Query Backup Versions
To see the backup versions present in a particular computer, use the Wbadmin get versions command. Note that, to use the Wbadmin command, you must be a member of the Administrators group or Backup Operators group and must open an elevated instance Cmd.exe (click Start, right-click Command Prompt, and then click Run as administrator). For detailed Wbadmin command documentation, see: http://technet.microsoft.com/en-us/library/cc754015.aspx.
Sample output of Wbadmin get versions command:
wbadmin 1.0 - Backup command-line tool
(C) Copyright 2004 Microsoft Corp.
Backup time: 3/12/2009 10:55 AM
Backup target: Fixed Disk labeled New Volume(I:)
Version identifier: 03/12/2009-05:25
Can recover: Volume(s), File(s)
Snapshot ID: {f5e946da-5cc7-44c3-a747-9f1079e639b0}
Snapshot ID in the above output is new in Windows Server 2008 R2. Snapshot ID is same as Shadow Copy ID. It corresponds to a specific backup version and can be used to delete that backup version.
To view all backup versions on a particular backup storage location, type:
Wbadmin get versions -backupTarget:<BackupStorageLocation:>
For example, if you want to view all the backup versions on the backup storage location K:, type:
Wbadmin get versions –backupTarget:K:
In the output of Wbadmin get versions command, Backup time is the local system time and Version Identifier is the GMT time at the time the backup was created. If you change your system time zone, the value for Backup time will also change. Note that Version Identifier is a unique identifier for a given backup version and remains constant for a backup.
How to Delete Non-System State Backups
Windows Server Backup deletes a backup by just deleting the corresponding shadow copy and updating the backup catalog. You can perform the same steps manually to delete backups on demand. However, the backup catalog update cannot be done manually and it will happen instead during the next backup. In short, to delete a backup version manually, you need to delete the corresponding shadow copy from the backup storage location.
To delete a shadow copy, follow these general steps:
1. Identify the backup version you want to delete by querying the backup versions on your backup storage location.
2. Determine the shadow copy ID of the version you want to delete.
3. Delete the shadow copy.
Identify the backup version:
To list all the shadow copies on a volume, use the Vssadmin command. (For the complete syntax for Vssadmin, see: http://technet.microsoft.com/en-us/library/cc754968(WS.10).aspx.) The following command line lists all shadow copies on a specified backup storage location:
Vssadmin list shadows /for=<BackupTarget>
For example, to list the shadow copies on the location Y, type:
Vssadmin list shadows /for=Y:
Determine the shadow copy ID:
On Windows Server 2008 R2, the shadow copy ID is same as Snapshot ID given in the output of querying backups. On Windows Server 2008, you can find your backup’s shadow copy ID by looking at output of Vssadmin list shadows /for=<Backup Target>. Match the shadow copy creation time with your backup’s Backup time value.
Delete the Shadow Copy for the specific Shadow Copy ID:
1. To open a command prompt with elevated privileges, click Start, right-click Command Prompt, and then click Run as administrator. Then type:
DiskShadow.exe
2. Type:
Delete shadows ID <Shadow Copy ID>
3. To exit DiskShadow type:
Exit
To delete the oldest shadow copy on backup storage location, type the following command in step 2 above:
Delete shadows OLDEST <BackupStorageLocation>
For example, if your storage location is volume G:, type:
Delete shadows OLDEST G:
If you have scheduled backups to dedicated disks, Windows Server Backup doesn’t assign a drive letter to the backup storage location to avoid any accidental data write or loss of backups. In that case, you can use the GUID of the backup storage volume to delete the oldest shadow copy. You can get volume GUIDs for all volumes on your system by using the Mountvol command. If your scheduled backup storage location is a dedicated disk, it will be reported with No Mount Points in the output of Mountvol. The volume GUID is in {XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX} format.
Then, to delete the oldest shadow copy on that volume, type:
Delete shadows OLDEST \\?\Volume{GUID}
For example, for a volume GUID of 7fc1871b-2e1f-11dd-a339-001e4fb7af35, type:
Delete shadows OLDEST \\?\Volume{7fc1871b-2e1f-11dd-a339-001e4fb7af35}
How to Delete System State Backups
In Windows Server 2008, each system state backup is a full backup and is stored in a separate directory, consuming the space needed for a full backup every time. New in Windows Server 2008 R2 system state backups are incremental and use VSS shadow copies for creating different versions of the backup.
There are three ways to delete system state backups:
o Delete a specified version of system state backup
o Example: Delete the version that was taken on Tuesday evening with a version identifier of 06/02/2009-18:25.
§ In an elevated command prompt, query backup versions and identify the backup created on Tuesday with the version identifier of 06/02/2009-18:25.
§ Then, type: Wbadmin delete systemstatebackup –version: 06/02/2009-18:25
o Delete the oldest version on a backup storage location
o Example: Delete the oldest version on backup target G:\
§ In an elevated command prompt type: Wbadmin delete systemstatebackup –backupTarget:G: –deleteOldest
o Delete all backups except the latest N versions on a backup storage location.
o In an elevated command prompt type: Wbadmin delete systemstatebackup -keepversions:N
Post by Madan Mohan
Classifying files based on their content is something we have covered before for the File Classification Infrastructure (FCI). Basically, FCI allows you to create rules that will search the contents of files (using the Content Classifier) for strings or patterns and when they are found, to set a classification property to a specific value. To extract text from files to search for strings or patterns, the Content Classifier uses the IFilter components that support the search indexing mechanisms. Out of the box, a series of file types are supported.
One common problem we see when searching through data for strings is that some data that is easily recognizable by humans is very difficult to find by software. The classic example is text embedded in images. Think about all the faxes or scanned documents lying around your Server. All of these may contain valuable information. However, up to now you have not had a good way to automate the process of finding it. In Windows 7 and Windows Server 2008 R2 there is a new optional component to help you with this problem: the Windows TIFF IFilter.
This is an optional Windows feature that you have to install (Server Manager –> Add Feature –> Windows TIFF IFilter). The Windows TIFF IFilter will then be able to perform OCR (Optical Character Recognition) of TIFF images (the most common format for faxes and scanned documents). With this '’feature’, the search indexer can essentially read the content of TIFF images to index these files according to the embedded text. This enables the Content Classifier to find text within images and classify the file.
Now your classification rule to find the word “Confidential” and mark those files as “Secrecy=High” can find the word in scanned documents too!
Languages
By default, the Windows TIFF IFilter uses the locale of the system to decide which language it should be attempting to OCR from images. However, this can be modified.
There is a group policy administrator template for setting preferred OCR languages. The only limitation is that languages must be from the same code page.
By selecting several OCR languages (e.g. English and Spanish) administrators can enable the Windows TIFF IFilter to process documents in both languages as well as those with the mixed language content. For more details please take a see: http://technet.microsoft.com/en-us/library/dd744701(WS.10).aspx
The Content Classifier in the File Classification Infrastructure extracts text from files using the IFilter mechanism that enables the Search Indexer. Here is a list of file types that have a corresponding IFilter installed on a Windows Server 2008 R2 install without any other software installed on it:
| Filter Name |
Extension |
| HTML Filter |
.ascx .asp .aspx .css .hhc .hta .htm .html .htt .htw .htx .odc .shtm .shtml .sor .srf .stm |
| Microsoft Office Filter |
.doc .dot .pot .pps .ppt .xlb .xlc .xls .xlt |
| MIME Filter |
.mht .mhtml .p7m |
| Plain text Filter |
.a .ans .asc .asm .asx .bas .bat .bcp .c .cc .cls .cmd .cpp .cs .csa .csv .cxx .dbs .def
.dic .dos .dsp .dsw .ext .faq .fky .h .hpp .hxx .i .ibq .ics .idl .idq .inc .inf .ini
.inl .inx .jav .java .js .kci .lgn .lst .m3u .mak .mk .odh .odl .pl .prc .rc .rc .rct
.reg .rgs .rul .s .scc .sol .sql .tab .tdl .tlh .tli .trg .txt .udf .udt .usr .vbs
.viw .vspscc .vsscc .vssscc .wri .wtx |
| RTF Filter |
.rtf |
| Wordpad Filter |
.docx .odt |
| XML Filter |
.csproj .user .vbproj .vcproj .xml .xsd .xsl .xslt |
Additionally, the a few Microsoft IFilters that can easily be added without extra cost
| Filter Name |
Extension |
Reference |
| Windows TIFF IFilter |
.tif |
Server Manager-> Add Feature –> Windows TIFF IFilter |
| Microsoft Filter Pack |
.docx, .docm, .pptx, .pptm, .xlsx, .xlsm, .xlsb .vdx, .vsd, .vss, .vst, .vdx, .vsx, .vtx .one .zip |
http://www.microsoft.com/downloads/details.aspx?FamilyId=60C92A37-719C-4077-B5C6-CAC34F4227CC&displaylang=en |
Other free and commercial IFilters also exist. You can start at http://ifilter.org/ to find more IFilters.
However, just because an IFilter exists, does not mean it will extract data from files. Some of these will not retrieve text to be scanned by the content classifier. For a complete list of file types that the default IFilters can extract text from and what data is extracted from each, you can look at the official list of included Filters at http://www.live.com/docs/toolbarts.aspx?t=MSNTbar_CONC_SearchableFileTypes.htm
If you would like to figure out which IFilters are installed on one of your servers, you can use the FiltReg (http://msdn.microsoft.com/en-us/library/ms692537(VS.85).aspx) tool.
The official IFilter blog has a lot more information as well as more links to IFilters to extend the reach of the Content Classifier (and the Search Indexer) into more file types.
Update: Formating issues with table
In this article, we'll take a look at a new class of VSS writers enabled in Windows 7 and Server 2008 R2 that lower the cost for applications to participate in backups. Before we get there though, let’s briefly recap the role of VSS writers in backups.
VSS and backups
The Volume Shadow Copy Service or VSS as its better known is the backup infrastructure in Windows. Data protection applications (requesters) use VSS to create snapshots of volumes for various purposes including data mining and backups. Backup agents rely on VSS writers to ensure that application data is in a consistent state on disk before creating a snapshot or point-in-time image of one or more volumes. The snapshot itself may be used as the backup or the data may be copied from it to tape.
Snapshots facilitate online backups i.e. the application can continue to process and write to disk, while the requester copies data from the snapshot to backup media. Absent snapshots, the requester would have to contend with open files and constantly changing data. All of this is described in more detail here.
VSS writers help backups and restores in one or more of the following ways.
· Discoverability: VSS writers make it possible for a requester (backup agent) to discover the location of an application's data stores and requirements for their backup and restore. For example, the writer may indicate in its metadata that the application needs to be re-started after the data is restored.
· Data Consistency: Writers ensure that the application’s data on disk is in a consistent state prior to the creation of the snapshot. In some cases, writers may rollback incomplete transactions on the snapshot during the auto-recovery phase.
· Post backup processing: Writers may perform clean-ups like truncating logs after the backup is complete.
· Restore processing: Some applications may require preparation prior to a restore like releasing handles or dismounting databases. In other cases the writer performs fix-ups like applying logs, after the restore.
Motivation for Express Writers
As we've just seen the traditional VSS writer model offers a great deal of functionality and supports rich semantics which are often necessary for sophisticated applications and services like databases and line- of-business workloads.
On the other end of the spectrum are several applications and OS components with relatively simple storage layouts. These applications may have their data and metadata contained in a few files and occasionally a local database. They are usually capable of recovering from a system crash because they transact updates or maintain logs. For this reason, there isn't anything to be done in the way of ensuring data consistency for a backup since they can recover from a crash consistent image of their data. Similarly these applications do not require any processing after a backup or restore either. They still do need to identify the locations of their data and metadata though.
For such applications, the traditional VSS writer model may present a relatively high overhead because of the need to host the writer in a long running service, deal with COM+ registrations and run-time issues like security context mismatches etc.
The new Express Writer APIs are intended for precisely these kinds of applications and present a much simpler interface with minimal run-time interactions.
Express Writer overview
The Express writer APIs are designed to address discoverability of application data and metadata for backups. Using the new APIs an application can register the location of its stores during an install. Similarly, in the event of a configuration change or servicing, the application can update this information. All the metadata is presented to the requester at the outset of a backup without the involvement of the application. In fact the application doesn’t even need to be running at this time. When the application is un-installed, it unregisters its metadata and is thus no longer reported to a requester.
It’s important to note that the Express Writer APIs are completely transparent to requesters. A backup application cannot tell the difference between a conventional VSS writer and an Express Writer and doesn’t require any changes to work with these new writers.
The Express writer APIs thus lower the bar for most applications to participate in VSS backups. The simpler APIs results in lower development, test and maintenance costs. There are also fewer moving parts in the system which ultimately leads to greater reliability and a better customer experience.
Incidentally the system state components, Performance Counters and Task Scheduler implement Express Writers in Windows 7 and Server 2008 R2.
Express Writer workflow and APIs
In this section we'll take a high level look at the APIs; you can find detailed documentation on MSDN and sample code in the Windows 7 SDK. You may notice that some of the APIs are similar to those for traditional VSS writers and in-fact they are a subset.
There are two workflows supported. In the first case, the backup metadata is built and registered at run time. This approach offers the most flexibility as the application can alter its metadata as needed at runtime - one example might be in response to configuration changes.
In the second approach, an application developer may build the metadata ahead of time, during the development phase and save the XML which is shipped with the application bits. During installation the application registers the previously created metadata with VSS. This workflow is ideal for applications that require metadata updates only in the event of servicing, if at all.
Here's the sequence of steps an application must follow for the first workflow.
1. Call CreateVssExpressWriter to instantiate the IVssExpressWriter interface
2. Invoke IVssExpressWriter::CreateMetadata to instantiate the IVssCreateExpressWriterMetadata interface.
3. Use the IVssCreateExpressWriterMetadata interface to build the component hierarchy including defining the backup and restore schema.
4. Register the metadata with the Volume Shadow Copy Service using IVssExpressWriter::Register
5. Update the metadata by first deleting it, using IVssExpressWriter::UnRegister and then repeat steps 1-4.
6. During un-installation, delete the metadata by calling IVssExpressWriter::UnRegister
In the second approach i.e. when using previously created metadata, the application developer must follow the first three steps above to create the metadata, call SaveAsXML to retrieve the XML and then save it to a file.
During installation, the application must load its metadata using IVSSExpressWriter::LoadMetadata and then register it as in step 4 above.
The Express writer sample can be found in the directory samples\winbase\vss\ExpressW. The RC version of the Windows 7 SDK is available here. Do try it out – we’d like to hear your feedback. For questions and comments you can reach us at vss(nospam)@microsoft.com
- Dinesh
In a previous article, we looked at LUN Resync a new fast recovery scenario in Windows Server 2008 R2. Himanshu from the VSS team has posted a few sample scripts to demostrate the scenario using Diskshadow and the VSS tools in the Windows 7 SDK.
This is the blog - LUN-RESYNC WITH DISKSHADOW AND VIRTUAL STORAGE
A request we’ve received consistently from our customers is – How do I know what DFS Replication is currently doing on my server? In Windows Server 2008 R2, we have attempted to provide a way for administrators to better understand the state of replication on their servers.
This feature is available by virtue of a new command line switch for the dfsrdiag.exe diagnostic tool. The ‘ReplicationState’ (or ‘ReplState’) command line switch enables an administrator to query the DFS Replication service and retrieve information about the status of replication activity on that server.
This command line switch can be executed against servers running Windows Server 2008 R2 only. The output of this command line switch consists of a list of updates that are currently being serviced by the replication service on all inbound and outbound replication connections. Since this command line switch provides a point in time snapshot of replication activity on a server, it is possible to see whether replication is making any progress by comparing the output of this command obtained at different points in time.
We can better understand how to use this command for monitoring purposes with a sample setup as described below.
The setup
Consider a replication group called ‘ContosoPublication’. The folder ‘ContosoPub’ is replicated between two servers (CONTOSO-HUB and CONTOSO-BRANCH) in this replication group. Typically, the administrator publishes data on the hub server (CONTOSO-HUB) and this data is replicated to the branch office server (CONTOSO-BRANCH) using the DFS Replication service.
An administrator may want to monitor the state of replication on either of the servers to better understand what the DFS Replication service is currently up to. The following sections explain how to use the new ‘ReplicationState’ command line switch for the dfsrdiag.exe diagnostic tool for this purpose.
Monitoring replication on the branch office server
In order to monitor the current replication state of the DFS replication service on these servers, the command ‘dfsrdiag.exe ReplicationState’ can be used. The /member (or /mem) option can be used along with the ‘ReplicationState’ command line switch to specify the server against which this command should be run. In this example, I’ve dumped a few files from the ‘Windows\System32’ directory into the replicated folder.
dfsrdiag ReplicationState /member:CONTOSO-BRANCH
The verbose option (‘dfsrdiag ReplicationState /all’) prints out more information for each update. This includes the versioning information maintained by the DFS Replication service (UID, GVSN, Parent UID) and the replicated folder to which the update belongs.
dfsrdiag ReplicationState /member:CONTOSO-BRANCH /all
Understanding the output of this switch
-
Active inbound connection: These are connections over which data/updates are replicated in onto the server being monitored. In this example, the active inbound connection is used by the DFS Replication service to replicate updates from CONTOSO-HUB to the branch office server (CONTOSO-BRANCH). Expect to see at least one active inbound connection per replication partner for all replication member servers on which this command is executed. On a server which is replicating with many replication partners (such as a hub server), if the ‘ReplicationState’ command line is executed, the output will display all the current active connections with these replication partners.
-
Active outbound connection: This is a connection over which data/updates are replicated out to other replication partners from the server being monitored. In this example, the replicated folder ‘ContosoPub’ has been configured to be a
read-only replicated folder on the branch office server (CONTOSO-BRANCH). Therefore, the branch office server will not have any active outbound connections – simply because it is not expected to replicate out any changes to its replication partners. That’s why the above output shows ‘Active outbound connections: 0’.
-
Sending member: This is the name of the replication partner which is sending data over this particular connection. In this example, the sending partner is the hub server (CONTOSO-HUB), which sends updates to the branch office server (CONTOSO-BRANCH) over the active inbound connection.
Number of updates = (Updates being processed + Updates scheduled)
-
Updates being processed: This value signifies the number of updates that the DFS Replication service is currently processing. For an active inbound connection, this means that the DFS Replication service is downloading data corresponding to that update from its replication partner. For an active outbound connection, it means that the DFS Replication service is currently transmitting the update to its replication partner.
-
Update information: This contains more information about the update including the name of the file, version information maintained by the DFS Replication service and the path. In case of files which are currently being downloaded or have been scheduled for processing, the path to the file may not always be available. In such cases the path is not logged in the output. Updates may also be directories contained within the replicated folder.
Monitoring replication on the hub server
The same command line switch can be executed against the DFS Replication service on the hub server (“dfsrdiag.exe ReplicationState /member:CONTOSO-HUB”) in order to monitor the state of the hub server.
-------
Mahesh Unnikrishnan
Over the long weekend, one of my colleagues and I were discussing the new File Classification Infrastructure in the upcoming R2 release.
My colleague asked me: “Why do you keep emphasizing the importance of separating the classification from the action – why not just take the action as you classify the file, for example: if a product that does content based analysis finds that a file has personal information on a public server, then it should delete it immediately”
Needless to say, I agree with my colleague that this is a good action to take during classification but I also pointed out that this is a very partial solution. For example, what if the file is not on a public server? We probably do not want to delete it but we also want to make sure that when the file is backed up, it will be backed up to an encrypted store so that if the tape is lost, the information does not leak out. Also, what if the file was classified as having “personal information” by a user and not by the content based analysis? It still needs to be deleted from the public server (if this is the policy we want to apply of course).
My colleague summarized this nicely by saying: “So, my example above was just one case of classifying and applying policy”
We went on to discuss the example of the content analysis product marking the file as having personal information and the backup application then backing up all personal information files to an encrypted store
I said that the way we approached this with the File Classification Infrastructure is to allow the IT administrator to define a property that will be attached to the file to indicate that the file has personal information (e.g.: “PersonalInformation=Yes”) and then, the content analysis product will assign this property to the file (or a user can set this property to the file). The administrator can then configure the backup application that all files that are classified as “PersonalInformation=Yes” need to be backed up to an encrypted store (of course, the backup application needs to be “classification” enabled)
He agreed that this works but wanted to know why not just have the backup application work directly with the content analysis product to determine which action needs to be taken – in his words: “Instead of setting PersonalInformation=Yes” on the file, the content analysis product can just set which policy the backup application should take – say a GUID that the backup application recognizes and knows to backup this file to an encrypted store.”
On the surface, this sounds like a great idea (and works well for some scenarios such as rights management) but I asked him what happens if a new application (say archival application) is introduced to the mix – how does this application understand what to do with this GUID? Furthermore, what if the backup application does not work with the specific content analysis application and what does he expect the user to enter when he manually classifies files as having “Personal Information”
We could have continued this back and forth for awhile. There are certainly many potential variants of technological solutions to the complex data management problems that organizations are facing today
In R2, we tried to keep it simple and empower the IT administrators to get insight into the organization's data so that they can apply actions based on that insight:
· The Organization defines the properties that should be attached to files (Taxonomy)
· Classify: Classification (Manual and automatic) assigns properties to files (e.g.: “PersonalInformation=Yes”)
· Apply policy based on classification: Data management is configured based on file properties (e.g.: backup all files with “PersonalInformation=Yes” to an encrypted store)
These additional blogs provide deep dives into how to leverage File Classification Infrastructure (FCI) in your IT environment and how to develop solutions to further plug-in and enhance FCI:
· Classifying files based on location and content using the File Classification Infrastructure (FCI) in Windows Server 2008 R2
· Dealing with stale data on File Servers
· Customizing File Management Tasks
(This is a follow up to the blog entry that presented the File Classification Infrastructure in Windows Server 2008 R2)
Post by Nir Ben Zvi
For those who are interested in the Windows Server 2008 R2 File Classification Infrastructure (FCI) and could not attend the live session, we have a recorded version of the session available online for you to view at your leisure
If you did attend the session and really liked it - feel free to forward the link
FCI Live meeting replay URL: https://www.livemeeting.com/cc/mseventsbmo/view?id=1032410139&role=attend&pw=9A7F8D1D
There will be a TechNet Webcast on File Classification Infrastructure (FCI) in Windows Server 2008 R2 tomorrow.
See the details below:
If you're interested in FCI, make sure to attend!
If you are attending the Microsoft TechEd 2009 conference in Los Angeles and you're looking forward to a deep dive into the new File Classification Infrastructure (FCI) in Windows Server 2008 R2, there will be a session today including a walkthrough of FCI with never-before-seen demos of partner solutions and how you can use PowerShell to extend FCI. Don't miss it!
| Session |
WSV329 |
| Title |
Windows Server 2008 R2 File Classification Infrastructure: Managing Cost and Mitigating Risk on File Servers |
| Date/Time |
5/14/2009 4:30PM-5:45PM |
| Location |
Petree Hall D |
