Here’s something that seems to keep coming up, but not frequently enough for me to write a blog post about until now:
You should not install SQL Server from a mounted ISO file. Instead, you should extract the contents of the ISO file first before installing it.
In June 2019 I tweeted:
[…] some ISO files need to be extracted to install the software that’s on them. Mounting them as a virtual device doesn’t always work.
In the old days, software used to be distributed on physical media like diskette, CD, and finally DVD. Nowadays we download and install software as standalone files. Even enterprise software like SQL Server is available for download in this way, usually distributed as an ISO file. Once you’ve downloaded it, you can mount that ISO file as a virtual drive and access it as though it was on physical media.
Or you can do the right and proper thing, and extract the ISO file to local storage first, using a tool like 7-Zip.
In my professional experience, there appears to be a problem with how SQL Server is packaged, which can randomly cause the installation to fail. Either there is a bug in the ISO maker, in the virtual device driver, or in the number of files. I don’t know for sure. It doesn’t seem to matter if you use the built-in feature in Windows Explorer (also known as File Explorer), or a third-party ISO mounting tool like Virtual CloneDrive; every so often you will run into an installation problem that is resolved by extracting the ISO and trying the install again from the extracted files.
Perhaps I’ve installed SQL Server so many times that the odds were higher for me to run into this problem, so I hope this heads-up helps someone!
Share your installer woes in the comments below.
Photo by Lucas Myers on Unsplash.
Good to know. I don’t think I’ve had any difficulties with a mounted version but better to be pre-warned and prepared than hit a failure
Have done numerous installations of SQL by mounting iso, never got this issue. Only issue used to be ensuring Sql 2005 files by copying the two cds into Server and Tools folder… But nevertheless interesting observation.
I have sometimes hit problems when installing on a very slow server, and also from a network share.
The main symptom for a failure on a very slow server are messages citing paths that do not exist on the server. It seems to me there may be a routine called by the installer that translates paths in the install media to paths found on the server, and this may be called by a POST or something similar. When Windows runs very slowly it is prone to get interrupts out of order – this can be easily seen on a GUI where a mouse move followed by a click sometimes sees the click as taking place where the mouse was before it got moved.
I have found that increasing the ServicePipeTimeout registry value overcomes most of these issues. It may be that an outstanding POST gets killled/ignored after a period that depends on the ServicePipeTimeout value.
The problem seen when installing from a network share often shows by a message saying that some DLL is corrupted (not always the same DLL). This happens randomly, mostly things work OK but now and again the install fails. I suspect something like a SOS_SCHEDULER_YIELD issue is happening in the middle of a read from the ISO, and this upsets the installer.
I get around this by also having the latest SP (where relevant) and CU downloaded, and using the PCUSource and CUSOURCE parameters on the install. These force the installer to build a local slipstreamed copy of the install media, which overcomes any IO issues with a network share or mounted ISO.
Comments are closed.