Wednesday, 5 December 2012

Windows file server migration to NetApp CIFS

Whilst migrating several windows file servers (various OSes from Windows 2000 to Windows 2008 R2) to a new NetApp CIFS environment I encountered a small but show stopping issue which caused a lot of head scratching for a while until the solution became clear.

The migration approach taken was to create a hidden root share on the NetApp CIFS volume and then on each file server run a sync job between them and a subfolder beneath the root share on the NetApp.  The tool used for the copying was called Super Flexible File Synchronizer (now called Syncovery I believe) which not only copies all of the data with NTFS permissions but also copies shares and share permissions across too and sets them up on the NetApp...nice and simple!

Once all of the data had been copied and a few subsequent incremental syncs completed we were ready to cut over from the windows servers to the NetApp appliance for all of our file shares.  The process for this is quite simple really.

Firstly, we had to shutdown the file servers being migrated and then change the DNS entries for each server to point to the CIFS IP address of the NetApp.  As the NetApp would be hosting several different file servers we also needed to set up netbios aliases too so that the controller would respond to the client requests as the original file servers (this saves re-mapping drives and even dfs links which was a real time saver!).
The commands for this were:

  1. options cifs.netbios_aliases (name of server)
  2. cifs nbalias load
  3. options cifs.gpo.enable on
  4. cifs gpupdate


In our case the list of server names was quite long and thus needed to be inputted like this as the line is not cumulative and subsequent additions would otherwise overwrite the previous entries:

          options cifs.netbios_aliases server1,server2,server3,server4,....etc

Next the gotcha.
After doing the above I then went to access a file share which had been migrated and instead of seeing all of the shares I had a blank windows explorer. no error, but no shares either.
It turns out that the last step to do is to actually remove the old file servers AD computer object and allow replication to occur.
Once the computer object was deleted and the client machine rebooted I was then able to connect to the file shares fine and also the dfs links too.

I'm not exactly sure why the computer object needs to be removed but I guess it has something to do with the NetApp being joined to the AD domain (for CIFS).  If I get a more specific reason for this I'll update this blog in the future...

6 comments:

Anonymous said...

Cheers! I appreciate the read.

Anonymous said...

Is it any way find out what are the shares are connected using alias?

Paul Petty said...

The only way that I was able to identify this over time was to add an additional IP address to our CIFS service and then move one of the aliases over to the new IP address and update DNS etc. I was then able to see which clients were connecting to the new IP and were therefore still using the old alias.

Rich said...

I stumbled upon your blog as our company is looking to migrate Windows files server shares over to a new netapp we purchased.
I am using syncovery but cannot get the software to create the CIFS shares as well. Is it possible to get more details on your setup steps?

Paul Petty said...

Hi Rich. Sorry for the delay in responding.
There is an option within the replication tool (I was using the previous version of Syncovery) to replicate shares and NTFS permissions.
We had to assign the account that was performing the file migrations permissions to the filer as well as the source files/shares - We cheated and used a Domain Admin account for this which worked, unsurprisingly, very well). Let me know if you are still trying to do this or having these issues and I'll send you some more details on the profile within SFFS.

Ben Hart said...

Awesome job! I realize Im a bit late to this party but thanks for outlining and posting your procedure. I was toying with keeping DFS in play, but requiring a locally mapped LUN on a server hosting the namespace would not work well for our env. I am planning on testing what you did but so far it looks like exactly what I'm need.

Thanks