As everyone should know by now, the way to get your Windows 2003 Cluster Server to Windows 2008 and 2008 R2 Failover Clustering is by doing a migration to the new cluster. So let’s say we have a Windows 2003 Cluster running as a File Server and we are going to be using new hardware (machines, SAN, etc). In order to migrate the shares, you can use the Cluster Migration Wizard in Failover Cluster Management.
The Cluster Migration Wizard does not copy data, so in the case of moving to a different SAN for your new Cluster, alternate means of moving the data would also need to be done. Another difference you may notice is that in the Windows 2003 Cluster Server, you may have either a single or multiple file share resources. Once it has been migrated over to the Windows 2008 and 2008R2 Clusters, the end result will be one File Serverresource.
The purpose of this blog is to let you know of another option to migrate the shares. With the File Server Migration TooIkit, you can migrate the shares over that also would include the data, NTFS permissions, and share permissions. I am not going to go over any pros, cons or comparisons between the two, just another alternative. You should test out each for your particular scenarios fully and form your own opinion on which to use.
Here is my File Share Group that currently resides on the Windows 2003 Cluster.
Disk X: (Physical Disk)
IP Address (IP Address)
Network-Name (Network Name)
Home-Shares (File Share)(Share Subdirectories)
Acct-Share (File Share)(No Share Subdirectories)
Mgmt-Share (File Share)(No Share Subdirectories)
Below are the shares in this group that I have and wish to migrate over. Both the Acct-Share and the Mgmt-Share do not have the option of Share Subdirectories selected while the Home-Shares do. I have modified the share permissions from the default recommended of Everyone Full Control. I did go into the NTFS permissions and set them accordingly to Domain Admins FULL and the specific users of the folders to FULL. In my case, the Cluster Service account is a part of the Domain Admins Group, so I did not specifically list it. So the directory structure and share permissions in Cluster Administrator would look like this.
Home-Shares
x:\home <<-- DomainAdmins FULL, DomainUsers FULL
x:\home\a-d <<-- DomainAdmins FULL, DomainUsers FULL
x:\home\e-j <<-- DomainAdmins FULL, DomainUsers FULL
x:\home\k-p <<-- DomainAdmins FULL, DomainUsers FULL
x:\home\q-x <<-- DomainAdmins FULL, DomainUsers FULL
x:\home\y-z <<-- DomainAdmins FULL, DomainUsers FULL
Acct-Share
X:\acct <<-- DomainAdmins FULL, AcctUsers FULL
Mgmt-Share
X:\mgmt <<-- DomainAdmins FULL, MgmtUsers FULL
One thing to note before beginning this process, In Windows 2003 Cluster, the Cluster Service account needed to have at least READ permissions from a share and NTFS level. In Windows 2008 and 2008R2 Clusters, there is no longer a Cluster Service account. Because we more rely on the local SYSTEM account, this account must be on the Share and NTFS level for Windows 2008 and 2008R2 in order to properly do its checks. When using the Cluster Migration Wizard, we will add it automatically for the share permissions. For the File Share Migration Toolkit, you need to add those permissions before accomplishing the migration. Otherwise, once moved over to the Windows 2008 or 2008R2 Cluster, the share will not be created.
On the 2008 or 2008R2 Cluster, you would first want to create your File Server Group within Failover Cluster Management with just the IP Address, Network Name, and Disk you will be using. Do not yet create any shares. One thing you must keep in mind is that the group on both the 2003 and the 2008 or 2008R2 Cluster must be online for the file share migration. So when creating the group on the 2008 or 2008R2 Cluster, you would need to use a different IP Address and Network Name (or Client Access Point). Otherwise, you will receive a duplicate IP Address or duplicate name error and the resource will fail to come online. You can create it with a different Client Access Point now, and change it after everything has been migrated over with the group on the 2003 Cluster File Share Group offline.
Now you want to run the File Server Migration Wizard to get this all started. At the start, choose a new project and run through the wizard.
At one point in the wizard, you need to uncheck the DFS options if the source and target are not going to participate as DFS Shares. For the Default Location, select the drive that you will send everything to and it will be referenced from the proper group. If you are running FSMT from a 2008 Cluster node that does not own the File Server Group you created, the drive will not be available to choose. Move the group over to this node so that it can locally get to the drive, if need be.
The next screen below you will want to select the Source Server which will be the Network Name in the File Server Group on the Windows 2003 Cluster. Keep in mind and remember how Windows 2003 Cluster is in regards to shares. It will display all shares on the machine, regardless of if it is a part of the same group or locally to the machine. So ensure that you select only the shares you want to migrate. You also want to make sure you select the “Copy security settings” as this is what will get you the NTFS and Share permissions.
When you choose to continue and view the report, it will give you a warning about this being a Cluster, but this can be safely ignored as long as you have everything properly configured as mentioned previously. If you look at the View Report button to the right, you would see this:
Once you continue and get to the finalization, please note the warning. Therefore, ensure you are doing this during downtime.
If you are running FSMT from a node that does not own the File Server Group (example, there was a failover or a moving of the group, the Finalization Process will fail. The other thing to mention is that if you already have a share by the same name, you get an error.
If you look at the Report, you would see this.
Here, you can see that it cannot find the path specified, object already exists, etc. Again, the “warning” about the name being a Cluster can be safely ignored. Another note here is to notice the path it is talking about. On the Windows 2003 Cluster, the paths were:
Home-Shares
x:\home
x:\home\a-d
x:\home\e-j
x:\home\k-p
x:\home\q-x
x:\home\y-z
Acct-Share
X:\acct
Mgmt-Share
X:\mgmt
With FSMT, it copies the data (folders and files) and will put them in a folder under the network name from the previous machine. So your folder structure would actually be this when completed.
Home-Shares
x:\network-name\home
x:\network-name\home\a-d
x:\network-name\home\e-j
x:\network-name\home\k-p
x:\network-name\home\q-x
x:\network-name\home\y-z
Acct-Share
X:\network-name\acct
Mgmt-Share
X:\network-name\mgmt
Once you fix the errors from above and continue, it will copy all of the folders, the data, and the permissions. Part of this process is to create a share which, in turn, creates the File Server resource in the group you specified. So now in Failover Cluster Management, you see this.
Notice also that the original network name from the 2003 Cluster is tagged at the end of the share name. So the new folder structure and the new share name needs to be taken into consideration. This is something that the FSMT does and is not a way of changing it for the migration. It can only be done afterwards. So you would either need to change the share name itself in Failover Cluster Management; or, if you have scripts run from the domain (or other locations), you will need to modify those scripts. You also will want to go ahead and take the group on the 2003 Cluster offline and change the Client Access Point (IP Address and Network Name) in the 2008 or 2008R2 Cluster to what you want it if they were to be the same.
As with all migrations, please test this process out before and after so that you can work out any kinks or issues found in your environment if this is the method you will be using. Also keep in mind that 2008 and 2008R2 Clusters “scope” the shares to the Network Name as explained here. Once everything appears as solid, then roll it out in your production environments.
No comments:
Post a Comment