I love patching clustered servers (not!), and patching polyserve is usually quite simple and not an issue.   I'm not referring to Polyserve patches, but Operating System (microsoft, hba, other drivers etc) patches.

We normally have designed a special "rolling" sequential patch of 15 minute intervals for the clustered servers, trying to give each server enough time to recover before the next one rolls.

Something happenned with that sequence, and things rolled like a ping-pong !  Polyserve stabilized, but there was an issue with two instances.  Review of the issue determined that the mount points that these instances rely on, did not happen, meaning the mounts failed.

I attempted to remount the volumes and received the following error, "10.10.49.114 assign_drive_letter failed: "D:\Mounts\SysData\" is already a reparse point.". 

I'm not really sure why this happenned, meaning windows, polyserve, san related root cause.  I attempted to reboot the nodes that these failed on and recieved the same error, hey a reboot fixes everything under windoze, right ?

I found the only way to correct this was to find the folder where these "reparse points" (junction point or mount point) stem from and to completely delete that folder.  So in the above example I had to delete the folder eamload_data1 under eam (remember to do this on each node that has a problem).  I then assigned the mount point as normal, and all the instances worked fine.

I've seen sporadic issues with mount points in the past, polyserve and non-polyserve.  See a previous point here on how to remove a ghosted mount point...

http://www.lifeasbob.com/2008/03/25/ManuallyRemoveAMountPoint.aspx 

It'll be interesting to see if this happens again or was a "one time" deal.