Windows server runs chkdsk after moving FC LUN

[cgeck0000]

For a customer I am moving iSCSI and FC LUNs from old aggregates running on DS14 shelves to new SAS drives.

When I connect the Windows 2008 server to the new LUN after a snapmirror replication and power on the server chkdsk comes up during initial boot up.

I cancel this and log into the server fine and can access the NTFS volume without issue.

Is there something more I need to do to the LUN to prevent chkdsk from coming up? Do I need to do something on the server itself so it doesn't see the new LUN having a potential issue?

[olson]

Greetings,

               You did not state so however, I suspect you are talking about the boot drive on a boot from san devices.

If you run

chkntfs /X  C:  

            On the source before migration it should prevent checkdisk from running on a dirty shutdown.

Make sure to reset it after migration.

chkntfs /d

if it is not causing a problem you may just want to let it run. 

John

[cgeck0000]

Hi Olson,

No, this is not a boot from SAN server.

The server itself is an HP 1U DL360 with the C:\ drive on local disks.

The LUN is an additional drive connected to the server, S:\ to be exact.

I snapmirror the volume to a new aggr. on new disks, shutdown the server, broke the snapmirror, moved the LUN initiator group to the new LUN, powered on the server.

No every time the server boots it want to chkdsk the volume before the server boots up all the way. Just wondering if I need to do something more in this process to prevent this from happening. We have a lot of servers with FC\iSCSI LUNs we need to do this to.

Thanks.

[olson]

Greetings,

              In that case use snapdrive to map the lun after the system is booted. That should prevent this issue from occuring.

[cgeck0000]

On the server I did

fsutil dirty query s:

And it came back stating the volume was dirty.

Did a chkntfs /x s: to stop chkdsk from scanning the volume on boot up.

So should I also use SnapDrive to disconnect the LUN\LUNs on the servers before shutting them down?

I've done this in the past with iSCSI LUNs and never had this problem. Do you think this may have been a one time anomoly?

Has anyone else had this issue before?