On what grounds would the lawyers pick it apart? It's really straightforward - if you do this, and it doesn't work, you're on your own.
It doesn't speak to any other use cases, and it doesn't necessarily pick on any particular third party. Kurt On Thu, Jul 22, 2010 at 14:43, Michael B. Smith <mich...@smithcons.com> wrote: > > Ah...but if MSFT says "I don't support this specific particular use case" > then people will take that WORD FOR WORD. Lawyers will pick it apart. > > I don't like it either - but I understand why they do it. It's a balancing > act, like so many other things. > > Regards, > > Michael B. Smith > Consultant and Exchange MVP > http://TheEssentialExchange.com > > > -----Original Message----- > From: Kurt Buff [mailto:kurt.b...@gmail.com] > Sent: Thursday, July 22, 2010 5:27 PM > To: MS-Exchange Admin Issues > Subject: Re: Guidance on disks for Exchange 2010 > > On Thu, Jul 22, 2010 at 10:34, Michael B. Smith <mich...@smithcons.com> wrote: > > Microsoft is not in the business of supporting third party storage > > systems. :-P > > True, but they could explain the use case that is offending, couldn't they? > > > If you call PSS and complain "Exchange is slow" and it's because every > > time a new block is written to the database and this causes the > > database to expand, the thinly-provisioned disk institutes a 100 ms > > delay to allocate that additional storage, why would you expect Microsoft > > to support that? > > See - that wasn't so hard to describe, was it? A simple thing like that is > *not* out of their reach. > > > Regards, > > > > Michael B. Smith > > Consultant and Exchange MVP > > http://TheEssentialExchange.com > > > > > > -----Original Message----- > > From: Kurt Buff [mailto:kurt.b...@gmail.com] > > Sent: Thursday, July 22, 2010 1:28 PM > > To: MS-Exchange Admin Issues > > Subject: Re: Guidance on disks for Exchange 2010 > > > > So, if I host my Exchange DB on a Lefthand that is thin provisioned, that's > > unsupported? > > > > Or, continuing on my Lefthand example, I've shut down the VM, expanded the > > space allocated to the drive on which the DB resides, then use diskpart to > > expand the partition to the size of the allocated disk - this isn't > > supported? > > > > It's so very vague... > > > > Kurt > > > > On Thu, Jul 22, 2010 at 09:01, Michael B. Smith <mich...@smithcons.com> > > wrote: > >> Note: I am not recommending you go against published guidance from MSFT. > >> > >> > >> > >> That being said – that recommendation is primarily against the > >> original Hyper-V. VHDs created by the original version of Hyper-V, or > >> disks that have been upgraded from Virtual Server or Virtual PC, expand > >> quite slowly. > >> > >> > >> > >> Disks that are created by Hyper-V R2 are only a couple of percentage > >> points slower than fixed size VHDs. Negligible. > >> > >> > >> > >> I know a number of companies that are running Hyper-V R2 > >> installations with variable disks. So far, at least, it hasn’t been an > >> issue. > >> > >> > >> > >> I don’t know how (or even if) this impacts VMware or XenServer. > >> > >> > >> > >> So….to tie this back to your question, if the storage virtualization > >> causes Exchange to notice whenever the disk expands, it’s not a good fit. > >> > >> > >> > >> Regards, > >> > >> > >> > >> Michael B. Smith > >> > >> Consultant and Exchange MVP > >> > >> http://TheEssentialExchange.com > >> > >> > >> > >> From: Sobey, Richard A [mailto:r.so...@imperial.ac.uk] > >> Sent: Thursday, July 22, 2010 6:35 AM > >> To: MS-Exchange Admin Issues > >> Subject: Guidance on disks for Exchange 2010 > >> > >> > >> > >> In the virtualisation guide for Exchange 2010, in the section on > >> storage this is written: > >> > >> > >> > >> Virtual disks that dynamically expand aren't supported by Exchange. > >> > >> > >> > >> Does anyone know if this also applies to a disk presented to a > >> physical server via some form of storage virtualisation appliance? > >> Said disk would be presented as 100GB, for example, and the OS would > >> see 100GB, but would grow to reach this size at the storage level. > >> > >> > >> > >> Thanks > >> > >> > >> > >> Richard > >> > >> > > > > > > > >
