The Storage Team Blog about file services and storage features in Windows and Windows Server.
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:
As with blog post 1 steps are missing:
You will have to create a storage using the storage wizard before you can walk through the remainder of this wizard.
You may also run into problems with network identification, especially if you assign IP statically (like you normally do for servers). Be prepared to assign a Virtual IP to the service manually when specifying the client access point.