• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1111
  • Last Modified:

Can one iSCSI target be used between two servers in a server migration preserving the NTFS file system and file rights?


Currently we are using a Windows 2003 R2 server / DC that hosts our file shares on an iSCSI drive mounted to that server.
All users access these file shares by using a DFS namespace, so the backend of these mappings to the real shares can be changed easily.
In the next weeks we are planning to use a new DC that also will host the DFS namespaces and must also take over the iSCSI target at the end of our server migration.

My question is really if NTFS will still function right and if it will not be damaged when i change the iSCSI to the newer server?
the SID's of the folder and files will still be the same..

I guess attaching the iSCSI target to both servers at the same time is dangerous and may damage the flle system or am i wrong?
Because these migration steps are taking outside of working hours, read and/or write errors, file locks should not happen i think.

Thanks in advance.

Best regards,

1 Solution
You shouldn't attached more than one server to the same iSCSI target. Someone else can probably qualify this further but from my understanding Windows is unable to control which server has dedicated control at any one time.. it's certainly possible but will likely cause data corruption.

I have seen iSCSI targets moved to different servers within the same security domain without compromising NTFS security.

NTFS is not a clustered files system designed to be used by multiple servers at the same time.  Each server will cache a copy of the MFT independently and, on shutdown, will flush to disk corrupting the MFT and destroying the integrity of the NTFS filesystem.  Even though NTFS is a journaled filesystem, it will be damaged beyond repair if you "share" it between two non-clustered servers.

Doesn't matter if it's a shared SCSI bus, FC SAN, ATAoE, or iSCSI, the result is the same.

If you accidently expose a LUN to two different server, do NOT shut down the server.  Power them off, pull the disks out, or otherwise *DROP* the disk and you *MIGHT* be able to get your data back.  Doing a clean shutdown is guaranteed to destroy the filesystem.

Even when clustered, NTFS filesystems are accessible to only on the *active* node.  Other clustered nodes can see the LUN but no reads or writes (and this is enforced by SCSI reserves).

As for changing the owner of the iSCSI targets, as long as you remove the current owner before adding the new owner, you should be fine.  At no point do two servers see the same target LUN which is where the risk of corruption comes in.

As for filesystem permissions, I'd use an activeperl script to recursively dump the ACL list for each file before the migration.  You can do a search/replace through the ACL dump to adjust owners if necessary and run another script to set the ACL permissions.  There's a book called Win32 Perl Scripting that actually comes with an example Perl script to do this--I'm sure there's free scripts online to do this as well.
RickAuthor Commented:
Sorry for the late reply, i'm gonna try to switch servers this weekend.
But first gonna make sure our backup works 100%! :-)
Lots of details here about NTFS and clustering that I didn't know, but in my practical experience, you can open disk management, right click on the iscsi array and choose Offline.  From then, you can disconnect from your iscsi share safely using the Initiator.  After that, connect to your iscsi device from any computer you wish.  My array is as the polite term goes, promiscuous.  It's been connected to several domains, various workgroups, and just bounces around while the files remain happily intact.  This is in a home lab sort of environment so I am not sure about the security info but the files are fine.

Featured Post

Hire Technology Freelancers with Gigs

Work with freelancers specializing in everything from database administration to programming, who have proven themselves as experts in their field. Hire the best, collaborate easily, pay securely, and get projects done right.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now