Log in



Categories » ‘Windows 2008’

DataOntap 7.3 upgrade & Windows 2008 disks offline on server reboot

May 6th, 2010 by Scott

A colleague of mine sent me a bug that is occuring to some of our clients when upgrading to DataOntap 7.3 and using Windows 2008.  When the server is rebooted the SAN attached disks do not come back on line.  It has been causing some headaches out there so I thought I would share the fix. 

The process to resolve the issue is a manual process, but the good news is that once you do it it doesn’t appear you have to do it again, or at least that is what I have been told from our client. 

Follow these steps:

  1. On Windows 2008 open System Manager
  2. Expand “Storage” and select “Disk Management”
  3. Right click the “Offline” disk and select “Online” (this will bring the disk back online)

Once the disk has been brought back on line all seems to be well, even after additional reboots.  

The NDU process was used but that did not resolve the issue either as noted in the below KB article. 

There is also a NETAPP article regarding the issue,  KB54672:

Disks show as offline in Windows 2008 after Data ONTAP upgrade

Symptoms

After upgrading Data ONTAP from 7.2.x to 7.3.x, all LUNs attached to Windows 2008 servers appear as ‘offline.’

 Cause of this problem
Data ONTAP upgrades to 7.3.x without using the NDU process will change the LUN revision numbers. Data ONTAP versions prior to 7.3 used a LUN revision number of 0.2, which can be seen using the devcon.exe utility:
MPIO\DISK&VEN_NETAPP&PROD_LUN&REV_0.2_\1&7F6AC24&0&4334677547345438416C4B4F: NETAPP LUN Multi-Path Disk Device 

After 7.2.x, LUN revision numbers took on the version of Data ONTAP and the filer was upgraded to:
MPIO\DISK&VEN_NETAPP&PROD_LUN&REV_7310\1&7F6AC24&0&5672482F2F4A54344E46674C: NETAPP LUN Multi-Path Disk Device

 Solution

 There are several options:

1. Use non-disruptive upgrades of Data ONTAP (with takeover/giveback) to prevent the LUN revisions from changing.|
2. Use SnapDrive to disconnect/reconnect drives, as it will automate the process of bringing drives online.
3. Do nothing and online the drives manually in diskpart or disk management GUI.

To prevent this issue entirely:

 For hosts that fall within the above conditions, we recommend setting the SAN Policy to “Online All” prior to the ONTAP upgrade. This will prevent the virtual disks from dropping offline after a reboot. Once the host is rebooted, the SAN Policy can be changed back to the default setting of “Offline Shared.”

Disappearing NetApp LUNs when moving to EMC?

March 10th, 2010 by Scott

I was at a client site yesterday in the process of moving them off a NetApp Storage array and onto EMC Storage.  My colleague and I ran into a very interesting problem and have no idea why it was happening.  If anyone has any ideas please, do share.

The setup was two Windows 2008 Servers with Exchange 2007 CCR split between two datacenters.  The servers were using Snap Manager for Exchange and Snap Manager.   There were four LUNs from the NetApp presented, three for databasae and one for the logs.  The LUNs were attached via iSCSI. 

Since the Exchange CCR environment was running in the HQ Datacenter we started by getting the EMC agents installon the the Server in the DR Datacenter.  The iSCSI LUNs from the NetApp were presented via Drive letters, there were four, three for the database and one for the logs.  If you’re not familar with deploying EMC apps the first app to deploy is the EMC NaviHostAgent.  When I installed the agent the server requested for a reboot.  This is where things got really funky.  When the server came back from a reboot the iSCSI disk drives from the NetApp were gone!  No idea why.  We scratched our heads and couldn’t figure out what happened.  According to the NetApp management console the LUNs were presented.  When we tried to remap the LUNs via Snap Manager it would state that the volume was already mapped to a drive on the server, but the Server could not see them!  This was odd.  We backed out the EMC NaviHostAgent and the LUNs reappeared but the drives were off line.  I brought the drives back on line and everything worked again.

We then started by reinstalling the EMC NaviHostAgent, no reboot was required this time and installed the EMCPowerPath application.  When we came back from a reboot the drives from the NetApp were off line again, I brought them back on line and had both the EMC and the NetApp storage provisioned.  Great, this is nice.  We presented the EMC LUNs as mount points and started up replication again from the HQ Exchange Server.  Once replication was caught up moved the cluster to the DR server to begin the same process on the HQ server thinking we had a fluke.

Well, the exact same thing happened!  When we installed NaviHostAgent no reboot was required.  We then installed PowerPath, Had to reboot the server and the NetApp LUNs vanished!  WTF right?  Not again!  We did the same procedure I mentioned above, removed PowerPath, removed NaviHostAgent, rebooted the Server in HQ.  When it came back the NetApp LUNs were gone!  No drive letters, no detection.  Checked the iSCSI Initator configuration, and it was perfect, it was seeing the iSCSI targets for both the NetApp and the EMC.  From the NetApps perspective the LUNs were provisioned.  What in Windows 2008 was preventing the LUNs from being seen?  I checked the Network settings via IPCONFIG and there was a “Local Area Connection 9″ that was there along with a Prod network and a iSCSI network.  Looking at the network configuration only two NICs were active for the machine.  No idea where the third NIC was coming from and by this time I was too tired to try to figure it out.  Anyone out there have thoughts on that one? 

Anyway, after troubleshooting for about 5 hours between the two servers I proposed a Plan B.  Since we had the NetApp storage (Thank God) and the EMC storage on the DR server I could create new Storage Groups and Databases on the DR server to the new EMC LUNs.  Create new EMC LUNs on the HQ Exchange Server to reflect what was in DR and let CCR take care of the rest.  Once the Storage Group and Databases were created I enabled replication only for the EMC Storage Groups (since the NetApp was off line on the HQ Server I couldn’t re-enable CCR) and started moving mailboxes.  This worked fine, disaster averted. 

I was glad Plan B worked, but more complexing is why did the NetApp LUNs disappear?  Anyone have an idea what may have happened with it?  Again this was a Windows 2008 Server with Exchange 2007.  The iSCSI network was correct, the NetApp was presenting the LUNs, when going into snap manager the LUNs said they were mapped.  I tried to do a rescan of disks, nothing.  Tried to take away the LUN and remap the LUN via NetApp management console and nothing worked.  The Windows Firewall was turned off, disabled AV Software, nothing worked.  Nothing would bring those LUNs back to the Windows 2008 server.  Has anyone seen anything like this?  Anyone have an idea on what happened?  Please do share!

Thanks,

  • You are currently browsing the archives for the Windows 2008 category.